BusinessIndustry Guide7 min readPublished September 1, 2026

Building got easy. Benefiting did not

A Third of Companies Skipped Buying Software and Built It

McKinsey’s 2026 State of AI survey has a number that software vendors will not enjoy: nearly a third of organisations have declined to buy something because a coding agent could build it. It has a second number that the builders should read just as carefully: the share seeing any profit impact from AI has not moved in a year.

DA
Digital Applied Team
Senior strategists · Published Sep 1, 2026
PublishedSep 1, 2026
Read time7 min
SourcesMcKinsey Global Survey
Declined a software purchase to build instead
32%
of 1,719 respondents; nearly half among AI high performers
Attribute any EBIT impact to AI
37%
essentially unchanged from 2025
AI high performers
6%
≥5% of EBIT from AI and “significant” impact; flat year on year
Constrained by AI operating costs
1 in 5
including token costs; high performers 3× as often on coding agents

McKinsey published the 2026 edition of its State of AI survey on August 25, 2026, and one finding travelled faster than the rest. “Nearly a third of respondents (32 percent) report that their organizations have decided against buying one or more software products or features because they could be built internally with agentic coding tools.” The survey drew 1,719 responses across 97 countries between May 4 and June 8, weighted by each country’s share of global GDP. The report gives no prior-year figure for it, so there is no trend line yet. There is, however, a companion finding that gives the 32% its meaning.

The share of organisations attributing any impact on earnings before interest and tax to AI is 37%, which McKinsey describes as “essentially unchanged from a year ago.” The share of high performers, organisations that credit at least 5% of EBIT to AI and call the impact significant, is flat at about 6%. So the survey describes a year in which AI became capable enough to replace purchased software, and in which the number of companies making money from it did not grow. Both things are true, and the useful question for a business is what separates the companies in the first group from the second.

Key takeaways
  1. 01
    The build-instead-of-buy decision is now mainstream.32% of all respondents, and nearly half of AI high performers versus 31% of everyone else, declined at least one software purchase because coding agents could produce the functionality in-house. Most common in technology and healthcare, then professional services and energy.
  2. 02
    Profit impact did not move.37% attribute any EBIT impact to AI, the same as 2025, and high performers stay at 6%, even as 44% now report AI scaling across the enterprise, up from 38%. Individual productivity gains, reported by 80%, have not turned into enterprise returns for most.
  3. 03
    High performers redesign the workflow, not just the tooling.McKinsey’s account of the 6%: they pursue growth or innovation alongside efficiency, “fundamentally redesign workflows that are enabled by AI rather than insert AI into existing ones,” and are twice as likely to have leaders visibly committed.
  4. 04
    Cost is the constraint arriving next.One in five organisations say AI operating costs, including tokens, already limit their use. High performers report cost constraints on coding agents about three times as often as others, because they use them most.

01The findingOne question, and what the unit is.

The survey’s own framing is careful. The full sentence in the report reads: “Coding agents are emboldening companies to build their own software rather than purchase it. Nearly one-third of respondents (32 percent) report that their organizations have decided against purchasing at least one software product or feature because they were able to build the functionality in-house using agentic coding tools.” Note the unit. It is one product or feature, at least once. A company that built a single reporting dashboard instead of buying a seat licence counts the same as one that replaced its customer platform. McKinsey adds that this “could be a sign that AI is beginning to reshape how technology budgets are allocated,” which is about as far as the evidence goes. The table below puts the number in the context of the survey’s adoption figures, all from the published report.

Selected findings from McKinsey’s “The state of AI in 2026: On the road to ROI,” published August 25, 2026. Online survey, May 4 to June 8, 2026, 1,719 participants in 97 nations, weighted by each nation’s contribution to global GDP. “Large” means annual revenue above $1 billion.
Finding20262025Note
Declined a software purchase because agents could build it32%no prior figure givenNearly half of high performers vs 31% of others; most common in technology and healthcare
Scaling software coding agentsabout 2 in 1031% at large enterprises; high performers twice as likely
Large organisations scaling AI agents40%27%Smaller organisations flat at 22%
AI scaling across the enterprise44%38%54% of large organisations vs one-third of smaller ones
Attribute any EBIT impact to AI37%about 37%“Essentially unchanged”
AI high performers (≥5% of EBIT, “significant”)about 6%about 6%Flat
AI operating costs constrained useabout 20%Consistent across sizes and industries; 60% still plan to invest more
Expect AI-related workforce decline next year39%32%Only 14% report an actual decline over the past year

02The tensionBuilding rose. Benefiting did not.

Read the table top to bottom and a pattern appears that the headline hides. Every measure of doing more with AI went up: enterprise-wide scaling, agent deployment at large companies, functions covered, budget share. The one measure of getting paid for it stayed still. McKinsey’s own summary is direct about this: “Organizations’ conviction in AI is growing faster than the immediate financial returns they can attribute to it.” Eighty percent of respondents say AI improved their individual productivity and half say it helps them make better decisions, and those gains, in the report’s words, “have yet to translate into broad financial impact for organizations.”

The build decision sits inside that gap. Declining to buy a product because you can build it is an act of capability, not of return. Whether it pays depends on what happens next: whether the thing you built replaced a real cost, whether it changed how work is done, and whether anyone maintains it in year two. The survey cannot see any of that, and it does not claim to. What it can see is that the group most likely to build, the high performers, is also the group most likely to report the other behaviours that the report associates with returns. That correlation is the interesting part, and it runs through workflow design rather than through tooling.

What a “feature” costs to keep

McKinsey’s question counts a decision, not an outcome. A team that builds a feature in-house with a coding agent takes on the maintenance, the security review and the migration burden that the vendor was pricing into the licence. The survey offers one hint about where that lands: high performers report being constrained by costs in their use of coding agents about three times as often as others. The companies building the most are the ones already paying attention to what building costs.

03The 6%What the companies making money actually do.

McKinsey defines high performers as respondents who attribute at least 5% of EBIT to AI and describe its impact as significant. They are 6% of the sample, the same as last year, and the report devotes its longest section to how they differ. Four differences matter for the build-versus-buy question specifically.

Difference one
They redesign the work
Workflow first, tool second

The report’s central claim: high performers “fundamentally redesign workflows that are enabled by AI rather than insert AI into existing ones.” Building a tool to fit an unchanged process is the pattern the 37% describes; changing the process and then building for it is the pattern the 6% describes.

The defining behaviour
Difference two
They build more, and buy less
Nearly half declined a purchase

High performers are twice as likely as others to be scaling coding agents and 2.7 times more likely to be scaling other agentic AI. Nearly half report deciding against a software purchase because they could build it, against 31% of other respondents.

The build gap
Difference three
They aim past efficiency
Growth and innovation, not only cost

Around 80% of both groups pursue efficiency. Most high performers also use AI to pursue growth or innovation, and they are 3.3 times more likely to intend to fundamentally transform their business within three years. A tool built to cut a cost has a ceiling; one built to sell something new does not.

Ambition
Difference four
They pay for it, and manage the risk
More than 15% of ICT budget

High performers are more than twice as likely to spend over 15% of their technology budget on AI, twice as likely to report visibly committed senior leaders and defined measurement processes, and much more likely to be working on AI-driven vulnerabilities and unintended actions.

Commitment and rigour

None of those four is a technology choice. The survey is about a group of companies that changed how they operate and then found that coding agents let them build what the new operation needed. The reverse order, buying the agent first and looking for something to build, is what produces a feature that was cheaper than the vendor’s and changes nothing. Our earlier case for custom tools over branded software made the same argument from cost; McKinsey’s data makes it from outcomes.

04ConstraintThe cost that is starting to bite.

About one in five respondents say AI-related operating costs, which McKinsey specifies as including token costs, have constrained their organisation’s use of AI. The report calls this “a meaningful consideration, but not yet a widespread constraint,” and the share is broadly consistent across company sizes and industries. For each of the three tool types the survey asks about, chatbots, agents and coding agents, about one in ten say cost has limited use. At the same time, 28% of organisations spend more than a tenth of their technology budget on AI and 60% expect to increase AI investment next year.

The build-versus-buy reader should hold two of those facts together. A purchased product has a price that is known in advance and mostly fixed. A built one has a token bill that scales with use, and the survey shows the heaviest builders are the ones already feeling it. That does not argue against building. It argues for pricing the run cost of a built feature the way a vendor would have, before the decision rather than after. The arithmetic for doing that on the current model price sheets is in our maintained per-million-token price index.

05The decisionWhich purchases to decline, and which to keep paying for.

The survey does not say which products the 32% declined, only that technology and healthcare organisations declined most often, followed by professional services and energy. The high-performer findings do suggest a rule for deciding, and it is the one we apply in our own work: build where the workflow is yours and the software would have shaped it; buy where the workflow is generic and the vendor’s scale is the value.

The process is specific to how you operate
A quoting engine, an operations dashboard, a customer-facing form that mirrors your own steps. The purchased version would force your process into its shape. This is where high performers redesign the workflow and build to fit it, and where the 32% is concentrated.
Build with coding agents
The function is generic and scale is the product
Payments, email delivery, accounting ledgers, identity. The vendor’s value is compliance, uptime and a thousand edge cases you will never hit first. Building here replaces a known price with an unknown maintenance burden.
Keep buying
You want one feature the vendor charges a tier for
The commonest case in the survey’s wording: a product or feature. Build the feature against the vendor’s data, keep the vendor. Price the token cost of running it and name an owner for year two before you cancel the upgrade.
Build the feature, keep the platform
You are replacing a system people rely on daily
The decision with the largest downside. Run the built system read-only beside the old one until it has earned trust, and treat the cutover as the project rather than the build.
Build, then roll out slowly

The last row is the one the survey’s optimism can obscure. A coding agent makes the build fast; it does nothing for the adoption. Our guide to replacing an internal system safely covers the read-only rollout pattern that turns a built replacement into a used one. And for the marketing function in particular, where “features” are often reports and automations rather than systems, the marketing tasks worth handing to a coding agent lists the ones that pay back first.

06ConclusionThe capability is real. The return is a separate decision.

McKinsey State of AI 2026

A third of companies can now build what they used to buy. The six percent making money from AI changed the work first, then built for it.

The 32% figure will be quoted for a year as evidence that software procurement is changing, and it is. It should be quoted next to the 37%, which says that for most organisations the change has not yet reached the income statement. McKinsey’s reading is that conviction is running ahead of returns. Ours is that building has become the easy half of the decision.

The companies the survey holds up as the model did not start by asking what they could build. They redesigned a workflow, set a growth goal rather than only a cost goal, committed budget and leadership to it, and then found that coding agents let them make exactly what that redesign required. Declining a vendor quote is the last step in that sequence. Taken first, it is a cheaper way to change nothing.

Build where the workflow is yours

Declining the quote is the last step, not the first.

We help operators decide which purchases to decline and which to keep, redesign the workflow before the build, and price the run cost of a built feature so the decision is made on returns rather than on what a coding agent can do.

Free consultationExpert guidanceTailored solutions
What we work on

Build-versus-buy engagements

  • Workflow redesign before any tooling decision
  • Build-or-buy scoring for each purchase under review
  • Run-cost pricing for built features
  • Read-only rollouts for system replacements
  • Year-two ownership and maintenance plans
FAQ · McKinsey State of AI 2026

The questions we get about building instead of buying.

That 32% of respondents say their organisation decided against buying at least one software product or feature because it could be built in-house with agentic coding tools. The unit is one product or feature, at least once. Among AI high performers the share is nearly half; among everyone else it is 31%. The report gives no prior-year figure for this question, so there is no year-on-year comparison.
Related dispatches

Continue exploring build versus buy.