One in Three Companies Just Cancelled a Software Purchase Because AI Could Build It. Here Is When That Actually Works

Somebody in your business has already said it: "we do not need to buy that any more, the AI can just build it." They are not being silly, and this is no longer a hypothetical. In McKinsey's latest global AI survey, published on 25 August 2026, 32% of respondents said their organisation had decided against buying at least one software product or feature because the functionality could be built in-house with agentic coding tools. That is one in three companies cancelling a purchase order. But the same survey, on the same page, reports that only 6% of organisations can attribute a meaningful profit impact to their AI use at all. This article puts those two numbers next to each other, because the gap between them is where the money is either made or quietly lost.

What the McKinsey Survey Actually Says About Build vs Buy

The figure comes from McKinsey's The state of AI in 2026: On the road to ROI, an online survey fielded from 4 May to 8 June 2026 with 1,719 respondents across 97 countries, weighted by each country's share of global GDP. It is worth knowing that this is a survey of what executives report, not an audit of their books — but it is a primary source, it is large, and it is consistent year on year, which is more than can be said for most numbers in AI coverage.

The build-versus-buy findings are specific:

• 32% cancelled a purchase. Nearly a third of respondents say their organisation decided against buying one or more software products or features because they could build the functionality internally with agentic coding tools.
• It is concentrated in the companies best equipped to do it. McKinsey reports these decisions are most common in technology and healthcare, followed by professional services and energy and materials — sectors that already employ engineers.
• The best AI operators do it far more often. Among the small group McKinsey classes as AI high performers, nearly half report cancelling a software purchase this way, against 31% of everyone else.
• Only about two in ten are actually scaling coding agents. That rises to 31% at larger enterprises. So the confidence to stop buying is running well ahead of the capability to build.

That last bullet is the one to sit with. A third of companies have changed a purchasing decision on the strength of a tool that only a fifth of them have deployed at scale.

The Number Printed Next to It: 6% Can Point to the Money

The same survey measured whether any of this is showing up in the accounts. It is not, for most people:

Eight in ten people say AI made them personally more productive. Half say it helps them make better decisions. And yet the share of organisations reporting any positive EBIT contribution from AI did not move at all in a year in which deployment clearly did. Personal productivity is real; it is simply not the same thing as profit, and it does not become profit by itself.

An AI agent can write the software. It cannot be the vendor.

Why "We Can Build That Now" Is Usually True, and Often Beside the Point

We build production software for a living, including systems with AI running inside them, and we use coding agents daily. So take this as a report from the inside rather than a defence of the trade: the claim is true. A capable coding agent, pointed at a well-specified internal tool by somebody who can read the output, will produce a working version faster than a procurement cycle can produce a signed contract.

The problem is that writing the code was never the expensive part of owning software. The expensive parts are the ones that begin the day after it works:

• Somebody has to be on call. When the thing that now runs your stock counts stops at 9pm on a Saturday, an agent does not get paged. A person does, and that person is on your payroll now.
• The rules keep changing underneath it. A tax table, an e-invoicing schema, a payment gateway's API, a bank statement format. Buying software means somebody else is contractually obliged to track those changes. Building it means you are.
• The person who built it will leave. Code written quickly by an agent and reviewed lightly by a developer who has since moved on is the single most expensive kind of software to inherit.
• It has an operating cost that a licence does not. If the tool calls a model at runtime, you have swapped a predictable subscription for a token bill that scales with usage — and, as we covered in our piece on what happens to AI prices on 1 January 2027, some of those rates are published with an expiry date on them.
• Security and access control are not features you notice missing. Nobody files a ticket saying the permissions model is too permissive. They find out later.

McKinsey's own data hints at the last point in an interesting way: 20% of respondents say AI operating costs, including token costs, are already constraining their AI use, and the high performers report being cost-constrained on coding agents about three times as often as everyone else. The companies furthest along are the ones running into the bill first.

The Honest Comparison

Set aside the price tag for a moment and compare what you are actually buying in each case.

Three Conditions That Make Building the Right Answer

Building your own is genuinely the better decision when all three of these hold. Not one. All three.

• The requirement is yours alone. If a process is a competitive quirk of your business — the way you allocate delivery routes, the way you grade a supplier — no vendor will ever fit it well, and the customisation fee will exceed the build.
• The blast radius is small. An internal dashboard that summarises data you already hold is a good candidate. Anything that touches money, tax filings, payroll or customer records is not, because the cost of being wrong is not measured in developer hours.
• You already employ someone who can own it. Not "can prompt an agent" — can read what the agent wrote, refuse the bad half, and still be here in eighteen months. If that person does not exist, you are not building software, you are generating a liability with a nice interface.

McKinsey's finding that these decisions cluster in technology and healthcare, and that high performers make them markedly more often, is consistent with exactly this. The companies cancelling purchases successfully are the ones who already had the engineering bench. The risk is the companies who read the headline and skip that part.

Where Buying Still Wins Outright

There is a category of software where "we will build it ourselves" is close to always the wrong call, and it is not the category most people expect. It is not the hardest software to write. It is the software whose specification is owned by somebody else and changes without asking you.

• Anything a regulator defines. Statutory accounts, e-invoicing formats, tax withholding tables, audit trails. Our Accounts module carries a multi-region tax engine for exactly this reason: the schema is not ours to freeze, and neither is the deadline. An agent will happily build you last year's rules.
• Anything where the hard part is operational, not logical. A camera system that has to keep judging a live video feed, hold up when the internet drops and not bankrupt you in inference costs is not a coding problem. AI Cam exists because most of that work is in the running of it, not the writing of it.
• Anything that is a solved commodity. Stock movements, purchase orders, delivery notes. Inventory management is well-trodden ground; rebuilding it is a way of paying twice for a problem the industry finished solving a decade ago.
• Anything with an integration surface. Every connection you build to a bank, a courier or a marketplace is a relationship you now maintain, in a format that someone else controls.

The pattern is simple enough to write on one line: build the part that makes you different, buy the part that makes you compliant.

What We Would Actually Do With This Number

If someone in your business is proposing to cancel a software purchase because AI can build it instead, that proposal deserves a serious hearing and four questions, in this order:

• Who owns it in year two? Name the person. If you cannot, the answer is buy.
• What does it cost to run, not to write? Add the runtime token cost and the on-call time, then compare against the subscription you were about to sign.
• Who is responsible when the rules change? If the answer is a regulator, buy. If the answer is you, build.
• What is the honest cost of it being wrong for a week? If that number is uncomfortable, this is not the tool to prototype your AI capability on.

The McKinsey survey is not really a story about software procurement. It is a story about the distance between 80% of people feeling faster and 6% of companies being able to prove it. The organisations that closed that distance did it, per the same report, by redesigning how work happens rather than by inserting AI into the workflow they already had — nearly three quarters of high performers report fundamentally redesigning workflows, against a quarter of everyone else. Deciding to build your own version of a tool you were about to buy is not a workflow redesign. It is a purchasing decision in a workflow redesign's clothes.

If you want the boring version of this: pick the one or two processes that are genuinely yours, build those, and buy the rest from someone contractually obliged to keep them working. You can see what we actually run and where the line sits for us across the full product range, and if you want to argue the toss about a specific system you were about to build, tell us what it is — we will tell you honestly if you should buy it from us or not.