Build vs buy for AI capabilities: the layers worth owning and the ones worth renting

Break it into layers first

The stack is roughly: the model itself, the orchestration around it, the domain logic that encodes your business, and the interface your users touch. Treating "AI" as one buy-or-build decision guarantees a wrong answer for at least one layer.

This framing also clarifies the strategic question. Whatever you buy, competitors can buy identically. Your differentiation lives in the layers you own, which tells you where to concentrate engineering effort.

Buy the model, effectively always

Training a foundation model is a capital project with no plausible return for a product company. Use hosted APIs or open-weight models depending on your data residency, cost and stability requirements, as covered in choosing an LLM.

The decision that matters here is not build versus buy but reversibility: keep the model behind your own interface so switching is a contained change. That single design choice is worth more than the initial provider selection.

Own your domain logic and evaluation

The prompts, retrieval strategy, business rules, permission model and evaluation suite encode how your organisation actually works. Nobody can sell you those, and they are the difference between a product and a thin wrapper around someone else's API.

The evaluation suite in particular is a compounding asset. It grows more valuable every time a model changes underneath you, because it is what lets you adopt an improvement in an afternoon instead of a quarter.

If everything in your AI feature could be bought off the shelf, your competitor's version is one purchase order away from parity.

The orchestration layer is the real question

Frameworks and platforms for retrieval, agent orchestration and evaluation genuinely accelerate early work. They also add a dependency whose abstractions may not match how your problem evolves, and unwinding that later is unpleasant.

Our general position is to buy infrastructure with clear boundaries, vector stores, observability, model gateways, and be cautious about frameworks that own your control flow. Control flow tends to become the thing you need to customise. The same reasoning as build versus buy generally.

Point solutions have a real place

For a standard capability outside your differentiation, transcription, translation, moderation, generic document extraction, buying is almost always right. These are commodity capabilities where a vendor's scale beats your effort.

The trap is buying a point solution for something that is core to your value, then discovering you cannot change its behaviour in the way your customers need. Ask what happens when you need it to work differently, and if the answer is a support ticket, reconsider. Vendor questions are in the AI vendor checklist.

Frequently asked questions

Are AI wrapper products defensible?

Only if the wrapper contains real domain logic, proprietary data access or workflow integration. A thin prompt over a public API is not a moat, and pricing pressure finds it quickly.

Should we use an AI framework or build our own orchestration?

Frameworks accelerate the first version. If your control flow is likely to become specialised, a thin custom layer over the provider SDK often ages better.

When does self-hosting a model make sense?

When data residency is contractual, when volume makes per-token pricing more expensive than infrastructure, or when you need a guarantee the model will not change.

Deciding which parts of an AI stack to own? A free 30-minute consultation will map the layers against where your differentiation actually is.