Build-vs-buy is usually argued as build-vs-buy. The useful version has a third option, and asks a different question about each piece.
Build-versus-buy gets argued as a single decision about a whole product, which is why it is usually argued badly. It is not one decision. It is one decision per component, and about a third of them have a third answer that rarely makes it onto the slide: skip it.
What follows is the way we work through it — not a framework so much as the order the questions have to be asked in for the answers to be worth anything.
Start by finding where AI actually moves the needle
Before anything is built or bought, the scoping question is where AI genuinely improves the product for a user, and — the half that gets skipped — where it does not.
This matters more in AI products than elsewhere because the technology is unusually good at producing demos. A feature can be impressive in a review and useless in the workflow it was meant to help, and that gap does not show up until real usage. So the first pass is not about implementation at all: it is deciding which capabilities are worth having, at which point most candidate features fail and the build-vs-buy question never has to be asked about them.
That is the "skip" column, and it is normally the highest-return part of the exercise. Every feature removed here is one that does not need a build estimate, a vendor evaluation, a reliability story, or a line in the roadmap.
Then ask, per piece: is this the product, or the plumbing?
For what survives scoping, the question that decides build-vs-buy is not cost and it is not time to market. It is whether the component is a thing your users are choosing you for.
Buy the plumbing. Model inference, speech, transcription, payments, authentication, email delivery. These are commodities with real vendors and real SLAs, and building one is a decision to spend your scarcest engineering attention on a problem several companies have already solved better than you will.
Build what makes it yours. The domain logic, the data model, the workflow, and — for anything agentic — the trust boundary. Our own assistant's two-plane security is built rather than bought, because the shape of the boundary is the product's safety claim, and a safety property assembled out of someone else's defaults is one you cannot describe, test, or defend when asked.
The reliable test: if the component failed and you swapped the vendor overnight, would a user notice a difference in what your product is for? If no, buy it. If yes, you are looking at the thing you actually sell.
Buying is a decision about coupling, not about a vendor
Most bad buy decisions are not wrong about the vendor. They are wrong about how tightly the product is allowed to bind to it.
We run three LLM providers with failover, which people usually read as a redundancy story. Half of it is. The other half is a design constraint imposed deliberately: because the product must be able to run on any of three, no provider-specific behaviour can leak into the application, and the interface between the product and "a model" stays narrow enough to reason about. The abstraction earns its keep on an ordinary Tuesday, not just during an outage.
The failure worth designing for is also not the one people plan for. Providers rarely die outright; they degrade — slower, rate-limited, subtly worse output — and a system that only handles hard failure will sail straight through that while its users have a worse time. Which is a reliability question rather than a purchasing one, and it is why the buy decision cannot be closed out at signature.
Two mechanical properties are worth insisting on for anything bought: structured, enforced outputs rather than free text you parse and hope about, and an evaluation harness that will tell you when the thing you bought changed under you. Both are cheap at the start and retrofits from hell.
Sequence the hardest, least certain part first
The most expensive mistake in this whole area is not a wrong build-vs-buy call. It is a correct set of calls executed in the wrong order.
The pattern is familiar: the team ships the easy parts first, because they are easy and because progress looks good, and discovers three months in that the hard part is impossible — or possible only with an architecture that invalidates what was already built. Everything shipped so far then has to be reworked or thrown away, and the calendar is gone.
So a phased plan should ship value early and put the least certain part first, and those two goals conflict often enough that reconciling them is most of the work. Usually it resolves into a thin, real, end-to-end slice through the risky part — not a prototype, not a spike, but something small that runs in production and answers whether the hard thing works. Everything downstream of that answer stays cheap to change until it comes back.
Write down why, not just what
A build-vs-buy decision has a shelf life. Model prices fall, vendors ship the feature you built, a provider's terms change, your volume goes up an order of magnitude and the arithmetic inverts.
Which means the decision record has to carry its reasoning, not just its conclusion. A roadmap that says "buy transcription" is a dead artefact in six months. One that says "buy transcription, because it is not what users choose us for, at current volume it costs less than a tenth of an engineer, and we revisit if volume passes X" can be re-evaluated by someone who was not in the room — including by your team, without us.
That last part is deliberate. The plan is written for your team to execute without us in it, because a recommendation you can only act on by hiring the people who wrote it is not a recommendation.
What this comes out as
Three artefacts: a product and roadmap document, a build-vs-buy recommendation with the reasoning attached to each call, and a phased delivery plan that ships value early and puts the hardest, least certain parts first.
It is most useful when the disagreement is about scope rather than ambition, when build-versus-buy is genuinely open, or when the sequence matters. When a team already knows what it is building and is right about it, this is not worth buying — which is a fine answer, and one we would rather give early than bill for slowly.
If it is the useful case, that is what our AI product strategy work is — and it comes from people who have shipped the kind of product being recommended, on iOS, on the web, and on our own infrastructure.