September 17, 2026
McKinsey's [The State of AI: Global Survey 2026](https://www.mckinsey.com.br/capabilities/quantumblack/our-insights/the-state-of-ai) surveyed 1,719 respondents across 97 countries between May 4 and June 8, 2026, and landed on a figure worth sitting with: 32% of organizations decided against buying at least one software product or feature because they could build it internally using agentic AI coding tools. That's not a rounding error or a fringe habit among scrappy engineering teams. It's roughly a third of surveyed organizations making a deliberate build-over-buy call, often about something that used to be an automatic line item in the SaaS budget.
The number gets more interesting when you break it down by sector. Technology leads at 41%, which is unsurprising—those teams already have engineers and AI coding tools on hand. But healthcare payers and providers aren't far behind at 39%, and professional services and energy and materials both sit at 38%. These are not industries known for do-it-yourself software culture. When hospital systems and materials companies are turning down vendor pitches at nearly 4-in-10 rates, the behavior has moved well past early adopters.
The most important detail in McKinsey's data isn't the topline 32%—it's who's driving it. Among McKinsey's 'high performers,' the 6% of respondents attributing at least 5% of EBIT to AI, nearly half skip software purchases in favor of building, compared with 31% of everyone else. In other words, the organizations getting the most measurable financial return from AI are also the ones most willing to walk away from a vendor contract and build the thing themselves.
That correlation cuts against the instinct that DIY software is inherently a corner-cutting move made by teams without budget or patience for procurement. If build-over-buy were mostly a risk-taking shortcut, you'd expect it to show up more among AI laggards experimenting recklessly, not among the companies squeezing the most profit out of their AI investment. Instead, it looks like a marker of AI maturity: the more competent an organization gets at deploying AI broadly, the more confident it becomes that internal builds can match or beat a vendor's product for its specific need.
The scaling data backs this up. Large enterprises with $1 billion or more in revenue have jumped to 40% now scaling agents in one or more business functions, up from 27% the prior year. That's a 13-point jump in a single year, at the largest and most risk-averse companies in the sample. When enterprises with the most to lose from a bad automation bet are scaling agents that fast, the build-over-buy trend isn't a phase—it's becoming standard operating procedure.
Here's where we push back on the uncritical read of this data. A lot of that 32% is, right now, an engineer with Cursor or GitHub Copilot open, cranking out a working internal tool over a weekend because it was faster than filing a purchase request. That's a real win—it proves the economics of build-over-buy—but it's also a narrow one. A script that works on one engineer's machine is not the same thing as software the rest of the company can log into, trust with sensitive data, and still be running in eighteen months when that engineer has moved teams or left the company entirely.
This is the gap nobody's counting in McKinsey's survey: how much of that 32% is actually hosted somewhere reliable, secured against the kind of access mistakes that turn an internal tool into a liability, and usable by the finance, ops, or support person who needs it—not just the developer who built it? Our guess, based on how agentic coding tools are typically used today, is not much. Most of these builds solve the demo problem and quietly stall out before they solve the production problem. They rot in a private repo, or they become one more thing IT has to explain when someone asks who owns it.
Our take: McKinsey's data proves the economic logic of build-over-buy is now mainstream, but the tooling gap it exposes belongs to platforms built for the whole business to operationalize AI-generated software—not just for people who already know how to code. That's the actual hard problem. Getting an AI coding agent to generate a working prototype is the easy 80%. Getting that prototype hosted, permissioned correctly, integrated with the systems your team already uses, and maintainable by someone in ops rather than someone in engineering is the 20% that determines whether the 32% urge to build turns into a durable capability or a pile of abandoned scripts. That's the case we make in more detail on our Buy vs. Build vs. ViibeStack page, and it's the design premise behind the AI App Builder itself—non-engineers building and keeping software running, not just prompting a first draft.
A fair reader could disagree with this framing. Maybe the engineering-team-hand-rolls-it model scales better than we think as agentic coding tools themselves get better at producing production-grade, documented, secure code without a no-code layer in between—in which case the market converges on 'better agents for engineers' rather than 'app builders for everyone.' We don't think that's the likely outcome, because the maintenance and access-control burden doesn't go away just because the code got better; someone still has to own uptime, permissions, and updates, and most of the people who need the software aren't the people who can debug it. But it's a real bet, not a foregone conclusion, and it's worth watching how role-based permissions and hosting concerns show up—or don't—in next year's McKinsey survey.
If you're staring at a SaaS renewal right now, the McKinsey numbers are a legitimate reason to ask whether that specific feature or product could be built instead—especially if your organization already has some AI maturity, given how strongly build-over-buy correlates with McKinsey's high-performer segment. But ask the harder question before you commit: who's going to host it, secure it, and still be maintaining it a year from now when the person who built it has moved on? If the honest answer is 'nobody, really,' that's the signal you need a platform designed for that handoff, not just an agent that's good at writing the first version.
Sources