Travel platform (source: Unsplash)

After years of helping travel businesses build and scale booking platforms, mobile travel applications, and digital travel ecosystems, I’ve noticed a recurring pattern: most travel platforms don’t struggle during peak seasons because of traffic alone. More often, the root cause lies in architectural decisions made long before the first surge in demand.

A platform may perform flawlessly under normal conditions for most of the year. However, when seasonal events drive a sudden increase in user activity, hidden scalability issues quickly surface. Search performance degrades, third-party integrations become unstable, booking confirmations slow down, and customer experience suffers.

In our experience, peak seasons rarely create problems; they simply expose the weaknesses that already exist within a platform’s architecture. Understanding these challenges is the first step toward building travel systems that can scale reliably as demand grows.

The real scaling challenges in travel platforms

01. Search traffic grows much faster than booking volume

One of the most overlooked realities of travel platforms is that search traffic scales much faster than actual bookings. Before making a purchase, travelers typically compare multiple destinations, departure dates, hotels, room types, and flight options. As a result, a single booking may generate dozens, or even hundreds, of search requests.

This means the search layer often becomes the first bottleneck during peak seasons. If the platform relies heavily on real-time queries to databases or third-party suppliers, response times can increase dramatically as traffic surges.

The result is slower search experiences, higher bounce rates, and ultimately lost bookings before users even reach the checkout stage.

02. Heavy dependence on third-party travel APIs

Unlike many digital products, travel platforms rarely operate in isolation. They depend on a complex ecosystem of external providers, including GDSs, hotel wholesalers, payment gateways, airline systems, PMSs, and channel managers.

During high-demand periods, these third-party services may experience rate limits, slower response times, or temporary outages. Even if a platform’s own infrastructure remains stable, performance can still be affected by external dependencies.

This creates a unique scalability challenge: the platform’s reliability is only as strong as the weakest integration in its ecosystem.

03. Real-time inventory synchronization

Travel inventory is highly dynamic. Hotel rooms, airline seats, tour slots, and transportation availability can change within seconds, especially during peak booking periods.

As traffic increases, multiple users may attempt to book the same inventory simultaneously. Without proper synchronization mechanisms, platforms can encounter issues such as overselling, duplicate bookings, or inaccurate availability displays.

Maintaining inventory consistency while supporting thousands of concurrent transactions requires far more sophisticated architecture than traditional content-driven applications.

How modern travel platforms scale

Leading travel platforms do not scale by simply adding more servers. Instead, they redesign their architecture to handle the unique characteristics of travel workloads.

01. Decoupling search from booking

In many legacy systems, search requests, bookings, payments, and customer data all rely on the same database. As traffic grows, search queries consume a significant portion of system resources and impact transactional operations.

Modern travel platforms typically use dedicated search infrastructure, such as Elasticsearch, OpenSearch, or Redis-powered caching layers, to handle large search volumes independently. This ensures that even during peak seasons, users can search smoothly without affecting booking performance.

02. Leverage event-driven architecture

Rather than processing interconnected processes (booking confirmations, payment, inventory updates, notifications, loyalty programs, analytics) synchronously, modern systems use event-driven architecture with technologies such as Kafka, RabbitMQ, or cloud messaging services. When a booking is completed, an event is published, and downstream services process their tasks independently.

This approach reduces system bottlenecks, improves resilience, and allows the platform to handle significantly higher transaction volumes.

03. Implementing intelligent caching

Not every request requires real-time processing. Destination pages, hotel information, popular search results, and travel content often change less frequently than booking transactions.

To reduce pressure on databases and third-party APIs, scalable travel platforms leverage multiple caching layers, including CDN caching, application caching, and distributed caching technologies such as Redis. This allows the system to serve frequently requested content with minimal latency while reducing infrastructure costs.

What does this mean when building a travel software platform

As travel businesses grow, they are not only serving more users. They are managing more searches, more inventory updates, more supplier integrations, more personalization, and more operational dependencies. Each layer adds new challenges that cannot be solved by infrastructure alone.

The travel platforms that thrive during peak seasons are rarely the ones with the largest engineering teams. They are the ones who anticipate growth early and build architectures designed for change.

In our experience, peak seasons don’t create scalability problems; they reveal them. The sooner travel companies recognize this, the better prepared they will be for sustainable growth in an increasingly competitive market.

A few weeks ago I caught one of our senior engineers staring at a 200-line idempotency validation module like it had personally insulted him. He had spent the morning trying to ship a feature, and this module kept rejecting his test bookings because of an edge case he had not anticipated. He turned to me and said, half-joking, “I want to delete this whole file.”

I told him I have wanted to delete that file at least three times this year. So has every senior engineer on the team. We never have. We never will. And the reason we keep wanting to is the entire point of this essay.

There is a layer in mature engineering systems that I have started calling the Boring Layer. It is the unglamorous infrastructure that protects you from your own mistakes, from your customers’ mistakes, from your suppliers’ mistakes, and from the universe’s general tendency toward entropy. Idempotency keys. Validation pipelines. Observability instrumentation. Circuit breakers. Retry budgets. The Boring Layer.

Every team I have worked with eventually realizes they need it. Most teams under-invest in it for years before admitting that. And nearly every team, once it is built, periodically tries to delete it.

This essay is about why.

The shape of the Boring Layer

Before getting into the leadership pattern, let me describe what I mean concretely.

If you map our booking platform’s components by how often each one gets touched in active feature development versus how often it gets touched in production incidents, you get a clean inversion. The features people are excited to build (recommendations, conversational booking, dynamic pricing) are touched constantly during development and rarely during incidents. The Boring Layer (deduplication, validation, retry logic, observability) is barely touched during development and shows up in nearly every incident postmortem.

The Boring Layer’s job is to be invisible when things work and indispensable when they do not. That is its actual function: a system that lives quietly underneath everything and absorbs the failure modes you did not predict.

A non-exhaustive inventory of what lives in the Boring Layer:

• Request idempotency keys that prevent duplicate bookings when a user clicks twice

• Cross-service trace context propagation so you can debug a failure six services deep

• Validation pipelines that catch bad parameters at the boundary instead of letting them reach external APIs

• Hallucination guards that block LLM-generated facts that are not supported by source data

• Rate limiters that protect downstream services from your own retry storms

• Tail-based sampling logic that decides which traces are worth keeping

• Schema versioning that lets you change inventory formats without breaking downstream consumers

• Circuit breakers that fail fast when a supplier API is down instead of cascading failure

If you have built a production system at any reasonable scale, you have written some of these. If you have not built them, you are accumulating debt that will become visible the first time something fails in a way you did not predict.

Why the Boring Layer is constantly under threat

Here is the thing that took me years to understand: the Boring Layer is not just under-invested in. It is actively under attack, often by the same people who built it.

Three forces work against it:

Force 1: It feels like it is not doing anything. When the Boring Layer works correctly, you cannot see it. There is no flashy metric. There is no demo to show stakeholders. The dashboard for “duplicate bookings prevented” reads zero, because the Boring Layer prevented them all. To a casual observer (or a junior engineer, or an impatient PM), the system looks like it is doing nothing. It is doing everything. That is the problem.

Force 2: It slows down the part of work that feels productive. Every feature ticket has to engage with the Boring Layer at some point. The new endpoint needs idempotency. The new tool call needs validation. The new service needs trace propagation. Each of these is a 30-minute task at minimum, and it does not produce visible feature progress. If your engineers are measured on shipped features, the Boring Layer is exactly the thing they will resent.

Force 3: Its failure modes are slow and silent. The Boring Layer protects against problems that compound. A duplicate booking today is one customer complaint. A duplicate booking that goes undetected for six months because there was no idempotency check is a class-action lawsuit risk. The pain is asymmetric in time. Skipping the Boring Layer feels free this quarter and catastrophic in two years. Most engineering organizations are structured to optimize for this quarter.

Combined, these three forces mean that the Boring Layer is constantly being questioned, deprioritized, or actively dismantled by teams that need to ship faster. I have watched promising young companies enter a death spiral that started with “we don’t need all this defensive code, it’s slowing us down.”

The leadership pattern I have settled on

After enough years of watching this dynamic play out, I have settled on a few principles for protecting the Boring Layer without becoming the engineering equivalent of a building inspector.

Make the Boring Layer’s value visible without making it the focus. When something fails in production and the Boring Layer caught it, write that up in the postmortem with explicit attribution: “the validation layer rejected this request before it reached Stripe; without that check, we would have charged the customer twice.” This is not chest-thumping. It is calibration. Engineers who only see the Boring Layer when it gets in their way will resent it. Engineers who also see it catching real failures develop an appreciation for it.

Treat Boring Layer work as feature work, not as overhead. When we estimate stories, the Boring Layer touch points get explicit time. “Add idempotency: 4 hours. Add tracing instrumentation: 2 hours. Add validation: 3 hours.” This makes the cost legible to PMs and engineers, and it removes the temptation to skip it under pressure. The thing that does not appear on the estimate is the thing that gets cut.

Resist the temptation to “simplify” the Boring Layer. A senior engineer will eventually look at a piece of the Boring Layer and propose a simpler version. Sometimes they are right. Often they are looking at the simplified version of a system that learned its complexity through painful production lessons. Before approving any simplification, ask: “what was the bug that caused the original implementation to be this way?” If nobody on the team can answer, that is a sign you are about to remove a load-bearing wall.

Make the Boring Layer look as good as the rest of the codebase. Bad Boring Layer code gets deleted. Good Boring Layer code survives. Refactors, tests, documentation, naming. This part of the codebase deserves the same craftsmanship as the customer-facing features. The fact that it is not visible to users is not a license to half-ass it.

Protect the people who maintain it. Some engineers are temperamentally drawn to defensive engineering. They like the puzzle of “what could go wrong here?” These engineers are gold. They get bored on flashy feature work and shine on idempotency and validation. Build their careers around this. Promote them based on incidents prevented, not features shipped.

The deletion impulse never fully goes away

This is the part I want to be honest about: even on a mature team that has felt the pain of insufficient defensive engineering, the impulse to delete the Boring Layer never fully goes away.

Last quarter we had a sprint where everything we tried to ship got blocked or slowed by some piece of validation, retry logic, or observability instrumentation. By Friday, two of our most experienced engineers were openly proposing that we rip out our hallucination validation pipeline because it was rejecting too many “obviously fine” responses from the LLM and forcing regenerations.

They were not wrong that the pipeline was being annoying. They were wrong that it should be deleted.

The conversation we had instead: what is the false-positive rate, what is the false-negative rate, what would happen if we tuned the threshold instead of removing the pipeline, what is the cost of a hallucinated booking detail reaching a customer versus the cost of a regeneration? We tuned the threshold. The annoyance dropped. The pipeline stayed.

This is the loop I have started to expect. Periodically, smart engineers under pressure will propose removing a piece of the Boring Layer because it is in their way today. The right response is not to defend the layer reflexively. It is to engage with the specific complaint, distinguish “this is poorly tuned” from “this is no longer needed,” and adjust accordingly. Most of the time, the answer is tuning. Some of the time, the answer is genuine deletion (the system has evolved past the original need). Rarely, the answer is “yes, this is critical, do not touch it.” All three answers require taking the complaint seriously rather than dismissing it.

Why this matters more in the AI era

A footnote that turned out to be the most important part of this essay.

When I started thinking about the Boring Layer, I was thinking about traditional distributed systems: idempotency, retries, validation, tracing. Standard SRE-flavored stuff.

The arrival of LLM-based features has dramatically expanded what lives in the Boring Layer. Hallucination validation pipelines. Tool-use call deduplication. Cost circuit breakers that prevent runaway agent loops. Confidence thresholds for autonomous actions. Memory architectures that prevent context drift across sessions.

Every one of these is a new layer of defensive engineering that LLM features need but their developers tend to under-invest in. The classic mistake is shipping a system that works on the demo path and discovering in production that it loops forever, hallucinates prices, or spends $50,000 in API calls before anyone notices.

There is now an entire generation of “AI features” being built without an AI Boring Layer underneath them. The companies that will win the next phase of LLM-powered software are not the ones with the most clever prompts. They are the ones whose AI Boring Layer is robust enough that the clever stuff can fail safely.

If you are leading an engineering team that ships AI features, the leverage right now is not in the model or the prompt. It is in everything underneath. The validation pipelines, the cost ceilings, the deduplication, the confidence thresholds. The Boring Layer for AI is being figured out in real time by every team that has hit a production incident and realized that “the model did something weird” is not a usable explanation for an angry customer.

What I tell new senior engineers

When I onboard a senior engineer to our team, one of the first things I tell them is: the most important code you will write here is code you will never demo. It will not impress anyone in a sprint review. It will not show up on your performance evaluation as a flashy launch. It will quietly prevent disasters that nobody will ever know about, and your reward will be that you sleep at night.

Some engineers hear that and visibly relax. They are the ones I want owning the Boring Layer.

Some engineers hear that and look concerned. That is fine too. They are probably better suited to the customer-facing parts of the codebase, and we need those people too. But they should know that the senior engineer building idempotency keys is not doing junior work. They are doing some of the most consequential work in the company. They just do not get to brag about it on Twitter.

A final thought on the deletion impulse

I started this essay with the engineer who wanted to delete the idempotency validation file. I want to come back to him.

He did not delete it. We talked through the edge case he was hitting, found that it was a legitimate gap in the validation logic (not a problem with the validation existing), fixed it, and moved on. He told me later that he was actually glad we had the file, because the edge case he found would have been a serious bug in production.

This is the version of the Boring Layer’s value that I think gets missed. It is not just protection against failure. It is a forcing function for thinking carefully about edge cases. Building defensive infrastructure is a way of compressing institutional learning into code. Every weird edge case that ever happened in production becomes a check in the validation pipeline. Every supplier API quirk becomes a normalization rule. Every category of LLM hallucination becomes a check in the validation layer.

A team without a Boring Layer has to remember its lessons. A team with a Boring Layer has its lessons baked into the system. The first kind of team forgets things over time. The second kind compounds knowledge.

If you are leading an engineering team and you have not invested in your Boring Layer, this is the leverage. Not the next feature. The infrastructure underneath the next feature.

I’m CTO at Adamo Software. I write occasionally about engineering leadership, AI tooling infrastructure, and what I learn running software delivery for international clients out of Vietnam.

Every developer using AI coding assistants seriously hits the same wall eventually: the AI keeps making the same mistakes you’ve already corrected. Hydration bugs you fixed last month. JWT config you debugged for hours. Architectural decisions you carefully made and explained. All gone the next session.

I spent the past few weeks designing a memory architecture to solve this for our team’s Claude Code workflow. The thinking process turned out to be more interesting than the final artifact. What follows is the full reasoning: what I tried, what failed, and the principles that ended up working.

If you’re using AI coding tools on anything bigger than a weekend project, this is worth your time.

The real problem isn’t memory. It’s compounding.

Most people frame this as “AI doesn’t have memory between sessions.” That’s the symptom, not the problem.

The actual problem is that knowledge doesn’t compound. A senior engineer doesn’t just remember bugs. They recognize patterns. Same symptom, different surface. Same root cause, different stack trace. That pattern recognition is what separates a five-year engineer from a one-year engineer doing the same task five times.

If your AI assistant can’t compound knowledge across sessions, it permanently operates at “fresh hire on day one” level. Forever.

There’s a useful analogy here from how teams actually scale. When a senior engineer leaves, the cost isn’t the lines of code they wrote. It’s the unwritten knowledge: the bugs they remember, the architectural choices they made and the reasons behind them, the gotchas in the data pipeline that aren’t documented anywhere. Onboarding a new hire takes weeks not because reading code is hard, but because compounding knowledge takes time to transfer.

Your AI assistant is in a permanent state of pre-onboarding. Every session.

The math gets ugly fast. If a typical mid-sized client project takes six months and produces, say, 200 reusable lessons that a senior engineer would internalize, your AI is fundamentally re-debugging the same 200 issues across 100+ sessions. Multiply that across multiple concurrent projects in an IT services context, and you’re looking at thousands of repeated bug classes per quarter, every one of them billable hours that compound nothing.

My first instinct was wrong

My initial design: one big Learnings.md file. Every time I solve something tricky, append it. Load it at session start.

It looks clean. It works for two weeks. Then it falls apart for three reasons.

Token cost. A 5,000-line learnings file loaded at every session means I’m burning context on 4,900 lines that have nothing to do with my current task. Modern models have generous context windows, but the relationship between context size and reasoning quality isn’t linear. More noise in context degrades output, and you’re paying API costs on every wasted token.

Signal-to-noise. The more I capture, the harder it gets to find the right lesson. Paradoxically, a more “complete” knowledge base becomes less useful. This is the same reason most internal wikis fail: not because they’re too sparse, but because once they cross a complexity threshold, finding the right entry costs more than re-deriving the answer.

Internal contradictions. Six months in, you have lessons that conflict. “Use pattern A” on line 200, “stop using pattern A” on line 1,800. Which is current? The AI doesn’t know. And it has no mechanism to resolve precedence: both lessons are equally weighted, equally available.

This is why most “auto-memory” systems people build degrade after two to three months. The structure can’t hold up.

The architectural shift that fixed it

Three principles changed the design.

1. Progressive disclosure. Don’t load everything. Load an index. Let the index route to the specific lesson needed for the current task.

This is the same principle behind how humans use reference material. You don’t memorize an entire codebase to make a change. You grep for the relevant function, read the surrounding 50 lines, and act. Your AI’s knowledge architecture should work the same way: a tiny, always-loaded index that knows what exists; full content loaded only when relevance is established.

In practice: a 50-line _index.md file at session start, with cards loaded individually only when the recall phase identifies a match. We cap loaded cards at five per session. Token cost stays nearly flat regardless of how big the knowledge base grows.

2. Symptom-first indexing, not topic-first. This was the single highest-leverage decision in the whole design.

Bugs recur at the symptom level, not the topic level. A developer hitting “Hydration mismatch” in the console searches for “hydration mismatch”, not for “Next.js rendering patterns.” If your index is organized by topic, the developer (or the AI) won’t find the right lesson even when it exists.

We tag every lesson with a symptom: prefix containing the literal error message keyword or observable behavior:

• symptom:hydration-mismatch

• symptom:401-cross-service

• symptom:json-malformed-with-fence

• symptom:agent-loops-forever

When the AI hits a symptom in the current session, the recall phase matches on these tags first, before falling back to topic tags. The match rate jumped dramatically once we made this change. In the topic-only version of the system, recall was finding relevant lessons maybe 40% of the time. After symptom-first tagging, that climbed to around 80% on bugs that had been previously captured.

3. Confidence + lifecycle, not append-only. Lessons should have a confidence score that moves over time. A lesson contradicted by new evidence loses confidence. A lesson unused for 90 days gets archived, not deleted. Hard-deleting loses history; never-archiving creates noise.

This was the hardest principle to internalize. My first design had no concept of stale knowledge. Everything captured stayed forever, equally weighted. That’s not how human memory works, and it’s not how a knowledge system should work either.

We use a 0.0 to 0.9 confidence range. New lessons start at 0.5 (bug fix), 0.7 (user correction), or 0.3 (retrospective). Confirmed-useful lessons go up; contradicted lessons go down. At 0.0, the lesson moves to an archive folder, still findable but excluded from normal recall.

The override I had to add: human-confirmed capture

The best existing pattern I studied uses auto-capture: when the AI detects a lesson worth keeping, it writes to disk automatically.

I rejected this for one reason: AI auto-capture overproduces noise.

When Claude Code decides “this is worth capturing,” it’s right maybe 60% of the time. The other 40% is: things that look like patterns but aren’t, things that are obvious framework behavior, things that are too session-specific to generalize. Auto-write means your lessons/ folder fills up with mediocre cards, and the high-quality ones get drowned.

So I changed it: every capture shows me the proposed card and asks y/n/edit. Three keystrokes. The friction is intentional. It forces a moment of “is this actually a lesson, or am I just feeling productive?”

After two weeks of use, my reject rate settled around 30%. That’s 30% of noise I’d otherwise be carrying. Compounded over six months, the difference between a curated knowledge base and an auto-captured one is roughly the difference between a usable tool and an unusable one.

A note on this: friction is usually treated as bad UX, but here it’s load-bearing. Every confirmation step is also a learning moment for the human. You start recognizing what counts as a real lesson versus what doesn’t, which improves your capture intuition over time. Auto-capture removes that feedback loop entirely.

What separates a “lesson” from “a thing that happened”

Designing the capture criteria forced me to articulate something I’d never written down. A real lesson has all four:

• A trigger I can recognize next time (the symptom)

• A root cause different from what the symptom suggests

• A prevention rule specific enough to apply, general enough to reuse

• A detection signal I can check before the bug bites

If a “lesson” is missing any of these, it’s just a war story. Useful for retrospectives, useless for future debugging.

This rubric alone has changed how I write commit messages and PR descriptions, even outside the AI context. It’s also become a useful frame for PR reviews. When reviewing someone else’s fix for a non-trivial bug, asking “what’s the trigger / root cause / prevention rule / detection signal?” surfaces a category of issues that get fixed in the immediate code but never captured as institutional knowledge.

Most “lessons learned” documents in engineering teams fail this test. They describe what happened (war story), not how to recognize it next time (lesson). The two look similar on paper. They’re completely different in utility.

What I’d do differently if I started over

A few things I’d front-load instead of discovering through use.

Symptom tags are the whole game. I almost designed this skill with topic-only tags. That would have failed silently. The cards would exist, recall just wouldn’t find them. Symptom-first tagging was the single highest-leverage decision. If you build something like this, start there, not with the storage format or the confidence math.

Empty is the right starting state. Don’t seed the system with example lessons. Empty cards from real bugs are worth more than 20 plausible-looking seeded ones. The latter creates phantom patterns the AI starts pattern-matching against. We seeded our first version with five “common Next.js issues” cards we wrote up from memory, and within a week the AI was confidently applying lessons to situations that didn’t quite fit, because the seeds were too generic.

Consolidation isn’t optional. I originally designed this without a quarterly cleanup phase. Within a month I had near-duplicate cards, conflicting cards, and stale cards. Periodic consolidation isn’t a “nice to have”. It’s the difference between a knowledge system that compounds and one that decays.

The consolidation pass takes about 30 minutes per quarter for a project. You read through the cards, merge duplicates, archive things that no longer apply, surface conflicts for explicit resolution. Tiny investment. Massive impact on signal quality.

Treat the index as a product, not a side effect. The auto-generated _index.md is what determines whether recall actually works. Spending time on its structure (column ordering, sorting logic, whether to include symptom tags inline) has more impact on system quality than anything in the cards themselves.

Why this compounds harder for IT services than for product teams

There’s a non-obvious second-order effect worth naming, especially for anyone running engineering at an IT services firm or agency.

For a product team, a memory architecture compounds knowledge within one codebase. Useful, but bounded.

For a services firm running multiple concurrent client engagements, the same architecture compounds across clients, even when their stacks differ. Why? Because symptom patterns repeat across stacks. The shape of “JWT misconfigured between services” looks structurally identical whether the stack is .NET + FastAPI, Node + Go, or Python + Java. The symptom tag matches; the lesson applies; the engineer ramps faster on a problem they’ve technically never seen before.

We’re seeing this play out across our client work. A lesson captured during a Next.js engagement transfers cleanly to a Vue project six weeks later, because the underlying symptom (hydration-style mismatch from runtime values in initial render) is framework-agnostic. The .NET-FastAPI lesson on env var naming applies to literally any cross-service auth setup.

This means the leverage isn’t linear in the number of projects. It’s roughly quadratic. Lesson density per project × number of projects × cross-applicability rate. For a five-engagement portfolio, that compounds into a body of institutional knowledge that’s worth real money in won deals and reduced delivery risk.

I haven’t seen this written about anywhere. The “AI memory” conversation is dominated by product-team perspectives, where the framing is about a single product’s lifecycle. The services-firm angle is structurally different and, I’d argue, where the highest leverage actually lives.

The broader lesson about building with AI

The thing I keep coming back to: AI tools don’t fail because they’re not smart enough. They fail because their environment doesn’t compound.

We obsess over prompts, models, context windows. There’s a whole content economy around prompt engineering tips and “the best Claude prompts” listicles. But the highest-leverage work is often the boring infrastructure underneath: how knowledge persists, how it gets retrieved, how it ages out, how it gets validated.

A mediocre AI with a great memory architecture will outperform a great AI with no memory architecture, on any long-running project. The compounding curve is just that powerful.

The model improvements you’re going to see over the next two years will be incremental. The infrastructure improvements you build into your AI workflow can be exponential. Engineering leaders should be spending at least as much time thinking about the second category as the first.

Where to start

If this resonates and you want to build something similar, start small.

Add a docs/lessons/ folder to your most active project. Don’t worry about the skill framework or the validation rules yet. Just commit to capturing lessons in a structured format (the four-part rubric is a fine starting point) and tagging them with symptom keywords from the actual error messages.

Manually load relevant cards into your AI assistant’s context when starting a related task. Yes, manually. The automation comes later. The discipline of recall, actually pulling up past lessons and feeding them to the AI before asking for help, is what builds the muscle. Once you’ve felt the difference between a session with relevant lessons loaded and one without, the rest of the architecture starts designing itself.

After a month, you’ll have between 15 and 40 cards, a clear sense of which symptom tags are actually useful, and enough operational experience to know what to automate. Then invest in tooling.

Most knowledge systems fail because they’re designed before the team has any data on what they actually need. Build the messy, manual version first. Let the structure emerge from real use.

If you’re leading engineering at scale and haven’t built a memory architecture around your AI tooling yet, that’s where the leverage is. Not in the model. Not in the prompt. In the infrastructure underneath.

I’d be curious to hear what other teams are building in this space. The pattern feels under-discussed for how high-leverage it is. If you’re working on something similar, or if you’ve tried and hit different walls than the ones I described, I’d genuinely like to compare notes.

I'm CTO at Adamo Software. I write occasionally about engineering leadership, AI tooling infrastructure, and what I learn running software delivery for international clients out of Vietnam.

Every travel startup that has walked into our office in the past eighteen months has a version of the same pitch. An AI concierge. Personalized itineraries. Natural language trip planning. Conversational booking.

And every one of them, without exception, has shown me a demo where they type “plan me a 5-day trip to Japan” into a chat box and watch GPT-4 generate a plausible-looking itinerary.

I have stopped being polite about this. The AI trip planner is the most over-indexed feature in travel tech right now, and almost nobody has figured out how to make it convert into revenue. I have watched teams spend six to twelve months building sophisticated AI planners, launch them, and discover that their users use the feature once, enjoy it, and then never book anything.

I want to write about why this keeps happening, what we have seen actually work across the travel platforms we have built, and what I now tell founders when they come to us with an AI itinerary idea.

The demo is not the product

Here is what a travel AI demo looks like:

User types a fuzzy request. Model generates a beautiful multi-day itinerary with restaurant recommendations, transit notes, and curated experiences. Founder gets excited. Investor gets excited. Article gets written in TechCrunch.

Here is what the product experience looks like four weeks after launch:

User types a fuzzy request. Model generates a beautiful itinerary. User reads it. User thinks “cool.” User closes the tab. User books their actual trip on Booking.com, Agoda, or Expedia because those places have prices, availability, photos they trust, reviews they trust, and a cancellation policy they understand.

The gap between these two experiences is where most AI travel products die. The demo optimizes for “wow, the AI is smart.” The product needs to optimize for “I am about to spend $3,000 and I need to be sure.”

These are not the same problem. Being impressive and being trustworthy are actually in tension. A confident AI narrator telling you about the “hidden gems” of Kyoto feels magical in a demo and vaguely sketchy when you are about to book non-refundable tickets.

What we have actually seen work

Across the travel platforms we have built in the last few years, including B2B aggregators handling 2M+ hotel properties, sports travel platforms serving 65K events across 240 cities, and several direct-to-consumer booking engines, the AI features that show up in retention data are not the ones founders expect.

The three that consistently earn their keep:

1. AI for friction removal, not inspiration. The best-performing AI feature we have shipped is not a planner. It is a deal-alert agent that watches prices on specific routes the user cares about and notifies them when something moves. Unsexy. Users love it. Conversion to booking is measurable.

2. AI as a search parser, not a search replacer. Users do not want to chat their way to a hotel. They want to type “beachfront Bali under 3M VND” and see filtered results instantly. We use LLMs to parse natural language into structured search parameters, then hand off to a traditional search UI with maps, photos, and filters. The LLM disappears after parsing. This converts. Full chat-based booking does not.

3. AI for post-booking operations. Re-accommodation during flight disruptions. Dynamic itinerary updates when a tour gets cancelled. Automated refund eligibility checks. These are boring, operational AI uses. They have real ROI because they replace expensive human support work. None of them demo well.

The pattern here is not subtle. AI wins when it removes a specific, repeated friction. AI loses when it tries to replace the trust infrastructure that OTAs have spent twenty years building.

Why founders keep building the wrong thing

I have theories on why this keeps happening.

First, the demo environment is seductive. GPT-4 and Claude can produce incredibly plausible travel content. When you are building the prototype, you are both the developer and the only user. You never test whether you would actually book a $4,000 honeymoon based on your own AI’s recommendation. Your users will.

Second, founders are not representative users. Most travel founders are frequent travelers, comfortable with new tools, willing to experiment. The user who actually drives volume in travel is the once-or-twice-a-year vacation planner who is anxious about spending money and wants social proof, not an AI opinion.

Third, there is a category error about what AI is good at. LLMs are excellent at generating plausible text. They are not, by default, excellent at making decisions where the user needs to feel certain. Travel booking is a high-certainty purchase. People read reviews for hours. They cross-reference. They are not looking for a confident narrator.

Fourth, the VC narrative rewards AI-forward pitches right now. If you raise a round by waving around an AI trip planner demo, you are incentivized to keep building that thing even when your retention data is screaming at you to pivot.

What I tell founders now

When a travel founder comes to us with an AI planner idea, I ask two questions before we talk architecture.

“What does conversion look like, and how do you know the AI caused it?”

Most cannot answer this. They have DAU numbers. They have session length. They do not have a clean funnel from AI interaction to booking revenue, and they have not thought about what attribution would look like. If you cannot articulate how the AI feature drives measurable revenue, you are building a toy.

“If you removed the AI tomorrow, which users would complain?”

This is the sharper question. For the best features we have built, the answer is clear and small: “the users who use our price alerts” or “the travel agents who use our itinerary parser to save time.” For failed AI features, the answer is “nobody, really.”

If nobody will complain when the AI goes away, you did not build a product feature. You built a marketing asset.

The honest middle path

I am not saying AI has no place in travel tech. It clearly does. We have shipped AI components in travel platforms that I believe in and that drive real outcomes.

I am saying the conversational AI trip planner, the thing most founders are building, is the least interesting and least defensible use of AI in this industry. The interesting work is in the operational layer: pricing intelligence, disruption management, fraud detection, personalization inside traditional UIs, dynamic packaging that responds to supplier inventory signals in real time.

None of these demo well on stage. All of them affect revenue.

If you are thinking about building an AI travel product, my suggestion is to start by mapping where your users currently experience the most friction. Not where you think AI would be cool. Where real money or real time is being lost to a broken workflow. Build the AI there.

That is where the customers who will pay you actually live.

I have spent the last two years leading engineering at Adamo Software, building AI-powered features for travel platforms. Recommendation engines, conversational booking assistants, dynamic pricing models, predictive disruption alerts. Some of them worked. Some of them did not. The ones that failed had one thing in common: they were solving a problem that sounded impressive in a pitch deck but did not exist in the user's actual experience.

This is not a product management problem. It is an engineering leadership problem. When a CTO greenlights an AI feature without interrogating whether the underlying system even needs intelligence, the team spends months building something sophisticated on top of something broken.

The pattern I keep seeing

A travel company wants “AI-powered search.” The pitch is compelling: travelers type natural language queries, the AI understands intent, and results are personalized in real time. The demo looks incredible.

Then you look at the actual search infrastructure. The database is not indexed for the queries users actually make. Availability data is cached for 30 minutes, so results are frequently stale. Filters do not work properly on mobile. The search is slow not because it lacks intelligence, but because the underlying data pipeline was never optimized for speed.

Adding an LLM on top of this does not make search better. It makes it more expensive and harder to debug. The AI generates beautiful natural language responses based on stale inventory data. The user sees a recommended hotel, clicks through, and discovers it is sold out. The experience is worse than a simple filter-based search that at least shows accurate availability.

I have seen this pattern three times in the last year alone. Each time, the fix was not more AI. It was fixing the data layer underneath.

Where AI actually moves the needle in travel

This is not an argument against AI in travel. It is an argument for precision about where AI creates value versus where it creates complexity.

After building and measuring AI features across multiple travel platforms, these are the three areas where AI consistently delivers measurable impact.

Dynamic pricing. Hotel and flight pricing involves hundreds of variables: demand patterns, competitor rates, local events, weather, booking pace, cancellation rates. No human revenue manager can process all of these signals simultaneously and update rates across 6 OTA channels in real time. AI pricing engines can. The platforms we have worked on report 7-12% revenue uplift after deploying AI-driven dynamic pricing. This is the clearest ROI case for AI in travel because the problem is genuinely too complex for manual solutions.

Disruption management. When a flight is cancelled, the traveler needs rebooking options immediately. The system needs to check alternative flights, hotel availability near the new departure point, ground transport options, and the traveler’s preferences, all within seconds. An AI agent that can query multiple systems, evaluate tradeoffs, and present a rebooking plan is solving a real problem that cannot be solved with a static rule engine. The key difference from the search example: disruption management involves genuine multi-step reasoning under time pressure with incomplete information. That is exactly what LLMs are good at.

Post-booking personalization. Not recommendation engines on the homepage. Those rarely move conversion in meaningful ways. What works is personalization after the traveler has already booked: suggesting restaurants near their hotel based on their dining preferences, alerting them about events happening during their stay, offering upgrade options at the right moment. This works because the system has rich context (confirmed dates, destination, traveler history) and the suggestions are actionable, not speculative.

Where teams waste months

And these are the areas where I see engineering teams burn quarters of work for minimal return.

AI-powered search on broken data. As described above. If your availability data is stale, your filters are broken, or your database is not indexed for the queries users make, adding an LLM layer will not fix the experience. Fix the data first. If search is still a problem after the data layer is solid, then evaluate whether AI adds value.

Chatbots that replace help documentation. A travel company builds a chatbot to answer customer questions. The chatbot is trained on the same FAQ content that was already on the website. Users now get the same answers through a chat interface instead of a help page. The interaction feels more modern, but the resolution rate is identical. Meanwhile, the chatbot hallucinated a cancellation policy twice last month, which the static help page would never do. The problem was never “users cannot get answers.” The problem was “users cannot find the help page.” That is a navigation problem, not an AI problem.

Recommendation engines with no behavioral data. A new travel app launches with an AI recommendation engine. The problem: the app has 3,000 users and minimal booking history. Collaborative filtering needs density to work. Content-based recommendations need well-structured property data. Without either, the “AI recommendations” are essentially random suggestions with a personalization label. A curated editorial list would outperform the algorithm at this stage and cost nothing to maintain.

The question I now ask before greenlighting any AI feature

After enough expensive lessons, I developed a simple filter. Before any AI feature enters our sprint backlog, I ask the engineering lead one question:

If we fixed the non-AI version of this experience, would users still need intelligence?

If the answer is no, we fix the underlying system first. If the answer is yes, we build AI. If the answer is “we don’t know,” we run a two-week experiment with the simplest possible version before committing engineering resources.

This filter has killed about 40% of AI feature proposals in the last year. Every one of them was replaced by a simpler fix that shipped faster and performed better.

What this means for how we build travel platforms

The companies that will win in travel tech over the next three years are not the ones adding AI to every feature. They are the ones building travel and hospitality platforms where the foundational systems, data pipelines, search infrastructure, payment processing, inventory sync, work well enough that AI can amplify them rather than compensate for them.

AI on top of a solid foundation is a multiplier. AI on top of a broken foundation is a distraction with a higher cloud bill.

I will be writing more about the specific engineering decisions behind building travel and enterprise platforms. What worked, what did not, and what I would do differently. If that is useful to you, subscribe and I will send it to your inbox.

When someone books a hotel through a travel platform, the transaction looks simple. The traveler pays, the hotel gets paid, everyone moves on. What actually happens underneath is closer to international wire transfer choreography.

A customer in Germany books a hotel in Vietnam. They pay in euros. The hotel expects Vietnamese dong. Our platform takes a commission in US dollars. That is three currencies moving through a single booking. Multiply that by a thousand bookings a day across twenty countries, and you start to understand why payment infrastructure in travel is a different engineering problem than payment infrastructure in e-commerce.

We learned this through an expensive first month in production. Our team builds custom travel and hospitality software, and payment infrastructure turned out to be the component we most underestimated. Our initial payment system leaked margin on FX spreads, silently failed 14% of European card transactions, and made month-end reconciliation a two-day manual exercise. This is the story of how we rebuilt it.

The problem with “just use Stripe”

Stripe is excellent. We still use it. But “integrate Stripe” is not a payment strategy for travel. It is a starting point that leaves three critical gaps unfilled.

The first gap is currency timing. A traveler searches for a hotel and sees a price in euros. Ten minutes later, they complete the checkout. The exchange rate has moved. The price they saw is no longer the price the platform receives after conversion. Someone absorbs that difference. If it is the platform, margin erodes quietly across thousands of transactions. If it is the customer, they see a different price at checkout than at search, and trust breaks immediately.

The second gap is split payouts. A single tour package booking might involve a hotel, a transport provider, and a local guide. Each expects payment in their own currency. Each has different payment terms. Hotels want payment within 48 hours of checkout. Guides might accept weekly batch transfers. The platform needs to hold funds, convert at the right moment, and pay each supplier on their terms while keeping its own books clean.

The third gap is European authentication. Strong Customer Authentication (SCA) is mandatory in the EEA and UK. If the checkout does not handle 3D Secure properly, European card transactions fail without any visible error. The customer simply sees “payment declined” and leaves. We lost 14% of European transactions before we understood this.

The decision that saved us the most money

We evaluated three approaches to currency conversion. The first was converting everything to USD at payment time. Simple to build, but the customer sees price fluctuations between search and checkout. The second was displaying in local currency, charging in local currency, and settling in USD. Better experience, but the platform absorbs the FX spread on every transaction. The third was locking the exchange rate when the user starts a search session, adding a small margin buffer, and holding that rate through checkout.

We chose the third approach. When a traveler begins searching, we lock the current exchange rate with a 1.5% buffer and store it for 30 minutes. Every price they see during that session uses the locked rate. When they pay, the rate is the same one they saw at search time. No surprises.

The 1.5% buffer exists because exchange rates move during those 30 minutes. Without it, roughly 8% of our transactions would have resulted in the platform receiving less than the base price after conversion. The buffer absorbs that movement. It is small enough that prices remain competitive, large enough that the platform does not leak margin.

Internally, we store all prices in USD and convert at the API layer. This single decision simplified accounting, supplier payouts, and financial reporting more than any other architectural choice we made.

Fixing European card declines without adding friction

The 14% decline rate on European cards was our most urgent problem. The root cause was straightforward: our checkout redirected to a 3D Secure page and assumed the customer would complete authentication. Many did not. Some were confused by the redirect. Others experienced timeouts. The transaction failed, and our system recorded it as a generic decline.

The fix was treating 3D Secure as a first-class part of the checkout flow rather than an afterthought. Instead of redirecting the customer away from our page, we used Stripe’s Payment Intents API to handle authentication inline. The customer completes the 3DS challenge without leaving the checkout. If their bank does not require 3DS, the payment proceeds normally with no extra steps.

After this change, European card decline rates dropped from 14% to 3.2%. That single fix recovered more revenue than any feature we shipped that quarter.

The reconciliation problem nobody warns you about

Building the payment flow is the visible work. Reconciliation is the invisible work that determines whether the finance team trusts the system.

A single booking generates multiple financial events: a customer payment in one currency, a platform fee in another, and one or more supplier payouts in potentially different currencies, each at different exchange rates, on different dates. At month-end, the finance team needs to trace every dollar from customer payment through to supplier payout, account for FX gains and losses, and confirm that the numbers balance.

Our first system made this nearly impossible. We did not record the exact exchange rate used for each transaction. We did not separate platform fees from supplier payouts in a way that survived currency conversion. Reconciliation took two full days every month, mostly spent in spreadsheets trying to reverse-engineer what happened.

The rebuilt system stores three things on every transaction: the locked exchange rate at payment time, the actual exchange rate at supplier payout time, and the exact amounts in both the base currency and the local currency. We batch supplier payouts by currency, so all payouts in the same currency use the same rate, which makes reconciliation predictable.

Monthly reconciliation now takes four hours, most of which is spot-checking automated reports rather than reconstructing data.

The numbers after rebuilding

After four months with the new payment infrastructure:

• European card decline rate dropped from 14% to 3.2%

• FX margin leakage went from roughly $2,100 per month to $180

• Reconciliation time went from 2 days of manual work to 4 hours

• Supplier payout failures dropped from 6% to 0.8%

What I would tell a CTO building this today

If you are building a travel booking platform that handles international payments, here is what I wish someone had told me before we started.

First, invest in the reconciliation layer before you invest in the payment flow. Stripe and Adyen handle the actual money movement well. What they do not handle is making sure your finance team can trace every cent across three currencies, two suppliers, and a cancellation that happened three weeks after the original booking. Build that traceability from day one. Retrofitting it is painful and expensive.

Second, treat 3D Secure as a product decision, not a compliance checkbox. The difference between a redirect-based 3DS flow and an inline one is the difference between losing 14% of European revenue and losing 3%.

Third, lock your FX rates at the moment the customer starts browsing, not at the moment they pay. The customer’s experience of price consistency matters more than saving a few basis points on conversion timing. A small margin buffer (1-2%) covers the rate movement and protects the platform without making prices uncompetitive.

Multi-currency travel payment processing is one of those problems that looks simple from the outside and reveals its complexity only after the first month in production. The payment itself is the easy part. The hard part is making sure the numbers still make sense when the currencies, the suppliers, and the timelines all diverge.