Most write-ups of this decision present two options and a bias toward one of them. There are three, and the third — wait — is the one nobody writes down, which is why it usually happens by accident instead of on purpose.
This is the decision that comes before tool evaluation. Once you have chosen to buy, how to evaluate the tool is a separate and well-defined problem. This is how to work out whether you should be shopping at all.
The question that decides it
One question does most of the work: is this capability differentiating for you, or is it table stakes?
Differentiating means a customer would choose you over a competitor because of it. Table stakes means a customer would reject you for lacking it, but would never pick you for having it.
The mapping is unglamorous and mostly correct:
- Table stakes → buy. Building infrastructure everyone has is a way of spending your scarcest resource on parity.
- Differentiating → build — though rarely the whole stack. See below.
- Neither yet → wait, deliberately, with a date.
The common error is misclassifying. Almost everything feels differentiating from inside the company, because you can see the detail. Ask instead: has a customer ever cited this in a buying decision, and would they notice if it were a third-party component?
Build is more expensive than the demo suggests
The model is the cheap part now, and this is the trap. A capable prototype takes a week, which makes the whole thing look like a month of work.
What the prototype omits is roughly everything that makes it a system: tool contracts and failure semantics, an evaluation set that reflects your actual traffic, the policy layer that constrains what it can do, run records, a rollout path, and someone on call for it. That work is not model work — it is ordinary systems engineering, and it does not compress the way the prototype did.
The honest multiplier I would apply to a working prototype is somewhere between five and ten times, and the variance lives almost entirely in how well-defined your existing systems are. If your data has undocumented semantics and your APIs have undeclared side effects, you are not building an AI feature — you are paying down integration debt that predates it, with an AI feature attached.
None of that argues against building. It argues against budgeting from the prototype.
Buy is also more expensive than the price
The licence is the visible cost and rarely the largest.
Integration is the real bill, and it is the same integration work as above — a vendor still needs your data to mean something, and it will not do that work for you.
Lock-in in a moving market is the risk specific to this moment. Ordinary vendor lock-in is a known trade. Lock-in to a category whose capabilities and prices are moving quarterly is a different kind of bet, and the cost is not the switching fee — it is being unable to take advantage of a change you correctly predicted.
Your data leaving is a decision that is very hard to reverse, and one that gets made in a procurement conversation rather than an architecture one.
Roadmap divergence. You are buying the vendor’s priorities. When your needs and their largest customer’s needs diverge, you find out slowly and cannot do much about it.
Wait is a real option and needs a real plan
Waiting has a bad reputation because it is usually indistinguishable from indecision. The distinction is simple:
A prepared wait spends the time removing what makes the decision hard. Define the metrics the capability would move. Build the evaluation set now — it will be valid whichever way you go, and it is the single most transferable asset in this whole decision. Clean the data. Write down the semantics. When you re-open the question, you decide in a fortnight rather than a quarter, and you can actually measure a vendor.
An unprepared wait is hoping the question resolves itself. It does not; it just gets asked again with less time to answer it.
Waiting also needs an exit condition, and “revisit next year” is not one. Use a trigger: a price threshold, a stability signal, a competitor’s move, or a specific customer asking twice. Write it down with a date, put it in someone’s calendar, and make re-opening the default rather than something requiring initiative.
The strongest argument for waiting right now is that the cost curve has been falling steeply. A capability that is marginal at today’s prices may be obviously correct in nine months without you doing anything. The strongest argument against is that evaluation sets and clean semantics take longer to build than the integration does — which is why the prepared wait is the only version worth defending.
The layer question
Build-versus-buy is almost never whole-stack, and framing it that way produces bad answers.
Nearly nobody should be training models. Nearly everybody should be building the harness — the contracts, the policy layer, the evaluation, the domain logic. That is where your differentiation actually lives, and it is also the part that survives when you switch the model underneath.
So the usual right answer is: buy the substrate, build the layer that knows your business. If a vendor is offering to own that layer, look closely — it is the part you least want to rent, because it encodes decisions about your domain that you should be making.
Choose for reversibility, not expected value
This is the part most frameworks get wrong, and it comes from decision-making under uncertainty rather than from software.
When you can estimate outcomes well, choose the highest expected value. When you cannot — and in a market moving this fast, you cannot — choose the option with the cheapest reversal. You are not trying to be right. You are trying to remain able to change your mind cheaply when you find out.
Practically that means: prefer the vendor with an export path over the one that is 15% better. Prefer the architecture where the model is swappable. Prefer the pilot with a natural end date over the one that quietly becomes permanent. Accept a worse expected outcome for a materially cheaper exit, especially early.
The corollary is that reversibility stops being worth paying for once the uncertainty resolves. Optionality has a price, and holding it forever is its own mistake — it is how organisations end up with three half-committed pilots and no capability.
If you genuinely cannot decide
Run a time-boxed bake-off — but write down the deciding criterion before you start, including the number that would make you walk away from all three options.
Criteria chosen after seeing results are not criteria; they are justifications. Once you have four weeks of data and a stakeholder asking when this ships, whatever you achieved will look like success. Pre-registering the bar is how you protect the decision from the pressure that will exist when you make it — the same discipline as setting a promotion threshold before the first shadow run.
Give it a real end date and an owner who is allowed to say none of the above.
The short version
Ask whether it is differentiating. If it is not, buy, and go and read how to evaluate the tool. If it is, build the layer that encodes your domain and rent everything under it. If it is neither yet, wait on purpose: build the evaluation set, fix the semantics, and set a dated trigger.
And whichever you choose, choose the version you can undo. The teams that have handled this period well are not the ones that picked correctly in early 2026 — nobody could. They are the ones who stayed cheap to change.
The integration work that dominates every one of these options is covered in The Agent Reliability Handbook and Hallucination Is a Data Contract Problem. Before approving a build, see What to Ask Before Approving an Agent Deployment.