Custom application or SaaS: how to work out which pays off

Choosing between a custom application and SaaS is a calculation over three to five years, not a matter of taste. SaaS wins for processes every company runs in much the same way: email, accounting, HR, video calls. A custom application starts to pay off where per-user pricing grows faster than the benefit, where the process is what sets the company apart, or where the team bends its work to fit the tool every day.

Most companies, however, compare a monthly subscription with a one-off development quote, which distorts both sides. The subscription is not the only cost of SaaS, and the quote is not the only cost of a custom system. Below are the lines you need to count, a worked example and the factors that cannot be expressed in money.

What SaaS actually costs

The starting point is a product: price per user, number of users and number of years. Many vendors price exactly this way; Salesforce's Sales Cloud pricing page lists prices per user per month and bills its higher editions on annual contracts. Under that model the bill grows with every hire, even when the new person uses the same three screens as everyone else.

On top of that come price increases at renewal, features available only on a higher plan and integration fees. The largest line, though, is often the work done beside the system: retyping data between tools, spreadsheets that fill gaps in reporting, manual month-end summaries. None of this appears on an invoice, but it can be measured by asking the team how many hours a week they spend outside the application.

It is also worth checking what the company pays for and does not use. The Zylo 2026 SaaS Management Index, based on more than 40 million licences and 75 billion USD of spend, reports that organisations leave an average of 36% of their licences unused against recommended utilisation levels. The announcement mentions segments such as large enterprises, organisations with more than 10,000 employees and a survey of 218 IT leaders, but gives no total number of companies or full breakdown of the sample, so we do not apply that figure directly to a small business. The practical lesson is general all the same: before you count users, count active users.

The last line is the cost of leaving. The Data Act has applied since 12 September 2025 and sets a framework for customers of data processing services to switch provider effectively. According to the European Commission's explainer, a SaaS provider must at a minimum export data in a commonly used, machine-readable format, and until 12 January 2027 providers may still charge for the costs of switching; after that, switching charges, including data egress, are to be removed. Exporting data is not the same as migrating a process, though. Configuration, automations and the team's habits do not travel in a CSV file, and rebuilding them has to be costed separately.

What a custom application actually costs

On the other side sit the build of the first version, moving data out of the current tool, and the team's time for testing and acceptance. Then come the recurring costs: hosting, domain, backups, monitoring, security updates, fixing defects and developing further features. External services such as SMS, payments or maps have their own pricing, independent of whoever builds the application.

The line most often left out is responsibility. With SaaS, the vendor patches vulnerabilities, keeps the service available and runs the backups. With your own application, a named person or team has to do that every month, including months when nobody asks for new features. If the budget has no line for maintenance, the application is not cheaper. It just carries a risk nobody has priced.

A hypothetical worked example

The figures below are invented for illustration and do not come from any project or price list. A company has 40 CRM users at 250 PLN a month each, which is 120,000 PLN a year, and assumes a 5% increase at every renewal. The team spends about 400 hours a year working outside the system, or 40,000 PLN at 100 PLN an hour. An integration connector costs 6,000 PLN a year. The first year of SaaS comes to 166,000 PLN, and five years to about 893,000 PLN.

The custom application needs 300,000 PLN to build and 30,000 PLN to migrate. Each year adds 24,000 PLN of hosting, 72,000 PLN of maintenance and 10,000 PLN of residual manual work, 106,000 PLN in total. After five years the sum is about 860,000 PLN.

The annual difference in running costs rises from 60,000 PLN in the first year to about 86,000 PLN in the fifth, and its running total only passes the 330,000 PLN upfront investment in year five. Over three years SaaS is clearly cheaper; over five the result is close to a draw. What the example mainly shows is sensitivity. With 60 users from the first year, the investment would be recovered in year three. If maintenance turned out twice as expensive, it would never be recovered.

How to find the break-even point

Break-even is the moment when the accumulated annual savings in running costs equal the investment in build and migration. Work it out year by year, not as an average, because price increases and headcount growth take effect with a delay. Record every assumption separately: active users in each year, expected price increases, hours of manual work before and after the change, and the cost of maintenance.

Then model two pessimistic cases: one against the build (delays, more expensive maintenance, a slower move away from spreadsheets) and one against SaaS (a growing team, a steeper increase, being forced onto a higher plan). If the custom application wins only in the optimistic case, the decision is too risky. If it wins in both, further calculation will not change the answer.

This is also how we work before quoting a tailor-made application: we set the current subscriptions against development, data migration and maintenance over the same period.

What AI-assisted development changes

AI tools for developers may lower build costs, but the evidence is weaker than vendor claims suggest. In a study from early 2025 in which tasks were randomly assigned to AI-allowed and AI-disallowed conditions, METR found that experienced open-source developers took 19% longer when using AI tools. In its February 2026 update it says developers are likely more sped up in early 2026, but that because of participant selection effects the new data are only very weak evidence for the size of that increase.

Our own view is cautious. AI shortens the writing of repetitive code, but it does not shorten agreeing requirements, migrating data, testing with the team or maintenance. A build-cost reduction should not go into the calculation until the contractor shows it in a quote for a specific scope.

Factors that do not fit in the spreadsheet

Data ownership and portability come first. In SaaS, your data is available on the vendor's terms; in your own system, the company decides where it lives and who can reach it. Lock-in cuts both ways, though: an application that only one contractor understands ties the company down as firmly as any subscription.

That is why source-code ownership and documentation matter. The contract should set out the rights to the code created and list third-party components with their licences. It is also worth checking whether another contractor or an internal team could take the application over: is the code in the company's own repository, is there a runbook for deployment, and are the infrastructure accounts in the company's name rather than the contractor's?

When not to build

Do not build when the process is standard and an off-the-shelf tool handles it well and cheaply. Do not build when requirements change every month and nobody knows which features the team actually uses; measure that in the current tool first. And do not build when nobody in the company will own acceptance of changes and the maintenance budget. A custom application without an owner ages faster than a subscription that someone, at least, keeps updated.