Signal
Insights September 7, 2026

McKinsey Says a Third of Companies Skipped Buying Software This Year and Built It Instead. Separate Research Says Most of Those Builds Fail.

McKinsey's State of AI 2026 survey, published August 25, found 32 percent of organizations skipped a software purchase this year because agentic coding tools let them build the functionality in-house instead — nearly half among AI 'high performers.' Separate MIT-linked research puts the success rate for internally built AI systems at roughly a third, versus two-thirds for vendor tools. The gap between those two numbers is a hiring decision, not a tooling decision.

McKinsey published its 2026 State of AI survey on August 25, and the number that should land on every CTO's desk is 32 percent. That's the share of organizations (out of 1,719 respondents across 97 countries, surveyed between May and June) who decided against buying at least one piece of software this year because agentic coding tools let their own team build the functionality instead. Among the 6 percent of respondents McKinsey classifies as AI "high performers" (companies attributing at least 5 percent of EBIT to AI), that number jumps to nearly half. On a broader measure in the same survey, large enterprises scaling AI agents across one or more functions rose to 40 percent, up from 27 percent the year before. Technology companies lead the build decision at 41 percent; insurance and the public sector trail at under 20 percent.

Lieven Van der Veken, a McKinsey senior partner, framed the shift as a posture change rather than 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's the optimistic read, and it's real. Coding agents genuinely lower the cost of standing up custom internal tooling. But "we decided not to buy it" and "we successfully built it" are two different sentences, and the survey only measures the first one. Separate research pointed at that exact gap is less flattering. MIT's NANDA initiative, in its widely-cited study of enterprise AI deployments (structured interviews with 52 organizations, survey responses from 153 senior leaders, and analysis of roughly 300 public AI projects), found internally built systems succeed at roughly half the rate of vendor-purchased ones. That's about 33 percent versus 67 percent. The researchers frame the gap as a learning problem rather than a technology one. "The core barrier to scaling is not infrastructure, regulation, or talent. It is learning," the report says. "Most GenAI systems do not retain feedback, adapt to context, or improve over time." My own reading of that is narrower: vendor tools have usually already absorbed the integration and iteration work internal teams skip, because internal teams tend to treat "the model works in a demo" as the finish line instead of the starting point.

Put the two studies next to each other and you get a specific, unglamorous warning. A third of the market just decided to build instead of buy. Something close to two-thirds of internal AI builds don't make it past the point McKinsey's survey stops measuring: the decision to build, not the delivered system. Those aren't contradictory numbers. They're the same trend, viewed from before and after the demo.

Here's where it becomes a staffing question instead of a strategy slide. "Build, don't buy" doesn't remove engineering cost: it relocates it from a vendor's license fee to your own payroll, and specifically onto the engineers who do the unglamorous back half of the work: hardening a prototype an agent scaffolded in an afternoon, wiring it into existing systems, writing the tests nobody asked for in the demo, and owning what happens when it breaks in production eighteen months from now. Shubham Jindal, director of AI at Harness, spent two years building AI systems inside an enterprise software company and reduced the lesson to two sentences: "The demo is the easy part. The system is the hard part." That's not the same skill as prompting a coding agent to get something working by Friday. Plenty of teams have someone who can do the first part. Fewer have budgeted for someone who can do the second, and the MIT numbers are a rough proxy for how many teams found that out the expensive way this year.

If your organization is one of the 32 percent that chose to build this year (or is about to be), the hire that determines which side of the 33/67 split you land on isn't the person who stood up the first working version. It's the senior engineer who's still there maintaining it after the vendor comparison is a distant memory and the thing has to actually run the business. Budget for that person before the build starts, not after the pilot stalls and someone asks why the "free" internal tool needs a headcount request to keep alive.


VC5 Consulting places the senior software engineers who carry an internally built system past the demo — the difference between the third of builds that survive and the two-thirds that don't. If your team chose "build" this year and the person who can own that outcome for the next three years isn't on staff yet, let's talk.