Build vs buy AI features: what McKinsey's 2026 data means for a 50-person team

For a 50-person company, buying an AI feature usually beats building it in-house, unless you already have spare engineering capacity dedicated to owning that build long-term. McKinsey's 2026 State of AI survey found nearly a third of respondents skipped a software purchase and built the equivalent themselves with agentic coding tools instead, but that shift is concentrated in organizations with the headcount to maintain what they build. Most 50-person teams don't have that headcount to spare.

Why "just build it" sounds cheap right now

A leader reads that Claude Code or a similar agentic tool can produce a working feature in days, and the pitch to the team becomes obvious: why pay a vendor when an engineer with an AI coding assistant can knock this out in a sprint? The demo works. The prototype ships. Then the vendor's edge cases show up, the one engineer who built it moves to a different project, and nobody owns the thing anymore.

That's the gap between "an agentic coding tool can generate this code" and "our team can own this code for the next three years." The first is now cheap. The second was never cheap, and coding assistants don't change that math.

What McKinsey's 2026 data actually shows

Brandon Vigliarolo reported for The Register on August 25, 2026 that McKinsey's State of AI 2026 survey found nearly a third of respondents "decided against buying one or more software products or features in favor of building the functionality in-house with agentic coding tools." The same report found agentic AI use scaling fastest at large organizations: 40% of respondents at companies with more than $1 billion in annual revenue said they were scaling AI agents, up from 27% the year before.

A separate wire piece syndicated by Yahoo Finance on September 1, 2026, "The Build-vs-Buy Shift: 32% of Enterprises Bet on Agentic Coding Tools," breaks the build-in-house trend down further. It reports that "nearly half" of McKinsey's "high performers" (the 6% of respondents who attribute at least 5% of their EBIT to AI) are skipping software purchases entirely, compared with 31% of their peers. Large enterprises over $1 billion in revenue show 40% scaling agents in one or more functions.

Both figures describe the same underlying survey and point the same direction: building in-house with AI coding tools is real and growing, and it's most common at the largest, most AI-mature organizations.

Why the "high performer" number doesn't transfer to a 50-person team

Here's the part that gets lost when this data gets used to justify a build decision at a smaller company: the "nearly half" figure applies to McKinsey's high performers, a group defined by already attributing 5%+ of EBIT to AI. Those are organizations that have already built AI platform teams, eval infrastructure, and the internal review process needed to catch what agentic coding tools get wrong. The 40%-of-large-enterprises figure describes companies with more than $1 billion in revenue, who can absorb a dedicated internal team owning one feature indefinitely.

A 50-person company is neither. Most engineering teams that size are already stretched across the product roadmap, with nobody who can be assigned to permanently own one internal AI feature. Building without that dedicated capacity doesn't reproduce McKinsey's high-performer outcome. It produces a different, more common outcome: a working prototype with no assigned owner, no update cadence, and no plan for what happens when the underlying model API changes or a security patch is needed.

The real cost of a build without spare capacity

The build itself might take a week with an agentic coding tool. What it costs afterward is the part that doesn't show up in the sprint estimate:

• Nobody owns it. The engineer who built it has moved to the next roadmap item, and now a support ticket about the feature has no clear owner.
• It doesn't get updated. Model providers change APIs and pricing regularly. A one-off internal build has no maintenance budget, so it breaks quietly and stays broken.
• It never gets the eval and monitoring layer that a vendor's product already has, so failures are invisible until a customer or employee notices.
• The next engineer to touch it has to reverse-engineer it, because the person who built it under deadline pressure didn't have time to document it.

None of this shows up in "can Claude Code build this in a week." It shows up eight months later, when the feature is quietly broken and everyone who could explain it has moved on.

How to build without creating an orphaned liability

The fix isn't to default back to buying everything. Some features genuinely are cheaper and better to build now, and the agentic coding tools that made McKinsey's build-in-house number climb are real. The fix is making sure the build has an owner from day one, not just a builder for the first sprint.

If the decision is "we're building a real product feature and need to own it long-term," the honest answer is bringing in a dedicated build team so the work doesn't fall on an already-stretched internal team. That's what a SaaS MVP build is for: shipping the feature with the same team responsible for the architecture decisions that determine whether it's maintainable in year two, not just demoable in week one.

If the decision is closer to "we need an internal tool or workflow automation, not a customer-facing product," the calculation is different. An internal build usually doesn't need a full product team, it needs someone who can build it right and hand off something your team can actually run. That's the case for custom automation work scoped specifically to internal tooling, built with maintenance and handoff built into the scope instead of assumed away.

Either path solves the actual problem in the McKinsey data: agentic coding tools made the build cheap, but they didn't create the spare capacity to own what gets built. Someone still has to.

FAQ

Is it cheaper to build an AI feature in-house or buy a tool in 2026?

It depends on whether you already have spare engineering capacity to own the build long-term. Agentic coding tools have lowered the cost of the initial build, which is why nearly a third of McKinsey's 2026 survey respondents chose to build in-house instead of buying software. But the ongoing cost of owning, updating, and monitoring that build didn't drop, and that's the cost most teams underestimate.

What percentage of companies are building AI features in-house instead of buying software?

Nearly a third of respondents in McKinsey's State of AI 2026 survey reported skipping a software purchase to build the equivalent functionality in-house with agentic coding tools, according to The Register's August 25, 2026 reporting. Among McKinsey's "high performers," the 6% of respondents attributing 5%+ of EBIT to AI, that figure rises to nearly half, compared with 31% of their peers.

Does McKinsey's build-in-house data apply to smaller companies?

The strongest build-in-house numbers in McKinsey's 2026 survey come from large enterprises (over $1 billion in revenue, 40% scaling agents in-house) and from "high performer" organizations that already have dedicated AI platform teams. A 50-person company without spare engineering capacity to permanently own a build isn't the population that data describes, so the same conclusion doesn't automatically transfer.

What's the risk of building an AI feature without dedicated ownership?

The build ships, then loses its owner when the engineer who built it moves to the next roadmap item. Without a maintenance plan, the feature breaks quietly when a model API changes, has no monitoring to catch failures, and becomes harder to fix the longer it sits undocumented.

When should a 50-person company build instead of buy?

Building makes sense when the feature is core to the product and you're willing to staff a dedicated team to own it past the initial sprint, structured as a proper build engagement rather than a side project for whoever is available. When the need is an internal tool rather than a customer-facing feature, a scoped automation build with handoff included is usually the lower-risk path.

How do I decide between a SaaS MVP build and a custom automation project?

If the output is a customer-facing product or feature that needs to scale and get maintained over years, that's a SaaS MVP build. If the output is an internal workflow or tool your own team needs to run, that's a custom automation project, typically smaller in scope with a faster handoff.

---

Sources: The Register, "McKinsey says enterprise AI is finally 'on the road to ROI'," Aug 25, 2026, Yahoo Finance, "The Build-vs-Buy Shift: 32% of Enterprises Bet on Agentic Coding Tools," Sept 1, 2026