Buy, build, or wait: a decision framework for AI capability
Three questions decide it: does this capability differentiate you, does the data sit inside your walls, and will the vendor market commoditise it within eighteen months? Everything else is noise.
Most build-versus-buy debates run long because they are argued on the wrong terms. Teams compare licence cost against engineering cost, which is the one comparison that will be obsolete within a year. Three questions settle it faster, and they settle it more durably.
It helps to start from where the market actually is. McKinsey's 2025 State of AI survey found 88 percent of organisations using AI in at least one business function, but only about 6 percent reporting a material effect on company-wide earnings, with roughly two-thirds still running initiatives that have not scaled beyond pilots. Very little AI capability is differentiating anyone yet. That makes the useful question not how to get ahead, but which of these capabilities is genuinely yours to own.
Does it differentiate you?
Would a customer notice if this capability were merely adequate rather than excellent? For an insurer's underwriting triage, yes. For its expense-report categorisation, no. Capabilities that do not differentiate should be bought at the lowest defensible cost and forgotten about, no matter how technically interesting they are.
Does the data sit inside your walls?
If the capability depends on proprietary data — your claims history, your trade records, your service transcripts — a vendor cannot replicate it and you should not hand it over. If it depends on public data or general language ability, you have no advantage to protect and building is a vanity project.
Build where your data is the moat. Buy where somebody else's scale is.
Will the market commoditise it in eighteen months?
This is the question that produces the third answer. Some capabilities are clearly on their way to being a checkbox in software you already own. Building those is buying an asset that depreciates to zero on a known schedule. Waiting is a legitimate decision, but only when it is an actual decision — with a date to revisit, a named owner, and a note on what evidence would change it. Waiting by default is just drift.
What the answers combine to
Differentiating and data-backed: build, and staff it properly. Differentiating but not data-backed: buy the platform and build the thin layer that carries your judgement. Neither: buy the cheapest thing that clears your security review. Differentiating, data-backed, but about to be commoditised: wait, with a date.
The framework's real value is that it makes the wait option respectable. Teams under pressure to show AI progress tend to build something rather than nothing. A documented decision to wait, with the evidence that would reverse it, is a stronger position than a half-built system nobody owns.
- McKinsey & Company, The State of AI, 2025 global survey. mckinsey.com
- The three-question framework is Biruni Applied AI's own, developed across client engagements.
- —Ask three questions: does it differentiate, is your data the moat, will the market commoditise it inside eighteen months?
- —Build where proprietary data gives you an advantage a vendor cannot copy.
- —Buy where someone else's scale wins, and stop discussing it.
- —Waiting is valid with a date, an owner, and the evidence that would change it. Otherwise it is drift.