McKinsey's State of AI survey landed on 25 August, and it mostly got covered for the grim headline: 80% of organisations report individual productivity gains from AI, 37% report any contribution to EBIT at all, and that second number is flat against last year. Everyone's written that post. Some of them wrote it twice.

The number I can't put down is further in. 32% of organisations said they decided against buying a piece of off-the-shelf software — a whole product, or just a feature — because they reckoned they could build it themselves with agentic coding tools.

Not "considered building it". Decided against a purchase they'd otherwise have made.

It's a real survey, for whatever that's worth: 1,719 responses across 97 countries, fielded 4 May to 8 June, weighted by each country's share of global GDP. Not a vendor landing page with a chart on it.

It isn't just the one number

Retool's Build vs. Buy report from February found 35% of respondents had already replaced at least one major SaaS tool with something built in-house in the preceding year, and 78% planned to build more. That's 817 people surveyed late last year, and you should discount it — they're Retool's own customers and builders, which is roughly like polling a gym about exercise. But the direction and the rough magnitude line up with a survey that has no such problem, and two flawed-in-different-ways numbers agreeing is more interesting than either one alone.

The distribution inside McKinsey's 32% is where it gets pointed. Among the 6% they classify as high performers — organisations attributing at least 5% of EBIT to AI — it's close to half. Everyone else sits at 31%. By sector: tech 41%, healthcare payers and providers 39%, professional services and energy both 38%.

So the companies getting the most measurable money out of AI are also the ones most aggressively cancelling software purchases. Draw whichever causal arrow you fancy; the survey can't tell you which way it points, and neither can I.

The economics that actually changed

Worth being precise about what moved here, because "AI writes code now" isn't it.

Build vs buy was never really a question about code. It was a question about the calendar. The reason buy won by default for fifteen years is that building the internal version meant two quarters and one of your better engineers, and the engineer had things to do, and by the time it shipped the requirement had changed anyway. The licence was never cheap — it was fast, and fast was worth more than cheap.

That's the bit that broke. The first working version of the boring internal tool — the approvals thing, the reconciliation thing, the dashboard that currently lives in a spreadsheet with one person's name on it — is now an afternoon. Not a good afternoon. An afternoon.

And I'm not going to do the routine where I imply the tools don't really work. They work. That's precisely why this is worth writing about instead of waiting out.

The invoice nobody reads

Here's where I think it goes wrong, and it's an accounting error rather than a technical one.

What you were buying with a SaaS licence was never the source code. Nobody has ever wanted the source. You were buying somebody else's on-call rotation. Somebody else's SOC 2 report to hand to your customer's procurement team. Somebody else's Friday evening when the auth library gets a CVE. Somebody else's migration when an upstream API version sunsets. Somebody else's problem when the one person who understood the sync logic takes a job somewhere warmer.

Agentic coding collapsed the cost of the first version to roughly zero. It did not touch a single item on that list. Not one. The build got cheap and the run didn't move at all — and the run is where the money always was.

So when a company says it skipped a purchase, what it often means is that it converted a predictable, boring, renegotiable line item into an unbounded internal obligation with no SLA, nobody to shout at, and no renewal date to force an annual conversation about whether the thing is still worth having. That can absolutely be the right trade. It is rarely priced as a trade.

The 60% is the actual story

The Retool figure that should be keeping somebody awake isn't the 35%. It's that 60% of those replacements happened as shadow IT — outside procurement entirely.

Sit with the shape of that. A tool a department now depends on. Never went through security review. Isn't in the asset inventory. Has no owner in any system of record. Exists because someone in ops had a productive Tuesday. And when that person leaves, the tool doesn't leave with them — it just quietly stops having anyone who knows why it does what it does at 3am on the last day of the month.

That isn't a build-versus-buy debate. That's the entire vendor-risk process a lot of organisations spent a decade assembling, routed around by people who were being helpful. Old shadow IT was a spreadsheet and a Zapier account: bad, but legible — you could find it on a credit card statement. The new kind produces things that look like real internal software, right down to the login page, and it doesn't appear on any statement anywhere.

I am the 32%, and here's my honest invoice

I should declare an interest, because I did exactly this.

This blog doesn't run on a hosted blogging platform. It runs on Notion as a CMS, an Astro build that pulls the posts out of it, and a Worker. I could have paid someone a monthly fee to have opinions on the internet. I didn't, because I could build it, and building it was fun.

Honest accounting, then. The build was a weekend. Since that weekend I have: keyed a render cache on a version constant so I can actually invalidate it, learned the hard way that the content fingerprint must only be promoted after a successful deploy, found and killed a cron that was firing the same build twice every morning, discovered that pinning security overrides to exact versions quietly leaves you sitting below the patch you pinned them for, and written a gate whose entire job is to catch me doing that again. There is a file in that repo whose sole purpose is explaining to my future self which of these landmines are load-bearing.

Do I regret it? Genuinely no — for me the run is the point, I wanted a thing I could take apart. But that's a hobbyist's justification and I know it, and it's exactly the justification that doesn't survive contact with a P&L. If I were expensing this, the honest line item wouldn't read "saved the CMS subscription". It'd read "converted a fixed monthly fee into an unknown number of my Saturdays, indefinitely".

Now multiply that by a department. Then by a company. Then remove the part where the person doing it finds it fun.

Where I'd actually draw the line

The question stopped being "can we build this". Yes. Everyone can build it. That question is dead and it's not coming back, and pretending otherwise is how you become the person in the meeting nobody listens to.

The question is what you want to still own in three years, and I think the split is reasonably clean.

Build the thing that's yours — the weird glue that encodes how your company actually works, the workflow no vendor models correctly because no vendor has your org chart, the thing whose requirements change monthly. That was always the right build. The tools just made it cheap enough to stop arguing about it in meetings.

Buy the thing where what you're really paying for is somebody else staying awake. Anything touching authentication, payments, personal data, compliance evidence, or a protocol that some third party will change on their schedule without asking you. The failure mode of the moment is treating the collapsed build cost as a reason to cross that line — rolling your own identity layer because an agent produced a plausible-looking one before lunch. It'll work. It'll pass the demo. You find out about the rest of it later, from somebody else, usually by email.

Anyway

One caveat worth holding onto: "decided against buying" is self-reported intent, collected at the precise moment when we build with AI now is the most flattering sentence an executive can say to a survey. Some slice of that 32% is a purchase deferred rather than killed, and it'll reappear in next year's budget once somebody has maintained the replacement through two framework majors and a dependency that went unmaintained. The honest read is the direction, not the decimal.

But the direction is real, and it's the least discussed part of this entire cycle. Everyone is still arguing about whether the models can write the code. Meanwhile about a third of the market has answered that with its wallet and is now discovering that writing the code was the part that was never expensive.

Anyway. Go and find out who owns the internal tool your team depends on most. If it takes more than one message to get an answer, that's the finding.