Custom Business Software vs SaaS: When It Pays to Build

SaaS is the cheapest way to start. A company can deploy CRM, forms, reporting, automation or customer support in hours without funding a development team. A few years later, though, one commercial process runs through five to seven products, and the business is financing a large system in fragments although it never bought one. How that state builds up we covered in Your business does not need more software. It needs less chaos. This article does not repeat the diagnosis. It deals with what comes after it: how to decide, and how to defend the decision with numbers.

The comparison of custom business software vs SaaS can be calculated so that the result holds up in front of the owner and the accountant. Most companies, however, decide on the two figures that say least about the real cost: the monthly subscription and the price on the development quote. Both are only entry fees to several years of operation.

The licence price is not the real cost

Total cost of ownership is a method that looks past the purchase price and counts everything that acquiring and running a thing still costs. Lisa M. Ellram described it in the mid-1990s on case studies of eleven companies, and for software it holds exactly as it does for buying materials: price is one line item, and usually not the decisive one.

Why this is not an academic nuance is shown by a lifecycle cost study of thirty IT application systems by Ruediger Zarnekow and Walter Brenner from the University of St. Gallen. Across five years of operation, the recurring cost of running, supporting, maintaining and further developing the system accounts for 79 % of lifecycle cost. Planning and initial development account for 21 %.

Most build-or-buy decisions are nevertheless made on the basis of that smaller fifth, because the fifth is what appears in the quote. The rest arrives later and dissolves into salaries, into support and into the time of people who somehow sort it out. Exactly the same underestimation applies on both sides: the running of a custom system and the administration of a growing bundle of subscriptions.

What actually belongs in the TCO table

A TCO table has two columns, today's stack and the proposed alternative, and the same categories in both. Otherwise you are not comparing two solutions, you are comparing two ways of doing the accounting.

Licences, consumption and unused seats. Beyond the monthly rate, this is where the behaviour of the price under growth belongs. Zylo reports in its 2026 SaaS Management Index that 78 % of IT leaders saw unexpected charges on consumption-based or AI pricing, that 61 % had to cut other projects because of unplanned cost increases, and that organisations leave an average of 36 % of SaaS licences unused. It puts median SaaS spend per employee at 9,455 USD, and in the previous edition reported year-on-year growth of 21.9 %. This is data from large-company portfolios. For a small business, the direction holds, not the absolute value.
Integrations and their upkeep. The MuleSoft Connectivity Benchmark Report by Salesforce states that the average organisation uses 897 applications, that only 29 % of them are connected, and that IT teams spend 39 % of their time designing, building and testing custom integrations. That time is a cost like any other, it simply never gets invoiced.
Human work between systems. Research published in Harvard Business Review tracked 137 people across twenty teams at three Fortune 500 companies. They toggled between applications and windows roughly 1,200 times a day, a single switch cost a little over two seconds, and in total that came to about 9 % of annual working time spent on re-orientation. In TCO it belongs as an hourly rate multiplied by hours.
Visibility into your own spending. Flexera reports in its 2026 State of ITAM Report that 43 % of organisations see year-on-year growth in wasted SaaS spend, 59 % in the case of AI software, and that only 36 % of them have full visibility into their IT estate. Without that visibility, TCO cannot be calculated and the decision is guesswork with a presentation attached.

Not everything should be custom-built

A bespoke calendar, email client or accounting package would be a nonsensical investment for most organisations. The reason is economic: these are capabilities whose development is funded by tens of thousands of customers at once. Eurostat reports that in 2025, 52.7 % of EU enterprises used paid cloud services, most often for email (85.2 %) and for financial or accounting software (58.2 %). At that level of adoption, nobody can reproduce that unit price for themselves alone.

Custom software starts to make economic sense where the process itself creates competitive advantage: pricing, capacity management, sales workflow, a customer portal or work with a proprietary data model. The right question is therefore not whether to build or buy, but: which part of its operating model should the company strategically own?

It is worth saying the part you do not usually hear from a development vendor. A large share of the requests that arrive with the sentence "we need our own system" can be solved far more cheaply: with a licence audit, with proper configuration of a tool you already pay for, by moving a process into one existing system instead of three, or with a no-code tool, meaning an environment where logic is assembled without programming. If the problem can be solved for a tenth of the price, custom development is the wrong answer. And if the process itself is broken, new software will only make it run faster, which we wrote about in AI will not fix a broken process.

The strongest architecture is often hybrid

Modern architecture does not mean programming everything from zero. The company keeps best-in-class external services for payments, email, accounting or authentication, and owns only the layer that governs its distinctive process, its data and its interface.

The mechanism is simple. The owned layer defines the data model, that is, how the company names a job, a client, capacity and price. The other systems then become replaceable suppliers of features instead of owners of the truth about the business. The difference only becomes visible at the second tool swap: the integration changes, the process does not. The hybrid has its own line in the table as well, though: there are more interfaces to maintain, not fewer.

"One build" does not mean zero recurring cost

Custom software is not a maintenance-free asset. It needs hosting, monitoring, security updates and continuous engineering. The difference against a subscription lies in the fact that the investment creates an asset under your control, not in the recurring costs disappearing.

On top of that comes delivery risk, which quotes rarely mention. Bent Flyvbjerg and Alexander Budzier analysed a sample of 1,471 IT projects and found an average budget overrun of 27 %. The shape of the distribution matters more: every sixth project was a so-called black swan, with an average cost overrun of 200 % and a schedule overrun of almost 70 %. The risk therefore sits in the tail, not in the average, and the larger the single scope, the higher the chance of ending up there. That is why it pays to build in small steps and to recalculate after each one whether the next still makes sense.

A three to five year business case

A one-year horizon cannot settle the question. In the first year the custom option normally loses: it carries the entire investment and almost no saving. Model three to five years and compare cumulative cost, not the first invoice. The model needs four inputs:

The baseline. What today's stack costs, including the human work between systems.
The growth curve. How the baseline behaves at double the number of clients. With per-seat licences it grows linearly, with an owned layer usually not.
The investment and its operation. Not only the price of the build, but also what the following five years will cost.
The break-even point. The year in which the cumulative curves cross, and what happens if it shifts by twelve months.

A worked example. The figures are chosen assumptions used to illustrate the calculation, not measurements from a real project. A company with 40 employees runs one order process through six tools and pays 2,200 euros a month in licences, which is 26,400 euros a year. At fifteen percent annual growth that comes to roughly 92,000 euros over three years. The quote for the owned layer is 70,000 euros. If the ratio from the University of St. Gallen study applied to it, where initial development makes up 21 % of five-year cost, the five-year total lands in the order of 330,000 euros, meaning around 66,000 euros a year.

Two things about this calculation matter. The first is methodological: 92,000 euros is a three-year total, 330,000 euros a five-year one, and only periods of equal length can be compared. On the same horizon, the custom option in this model comes out more expensive, not cheaper. The second is uncomfortable: the saved licences alone will never pay for that difference. The business case has to rest on released people capacity, on shorter lead time for an order, on errors that stop occurring, or on revenue that today's stack cannot serve. If none of that can be estimated at least roughly, the project is not ready for a decision.

The investment is also not compared against zero, but against the best available alternative, which tends to be another full-time hire. We devoted a separate article to that question, on whether a company needs a system or a new employee.

Signals that building pays off, and signals that it does not

Worth the calculation if several of these apply

The process in question is a source of your competitive advantage, not an administrative obligation.
Cost grows linearly with the number of people or transactions, while the benefit of the tool does not.
The vendor changed its pricing model or withdrew a feature your process depends on.
What you can offer customers is limited by what the tool allows, not by what the market wants.

It is the wrong answer if any of these apply

It concerns a commodity capability that a ready-made service handles just as well.
The company has not yet run a licence audit and does not know exactly how much it pays today and for what.
Requirements change every month and nobody can hold them still even for a single quarter.
There is nobody in the company who will take the system over after delivery and be accountable for it.

Exit costs have stopped being an unknown. In the EU at least

What leaving costs belongs in TCO as well. Until recently this line could not be priced, so it turned into a fatalistic argument along the lines of "we are locked in with the vendor anyway". Regulation changed that. According to the European Commission, the Data Act, Regulation (EU) 2023/2854, is applicable from 12 September 2025 and makes both data portability and switching between cloud providers easier. Legal analysis by the firm Latham & Watkins adds that the obligations cover IaaS, PaaS and SaaS, and that since 11 January 2024 providers may charge switching fees only as a pass-through of direct costs without margin. From 12 January 2027 they will be prohibited entirely.

There are two consequences and they do not point the same way. The cost of leaving is falling, so choosing a ready-made service is less risky, because a badly chosen tool can be replaced. At the same time the barrier to moving data onto your own infrastructure is falling, which makes the route to an owned solution cheaper too. The TCO table therefore needs a line for the price and the format of the export. That can be tested today, not at the moment of separation.

The decision between an owned system and a subscription is not a question of technological taste. It is a question of which part of its operating model the company wants to own, and whether it will still be able to pay for it in three years. The answer cannot be requested from a software vendor, who knows their own offer, not your numbers. The first step is not the choice of technology, it is diagnosis: what your stack costs today, how much human work it generates around itself, and which part of it is a commodity.

Key takeaways

Compare total cost of ownership, not the price of the subscription or the price of the build. According to the University of St. Gallen study, initial development is only a fifth of an application's five-year cost.
Model three to five years and look for the break-even point, with both options on an equally long horizon.
Before you build anything, run a licence audit and consolidate. If the problem is solved for a tenth of the price, custom development is the wrong answer.
Own the process that sets you apart and buy what is a commodity. Hybrid architecture is usually a more sensible compromise than either extreme.
The risk in an IT project sits in the tail, not in the average. Build in small, independently useful steps.