Build vs. buy, for teams that keep answering it wrong
Most build-vs-buy decisions for AI features are made on price and delivered on regret. A simpler test: what happens to this capability when the market moves in six months?
The build-vs-buy conversation for AI features usually arrives framed as a cost comparison — a vendor quote on one side, an engineering estimate on the other. That framing reliably produces the wrong answer, because it prices the thing you are buying today rather than the position you will be in a year from now.
A better question
Ask instead: if the underlying capability improves tenfold in six months, does that help us or hurt us?
For a capability that is genuinely commodity — transcription, OCR, generic summarisation — improvement in the market helps you, and building it yourself means you have volunteered to keep pace with a well-funded industry using two engineers. Buy it, wrap it behind an interface you control, and move on.
For a capability that encodes something specific to your business — how your risk team actually scores a case, how your support organisation actually escalates — improvement in the market does nothing for you, because nobody else has the data or the rules. That is the part worth building, and it is usually much smaller than the thing the team wanted to build.
The interface is the real decision
In practice most engagements land on the same shape: buy the commodity layer, build the thin layer that makes it yours, and put a gateway in between so the commodity layer is replaceable. The gateway is what makes the decision reversible, and reversibility is worth more than getting it right the first time.
That gateway does not need to be exotic. Authentication, routing, per-team quotas, logging and a stable request shape covers most of it. What it buys you is the ability to change your mind without changing every consumer.
What usually goes unsaid
Two things rarely make it into the decision document and should:
- Who is going to operate this at 3am. A bought system has a support contract. A built system has a person, and that person has other work.
- What the procurement cycle costs. In a regulated organisation a vendor can take longer to approve than the feature would take to build. That is a real cost and it belongs in the comparison.
The decision is rarely close once those are on the table. It is just that nobody puts them there.