Build vs buy AI

The short answer

You are not choosing between building and buying. You are choosing, for each layer of the system, which one you own. Almost nobody should build a model. Almost nobody should buy the part that encodes how their business decides.

Framed as a single yes or no, this question has no good answer, which is why it stalls in committees for months.

The question is which layer, not whether

Every production AI system is a stack. At the bottom, the model. Above it, the plumbing: retrieval, orchestration, evaluation, observability. Above that, the integration into your systems. At the top, the decision logic, which is the part that encodes what your business does and why.

Those layers have opposite economics. The bottom is a commodity getting cheaper and better without you. The top is the only part a competitor cannot copy by signing the same contract you did.

So the rule is simple to state and hard to follow: rent the bottom, own the top.

What you should almost never build

The model. Training or fine tuning a foundation model to compete with what you can call through an API is a way to spend a year losing ground, and the gap closes on its own every few months.

The commodity plumbing. Vector storage, log aggregation, tracing. These are solved, cheap, and boring, and building them consumes senior engineering time that has better uses.

The generic interface. If your use case is a chat window over documents, there are twenty products that do it, and the honest question is whether you actually needed a chat window.

What you should almost never buy

The decision logic. The rules about when to approve, when to escalate, what to offer whom, what never to do. That is your business. Buying it means renting your own judgment back from a vendor, and it is the fastest way to end up identical to your competitors.

The evaluation criteria. What counts as a correct answer in your domain is not something a vendor can define for you. If they define it, they control the standard you are held to.

The integration into your core systems. Not because vendors cannot do it, but because that seam is where your operational knowledge lives. Outsource it and every future change routes through someone else's roadmap.

The hidden cost of buying

The license is the visible number and rarely the largest one. Underneath it: configuration work that looks like implementation and behaves like development, data preparation that you do regardless, and the integration nobody scoped.

Then the structural costs. Your data shape has to bend to their model. Your process has to bend to their assumptions. When you need behaviour their roadmap does not have, you wait, and waiting is a cost even when nobody bills you for it.

The one that hurts most arrives later. If the tool becomes load bearing and the vendor raises prices, changes terms, or is acquired, your leverage is whatever switching cost you allowed to accumulate.

The hidden cost of building

Hiring is the obvious one, and it is deferred rather than avoided. Senior AI engineers take months to hire, cost meaningfully more than the salary line, and ship nothing during ramp.

The larger cost is the learning curve on the boring parts. Guardrails, evaluation, cost control, prompt versioning, observability. A team building its first production AI system pays for those lessons in incidents, and pays again in the rewrite that follows.

And maintenance never ends. The model provider ships updates, your data drifts, your product changes. Something you built is something you keep, which is fine if it is core and expensive if it is not.

The hybrid that usually wins

Rent the model. Use mature open tooling for the plumbing rather than building or buying it. Own the retrieval over your own data, own the decision logic, own the evaluation criteria, and own the integration into your systems.

In that shape the vendor risk is contained to the layer that is genuinely a commodity, and the part that differentiates you stays in your repository. Switching model providers becomes a configuration change rather than a rebuild.

This is the shape we build toward when we do production AI, end to end, not because it is fashionable but because it is the only arrangement where the expensive part is also the part you keep.

How to decide in one afternoon

Take the specific use case, not AI in general. Write down the decision at the centre of it. Then four questions.

Does this decision encode something specific about how we operate, or would any company in our sector decide the same way? Specific means build. Generic means buy. Would a competitor gain anything by having exactly this? If yes, build. Is there a product that already does eighty percent of it, and is the missing twenty percent cosmetic or structural? Cosmetic means buy. And if this vendor doubled their price in eighteen months, what would we do? If the answer is pay, you are buying something you should own.

Notice that none of these are technical questions. If the honest answer is that you need the capability permanently, the comparison shifts to team building, which we covered in AI studio vs building in-house.

What changes at scale

Volume changes the arithmetic. At low volume, per request pricing is cheap and building is hard to justify. Past a threshold, the same bill funds a team, and the calculation inverts without anyone revisiting it.

Regulation changes it too. Once you have to show why a decision was made, an opaque vendor becomes a liability rather than a shortcut, and the audit trail has to be yours.

The practical advice is to revisit the decision annually rather than treating it as permanent. Most stacks accumulate tools nobody would choose again, and nobody notices because the choice was made once. If you want a quick read on your current setup, our free AI readiness checker covers the visible side of it.