Buying software gives parity. Only what you build sets you apart.

The question almost always comes from the board's table, and comes wrapped in cost: build our own software or subscribe to a SaaS that already exists? Put like that, the answer looks like a spreadsheet. It is not. It is a question about where your advantage lives. Buying software solves what is common and delivers you what the entire market already has. Building custom is for the core that sets you apart. What is alike puts you ahead of no one, and that is how this decision should be read before it is read by price.

What is really being decided

The engineer Martin Fowler proposes a simple and useful division. There is utility software, which everyone needs and which only has to work, and there is strategic software, the kind in which the way it performs a function is part of what makes it better than the competition. Payroll is the classic example of utility: no one wins clients by processing salaries in a more ingenious way. And this is where the buy-or-build rule comes from.

Since the definition of utility is that there's no differentiator, the obvious thing is to go with the package. [...] For a strategic function you don't want the same software as your competitors because that would cripple your ability to differentiate. Martin Fowler, Utility Vs Strategic Dichotomy, 2019

It is not a solitary idea. Geoffrey Moore, in Dealing with Darwin, separates the core, what creates purchase preference, from the context, everything that has to be done to stay in the market but that does not set you apart, and recommends minimising or outsourcing the context to free the best people for the core. Gartner arranges the same instinct into a three-layer architecture: systems of record, which last a decade and only have to be right; systems of differentiation, which encode what the company does differently; and systems of innovation, short-lived, to test new opportunities. Three languages, one conclusion: you buy the record, you build what differentiates.

Buying gives you parity, and sometimes that is enough

It is worth saying what SaaS does well, because it does. For accounting, email, payroll or an early-stage CRM, buying is the right decision and almost always the cheapest. It is not worth building the thing in which the difference changes nothing for the client. But there is a price that is not on the invoice, and it is not the financial one. When you subscribe to the same tool your competitors subscribe to, you inherit the capability and you also inherit the limits. The system was designed to serve a thousand companies, not yours, and yours ends up shaping the process to the tool. In context, that is acceptable. In core, it is handing the difference to a supplier who sells it identically to the neighbour next door.

The list price is not the cost

The second mistake is to think the cost of SaaS is the number on the table. Worldwide spending on SaaS applications is expected to approach 300 billion dollars in 2025, up from a little over 250 billion in 2024, according to Gartner. It is not the market volume that matters here, it is what it hides inside each company that adds up to that total.

Three costs rarely enter the upfront calculation. The first is that the price rises. The Vertice index, a platform that helps companies negotiate software purchases, recorded an average rise in SaaS prices on the order of 12% over a twelve-month period, against 6% in 2019. It is a figure with an interest of its own, and I return to it right afterwards, but the direction is familiar to anyone who renews contracts: the monthly fee you signed is not the monthly fee you will be paying three years from now.

The second is that you pay for what you do not use. According to Zylo's SaaS management index, companies use on average about half, 49%, of the licences they buy, with an average waste on the order of 18 million dollars a year in idle licences. The third is structural and is the least visible: SaaS is a recurring expense that scales with every seat and every integration, and that keeps leaving the account every month for as long as the company exists. Building has a high upfront cost and then amortises. Buying has a low upfront cost and then compounds, forever.

The honest limit of these numbers

Here it is necessary to be rigorous about the strength of this evidence. Zylo sells SaaS management and Vertice sells software negotiation: both have an interest in waste and inflation looking large. Zylo's sample is companies that have already hired SaaS management, that is, those who already had excess to control, and it skews towards large organisations, which pulls the 18-million average upwards. Licence waste is a management failure, not an inherent defect of the model, and an announced price increase is not the increase actually paid by those who negotiate. None of this proves that buying is bad. It proves that the cost of SaaS is not the number on the table, and that whoever decides with the number on the table decides with incomplete information.

The economics that artificial intelligence changed

There is a new reason to reopen this decision in 2026, and it is on the build side. The routine work of development, the repetitive code, the tests, the scaffolding put up before the hard part begins, has become cheaper. In a controlled trial with 95 programmers, the group with access to GitHub Copilot completed a task 55.8% faster than the group without the tool.

The treatment group, with access to the AI pair programmer, completed the task 55.8% faster than the control group. Sida Peng, Eirini Kalliamvakou, Peter Cihon and Mert Demirer, The Impact of AI on Developer Productivity, 2023

The task was to build an HTTP server in JavaScript, a self-contained, well-defined exercise, exactly the type of work that fills the first weeks of any project. If half of that work becomes faster, the fixed cost of building the core that sets you apart falls. What previously paid off only at a large scale begins to pay off earlier. This is the concrete change: building custom is no longer the preserve of those with a team of dozens of people.

What this does not prove

This is the part that separates a line of reasoning from a sales argument, and it is the part that cuts against easy enthusiasm. The 55.8% gain was measured on an isolated, from-scratch task, done by professionals recruited for the trial, in a study by GitHub itself. The study measures speed on a task, it does not measure quality, maintenance or the outcome of a product. And when you measure precisely the other case, that of working inside a large codebase that already exists, the result reverses.

When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025

In this 2025 trial, sixteen experienced programmers worked in repositories they had known for years, on 246 real tasks, and allowing AI made them take 19% longer. The most uncomfortable fact is not the slowdown, it is the perception. The same programmers had predicted that AI would speed them up by 24% and, after the experience had slowed them down, they remained convinced it had sped them up by 20%. The tool feels fast, and the feeling does not match the stopwatch.

And building carries risk, even when it becomes cheaper. The Standish Group's 2020 CHAOS Report places 31% of projects as successful, 50% compromised by deadline or budget and 19% failed. The report itself is criticised by academics, who point out that the sample is proprietary and that its definitions, based solely on the accuracy of estimates, bias the numbers, and so it is read by direction and not by exact value: building from scratch is a bet that is budgeted with a margin of error, not a guaranteed saving. The honest conclusion is not to build everything. It is that AI lowered the cost of building what matters, and not the probability of erring when you build what did not matter.

Where the line falls, in practice

That said, the decision ceases to be buy or build and becomes where to draw the line, company by company. The practical answer is hybrid, and the test is a single question: does this system encode what makes people choose you? If the answer is no, you buy. Accounting, email, salaries, the CRM while the company is small, videoconferencing: it is context, and context is bought ready-made and cheap. If the answer is yes, you build. The operational engine that no one in the market runs the way you do, the pricing or logistics logic that is your advantage, compliance with a specific rule of your sector that no generic package covers without forcing you to be the same as everyone: it is core, and core is not rented.

There is a signal that decides many of these lines. When an off-the-shelf package forces you to change your process to fit it, and that process is precisely what sets you apart, you are paying to become the same as the competition. In context, moulding yourself to the tool is sensible and saves time. In core, it is buying the parity you should be avoiding.

What stays on the balance sheet

In the end, the difference between buying and building is the difference between an expense and an asset. The software you buy leaves the account every month and is not yours: it is a rented capability, the same one the competitor rents next door. The software that encodes what sets you apart stays, capitalises and works for you once paid for. We exist to convert perception into a financial asset, and the technological architecture that sustains that perception obeys the same rule. What is alike has no authority, and what is alike also does not enter the balance sheet as value. It enters as a recurring cost.

Sources

Every number in this article was verified against the primary source. Where the source does not support the current reading, we say so in the body of the text.

1. Martin Fowler, Utility Vs Strategic Dichotomy, martinfowler.com, 2019. martinfowler.com/bliki/UtilityVsStrategicDichotomy.html
2. Geoffrey A. Moore, Dealing with Darwin (Portfolio, 2005), the core vs context model. en.wikipedia.org/wiki/Dealing_with_Darwin
3. Gartner, Pace-Layered Application Strategy (systems of record, differentiation and innovation). gartner.com/en/documents/3297020
4. Gartner, forecast of worldwide SaaS spending (~250 billion USD in 2024, ~300 billion in 2025), via CIO Dive, 2024. ciodive.com/news/cloud-spend-growth-forecast-2025-gartner
5. Zylo, 2024 SaaS Management Index (average utilisation of 49%; ~18 million USD in average annual waste). zylo.com/news/2024-saas-management-index
6. Vertice, SaaS Inflation Index (average increase ~12% over twelve months, against 6% in 2019), via CFO Dive, 2023. cfodive.com/news/saas-prices-jumped-vertice
7. Sida Peng, Eirini Kalliamvakou, Peter Cihon y Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv 2302.06590, 2023. arxiv.org/abs/2302.06590
8. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025. metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
9. The Standish Group, CHAOS Report 2020: Beyond Infinity (31% successful, 50% compromised, 19% failed), with the critique by Eveleens and Verhoef, IEEE Software, 2010. review of the report