The build-vs-buy question for AI is not about engineering pride – it is about where your durable advantage actually sits. Draw the line in the wrong place and you either rent your differentiation from a vendor or rebuild a commodity at three times the price.

Every enterprise AI roadmap eventually arrives at the same fork in the road: do we build this ourselves, do we buy a product, or do we put a thin layer of our own around a foundation model (wrap)? The decision is usually made from the gut – the engineering team wants to build, procurement wants to buy, and whoever is loudest in the room wins. That is how organisations end up running a bespoke vector database that a managed service would have handled for a fifth of the cost, or pushing their most sensitive pricing logic through a SaaS black box they cannot audit.

We have made this decision on both sides, for banks, insurers and telcos, and the pattern that holds up is not “build the hard things”. It is: “build only what compounds.”

The real problem: teams optimise on the wrong axis

Most build-vs-buy debates revolve around effort – how many engineering months will it take? Effort is the least durable factor in this decision. A nine-month build is a one-off block of cost; a boundary drawn in the wrong place is a recurring tax you pay every quarter for years.

The two axes that genuinely matter are differentiation (does this capability make you measurably better than your competitors in the eyes of your customers?) and control requirements (how strongly do data sensitivity, latency, audit and regulatory obligations force you to own the implementation yourself?). Effort only decides a tie.

Place any AI capability on those two axes and the answer falls out by itself:

• High differentiation, high control requirements → build. This is your moat. A claims triage model trained on fifteen years of your own claims data is not something you buy; it is the reason a customer chooses you. Own it end to end.
• Low differentiation, high control requirements → wrap. You need control, but the capability is generic. Question answering over internal policies, for example: the intelligence is a commodity model, but the data and the audit trail have to stay with you. Put your own retrieval, logging and guardrails around a foundation model.
• High differentiation, low control requirements → close partnership. Rare, and usually a sign that you have misjudged the control requirement. If something genuinely differentiates you, you almost always have to control it as well.
• Low differentiation, low control requirements → buy. Meeting transcription, generic coding assistance, first drafts of marketing copy. Buy the SaaS, negotiate the per-licence price, move on. Building this yourself is engineering vanity.

A framework that prices in the cost of being wrong

The quadrant gives you the direction. To defend the decision in a budget round you need three more numbers – and these are exactly the ones teams leave out:

1. Switching costs. If you buy and the vendor doubles its price or gets acquired: what does the exit cost? If that number is high and the capability is central, then “buy” is quietly a “build” with worse economics and a deadline you do not control.
2. The running cost of a build. A model in production is not a project; it is a service with an owner, an on-call rota, an eval suite and a retraining rhythm. Budget 20–30% of the original build cost per year just to keep it alive. A build that nobody is funded to maintain is the most expensive option of all.
3. Time to defensible value. Not the time to a demo – the time until the capability reliably contributes to the P&L. Buying often wins for that reason alone, because it delivers the benefit two quarters earlier, and two quarters of benefit can far outweigh the licence difference.

A worked example: document processing for an insurer

A mid-sized Swiss insurer wanted to use AI to extract structured data from incoming claims documents – around 40,000 documents per month, a mix of PDFs, scans and emails. Three options were on the table.

Buy – a specialised document AI SaaS at roughly CHF 0.42 per document. Annual running cost: 40,000 × 12 × 0.42 ≈ CHF 200k/year, scaling linearly with volume. Quick to introduce (~6 weeks). But the claims data leaves the perimeter, and the extraction schema belongs to the vendor, not the insurer.

Build from scratch – a bespoke pipeline and fine-tuned models. Estimated CHF 480k to first production value over ~7 months, plus ~CHF 120k/year to run it. Full control, but the team would have rebuilt OCR and layout parsing, which are genuine commodities.

Wrap – managed OCR plus a foundation model behind the insurer’s own retrieval, schema, validation and audit logging, in the insurer’s own cloud region. Build cost ~CHF 180k over ~10 weeks, running cost ~CHF 55k/year (inference plus infrastructure), and the data never leaves the region.

The wrap option won – and not because it was the cheapest in year one. It won because the differentiation sat in their extraction schema and their validation rules – the part that encodes how this particular insurer actually underwrites – while the commodity intelligence (OCR, baseline extraction) was rented. They owned the 20% that compounds and bought the 80% that does not. The three-year TCO came to around CHF 345k against CHF 600k for buy and CHF 840k for the full build – and the data residency requirement was satisfied by construction.

The boundary moves – plan for it

The most expensive mistake is to treat build vs buy as a one-off decision. The boundary between what you should own and what you should rent shifts over time, and it shifts in a predictable direction: capabilities that differentiate today become commodities tomorrow. Three years ago, in-house document OCR was reasonable engineering; today it is a solved, cheap commodity that would be foolish to build yourself. The same drift will come for whatever you build this year. A decision framework that ignores this produces a portfolio of bespoke systems that each made sense at the time and together became a maintenance burden once the market caught up underneath them.

The practical hedge: architect even your “build” decisions so that the commodity layers stay swappable. When we build a differentiating capability, we still isolate the generic components – the base model, the OCR, the vector store – behind interfaces, so that once the in-house piece becomes a commodity (and it will), we can drop it and adopt the cheaper market option without touching the part that actually differentiates. That way a “build” made today does not turn into a “rebuild” in two years, but into a thin layer of your own over an ever-cheaper commodity base. The moat shrinks to exactly the part that genuinely belongs to you, and everything around it benefits from falling market prices.

That changes the whole exercise. The question is not “do we build or buy this capability?”, but “which thin layer of this capability belongs to us permanently, and how do we own that while renting everything beneath it?”. The barbell portfolio is not static – it is actively curated: capabilities migrate from the “build” end to the “buy” end as they become commodities, and the organisation deliberately lets go of bespoke systems that no longer differentiate. The discipline of no longer owning something is just as important as the discipline of building it – and far rarer.

Pitfalls we see again and again

• Confusing “we can build it” with “we should build it”. A strong team can build almost anything. That is exactly why the decision needs the differentiation axis – capability is not the bottleneck, focus is.
• Treating the foundation model as the product. The model is the least defensible layer; it will be cheaper and better in six months whatever you do. Your moat is the data, the workflow integration and the evals around it.
• Ignoring the exit cost of “buy”. The cheapest licence with a restrictive clause on data export is a trap. Demand your data and your prompt logs in a portable format in the contract, before you sign.
• Unfunded builds. Approving the build budget but not the running budget guarantees a model that quietly rots until somebody notices that accuracy collapsed a year ago.

The decision checklist

Before you commit, you should be able to answer all seven questions:

1. Does this capability make us measurably better for customers, or only more efficient internally? (Differentiation)
2. Do data sensitivity, latency or audit obligations force us to own the implementation ourselves? (Control)
3. If we buy: what does it cost – in time and money – to switch vendors in year three?
4. If we build: who is accountable in production, and is that time funded?
5. How long does each option take to reach defensible value, and what are two quarters of that value worth?
6. Which layer is the moat – and are we deliberately building that layer, or rebuilding a commodity around it?
7. What is the three-year TCO, including running costs and a realistic retraining rhythm?

The gridz view

The strongest enterprise AI portfolios we have built have the shape of a barbell: a small number of deeply embedded, differentiating capabilities owned outright, and everything else bought or wrapped in a thin layer. The failure pattern is the mushy middle – half-finished platforms that differentiate nothing and tie up a whole team in maintenance. Decide where your advantage actually lies, build exactly that, and rent the rest without sentimentality. If you are standing at this fork right now, talk to us: we will run the quadrant and the three-year TCO with your real numbers in a couple of workshops – and tell you honestly which of your AI ambitions are moat and which are maintenance.