A Third Skipped a SaaS Buy. Now Price the Run Cost.

McKinsey's 2026 survey found 32% of organizations skipped a software purchase because agentic coding tools could build it in-house — while the share reporting any EBIT impact from AI stayed flat at 37%. The industry spread explains why: insurance and the public sector, at 19% and 17%, buy audit evidence and liability, not code.

By Rajesh Beri·August 31, 2026·11 min read
Share:
A conference-room table where a slim printed software renewal contract has been pushed aside, replaced by a much taller stack of loose printed code listings and thick ring-bound audit folders.

Illustration generated using AI

Your engineering team can now build the thing you were about to renew. That is not the same as saving the money. McKinsey's State of AI in 2026, a survey of 1,719 business leaders, found that 32% of organizations decided against buying at least one software product or feature because they could build it internally with agentic coding tools. The same survey found the share attributing any EBIT impact to AI stayed flat at 37%, with only 6% clearing the high-performer bar. A third of the market walked away from a purchase and the earnings line did not notice.

There is a reason for that, and it is visible in the industry breakdown.


What the Survey Actually Asked People

The 32% is a decision not to buy, not a system in production. Respondents were asked whether their organization had forgone one or more software products or features because the functionality could be built internally with agentic coding tools — and nearly a third said yes. Nobody was asked whether the replacement shipped, whether it passed an audit, or whether it is still running a year later.

The industry spread is where the number gets interesting. Technology firms lead at 41%, followed by healthcare payers and providers at 39%, professional services and energy and materials at 38%, financial institutions at 36%, media and telecom at 34%, and pharma at 33%. At the bottom, a long way down: insurance at 19% and the public and social sector at 17%.

McKinsey senior partner Lieven Van der Veken framed the shift as a posture change, not a cost play: organizations moving fastest are "becoming more deliberate about where to buy, where to build, and where to develop enough internal capability". That is a defensible reading. The one your engineering team is about to give you at the renewal meeting will be simpler: the license costs $400,000 and Cursor can build it in a sprint.


The Same Survey Says It Never Reached EBIT

If a third of organizations stopped buying software, that saving should be visible somewhere in the P&L. It is not. The share of respondents reporting any EBIT impact from AI held at 37%, unchanged year over year, and the 6% who attribute at least 5% of EBIT to AI was also flat. Meanwhile 20% of respondents said AI-related operating costs have already limited how much technology they use.

Two readings fit. The charitable one is timing: a purchase avoided in Q1 shows up in EBIT over years, and McKinsey's Michael Chui called it "a journey, not a destination". The uncharitable one is that the avoided license was never the expensive part, and the cost that replaced it lands in a different budget line — headcount, on-call, security remediation — where nobody is tracking it against the software savings that justified the decision. The pattern is familiar to anyone who has watched CFOs try to reconcile AI spend against a P&L.


Coding Agents Cut the Cheapest Line in the Budget

Writing the first version of a system is the smallest cost it will ever incur. Estimates of maintenance as a share of software lifecycle cost cluster between 60% and 90%; a 2013 peer-reviewed paper, citing earlier estimates, puts it at roughly 90% of the cost of the software's life. Run cost is everything after the first release: bug fixes, dependency upgrades, security patching, integration repair when an upstream API changes, compliance evidence, and the person who gets paged when it breaks.

Agents are demonstrably good at the first line and demonstrably weak at the rest. Stanford research cited in Google's DORA ROI analysis puts the gain at 35 to 40% on simple, greenfield tasks and 10% or less on complex legacy code — and DORA's own ROI model assumes change failure rate rises from 5% to 6% after AI adoption, a $344,000 downtime charge in its worked example. METR's randomized controlled trial is sharper still: 16 experienced developers working on repositories averaging 22,000 stars and over a million lines of code took 19% longer with AI tools, while believing they had been sped up by 20%. Date that one before you quote it: the trial ran in early 2025 on that year's models, and METR has since said it believes developers are more sped up now than that estimate — while conceding its own follow-up data is "only very weak evidence" for the size of the change, because developers who will not work without AI now select themselves out of the control group. The direction holds. The magnitude is contested, including by the people who measured it. Greenfield is where agents win. A mature codebase is where they lose. The system you build this quarter becomes a mature codebase.

The maintainability data points the same way. GitClear's analysis of 623 million changes from 2023 to 2026 found duplicated code blocks up 81%, cross-file function calls down 35%, refactoring collapsing from 21% of line movement in 2022 to 3.8% year-to-date, and long-term legacy maintenance down 74%. Security is flat: Veracode's July 2026 report found the average security pass rate across models stuck at 56%, with roughly 44% of code-generation tasks introducing a known vulnerability when the prompt does not ask for security. The best model in the snapshot, GPT-5.5, still failed nearly one in three security tasks.

And the patching treadmill you inherit is getting steeper. NIST announced in April 2026 that it enriched nearly 42,000 CVEs in 2025 — 45% more than any prior year — and still could not keep up, so the National Vulnerability Database now prioritizes CVEs in CISA's KEV catalog, federal software, and EO 14028 critical software. Everything else is still logged, but marked lowest priority and not scheduled for analysis — your triage problem now. When you bought the SaaS, it was the vendor's.


Insurance Said 19 Percent. That Is the Tell.

Some of that 19% and 17% is ordinary lag, and it is worth conceding before building an argument on it. McKinsey's own July 2026 public-sector research scores government lowest of any sector on AI adoption, 28 against a 33 cross-industry average, held back by rigid procurement, fragmented data and high operating costs. But lag closes on its own, and this gap has a reason not to. In these two sectors the thing you buy from a software vendor was never primarily the code. It was evidence, and someone else's liability.

An insurer running AI in underwriting, rating, claims or fraud now operates under the NAIC Model Bulletin, adopted by 24 states plus DC as of early 2026. It requires a written AI Systems Program with board accountability, documented validation and retesting, and — the part that prices build-versus-buy — contractual audit rights over third-party AI, because regulators have signalled they will "look through" vendor relationships during examinations. A vendor sells you that documentation package as a line item. Build it yourself and you are producing model validation reports, bias testing and lineage evidence for an examiner, forever, with your own actuaries.

The public sector's version has a price tag you can look up. FedRAMP authorization runs roughly $250,000 to $500,000 at Low and $1 million to $2 million-plus at Moderate, with $50,000 to $400,000 a year in continuous monitoring and a 12-to-18-month timeline at Moderate. That is what a government buyer is actually purchasing when it buys authorized SaaS — and why one procurement clause can lock half a vendor field out of a $91.8B market, and why an agency deployment gets shaped by which models hold an IL5 authorization rather than by which models are best.

Seventeen percent is not only slower adoption. It is also a sector that has already priced the run cost and found that building does not clear it.


The Case for Building Is Real This Year

The strongest version of the build argument is not that agents are cheap. It is that SaaS pricing has stopped behaving. Vertice — a procurement platform that sells SaaS cost reduction, so weigh the source — puts SaaS price inflation at 16.4% in June 2026 across the $75 billion-plus of spend it manages, the highest it has recorded and up from 12.1% in April. Against a vendor raising 16% a year on a product you use three features of, a maintained internal build is a genuine option, and the leverage of being able to say "we can build this" is worth something at the table even if you never do.

Where building actually wins is narrow and identifiable: a thin internal tool with one integration, no regulated data, no external users, an owner who will still be there in two years, and a vendor whose price is set by seats you do not need. That is a real category. It is not a CRM, an HRIS, or anything that produces evidence for a regulator.

Steel-man it with the most-cited case and it gets weaker, not stronger. Klarna's 2024 announcement that it was shutting down Salesforce and Workday is the story every engineering team cites. What it actually did was replace them with other SaaS — Deel for HR, assorted tools for CRM — with AI layered over a consolidated stack. The famous SaaS-killing was a SaaS-to-SaaS migration with a better negotiating position. That is a fine outcome. It is not the one being proposed in your renewal meeting.


What to Price Before You Cancel the Renewal

Treat a build proposal like a vendor proposal: make it produce a five-year number, not a sprint estimate.

This Week:

  1. Ask the team proposing the build for a named owner and a named backup, by person, for years two through five. If the answer is "the platform team," the proposal has no owner.
  2. Pull the actual usage data on the contract you are about to cancel. Most build-versus-buy arguments are really "we use 3 of 40 features" arguments, and that is a negotiation, not a build.
  3. Write down what the vendor contract gives you that code does not: SOC 2 or FedRAMP evidence, indemnification, breach notification, a support SLA, and a named party who is liable. Price each line at zero and see whether the business signs it.

This Month:

  1. Require the build proposal to carry a run-cost line at 15-25% of build cost per year, and to name which budget it comes from. If it lands in the engineering headcount plan rather than the software line, the "saving" is a transfer.
  2. Add an independent review gate. A coding agent reviewing another agent's output is not independence — the same vendor writing and reviewing the code is a control gap, and it is the exact gap the DORA change-failure-rate number is measuring.
  3. Force the spec into a machine-checkable form before the agents start. Writing the contract in code rather than prose is the difference between a system you can regenerate and one you can only patch.

Before Renewal:

  1. Run the build-to-buy spectrum on the specific capability, not the whole product. The right answer is usually to buy the hard, regulated, integrated core and build the thin layer on top — the same conclusion that holds for RAG, where you buy the index and build the eval set.
  2. Check the dependency you are creating on the coding tool itself. GitHub Copilot, Devin and their peers are vendors too, with their own roadmaps and model-access terms — as teams found when OpenAI cut Cursor's model access with a dated deadline. You do not remove vendor risk by moving it upstream.
  3. If you still want to build, build one thing, instrument its run cost separately, and re-read the number in twelve months before you cancel the second contract.

The Bottom Line

Every platform cycle has produced a moment when the cost of writing software fell far enough that buying looked foolish — 4GLs, Visual Basic, Rails, low-code. Each time, the organizations that built everything discovered that the writing was never the expensive part, and each time the sectors with auditors and regulators figured it out first, because their auditors made them count. Agentic coding is a bigger drop than any of those. It is a drop in the same line item.

The 32% is real and the 37% is real, and the gap between them is the whole story. McKinsey's own framing is the useful one: this is about agency, about choosing deliberately where to build. Cancelling a renewal because a demo compiled is not agency. It is a purchase order moved to a payroll line where nobody will audit it.

You did not save the license. You bought the next five years of it.

Continue Reading

Share:

Frequently Asked Questions

What did McKinsey's State of AI 2026 survey find about building software instead of buying it?

In a survey of 1,719 business leaders, 32% of organizations said they decided against buying at least one software product or feature because they could build the functionality internally with agentic coding tools. The figure ranged from 41% in technology down to 19% in insurance and 17% in the public and social sector.

If a third of companies stopped buying software, why didn't AI show up in earnings?

The same McKinsey survey found the share of respondents attributing any EBIT impact to AI stayed flat at 37%, and the 6% attributing at least 5% of EBIT to AI was flat too. Avoided licenses are a small share of software lifetime cost, and the cost that replaces them lands in headcount, on-call and security budgets rather than the software line.

What share of software cost is maintenance rather than initial development?

Published estimates put maintenance at roughly 60% to 90% of total software lifecycle cost, with peer-reviewed work citing figures around 90%. A common budgeting rule of thumb is 15% to 25% of the original build cost per year, higher in regulated industries.

Are AI coding agents as effective on existing systems as on new ones?

No. Stanford research cited in Google's DORA ROI analysis puts the gain at 35 to 40% on simple greenfield tasks but 10% or less on complex legacy code. METR's early-2025 randomized controlled trial found 16 experienced developers took 19% longer on mature million-line repositories when allowed to use AI tools, while believing they were 20% faster. METR said in February 2026 that it now believes developers are more sped up than that figure suggests, but that its follow-up data is only very weak evidence for how much.

When does building instead of buying actually make sense in 2026?

When the capability is thin, has one integration, touches no regulated data, has no external users, has a named owner for the next several years, and the vendor is charging for seats or features you do not use. It rarely makes sense for systems that must produce validation, audit or authorization evidence for a regulator.

Newsletter

Stay Ahead of the Curve

Weekly enterprise AI insights for technology leaders. No spam, no vendor pitches—unsubscribe anytime.

Subscribe

Latest Articles

View All →