Every senior team that hires us asks the same question in the first hour. Should we build this in-house, or should we buy it? It's a sensible question. It's also, increasingly, the wrong question.
For most of software history, build vs buy was a clean trade. You either licensed a packaged product that did roughly what you needed, or you built something custom that did exactly what you needed. The dimensions were predictable: cost, time to deploy, fit, total cost of ownership over five years, lock-in, switching cost. The maths landed where it landed and you wrote a memo.
That framing worked because the software market was shaped like a mall. You walked the corridors. You picked things off shelves. You built only the things the mall didn't sell.
Why it broke.
Three things broke the framing at roughly the same time, and they broke it in compounding ways.
One: the building blocks shifted from products to primitives. The OpenAI API isn't a product. It's a primitive. So is Anthropic's. So is the embedding layer of any major foundation model. You don't license them and use them. You compose them, and the composition is the system. The thing you'd have called "buy" five years ago now sits underneath the thing you build, every time.
Two: the cost curve flipped. Building a custom internal tool used to cost £100K and take six months. The same tool, today, with a competent team and a good model behind it, takes two weeks and costs more in licence fees than in build hours. The buy-side products that used to cost £40 a seat per month are still £40 a seat per month — but the build cost has fallen by an order of magnitude. The maths doesn't land where it used to.
Three: the buy-side products got hollowed out. Every SaaS product worth its name is now a thin wrapper around a foundation model plus a workflow. The defensibility is in the workflow, not the model. Which means the buy-vs-build question is increasingly: do we want to pay £200 a seat per month for someone else's workflow, or build a slightly worse one ourselves and pay the model cost direct?
The buy-side products are no longer cheaper. The build-side projects are no longer slow. The trade is broken because both sides moved.
The better question.
The question that replaces build vs buy is two questions, run sequentially.
First: what's the workflow? Not the tool, not the technology — the workflow. What's the actual sequence of decisions and actions, with who, on what cadence, producing what output? If you can't write that down in plain English, no buy-vs-build decision matters because you don't yet know what you're deciding.
Second: where does this workflow live? In a tool you license. In a tool you build. In a script you run. In a person's head. In a meeting that happens every Wednesday. The "where" is the architectural question — and once it's answered, the build-vs-buy question becomes a procurement question, not a strategic one.
Most senior teams skip the first question and start with the second. They land on a tool, they buy seats, they roll it out, they wonder six months later why nobody uses it, and they conclude that AI is overhyped. The tool was fine. The workflow was undefined. No tool fixes that.
What this looks like in the audit.
When the 14-day audit runs against a business, the build-vs-buy question doesn't appear in that form. The angle gap analysis names the workflow first. Then the gap statement specifies what the workflow needs in order to operate at the maturity level the leverage potential implies.
Sometimes the answer is buy. Off-the-shelf tools that already encode the right workflow exist for a lot of common patterns — particularly in sales enablement, support, and content QA. When the workflow matches the product's assumed workflow within 80%, buy is almost always the right call.
Sometimes the answer is build. When the workflow has unusual inputs (regulated data, proprietary process), unusual outputs (specific deliverable formats, specific QA criteria), or unusual cadence (real-time, batch nightly, monthly close), the buy options force you to redesign the workflow around the product instead of the other way around. That's the moment to build.
And sometimes — increasingly often — the answer is neither. The workflow gets redesigned to remove the step entirely. AI doesn't make the slow step faster; AI makes the step unnecessary because the upstream signals are now interpretable in a way they weren't before. That's the highest-leverage outcome of any audit, and it's invisible if you start with build vs buy as the framing.
How to actually think about it.
Three rules of thumb that keep teams out of trouble.
Don't buy a tool to fix a workflow you haven't defined. The tool will land, nobody will adopt it, and you'll write off the budget. This is the single most common failure pattern in the first hundred audits we've run.
Don't build a tool to replicate a buy you haven't tried. The buy products are increasingly good, increasingly cheap, and increasingly composable. If you haven't piloted a buy option for sixty days, you don't know enough to commit a build budget against it.
Don't treat the cost curve as static. What was buy-only three years ago is build-feasible today. What was build-required five years ago is buy-trivial now. The 12-month roadmap should re-test the build-vs-buy assumption at each quarterly review, not lock it in at month one.
The framing isn't dead because the question is dead. It's dead because the question got more interesting. The audit gets you the better question. The embed answers it for the next twelve months.
FILED UNDER · FIELD NOTES · STRATEGY · PROCUREMENT