A third of companies stopped buying software

McKinsey published its 2026 State of AI survey at the end of August. One number is doing the rounds: 32% of organizations declined to buy at least one software product because coding agents let them build it in-house. Retool asked a harder version of the question in February and got 35% who had already replaced a SaaS tool with something they built. The categories most exposed are the ones you'd guess: workflow automation, internal admin tools, BI, CRMs, form builders, project management, support.

Here's the number I haven't seen quoted next to it. The share of companies attributing any earnings impact to AI stayed flat at 37%. High performers, the ones crediting 5% or more of earnings to AI, are still about 6%.

So a third of the market walked away from a purchase and the earnings line didn't move.

The consensus explanation is that "decided not to buy" is not the same as "shipped a replacement." True. But I think that misses the real reason. In my last issue I wrote about the year I spent building in the wrong order inside a 12-person company. The survey is what that year looks like from the outside.

The tool was never the hard part

Building a CRM, a catalog, a scheduling tool, or an approval workflow with a coding agent is real. I've built versions of most of those this year. The build is fast. What's slow, and what the survey can't see, is everything the tool has to sit on top of.

Every internal tool is a view over your data. If your customer records live in three systems with three definitions of "customer," if product data comes from twelve vendors in twelve shapes, if meeting decisions live in someone's head and order history lives in a system nobody can query, then a coding agent can build you a beautiful screen that shows you garbage faster.

You don't get a working system. You get a fourth definition of "customer."

That's why the 32% and the 37% can both be true. Companies are finding out that the tool cost went to near zero and the integration cost didn't. The integration cost was always most of the bill. Vendors just hid it inside the subscription.

What changed for us

At Doing Good Works we sell branded merchandise. Our data is scattered by design: orders in commonsku, pipeline in HubSpot, conversations in Slack, meeting notes in Granola, product catalogs across SAGE, PSRestful, and a long tail of supplier exports, shipping in ShipStation. Seven systems, no shared key, no shared vocabulary.

For years every "could we just build a tool for X" conversation died at the same spot. Not because we couldn't build the tool. Because the tool needed data from four places that didn't agree with each other.

What made building the right move was not a better coding agent. It was the unglamorous months spent standardizing the layer underneath:

• One web service that connects all seven systems and speaks one schema. A client is one thing. An order is one thing. A product is one thing no matter which supplier it came from.

• A curated product store. Instead of querying twelve vendor APIs with twelve schemas, we pull the top vendors into one table with one shape, and go back to the source live when a price or an image needs to be current.

• Sales history, meeting intake, and client segment tags attached to that product data, so ranking uses what we actually sold, not what a supplier wants to promote.

None of that is a tool. Nobody on the team uses "the web service." It's plumbing.

Then the tools got cheap

Once that layer existed, here's what happened in about six weeks:

A shop for our education clients. Eight days, 109 commits. A client picks products, a commonsku project and estimate get created, and the rep gets a Slack notification. It works because the product data was already standardized and the commonsku write path already existed.

Self-serve product collections for mid-tier accounts, replacing the hour-long presentations our reps were building by hand, one client at a time. The drafter looks for a standing collection first, falls back to composing one from the product store with a good/better/best cut, and pulls social proof from real sales counts. It reuses the shop's tables and the web service's estimate path.

An agent factory: agents for the team, starting with sourcing and segment strategy, each one backed by the same web service. They're reachable from ChatGPT today, backed by the knowledge base. Same data layer, third consumer.

Each tool was cheaper than the last because it inherited more. The shop had to build the product store. Collections got it for free. The agents got both.

That's the compounding part, and it has nothing to do with model quality. Value compounds on standardized data, not on prompts. The first tool on a clean layer costs X. The fifth costs a fraction of X and does more, because it can treat every other tool's outputs as inputs.

And the hour a rep used to spend building a presentation by hand didn't disappear into a dashboard. It went back to the client relationship, which is the one part of this business a tool can't do.

Companies stuck at the 32% are building tool number one on a layer that doesn't exist yet, and discovering that tool number one has to build the layer. So it takes months, it's fragile, and finance can't find the line item. The survey records a declined purchase and a flat P&L.

Start with the nouns

If you want the build-vs-buy math to work, the sequence is backwards from how most teams are approaching it.

Don't start with the tool your team is begging for. Start with a question: what are the five nouns in this business, and does every system agree on them? Client, product, order, project, conversation. Pick the ones that show up in every request. Build the layer that makes each of them one thing.

That work is boring. It produces nothing a stakeholder can click. And it's the entire reason the tools that come after it will be worth anything.

It's also the work vendors have been doing for you, badly, at 16% annual price increases. Vertice put SaaS price inflation at 16.4% in June, the highest they've recorded. The build case is strongest exactly where a vendor is charging you seats for a thin tool sitting on top of your own data. But you only get to make that case once your data is yours, in a usable shape.

McKinsey does note that the 6% are also the group most likely to skip a purchase. Nearly half of them have, versus a third of everyone else. I can't see what they built underneath. I can see what happened inside one small company once the layer existed.

The 32% figured out the tool is cheap. The 6% figured out the layer is the product.

Next issue: what the web service actually looks like, and the three schema decisions I'd make differently.

P.S. Reply with the noun your systems disagree on most. Client, product, order, something else. I'll pull the answers into a future issue.

Sources: McKinsey, The State of AI: Global Survey 2026 (August 25, 2026); Retool, 2026 Build vs. Buy Report (February 2026); Vertice SaaS Inflation Index, June 2026.