AI Build Versus Buy: How to Make Better Ownership Decisions

In this article9 min read

A line in software procurement has moved.

In McKinsey’s 2026 global AI survey, 32% of relevant respondents said their organisation had decided against buying at least one additional software product or feature because the functionality could be built internally using AI coding tools.

That makes AI build versus buy a live leadership question. Coding agents can turn a requirement into working code quickly enough to make internal development credible where it once looked uneconomic. A supplier quotation is no longer being compared only with months of conventional development. It may be compared with a convincing prototype produced in days.

But a prototype and a supported service are not equivalent options. The visible cost of creation may have fallen. The organisation still has to integrate, secure, test, operate, support, change and eventually retire what it creates.

AI changes the price of creation. It does not repeal the obligations of ownership.

The AI build versus buy threshold has moved

The state of AI in 2026: On the road to ROI shows the change most clearly in larger organisations. Thirty-one per cent of respondents from organisations with at least $1 billion in annual revenue reported scaling software coding agents, compared with 17% at smaller organisations.

The purchase effect appears across every industry shown in the report. It is most commonly reported in technology at 41%, followed by healthcare payers and providers at 39%, professional services at 38%, and energy and materials at 38%. Those industry samples vary considerably—healthcare’s result is based on 47 respondents—so the ranking should not be treated as a stable league table.

There is a more important qualification. The survey question is satisfied whether an organisation avoided buying one small feature or replaced a substantial product. It does not tell us whether the internal alternative was completed, adopted, secure, reliable or cheaper over its useful life.

The finding establishes optionality, not economic superiority. Coding agents have not settled the build-versus-buy question. They have made it worth asking again.

The comparison is code versus complete service

The easiest mistake is to compare the cost of an internally generated first version with the price of a mature commercial product. One side contains code. The other may contain hosting, security updates, support, documentation, service management, compliance evidence, resilience and a roadmap.

That does not make buying automatically better. Supplier lock-in, poor workflow fit, weak integration and expensive customisation can make a commercial product the wrong choice. It does mean the two options need the same denominator.

The UK Government Service Standard requires teams to understand the total cost of ownership, show good decisions about what to build and buy, and preserve the ability to change direction. Its purchasing guidance makes the lifecycle explicit: building or buying, upgrading, continuous improvement and retirement all belong in the case.

NIST’s Secure Software Development Framework adds another set of obligations. An organisation producing software needs roles, protected development environments, secure releases, component provenance and a process for finding and responding to vulnerabilities. None disappears because a model generated part of the code.

This is the same verification problem explored in AI Coding Has Moved the Bottleneck From Creation to Verification. If output rises faster than review, testing and operational assurance, the cost has not vanished. It has moved downstream.

Speed is not yet the business case

It is tempting to calculate the internal option from an observed burst of developer speed. That evidence needs care.

In a randomised study of 16 experienced open-source developers completing 246 real tasks in repositories they knew well, METR found that early-2025 AI tools increased completion time by 19%. The developers expected a 24% improvement and still believed afterwards that AI had made them 20% faster.

That is a narrow setting with a small specialist sample and older tools. METR’s 2026 follow-up says later tools probably provided greater benefit, but the updated estimate was not reliable enough to publish as a clean speed figure. The useful lesson is not that coding agents make developers slower. It is that perceived speed and generated-code volume are weak foundations for an ownership decision.

Measure accepted changes, end-to-end lead time, defects, recovery, support effort and user outcomes. Code output is activity. A reliable service is the result.

DORA’s 2025 research on AI-assisted software development offers the wider operating explanation. It describes AI as an amplifier of the organisational system already in place. Automated testing, fast feedback, mature version control, a capable internal platform and loosely coupled architecture help teams absorb more change. Weakness in those areas is amplified too.

A faster builder does not clear the queue around it. That is why speeding up the builder will not clear the jam remains relevant even when the builder is an agent.

---

Build, buy or hybrid allocates the same obligations differently

The useful decision is rarely ideological. It is an allocation of capability, control, risk and future choice.

Build when the capability deserves internal ownership

Internal development becomes more credible when the need is genuinely distinctive, deep workflow fit matters, available products cannot adapt without damaging compromises, and the organisation has the capability to run what it builds.

“We can generate it” is not enough. A named service owner, supported architecture, repository, release path, monitoring, incident response, documentation and succession plan need to exist beyond the team that produced version one. Otherwise, the organisation has created an asset without creating an operating model.

This is where AI-generated technical debt becomes an ownership issue rather than a coding-style debate. Unexplained dependencies and locally understood design choices become expensive when the original creator moves on.

Buy when the need is commodity and the supplier carries the burden well

Buying can be the better decision when a product meets most user needs, the supplier has stronger specialist capability, updates and assurance are part of the service, and the organisation can preserve acceptable data and exit rights.

Buying does not remove accountability. It changes how it is exercised. Due diligence, contractual controls, supplier monitoring, integration, user support and contingency planning remain with the customer. The supplier may own the codebase; the organisation still owns the outcome and the consequences of failure.

Use a hybrid when the boundary can be made explicit

Many strong decisions will combine a reusable platform with organisation-specific workflow, data or decision logic. The value may sit in the custom boundary rather than the underlying commodity capability.

Hybrid fails when it becomes an unplanned middle: a heavily customised product that cannot be upgraded, or an internal layer nobody owns sitting on top of a supplier service nobody can leave. Interfaces, decision rights, support boundaries and exit paths need to be designed at the start.

---

Seven questions before approving an internal build

The decision can be tested without building a large governance ceremony around it. Ask seven questions while the option is still cheap to change.

1. What user outcome requires software? Describe the need and present constraint without naming a preferred tool.
2. What is genuinely distinctive? Separate the capability that creates advantage from commodity functions already available elsewhere.
3. Who owns the complete service? Name the accountable owner for operation, risk, cost, change and retirement—not only delivery.
4. What is the whole-life cost? Include integration, data, testing, assurance, infrastructure, tokens, monitoring, support, incidents, dependencies, improvement and exit.
5. Which obligations are transferred? For a supplier or hybrid route, state what the vendor carries and what remains with the organisation.
6. What evidence would change the decision? Test the riskiest assumption before committing. A Minimum Idea State is more useful here than a polished demonstration.
7. How will this end? Define migration, data export, archival and retirement before accumulated use makes exit difficult.

A lightweight record makes the decision reviewable. It should preserve the options considered, assumptions made, conditions attached, owner, review date and the measures that will show whether the case held.

High performers see the cost because they use the capability

McKinsey’s high-performer comparison adds a useful tension. Forty per cent of the 92 AI high performers reported scaling software coding agents, compared with 20% of other respondents. Nearly half said their organisation had decided against a purchase because it could build the functionality, compared with 31% of others.

The same group was also three times as likely to report that coding-agent costs had constrained use: 18% against 6%. Cost constraint is not evidence of negative return. It may simply reflect broader use. But it shows that serious adoption makes operating economics visible.

The mature response is neither “build everything” nor “keep buying what we always bought”. McKinsey’s own commentary argues for a more deliberate mix: know where to buy, where to build and where to develop enough internal capability to integrate and scale what works.

That decision also needs a verification plan. The 30-day verification approach offers a practical way to make quality, authority and evidence visible before generated software spreads.

---

Download the AI Coding Build-versus-Buy Decision Pack

The free seven-page decision pack below is designed for a 45-minute review with product, engineering, security, operations and commercial colleagues. It includes:

• a decision canvas that starts with the user outcome;
• a common scoring test for build, buy and hybrid options;
• a lifetime ownership map from decision to retirement;
• seven red-line gates that expose unownable services;
• a decision record and 90-day evidence review.

The score is deliberately comparative rather than a universal approval threshold. Context matters. The obligations do not disappear.

What the research can—and cannot—tell us

McKinsey’s online survey ran from 4 May to 8 June 2026 and included 1,719 participants across 97 nations. Responses were weighted by each nation’s contribution to global GDP. Thirty-six per cent of participants worked for organisations with more than $1 billion in annual revenue.

The survey is useful evidence that sourcing behaviour is changing. It is not a record of software transactions, audited costs or completed internal products. The high-performer group contains 92 respondents and is defined partly by self-reported financial impact. The associations do not show that coding agents caused their performance.

The operating framework in this article and the downloadable pack are Beta Tester Life interpretations of the evidence. They are decision-support tools, not claims made by McKinsey and not substitutes for legal, security, procurement or financial advice.

Sources used

1. Dan Tinkoff, Lieven Van der Veken and Michael Chui, with Tara Balakrishnan, The state of AI in 2026: On the road to ROI, McKinsey & Company, 25 August 2026.
2. Google Cloud, 2025 DORA State of AI-assisted Software Development Report.
3. National Institute of Standards and Technology, Secure Software Development Framework (SSDF) Version 1.1, NIST SP 800-218.
4. Government Digital Service, Choose the right tools and technology, Service Standard point 11, updated 29 January 2026; and Define your purchasing strategy.
5. Joel Becker, Nate Rush, Beth Barnes and David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 July 2025; with the February 2026 methodology update.

When creating software becomes easier, deciding what deserves to exist becomes the scarce capability. The strongest teams will not be those that build the most. They will be the ones that know which obligations they are willing—and able—to own.