Software maintenance cost: how much to budget per year, line by line

Software keeps costing money after launch, even if nobody asks it to do anything new. The figure quoted everywhere, 15 to 20 percent of the original build cost per year, is a rule of thumb with no published method. The most detailed public benchmark we found, published in 2026 and covering 24 SaaS products, puts the median between 21 and 26 percent a year, and 10 to 16 percent for a stable internal tool. The useful move is not to pick a percentage but to build the budget line by line.

This article is about cost and the annual budget. For what maintenance covers and what the agreement should say, read our guide to business application maintenance.

Why "15 to 20 percent a year" is not enough

The percentage rule has one virtue: it reminds you that software is never paid for once and for all. It also has three flaws.

• It starts from the wrong number. Two applications built for the same price do not cost the same to run. One that depends on five external APIs, handles health data or serves customers around the clock costs far more to maintain than an internal tool used by ten people during office hours.
• It lumps together unrelated costs. Hosting is fixed, bug fixing depends on the initial quality, enhancements depend on your requests. Merging them into one percentage makes the budget impossible to steer.
• Nobody sources it. The pages that quote it publish no sample and no method.

The most detailed figures we found come from Wavect, a German software agency, published on 10 July 2026 and reviewed on 2 September 2026: a benchmark of 24 SaaS products in Germany, Austria and Switzerland maintained between 2023 and mid-2026. The author calls it directional, not statistically representative. Its median annual spend, as a share of the original build cost:

The same benchmark suggests 18 to 30 percent for a SaaS product that keeps evolving, and 10 to 16 percent for a stable, low-risk internal tool. The lesson is the spread: a factor of three between applications that cost the same to build.

The eight lines of a maintenance budget

Keep enhancements on a separate line. Strictly speaking, they add value instead of preserving it, and mixing them in hides drift in the other lines. Hosting often arrives on a different invoice, but it comes out of the same budget. Our article on hosting a business application in Europe covers those choices.

Upgrades: the line that grows if you ignore it

Every application sits on components with a finite life. PHP is a public example: according to the official supported versions page (checked on 7 November 2026), each release gets two years of active support, then two years of security fixes only. PHP 8.2, released in December 2022, receives no security fixes at all after 31 December 2026. Every major framework and runtime follows a similar calendar.

An application upgraded every year takes a few days of work each time. One left alone for three years has to jump several versions at once, with every breaking change stacked together, and that can take weeks or require rewriting parts of it. This is technical debt in its most literal form: it shows up on no invoice until the day you pay it back.

What makes the bill vary

For the same build cost, six factors explain most of the difference:

1. Integrations. Every external API (ERP, payments, email, government portals) can change version or go down. This is the main source of unplanned work.
2. Criticality. If an outage stops invoicing or production, you need short response times, sometimes outside office hours. On-call cover is paid for.
3. Initial quality. Automated tests, documentation, readable code: what was saved during the build is repaid in maintenance.
4. Technology choice. A mainstream stack is cheaper to maintain, and more providers can take it over.
5. Regulation. Privacy law, e-invoicing mandates, health data rules: each new rule is an adaptation project. In France, for example, the e-invoicing mandate forces changes in any software that issues invoices.
6. User count. It weighs less on the code than on support: more users, more questions.

If you sell software to other businesses in the European Union, add the Cyber Resilience Act: its reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027, including vulnerability handling across the product lifecycle. Check with counsel whether your product is in scope.

A worked example

An illustration, not a quote: an internal application that cost 60,000 to build (in dollars, euros or pounds, the ratio is what matters), used by about thirty people, connected to an accounting package.

1. Apply the range for its profile. Stable internal tool: 10 to 16 percent per year according to the benchmark above, so 6,000 to 9,600.
2. Check each line. Is hosting inside that figure? Is a major framework upgrade due this year? Does the accounting connector rely on an API that changes often?
3. Budget year one separately. It is usually higher, while real use surfaces the forgotten cases.
4. Take enhancements out. If you already know three new screens will be requested, price them on their own.

You end up with a range you can defend, and test against the quotes you receive.

How maintenance is paid for

The billing model does not change the work. It changes who carries the risk when the budget slips.

Paying on demand looks cheap while nothing breaks. When something does, you negotiate under pressure. For the general logic, see fixed price vs time and materials.

What skipping maintenance really costs

Cutting maintenance is tempting when everything works. The consequences arrive later, all at once:

• a published vulnerability stays open on an internet-facing application;
• the framework drops out of security support, and your host eventually stops offering the runtime version you need;
• a connected service changes its API and the sync stops on a Monday morning;
• nobody knows the code any more, and the first provider you call proposes a rewrite.

At that point the question is no longer the annual cost but the price of a catch-up or a rebuild. Our article on software modernization cost shows what that involves.

Cutting maintenance cost at design time

Much of the maintenance budget is decided before the first line of code:

• automated tests on the business rules, so an upgrade cannot silently break them;
• few dependencies, and widely used ones;
• a mainstream stack that other providers can take over;
• living documentation: architecture, deployment, accounts, restore procedures;
• monitoring that alerts the team before users call;
• a small initial scope: every screen you build is a screen you maintain for years.

That last point is why we show a prototype before any build. A screen nobody would use, dropped at that stage, costs nothing to maintain for the next five years.

Checklist for reading a maintenance quote

1. Is hosting included? With which backups, and is a restore ever tested?
2. Are language and framework upgrades covered, or billed as extras?
3. What response times by severity, and during which hours?
4. How much enhancement work is included, and at what rate beyond it?
5. How do users reach support, and who answers?
6. What happens when the contract ends: code, data, documentation? Rights are defined case by case in the contract, so read that clause.
7. How is the price revised from one year to the next?

Common mistakes

• Approving the build without the run. A project signed off on build cost alone strains the budget from year two.
• Comparing quotes with different scopes. A low fee that excludes upgrades is not cheaper, it is incomplete.
• Mixing enhancements with maintenance. You can no longer tell whether the software is expensive to run or you simply ask for a lot.
• Cutting maintenance to fund a new feature. The application ages while you add to it.
• Forgetting internal time. Someone on your side triages requests, tests releases and answers users. That time has a cost.

When a subscription changes the maths

Another approach is to stop separating build and run. With our subscription model, you do not pay for development: a monthly fee covers hosting, maintenance and enhancements. The risk of maintenance costing more than planned moves to us, and your budget becomes one fixed line.

It is not the right fit for everyone: over a long period, software you buy outright and maintain can cost less. We compare both approaches in software subscription vs upfront build, and build costs themselves in custom business application cost.

Where to start

1. List your dependencies: language and version, framework, external services, hosting. Note each one's end-of-support date.
2. Sort the last twelve months of spending into the eight lines above.
3. Separate enhancements from maintenance proper.
4. Provision year one separately for any new application.

If you are planning a new project, the cheapest time to reduce maintenance is before development starts. We build a free visual prototype and present it by video call within 5 working days: you see what will be built, and therefore what will need maintaining, before committing a budget. The idea is explained in see your software before you pay.