The build-versus-buy question for enterprise LLMs, answered honestly

Build versus buy is rarely a technical question. It is a question about where your advantage lives and which constraints you cannot negotiate away. Answer those two honestly and the architecture mostly decides itself — which is why the firms that agonize over model benchmarks before settling either one tend to optimize the variable that matters least.

Buy until a constraint forces you to build

An API is enough far more often than the vendors building models would like to admit. It is faster to start, cheaper to run at modest volume, and someone else absorbs the cost of keeping the frontier current. The honest default for most use cases is to buy, wrap the API in your own retrieval and guardrails, and spend your scarce engineering attention on the parts of the problem that are actually yours. The case for building your own model is real, but it is specific, and it is worth committing a year to only when one of a few conditions holds.

• Your data cannot leave your control, which rules out anything you cannot run inside your own infrastructure. For many regulated firms this alone settles the question, because the deployment constraint is not negotiable and most hosted options cannot meet it.
• Your domain language is far enough from the general distribution that retrieval alone does not close the gap. When the model has to reason in vocabulary, formats, and conventions the base model has barely seen, tuning on your corpus earns its cost. When retrieval over a general model gets you there, building your own does not.
• The use case is core enough that the model itself is part of the moat, not a commodity input. If the model is the product, or the thing competitors cannot easily copy, owning it makes sense. If it is a feature that a better base model would improve for free next quarter, renting it is the wiser bet.

Cost the whole ledger, not the sticker

The build-versus-buy math looks lopsided until you write down both full ledgers. Buying carries a running per-token cost, exposure to price and policy changes you do not control, and the quiet risk of lock-in and data egress. Building carries a much larger set of costs that rarely make it into the first business case: the talent to train and maintain the model, the evaluation infrastructure to know whether it is any good, the ongoing work of keeping it current as the field moves, and the fact that a model is not a project but a system someone owns for as long as it runs. Compare the sticker prices and building looks expensive. Compare the full ledgers and the answer depends entirely on volume, sensitivity, and how central the capability is.

If none of the conditions to build hold, building your own model is an expensive way to reach a result you could have rented.

The middle most firms actually want

Framed as a binary, build versus buy misses where most of the good answers live. The pragmatic path is to buy the base capability and own the layer that is genuinely yours — the retrieval over your corpus, the fine-tune that encodes your domain, the evaluation and guardrails that make the system safe in your context. You rent the part that is a commodity and improving for free, and you build the part that is your advantage. That way the frontier moving forward helps you rather than stranding a year of training work, and your investment concentrates where it compounds.

Apply the reversibility test

When the conditions are ambiguous, ask which decision is easier to undo. Starting with a bought API and moving to a built model later is a normal migration; you will have learned what the use case actually needs, and much of the surrounding system carries over. Starting with a year of custom training and discovering an API would have sufficed is a harder loss to recover, because the cost is already sunk and the opportunity is already gone. When in genuine doubt, choose the reversible path, run it in production, and let real usage tell you whether the constraint that would justify building is actually there.

Two firms, two right answers

A logistics company we know wanted document summarization across general business correspondence. No residency constraint, ordinary language, a useful feature rather than a moat. They bought — wrapped an API in their own retrieval, shipped in weeks, and have never regretted not training a model that would have improved on nobody's timeline but their own vendor's. A bank facing the same surface decision reached the opposite conclusion for the opposite reasons: data that could not leave the building, dense regulatory language the base model handled poorly, and a use case central enough to be worth owning. They built. Both were right, because both answered the two questions that actually decide it — where the advantage lives, and which constraints cannot be moved — before arguing about the model.