Build vs Buy: A Decision Framework With Real Numbers

Something measurable has changed in this decision, and it happened recently.

In McKinsey's The State of AI in 2026 (published August 2026), a survey of 1,719 respondents across 97 nations, 32% reported their organisation had decided against purchasing at least one software product or feature because they could build the functionality in-house using agentic coding tools. Among AI high performers the figure was nearly half, against 31% of everyone else. (McKinsey — note McKinsey reuses this URL for each annual edition)

That is a real shift in the cost of building, and it deserves to change decisions. What it does not do is make building the default answer, and the reason is that the build was never the expensive part.

The question is not cost. It is what you are taking on.

The standard framing — build is expensive and slow, buy is cheap and fast — compares the wrong things. Buying transfers most of the ongoing burden to a vendor. Building keeps it. The purchase price and the development estimate are the two least important numbers in the comparison.

Consider what the ongoing burden actually consists of.

Of the more than $100 billion the US federal government spends annually on IT and cyber-related investments, agencies have typically reported spending about 80% on operations and maintenance of existing IT rather than on building anything new. (GAO) That is a portfolio figure for an old and unusual estate, not a law — but it points at the right thing.

So does the evidence on engineering capacity. DORA found that even elite-performing teams report spending only about 50% of their time on new work, the rest going to unplanned work, rework, defects and support. (DORA)

And so does the debt. McKinsey's 2020 survey of 50 CIOs at financial services and technology firms above $1 billion in revenue found technical debt estimated at 20–40% of the value of the entire technology estate before depreciation, with 10–20% of new-product budget diverted to servicing it. (McKinsey)

When you build, you acquire all of that. When you buy, you rent it — and you pay a margin for someone else to carry it.

That is the actual trade. Everything else is detail.

What the evidence says about each path

On building: the most rigorous study of IT project costs — 5,392 projects collected, 4,677 with usable cost data, 2002 to 2014 — found the median project lands on budget, with a mean overrun ratio of 1.8 driven by a power-law tail. Critically, the same study found no statistically significant difference in the tails across project sizes (p = 0.863). Small builds are not safe builds; the largest overrun in the dataset was a $1,500 workflow customisation that finished at $425,000. (JMIS, 2022)

On partnering: Project NANDA's 2025 study of enterprise AI found external partnerships reached deployment around 67% of the time versus about 33% for internally built tools, with roughly double the employee usage. It is a preliminary working paper, its interview sample is 52 organisations, its figures are self-reported, and its authors sell AI infrastructure — directional, not definitive. But it aligns with the older outsourcing literature: Lacity and Willcocks, studying 61 sourcing decisions across 40 organisations, found selective outsourcing outperformed both total outsourcing and total insourcing. (MIS Quarterly, 1998)

On buying: the cost that never appears in the comparison is the cost of leaving. The UK Competition and Markets Authority found that in cloud services, less than 1% of customers switch provider each year, identifying egress fees as a key commercial barrier and finding that technical and commercial barriers together "lock customers into their initial choice of provider." (CMA, July 2025)

Under Article 29 of the EU Data Act, cloud switching charges are prohibited entirely from 12 January 2027. (Regulation (EU) 2023/2854) If you are architecting anything now, that date is a planning input.

The framework

Five questions, in order. The first one usually settles it.

1. Is this how you compete, or how you operate?

Build what makes you different. Buy what makes you functional.

If a capability is the reason customers choose you, owning it is worth the burden — you need to change it faster than a vendor's roadmap allows, and you cannot afford your competitor buying the identical thing. If it is payroll, helpdesk ticketing or expense management, a vendor has solved it better than you will, for less, and has a compliance team you do not.

The common failure is building something operational because the team found it interesting, or buying something differentiating because it was quicker this quarter.

2. How unusual are your requirements, honestly?

Most organisations believe their processes are unique. Most are not — they are conventional processes with accumulated local habits, and the habits are frequently the part worth losing.

Test it: if the off-the-shelf option requires you to change how you work, is that change actually bad? Sometimes the software is right and the process is a historical accident nobody has revisited.

But if you find yourself planning heavy customisation of a bought platform, stop. Customisation is the worst of both worlds — vendor licence fees, vendor lock-in, and a codebase you maintain. It is often more expensive than building, with less control.

3. Can you staff it in year three?

Building is not a project, it is a commitment. Whoever builds it must maintain it, or hand it to someone who can.

Ask the uncomfortable version: if the two engineers who build this both leave, what happens? If the honest answer is that nobody else can maintain it, you have not made a build decision — you have made a hiring decision, and bound it to two people.

4. What does the AI shift actually change?

It lowers the cost of producing code. It does not lower the cost of owning code.

The 32% who declined to buy are reporting something real. But generated code still needs review, testing, security assessment, dependency maintenance and someone who understands it at 2am. If AI tooling has halved your build estimate, it has changed one term in the equation — the smaller one.

Where it genuinely does change the decision: small, well-bounded internal tools that previously were not worth a developer's time now clear the bar. That is a real expansion of what is worth building, at the low end.

5. What does it cost to reverse?

Both directions. If you build and it fails, can you buy your way out? If you buy and the vendor raises prices, is acquired, or discontinues the product, what then?

Ask any vendor what a full data export contains, in what format, and how long it takes. Ask it before signing.

The answer is usually neither, exactly

The outsourcing literature's most durable finding is that selective sourcing beats both extremes. In practice that means buying the commodity layer, building the differentiating layer, and spending real effort on the integration between them.

Which introduces the cost that appears on neither side of the comparison: every tool you add has to talk to the others, and the connections need maintaining as both ends change. A decision that looks cheap in isolation can be expensive in aggregate.

Count the integrations before you count the licences.

Where we sit

We build software, so our incentive is obvious — and we tell clients to buy fairly often. If a mature product already does what you need and you are contemplating customising it heavily, we will say so, because customisation projects are how firms like ours make comfortable money and clients acquire expensive regret.

If you are working through this decision and want it examined by someone who will tell you when the answer is "buy," that is a conversation we are glad to have.

Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source, with its sample size and limitations stated where they matter.