Build vs Buy AI: The Two Walls Nobody Prices, and Where to Draw the Line

In software, “it got better” is good news. In AI, better can quietly kill the thing you just built.

That sentence sounds wrong the first time you read it. Improvement is supposed to be the reward. But it is the single most under-priced risk facing any company deciding whether to build its AI in-house, and it is the reason the build-versus-buy debate is usually settled with the wrong arithmetic.

The question is not coming from travel

A few people asked me this same question last month. None of them work in travel. One in operations, one in finance, worlds that have nothing to do with each other. Every one of them asked some version of: should we build our AI in-house, or buy it?

That tells you something. This is not a travel problem, or a TMC problem. It is the question of the moment in every industry that runs on software. What differs by industry is not the question, it is which constraints make the answer bite hardest.

And almost everyone starts in the same place: cost. Engineers are expensive. Models are expensive. All true, and all beside the point. Cost is not the hard part.

There are two walls. Almost nobody prices the second one.

Wall one: the pilot works, production is a different machine

The demo always works. That is what demos are for.

Production is a different machine entirely. At scale, the questions that were invisible in the pilot arrive all at once. How do your agents share one memory? How do they communicate with each other when there are twenty of them and not one? What happens the night a wrong answer costs someone a booking, or a bed in the wrong city?

This wall is well documented, even if it is rarely priced honestly. Gartner found that more than half of enterprise generative AI projects were abandoned after the proof-of-concept stage. Note what the reasons are: poor data quality, insufficient risk controls, rising costs, unclear business value. Not one of them is “the model was not good enough.” The technology worked. The operation around it did not.

The same pattern shows up in the Gartner survey of 782 infrastructure and operations leaders: only 28% of AI use cases fully succeed and meet ROI expectations. Among leaders who reported setbacks, 38% pointed to a lack of team expertise. Gartner also expects more than 40% of agentic AI projects to be cancelled by the end of 2027, on escalating costs and unclear value.

Most teams see this wall coming, even if they underestimate it. The second one, they do not see at all.

Wall two: the model will not hold still

Here is the part I did not see coming.

The model does not stand still. Every few months it gets dramatically better, and it starts doing things it simply could not do before. Sounds like good news. It is not, if you built for the old model.

Every workaround you wrote to compensate for what AI could not do last year becomes dead weight the moment it can. All that careful scaffolding, the guardrails, the clever fallbacks, the hand-written logic covering the model’s gaps. The frontier moves and your best engineering becomes the thing standing in its way. Your architecture ages backwards.

It does not stop at the code. The people you hired to fill those gaps have had their job changed underneath them, without anyone deciding it. That is not a maintenance problem. That is an org problem arriving on a technology schedule you do not control.

So you are not maintaining software. You are re-architecting your product and reshaping your team every time the frontier jumps. Buy it, and that cost belongs to your vendor. Build it, and it is yours. Permanently.

This is what a16z heard from 100 enterprise CIOs: companies are moving away from building, because internally developed tools are “difficult to maintain and frequently don’t give them a business advantage.” In their follow-up work, 65% of enterprises said they preferred incumbent solutions, citing trust, integration, and procurement simplicity. That is not laziness. That is organizations pricing the second wall correctly, often without articulating it.

Stop asking build or buy

It is the wrong question, and asked at the wrong altitude.

Start somewhere else. In your own operation, what is the part that changes fastest? Name it. Draw a hard line around it. Build a clean interface to it, so that you can swap whatever sits behind that line without touching everything else.

Right now, that fast-moving part is the AI layer itself. Here is why, precisely: it keeps moving work out of your code and into the model. What your engineers wrote by hand last year, the model just does this year. The boundary between “our software does this” and “the model does this” shifts every few months. That boundary is the moving target.

So put your seam exactly there. Then own the durable side.

Where the line goes in a TMC

Take post-booking. Cancellations, changes, the reroute at midnight when a flight dies and someone is stranded.

Here is the part that gets misread: post-booking is one example, not the answer. The same split runs through your booking engine flow, your sourcing and procurement, how you find and fix bugs, your whole development lifecycle, operations, CRM, sales, marketing. Every one of them has a part the frontier is about to take and a part that stays yours. The exercise is the same everywhere. Only the seam moves.

So take post-booking as the worked example. You own that workflow by defining it well. That is the most important part, and it is the part nobody can hand you. Then define a clean interface to your data, and own that too. Then implement the workflow so the AI layer underneath stays flexible. The accumulated knowledge of how a change actually clears, what the supplier will accept, what breaks at 2am, lives in that definition. None of it arrives free with a model upgrade. It compounds, and it is yours.

The reasoning inside the workflow is the moving part. Today it takes real engineering. In eighteen months, a chunk of it will be something the model simply does. So rent it, or build it while keeping it swappable, so you can rent it the day someone does it better than you.

Just do not weld the thing that changes to the thing that lasts. That weld is what turns a frontier leap into a rewrite.

Do not flinch from the model

One more thing about where you draw the line, because the instinct here runs the wrong way.

The model is not deterministic. Faced with that, the reflex is to pull work back into code, where behaviour is predictable and you feel in control. Resist it. Rely on the model’s reasoning.

If you find yourself debating whether to write the logic yourself or let the model handle it, the debate is your answer. It is probably a matter of time before your logic is useless. Write it if you have to, but write it to be thrown away. That decision, which logic enters the model and which stays in your own logic layer, is the boundary that keeps moving. Design for it to move.

What this buys you

Here is the optimistic part, and it is the reason this framing matters more than the cost math.

Draw the line in the right place, and every leap the frontier makes upgrades you for free instead of breaking you. The same improvement that would have obsoleted six months of work becomes a version bump behind an interface you designed. You stop bracing for progress and start compounding on it.

The companies that win the next few years will not be the ones with the biggest AI team. They will be the ones who drew that line in the right place.

So: where is your line?

This is the kind of thing we think about while building Bitravel. We made the same call ourselves, deliberately. Bitravel is AI native, and we kept the line between our logic layer and the AI layer movable, not welded to any single model, so we can switch as the models develop and as the economics change. Book a 30-minute call for a live look, no deck.