Build, buy or wait: the decision CIOs get wrong most often

Every approved AI use case soon reaches a fork with three exits: build in-house, buy on the market, or wait. The first two exits have fierce internal lobbies, the engineering team that wants to build and the procurement team besieged by vendors, while the third has nobody defending it, and this imbalance of representation is the first cause of the errors later counted in the portfolios. The decision, taken well, is an exercise in criteria; taken as it usually is, it is an arm-wrestle between biases.

The criterion that orders all the others

The question that should open every build-or-buy discussion is whether the capability in question differentiates the company on the market or merely keeps it operational. The distinction between core and context, which Geoffrey Moore made canonical, applied to AI produces a rule with few exceptions: you build only what touches the heart of the competitive advantage, where your data and your domain knowledge create something the market cannot offer anyone else, and you buy everything else, because in everything else the market product embeds the learning of hundreds of customers and improves at their expense.

The most frequent classification error leans towards the core side: almost every function considers its own process differentiating, and the test to deflate the illusion is asking whether a competitor, using the same market product, would obtain the same result. If yes, the advantage never lived in the software, and building it in-house produces only a perpetual maintenance cost dressed up as an asset.

Beneath the core criterion, the others act as a court of appeal: the maturity of the market offering (buying an immature product is a build with the wrong supplier), the real internal skills with their retention outlook, the three-year total cost where the build pays maintenance forever and the buy pays the fee forever, the speed the business requires.

The wait, the option without a lobby

AI adds to the classic fork a third exit that deserves more respect than it receives, because the underlying technology has a rare property: it improves and depreciates at visible speed. Capabilities that twelve months ago required bespoke projects now sit inside a product or a base model, and the per-token costs of the same capability have fallen by multiples year over year. In such a context, waiting six months can be the highest-return decision of the three, because the problem that requires a build today can be bought tomorrow, and the day after it is a feature included in something you already own.

The legitimate wait, though, has a precise shape distinguishing it from procrastination: it is a written decision, with a review date, the conditions that would end it early (a competitor moving, a product maturing, a regulatory deadline) and an owner watching the calendar. It also has a cost, to be looked at squarely: the months of organisational learning forgone, the head start a more impatient competitor can accumulate. A wait without a date and a declared cost is not a strategic option, it is the no-go nobody had the courage to sign.

The biases in action, and the countermeasure

It is worth naming the biases as they present themselves in committee. The build bias speaks the language of uniqueness ("our needs are special") and of prudence ("this way we keep control"), and thrives where engineering is strong and under-utilised. The buy bias speaks the language of speed and de-risking ("the supplier will handle it"), and thrives under budget and quarterly pressure. The bias against the wait unites them: in a season where "doing something with AI" is a reputational imperative, patience looks like inertia, and no manager gets promoted for having waited well.

The countermeasure is procedural more than psychological: the three options always get evaluated, all three, in writing, on the same criteria, with the cost of the wait quantified next to the other two, and the decision is signed by whoever owns the P&L of the process, never by whoever owns the technology or the contract. Where the method exists, the biases do not disappear, but they stop deciding on their own.

In our AI Strategy work the three-exit fork is crossed inside the Canvas and the backlog, with this article's criteria made explicit case by case: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The retrospective test, for anyone wanting to measure their exposure to the biases, is looking at the last five build-or-buy decisions taken in the company and asking how many times the wait was evaluated in writing. If the answer is zero, it is not because waiting was never the better deal.