32% of companies stopped buying software this year, because AI made "build" cheaper than "buy"

The latest McKinsey State of AI survey, reported on 30 August 2026 by outlets including Yahoo Finance, Startup Fortune and Digital Applied, found that 32% of organizations have skipped buying at least one software product or feature because they could build it internally using agentic coding tools.

That is the clearest data point yet that the build-versus-buy calculation has moved. Not shifted slightly. Moved. A third of the market looked at a subscription, looked at a coding agent, and chose the agent.

What the number actually says

It is worth reading the finding carefully, because it is narrower and more useful than the headline suggests.

It does not say that a third of companies replaced their core systems. It says they declined a purchase: one product, or one feature they would previously have paid a vendor for. An internal dashboard. A reporting export. A small integration between two tools. The kind of thing that used to cost 40 dollars per seat per month forever, and now costs an afternoon.

It also does not say those companies want to become software companies. Almost none of them do. What they want is the outcome of custom software without being locked into someone else roadmap, pricing changes and deprecation notices. The build wave is less about engineering ambition and more about control.

The same number cuts two ways

If you sell software, this is a warning. Any feature that can be described in a paragraph and built in a day is no longer a line item. The pricing power has drained out of it. Vendors whose value was packaging convenience are in trouble.

If you build software for clients, it is the opposite. Demand for the outcome is rising, and the people generating that demand have just discovered how far a prototype gets them, and exactly where it stops.

That stopping point is consistent, and it is not about code quality. A coding agent will produce a working application faster than most teams can write the brief. What it will not do on its own is make decisions about tenant isolation, session handling, permission boundaries, billing states, upgrade paths and what happens when 1 customer record must never be visible to another. Those are not features. They are architecture, and they are decided early or paid for painfully later.

Where fast prototypes break

The pattern repeats. A team plans in Claude, builds in Cursor, and has something demonstrable inside a week. Everyone is pleased, correctly. Then the questions arrive.

Who can see what, and is that enforced in the database or only in the interface. What happens when a customer downgrades mid-cycle. What happens when the subscription lapses: does the store go dark, go read-only, or keep taking orders it cannot fulfil. How do you apply a security patch across 12 client deployments without touching each one by hand. What does the audit trail look like when a client asks who changed a price.

None of these are hard to solve once. All of them are expensive to solve late, and almost impossible to retrofit into an application that assumed a single tenant and a single trusting user. The prototype was never wrong. It was answering a different question.

What replaces build versus buy

The old framing was binary: license a product and accept its limits, or start from an empty repository and accept the timeline. AI coding tools did not resolve that trade-off. They made a third option obvious.

You build, but not from zero. You start from a platform that has already made the load-bearing decisions, and you spend your speed on the parts that are actually specific to your business.

That is the position Nudova is built for. The catalog, commerce, cms, blog and crm layers are there, along with the parts nobody enjoys building twice: authentication, roles, tenant separation, billing states, deployment and upgrades. Above that, it is yours. Your data model extensions, your checkout logic, your integrations, your interface.

If you run a store

You do not need to care about any of the above, and that is the point. What you should take from the McKinsey number is simpler: you no longer have to accept a tool that is 70% right because rebuilding it was unthinkable.

Practically, that means asking better questions when something in your admin panel does not fit how you actually work. A field that should be required and is not. A report that exists but not in the shape your accountant wants. A process that takes 6 clicks and should take 2. Those gaps used to be permanent. They are now small pieces of work, and Nudova Run exists so you can request them without also taking on hosting, updates and infrastructure.

Start on Starter, move to Growth or Business when volume or team size requires it. The platform underneath does not change when you do.

If you are an agency or an engineering team

The clients declining vendor subscriptions are not declining help. They are declining lock-in. They will pay for a partner who gets them to a system they own, and they will be noticeably faster to convince than they were 2 years ago, because they have already built something themselves and seen where it thinned out.

Nudova Build is the licensed track for that work: you get the source, you extend it, and the client runs a system you can hand over cleanly. Build 10 covers 10 projects under a single license, which tends to match how a working agency actually operates rather than how per-seat pricing wishes it did. Nudova SaaS is for teams going further and running a multi-tenant product of their own, where the isolation and billing model needs to be right on day 1 rather than day 300.

Details on licensing, limits and renewal dates are in the docs and on the pricing page. No surprises buried in a footnote.

The honest limit

Buying still wins sometimes. If a product is genuinely commodity, deeply regulated, or maintained by people whose entire job is one narrow problem, build it yourself at your peril. Payment processing is the obvious example. So is tax calculation across jurisdictions.

The 32% figure is not an argument for building everything. It is evidence that the default has flipped for the middle layer: the applications that carry how your business specifically works. That layer was always a poor fit for generic software, and it is now affordable to build properly.

The question is no longer build or buy. It is what you build on.