Build vs buy is changing: AI is rewriting the economics of owning software

For years, the sensible default was simple: buy commodity software and reserve custom development for the few capabilities that genuinely differentiated the business.

There were good reasons for that. Building meant recruiting engineers, selecting infrastructure, creating delivery practices and carrying a long operational tail. Buying offered mature functionality, support and a maintenance model that sat somewhere else. SaaS made the case stronger by turning large implementation programmes into subscriptions.

That logic remains useful. What has changed is the cost curve underneath it.

The cost of creation is falling

AI coding tools can generate, refactor, test and document code. Low-code and application platforms provide authentication, data access, workflow and user-interface primitives. Managed cloud services remove large parts of the infrastructure burden, while APIs make sophisticated capabilities available without recreating them from first principles.

The claim needs care: software has not become free, and productivity gains observed on a bounded coding task are not the same as gains across a production system. But the direction is now supported by more than anecdotes. In a controlled experiment with 95 professional developers, GitHub and Microsoft researchers found that the group using Copilot completed a JavaScript task 55% faster on average.¹

The more important shift is cumulative. A small, experienced team can now assemble useful software from mature components and use AI to accelerate the custom work between them. For internal tools and narrow operational workflows, a credible prototype may arrive before a traditional procurement process has finished its shortlist.

Retool’s 2026 survey of 817 builders, including its own customers, found that 35% had already replaced at least one SaaS tool with a custom build and 78% expected to build more in 2026.² The sample is commercially interested and should not be treated as a neutral view of the whole market. It is still a useful signal that the old assumptions are being actively retested.

The change matters most in the middle

A twenty-person company once faced a stark choice: adapt its operating model to the nearest SaaS product, or fund bespoke software that was difficult to justify at its scale. Today there is a much larger middle ground.

A business can combine managed identity, a database, workflow, payments, hosting and AI-assisted engineering into a capability tailored to the way it actually works. It can begin with one high-value workflow, validate the economics and expand only when the evidence supports it.

If that same business spends £50,000 or £100,000 each year licensing software for a process central to its operation, comparing the subscription with the historical cost of bespoke development is no longer sufficient. The comparison must use the current cost of creating and operating the capability.

Renting capability or investing in IP

When an organisation buys SaaS, it rents access to a vendor’s product model. The vendor owns the roadmap, the data model, the economics and the constraints. The customer often owns a growing configuration and integration estate designed to bridge the gap between that model and the way its business actually works.

That can be exactly the right decision for commodity capability. Payroll, commodity communications and standard accounting rarely become more valuable merely because they are bespoke.

But when software captures a distinctive process, proprietary data or domain knowledge, building can create an asset rather than simply another operating cost. It may make the company faster, harder to copy, cheaper to operate or better able to exploit its own data. Occasionally, an internal capability can become a customer proposition or new revenue stream.

The strategic mistake is to treat all software as equivalent. Some systems are utilities. Others encode the business.

A prototype is not a platform

The new economics create a dangerous illusion: because an application can be produced quickly, it can be owned cheaply.

Google’s 2025 DORA research found that 90% of respondents were using AI at work and more than 80% believed it had increased productivity. Yet AI adoption still had a negative relationship with delivery stability. DORA’s conclusion is important: AI accelerates change, but without strong testing, version control and fast feedback loops, that acceleration exposes weaknesses downstream.³

Architecture, security, resilience, observability, documentation, support and business continuity do not disappear. The UK National Cyber Security Centre’s guidance applies across secure design, development, deployment, operation and maintenance — including when a system is assembled on top of hosted models and external APIs.⁴

The risk has shifted. Historically, the biggest barrier was often the cost of getting started. Increasingly, the harder question is whether the organisation is prepared to own what it can now create.

A better build-versus-buy framework

Start with the business capability, not a technology preference. Then make the alternatives explicit: buy, configure, compose from managed components, or build. The decision is no longer binary.

Compare total economics over a realistic decision horizon. For SaaS, include licence growth, implementation, configuration, integration, process compromise and switching cost. For a build, include engineering, hosting, security, support, maintenance and future change. Price uncertainty should be modelled on both sides.

Then decide where responsibility should sit. Someone must own availability, security, access, technical debt and product direction. AI changes the effort involved; it does not remove accountability.

The threshold has moved

The strongest argument for reopening build versus buy is not that building is suddenly better. It is that many organisations are still making the decision using assumptions formed when custom software was much slower and more expensive to create.

The winners will not replace every SaaS subscription with an AI-generated application. They will become more deliberate about where they rent capability, where they compose it, and where owning the workflow and IP is worth the responsibility.