Software maintenance cost is the number that turns a successful project into a difficult conversation eighteen months later. The build was budgeted, approved and delivered. What happens after it goes live was described as “support” and given a figure somebody guessed at, and that figure was almost always too small.
The reason is structural rather than careless. A build has a scope you can price. Maintenance has no scope, because it is defined by things that have not happened yet: a library with a vulnerability, a supplier changing an API, a user hitting a case nobody anticipated.
The rule of thumb everyone quotes is 15 to 20 per cent of build cost per year, and it is close enough to be dangerous. It is right often enough to feel safe and wrong in a predictable direction: it undercounts the first year, when defects surface, and it collapses entirely for systems with regulatory obligations or many third-party integrations, where the work is driven by outside events rather than by your codebase.
What Software Maintenance Cost Actually Covers
Five distinct categories, and mixing them up is what produces the wrong number.
Corrective work. Fixing defects. Front-loaded, because most bugs surface in the first months of real use, and this is the category the percentage rule handles best.
Adaptive work. Keeping up with things outside your control. A dependency releases a security patch. A payment provider deprecates an API version. A browser changes behaviour. None of this adds a feature and all of it is compulsory.
Preventive work. Upgrading before you are forced to. Skipping it does not remove the cost, it defers and compounds it, which is how a routine framework upgrade becomes a three-month project.
Operational running. Hosting, monitoring, backups, certificates, and the people time to watch them. Often accounted separately, which is fine as long as somebody accounts for it at all.
Small changes. The steady stream of adjustments a live system generates once real users are in it. Individually trivial, collectively the largest category in most years.
Only the first is what people usually mean by maintenance. The other four are why the budget runs out.
Why the Percentage Rule Misleads
It anchors on the wrong quantity. Maintenance effort tracks the number of moving parts and the rate at which the outside world changes them, not what the build happened to cost.
Two systems built for the same money can differ by a factor of three. A self-contained application with two dependencies and no regulatory exposure is cheap to keep running. A system integrating six third-party services, handling personal data and subject to sector rules is not, because every one of those integrations is a source of work you do not schedule.
The percentage also assumes a steady state that does not exist in year one. Real usage finds defects, and the first six months after launch typically run well above the annual average before settling.
A better estimate starts from the moving parts. Count the integrations, the compliance obligations and the number of users generating support contact, then price the time those realistically consume. Our custom software development cost guide covers the build side of the same arithmetic.
The Line Items Teams Forget
Dependency upgrades. Not optional, because unpatched libraries are how systems get compromised, and the effort is genuinely unpredictable since it depends on what upstream maintainers do.
Third-party API changes. A supplier deprecates a version and gives you a deadline. You did not choose the timing and you cannot decline.
Certificate and domain renewals. Trivial until one lapses on a weekend and the site is down.
Monitoring and the response to it. Alerts are useless without somebody who reacts, and that availability is a real cost whether or not anything breaks.
Knowledge transfer. People leave. The cost of the next person learning the system is a maintenance cost, and it is proportional to how little was written down.
Data growth. Storage cost rises, queries that were fast get slower, and the work of dealing with that arrives on a schedule set by your own success. Our guide to database performance covers what that looks like in practice.
What This Costs in the UK
Rough annual ranges for maintaining a custom system, assuming an external provider rather than in-house staff.
| System shape | Typical annual cost |
|---|---|
| Small internal tool, few integrations | £6,000 to £15,000 |
| Customer-facing app, several integrations | £20,000 to £60,000 |
| Regulated or high-traffic platform | £60,000 upwards |
These exclude hosting and licences, which are billed separately and vary enormously. They also assume the system is in reasonable condition. Maintaining something nobody documented, with no tests and one person who understands it, costs more and carries risk that no retainer removes.
How to Structure It
A retainer with defined hours works when the volume is broadly predictable. It buys availability, which is most of what you are paying for, and unused hours are not waste since the alternative is having nobody.
Time and materials suits low-change systems, but response time is whatever the provider’s other commitments allow, and that is the trade.
A fixed support contract shifts the risk to the provider, who prices that risk into the fee. Reasonable for critical systems where predictability is worth more than the margin.
Whichever you choose, agree what counts as maintenance and what counts as a new feature before you need to. That boundary is the source of nearly every dispute in support relationships, and it costs nothing to define at the start.
Mecanik maintains systems we did not build as well as ones we did, as part of our software development work. The first month of any handover is usually documentation, because that is what determines the cost of every month after it.
Related reading: Fixed Price Contract or Time and Materials? , How to Write a Software RFP That Gets Useful Quotes , Software Escrow: Who Actually Needs It and MVP Software Development: Scope, Cost and Timeline .
Frequently Asked Questions
How much does software maintenance cost per year? The common rule of thumb is 15 to 20 per cent of build cost annually, but it undercounts the first year when defects surface and breaks down entirely for systems with many integrations or regulatory obligations. Rough UK ranges run from £6,000 to £15,000 for a small internal tool up to £60,000 or more for a regulated or high-traffic platform, excluding hosting.
What does software maintenance actually include? Five categories: corrective work fixing defects, adaptive work keeping up with dependency and third-party API changes, preventive work upgrading before you are forced to, operational running such as hosting and monitoring, and the steady stream of small changes a live system generates. Only the first is what most people mean by maintenance.
Why is the percentage of build cost rule unreliable? It anchors on the wrong quantity. Maintenance effort tracks the number of moving parts and how fast the outside world changes them, not what the build cost. Two systems built for the same money can differ threefold depending on integration count, regulatory exposure and support volume.
What maintenance costs do teams forget to budget? Dependency upgrades, third-party API deprecations with deadlines you did not choose, certificate and domain renewals, the human availability behind monitoring alerts, knowledge transfer when people leave, and the effect of data growth on storage cost and query speed.
Should I use a retainer or pay as needed? A retainer with defined hours suits predictable volume and buys availability, which is most of what you are paying for. Time and materials suits low-change systems but response time depends on the provider’s other commitments. Whichever you pick, define what counts as maintenance versus a new feature before you need to.
Comments