Build vs. buy for enterprise AI: a decision framework

The build-versus-buy question arrives in every AI programme, usually framed as a philosophy — "we are a buy-first organisation" — when it is properly a per-initiative calculation. Organisations that answer it once, globally, get roughly half of their individual decisions wrong.

It is also framed as binary when it is three-way. The option most frameworks omit is partnering: having a specialist team build something your engineers then own. It is neither buying a product nor staffing a permanent capability, and for a great many enterprise AI initiatives it is the correct answer.

The six questions

These resolve most cases without needing a model. Work through them in order; the first one that produces a clear answer usually is the answer.

1. Is this capability identical for us and our competitors? If yes, buy. Building a slightly better version of a commodity is a poor use of an engineering team.
2. Does it encode knowledge only we have — our process, our domain judgement, our data? If yes, build or partner. No vendor can sell you your own expertise back.
3. Will we run this at a volume where per-unit licence cost becomes material? Vendor pricing that is attractive at pilot volume frequently is not at production volume. Model it at 100×.
4. Does it need to be deeply integrated with systems we control? Deep integration is where vendor products become expensive, because each connection is either a professional-services line item or a limitation.
5. Would we need to sustain a team for this after launch, and do we want to? If the answer is no, partner rather than build — and be honest, because the failure mode here is building something nobody is resourced to maintain.
6. What does switching cost in three years? Vendor lock-in is a real cost with a real number. So is a bespoke system whose original authors have left.

When buying is clearly right

Commodity capabilities: speech-to-text, translation, generic document OCR, standard helpdesk agent-assist, meeting transcription. These are undifferentiated, improving rapidly through vendor investment you do not have to fund, and available at prices that reflect genuine competition. Building them is a way of spending engineering capacity on a problem that is already solved.

The trap in the buy column is the platform that promises to cover everything. It will deliver perhaps 70% of each of six capabilities, and the remaining 30% of each will come back as a professional-services engagement. Two years later you have a licence, a services bill, and a system nobody internally understands. Buy narrow, well-defined capabilities from vendors who do one thing; be sceptical of suites.

The second trap is buying based on a demo of the happy path. Vendor evaluations should run against your real data, including the messy tail, with a scoring rubric agreed before you see the results. We have run evaluations where the vendor ranked first on the demo and third on the client’s actual documents, which is exactly the kind of finding that only appears when you insist on your own data.

When building is clearly right

When the capability encodes something specific to you. A screening rubric that outperforms competitors. A claims-assessment approach refined over fifteen years. A routing logic that reflects how your operation actually works rather than how the category assumes it works. No vendor can sell this to you, because you are the source of it.

When unit economics at volume favour ownership. Vendor per-unit pricing typically includes their margin, their infrastructure, and the cost of features you do not use. At high volume, running an equivalent capability yourself — often on a smaller open-weight model tuned to your specific task — can cost a fraction. The crossover point varies, but it arrives sooner than most teams expect for high-volume, narrow tasks.

And when the integration is the product. If the value is in how deeply the capability connects to systems you control, a vendor product will always be a layer away from where the value is. This is why AI integration work is so frequently built rather than bought: the capability is generic, but the connection is not.

The third option: partner to build, then own

Most build-versus-buy frameworks are written by consultancies or vendors and therefore have an incentive to omit this. It deserves naming because it fits a large share of enterprise AI initiatives.

The pattern: a specialist team builds the system, your engineers participate throughout, and your organisation owns the code, the models and the operational knowledge at handover. You get a built system without hiring a permanent AI team, and without the vendor dependency of buying.

It fits when the capability is genuinely yours to own but you do not yet have the internal capability to build it, when you need it faster than hiring would allow, or when the initiative is a one-off that does not justify a standing team. It fits badly when the system will need continuous development for years and you have no plan to build the internal capability — in that case you have simply deferred the hiring decision at a premium.

The thing to check in a partner arrangement is what happens afterwards. If the handover produces a codebase your engineers cannot modify, you have bought a product with extra steps. Ask specifically: who owns the code, what documentation exists, will our engineers be in the build, and what does the system need in order to run without you.

The cost comparison that changes answers

Most build-versus-buy comparisons run on year-one cost, which is where the wrong answer comes from. Buying looks cheap in year one because the build cost is concentrated and the licence is annual. Over five years the shape usually inverts.

Two line items decide most comparisons. Licence escalation compounds: a 10% annual increase nearly doubles the cost by year six, and it applies to a base that grows with your volume. And the integration line, which is where vendor products quietly become expensive — every connection is either billable or impossible, and the impossible ones become manual workarounds that never appear in the comparison at all.

The hybrid answer most initiatives actually need

Framing the decision per initiative reveals something the binary framing hides: most individual initiatives are themselves a mix. A claims automation programme buys OCR and speech, builds the extraction schema and validation rules that encode the carrier’s policy, and partners for the orchestration layer it does not want to sustain internally.

The useful discipline is to decompose the initiative into layers and answer for each. The model layer is bought — nobody should be training foundation models. The commodity capability layer (speech, translation, generic OCR, embeddings) is bought. The domain layer, where your policy and judgement live, is built. The integration layer is almost always built, because it is specific to your systems by definition. The orchestration and governance layer is the one where partnering most often makes sense, because it is standard engineering that nonetheless needs doing well.

This decomposition also protects against the failure mode where a single vendor decision quietly determines four layers. A platform that supplies the model, the extraction, the orchestration and the integration is convenient and it means the switching cost in year three is the whole system rather than one component.

The corollary for architecture: keep the boundaries between layers explicit and standard. A model accessed through an internal gateway rather than called directly from application code can be swapped in an afternoon. The same is true of a speech vendor behind an interface. Cheap optionality now is what makes a build-versus-buy decision reversible later, and reversibility is worth more than getting the decision right the first time.

How to run a vendor evaluation that means something

If the answer is buy, the evaluation deserves the same rigour as a build. Four rules we apply.

• Evaluate on your data, not their benchmark. Include the messy tail — the phone photographs, the malformed records, the three suppliers who do everything differently.
• Agree the scoring rubric before you see results, with weights. Otherwise the rubric drifts toward whichever vendor demoed most impressively.
• Test the failure path, not the happy path. What does it do with an input it cannot handle? Does it fail loudly, guess silently, or escalate?
• Price at year-three volume with escalation, and ask explicitly what integration is included versus billable.

It is also worth asking who is doing the evaluating. Any consultancy with a reseller relationship has an answer before it starts. We hold none, which is the only reason our vendor evaluations are worth commissioning — and we say the same about anyone else’s.

Revisit the decision on a schedule

A build-versus-buy decision made eighteen months ago was made under different conditions. Model costs have fallen, open-weight capability has risen, and several categories that were genuinely worth building are now commodities. The reverse also happens: a vendor gets acquired, repricing follows, and a bought capability becomes a build candidate.

We re-score client portfolios quarterly under advisory retainers, and the questions are the same six with fresh numbers. Two changes trigger a genuine re-decision. First, a cost curve moving far enough that the volume threshold shifts — this has happened repeatedly as inference prices fell. Second, a capability becoming commoditised, at which point continuing to maintain your own version is spending engineering capacity on something you can now buy.

The practical protection is architectural rather than analytical. If the boundary between your system and the bought capability is a clean interface, changing the decision is a week. If the vendor’s SDK is threaded through your application code, it is a project — and the analysis will conclude that switching is not worth it regardless of what the numbers say.

The decision in one paragraph

Buy what is identical for you and your competitors. Build what encodes what only you know. Partner when the thing should be yours but the capability to build it is not yet. Compare on five years rather than one, include integration and switching, and make the decision per initiative rather than as a policy. If a framework gives you a single answer for your whole organisation, it is not a framework, it is a preference.