Build vs buy: a decision framework that survives contact with reality

Build or buy software decisions usually turn into a spreadsheet comparing a licence fee against an estimated build cost. That comparison is wrong in a specific and expensive way: it compares a recurring cost to a one-off one, when building is not a one-off cost at all.

The question that decides it

Is this something customers choose you for?

If yes, build it. A vendor's roadmap will never prioritise your differentiator the way you would, and outsourcing it caps how good it can become.

If no, buy it. You are not going to build a better one than a company whose entire business is building that one thing, and every hour spent trying is an hour not spent on what you are actually for.

Most decisions resolve at that question. The remainder are genuinely difficult.

The cost that gets left out

A build estimate is a starting cost. The real figure includes everything after:

• Security patches and dependency updates, on someone else's schedule
• Someone on call when it breaks at 2am
• Every new engineer learning it
• Documentation, written and then maintained
• Migrations when the platform underneath it changes
• The features you will need next year, and the year after

A reasonable heuristic is that a system consumes a meaningful fraction of its original build cost every year simply to keep existing. Over five years, a "cheaper to build" decision frequently turns out to have been the more expensive one — and the cost arrives as engineering capacity you cannot spend on your product.

Where buying goes wrong

Two failure modes, both worth checking for before you sign.

Lock-in. Your data and processes become entangled with the vendor to the point where leaving costs more than any price increase they might impose. The tell is that you cannot answer "what would it take to move off this?" with a number.

The ninety-percent problem. The tool does most of what you need. The remaining ten percent is genuinely impossible — not on the roadmap, not achievable through the API. So you build workarounds, and the workarounds accumulate, and three years later you have built a worse version of the thing anyway, wrapped around a vendor you are still paying.

The ninety-percent problem is the more common and the less anticipated. Test for it during evaluation by trying the hardest thing you need, not the demo.

Why this decision is harder for AI features specifically

Build-versus-buy gets genuinely more complicated for AI-powered capabilities, because the usual signal — "is this our differentiator" — answers less cleanly than it does for conventional software.

A company building an AI-powered search feature is not differentiated by having AI search; dozens of competitors can buy or build something similar. What differentiates it, if anything, is the underlying data the search runs over, the specific workflow it is embedded in, and the quality of the evaluation work behind it — not the presence of a model call. This means the honest build-versus-buy question for most AI features is not "build the AI or buy the AI" but "build the surrounding product or buy a generic tool that does not know our data."

In practice this usually resolves toward buying the underlying model capability — nobody should be training their own foundation model — while building the integration, the retrieval layer over proprietary data, and the evaluation harness that makes the feature trustworthy. That combination is genuinely differentiating in a way that "we added AI" is not. Our guide on whether your startup should build AI features goes into this distinction in more depth, including the unit economics that make some AI features expensive to run regardless of who built them.

A working framework

A worked total cost of ownership comparison

The five-year comparison mentioned above is more convincing with real numbers attached, so here is one run against an actual decision: whether to build a customer support ticketing system or buy an established SaaS product.

Buying. A mid-tier support platform for a twenty-agent team runs roughly £15,000–£25,000 a year, scaling with seats. Over five years: £75,000–£125,000, entirely predictable, with the vendor absorbing security patching, uptime and feature development.

Building. An initial build — ticket queues, agent assignment, customer-facing forms, basic reporting — is a genuine four-to-six-month project, roughly £80,000–£140,000 depending on ambition. That is comparable to two to five years of the SaaS subscription, and the build cost is only the beginning.

Add the ongoing cost of keeping it alive: a reasonable estimate is 15–20% of build cost per year in engineering time for security patches, dependency updates, bug fixes and the small feature requests that accumulate once agents actually use it daily. Over five years, that is a further £60,000–£140,000, on top of the original build — bringing the true five-year total to somewhere between £140,000 and £280,000, against opportunity cost, not cash spent externally.

The build only wins this comparison if support ticketing is somehow core to the product being sold — for a company selling customer service software, building makes obvious sense; for almost everyone else, it does not. This is the pattern that repeats across nearly every build-versus-buy decision: the total cost of ownership for building is routinely two to three times the naive comparison, once ongoing engineering time is priced at what it could otherwise produce.

SaaS versus custom software: a sharper version of the same question

"SaaS vs custom software" is usually asked as though it were a separate question from build-versus-buy, and it is really the same question with the vendor relationship made explicit.

The case for SaaS beyond pure cost: faster time to value, since there is no build phase at all; continuous improvement from a vendor whose whole business depends on the product getting better; and — often underweighted — the vendor's own customer base surfaces edge cases and feature requests long before your usage would.

The case for custom software beyond differentiation: SaaS pricing scales with seats or usage in ways that can become expensive at scale in a way a fixed engineering cost does not; SaaS products are built for a broad market and will always carry compromises specific to nobody; and integration with unusual internal systems is sometimes genuinely impossible through a SaaS product's API, forcing workarounds that erode the cost advantage the SaaS option was supposed to provide.

The practical resolution is the same framework as above, applied more specifically: SaaS for anything commodity, custom for anything that is the actual product. Where the two blur — a workflow tool that is important to how the business runs but not what customers pay for — the wrap-it approach described below is the right middle path.

The middle case

The hard one: a capability that is not your differentiator but is deeply embedded in how you operate.

The answer here is buy, but wrap it. Put an interface of your own between your code and the vendor, so the dependency lives in one place. This costs a small amount now and preserves your ability to change your mind, which for an embedded system is worth a great deal.

This is the same principle as treating backing services as attached resources — the value is not abstraction for its own sake, it is that switching becomes a bounded project rather than an unbounded one.

Revisit it

This is not a permanent decision. Volumes change, requirements change, vendors change their pricing and their roadmap.

Set a reminder to re-evaluate significant vendor decisions annually. Know what your switching cost is before the renewal conversation rather than during it — the negotiating position is entirely different when you can credibly leave.

How this interacts with scope and cost

Build-versus-buy decisions compound with the scoping discipline described in what to build first. A narrow first release makes buying more attractive by default, simply because there is less custom behaviour needed early — a commodity tool covers a narrow workflow more completely than it covers a mature one, so the case for building tends to strengthen over time as the product's needs diverge further from what any vendor offers.

This also directly shapes what a build actually costs. Our guide on MVP cost in 2026 breaks down the same total-cost-of-ownership thinking used above, applied to first-version products generally rather than to a single build-versus-buy decision — the same discipline of counting ongoing engineering time, not just the initial invoice, applies in both places.

A pattern worth naming: buy first, build later

A sequencing option that resolves a surprising number of build-versus-buy arguments: buy the commodity tool now, and revisit building only once genuine limitations appear in practice rather than in a spreadsheet.

This works because most build-versus-buy debates happen before anyone has real usage data, which means both the "buy" and "build" cases are somewhat speculative. Starting with a bought tool costs little to reverse — the switching cost is usually manageable in the first year, before deep integration has happened — and it converts an abstract argument about hypothetical limitations into a concrete list of things the tool actually cannot do, gathered from real use rather than imagined in advance.

The cases where this does not apply are the ones where the capability is unambiguously your differentiator from day one — there, building immediately is correct, because delaying it means competing on a level playing field with anyone else who bought the same tool.

A final check before signing either way

Before committing to build or buy, write down the specific answer to "what would make us reverse this decision in a year" for whichever option is chosen. For buying, that is usually a switching-cost or pricing threshold. For building, it is usually a volume or feature-parity threshold relative to what a vendor now offers. Naming the reversal condition in advance, while the decision is still theoretical, produces a far more honest answer than trying to recognise the moment after the fact, once switching costs or sunk engineering investment are already shaping the judgement.

The decision nobody regrets

Across every build-versus-buy decision we have seen play out over years rather than months, the ones nobody regretted were the ones where the reasoning was written down at the time — not just the decision, but why. A team that can point back to "we bought this because it was not our differentiator and the vendor had a strong roadmap" makes a better decision when the vendor's pricing changes eighteen months later than a team relying on memory of a conversation nobody wrote down. The framework in this piece is worth less as a one-time exercise than as a habit applied consistently to every capability decision as it comes up.

In one sentence

Build what makes you money by being yours; buy everything else, and write down why so the decision can be revisited honestly rather than re-litigated from memory.

A practical next step

Take the single capability decision currently sitting on your roadmap and run it through the question at the top of this piece explicitly, in writing: is this something customers choose us for? Answer in one sentence, then check that sentence against the total-cost-of-ownership comparison above before committing either way. Most build-versus-buy mistakes happen not because the framework was wrong, but because nobody applied it deliberately — the decision just happened, by default, in whichever direction felt more familiar at the time.

Applying this beyond software

The same discipline extends naturally beyond pure software decisions — the same question of differentiation versus commodity applies to whether a company builds its own analytics dashboards, its own internal tooling, or relies on off-the-shelf alternatives for functions adjacent to but not central to the product. The framework in this piece generalises well past the specific examples used to illustrate it, and is worth applying consistently across every capability decision a growing company faces, not only the ones that happen to involve customer-facing software.

One more thing worth saying

Neither choice is permanent, and neither should be treated as a verdict on the team's capability. It is a resourcing decision, revisited as the business and the market around it change.

The teams that get this right

The teams that consistently make good build-versus-buy calls are the ones who apply the same question — is this our differentiator — every time, rather than deciding case by case based on which option feels more exciting to build.