Software maintenance cost is the figure almost every business gets wrong, because it is the only line in a project that arrives after the celebration. The build is signed off, the launch email goes out, the invoice is paid — and then the product starts ageing from the first day it is live. Browsers update, dependencies publish security advisories, the payment provider deprecates an endpoint, and a user finds the one workflow nobody tested.
None of that is failure. It is the normal condition of working software, and it has a price. The mistake is not that businesses refuse to pay it; it is that they never budgeted for it, so every patch becomes an unplanned negotiation and every quarter the product falls a little further behind. A custom system with no maintenance line in its business case is a system with a quiet expiry date attached.
This guide puts a number on that line. It covers what a realistic software maintenance cost actually includes, why the familiar fifteen-to-twenty per cent rule exists and when it is wrong, annual price bands by application type, the recurring bills that arrive whether or not you change a thing, the support models on offer and what each one hides, and a method for reaching your own figure in an afternoon. If you are still at the estimating stage of a build, read it alongside our guide to custom software development cost — the two numbers should be decided together, not two years apart.
Table of contents
- What software maintenance cost actually covers
- The percentage rule and where it comes from
- Software maintenance cost by application type
- Recurring bills that arrive whether you change anything or not
- Security patching and the price of falling behind
- Support models and the software maintenance cost of each
- Hidden costs that break a maintenance budget
- How to estimate your software maintenance cost in an afternoon
- Reducing the bill without letting the product rot
- Frequently asked questions about software maintenance cost
- Making maintenance a decision, not a surprise
What software maintenance cost actually covers
Suppliers quote very different figures for what sounds like the same arrangement because they are pricing different amounts of work. The engineering discipline splits software maintenance into four recognised categories, and a practical budget adds a fifth for the support wrapper around them. A quote that omits one of the five has not saved you money — it has moved that work onto your team, or onto a change request with a separate invoice number.
Corrective maintenance: fixing what breaks
This is what most people picture: a defect is reported, reproduced, fixed, tested and released. It is usually the smallest slice of the software maintenance cost — typically twenty to twenty-five per cent of the annual figure on a well-built system. If it is dominating your bill, the problem is not maintenance pricing, it is build quality, and no support contract will fix that.
Adaptive maintenance: keeping up with the platforms
Your software sits on a stack that changes without asking you. Operating systems, browsers, mobile OS releases, database versions, payment gateways and identity providers all move on their own schedule. Adaptive work keeps the product compatible with a world that has moved, and it is the least negotiable element of any software maintenance cost. It is also the category businesses most often try to defer, which is how a two-day update becomes a three-week emergency.
Perfective maintenance: the changes users ask for
Once real people use the product, they want it different. A field added, a report reshaped, a step removed from a workflow, a permission split in two. This is the most valuable part of the software maintenance cost because it is the part that compounds — a system that keeps absorbing feedback stays useful, and a system that freezes at launch quietly loses its users to spreadsheets.
Preventive maintenance: paying down technical debt
Refactoring, test coverage, dependency consolidation, removing the workaround somebody added under deadline pressure. None of it is visible to users, which is exactly why it is the first thing cut from a software maintenance cost. Left unfunded, technical debt raises the price of every future change until a rebuild starts to look cheaper than another year of patching.
The support wrapper around all of it
Somebody has to answer the phone, triage the report, decide whether it is a bug or a request, and tell the user what happens next. Triage, monitoring, release management and communication are real hours, and a software maintenance cost that prices only development time has left the wrapper out.
The percentage rule and where it comes from
Ask three suppliers how to size a software maintenance cost and all three will start with a percentage of the build. It is a reasonable opening position, provided you know why the range exists and which end of it your product sits at.
Why fifteen to twenty per cent of build cost is the starting point
The rule survives because it roughly matches observed effort: keeping a system current absorbs about one-sixth of the work that created it, every year, indefinitely. On a £120,000 build that is a software maintenance cost of £18,000–£24,000 a year. Treat it as the opening estimate for a straightforward business application with modest integrations — not as a law, and never as a ceiling.
What pushes the software maintenance cost above twenty-five per cent
Four things reliably drive it up: heavy third-party integration, mobile applications with two app stores to satisfy, regulated or payment-handling data, and a high rate of business change. Any two of those together put you at twenty-five to thirty-five per cent. A platform stitched into five external systems is not maintained, it is continuously repaired.
What pulls it below fifteen per cent
A stable internal tool with few users, no public exposure, a boring stack and a business process that has not changed in years can genuinely run at eight to twelve per cent. So can a product that was built with automated tests and a clean deployment pipeline. Good engineering shows up as a lower software maintenance cost long before it shows up anywhere else.
Applying the rule to a real build budget
Take the true build cost — including discovery, integrations and project management, not just the development line — and apply your percentage to that. Businesses that apply it to the development figure alone routinely underfund maintenance by a third. If your build ran to a substantial software discovery phase, that effort belongs in the base.
Why year one is not the cheapest
Everyone expects the first year to be quiet because the product is new. In practice it is often the busiest: real usage exposes assumptions, the first wave of enhancement requests lands, and the deployment process gets properly exercised for the first time. Budget the full software maintenance cost from month one, then reassess after twelve months of evidence.
Software maintenance cost by application type
Percentages are useful when you know the build price. When you do not — because you inherited the system, or you are comparing options before committing — annual bands by application type are more practical. The figures below reflect UK market rates in 2026 and exclude the platform bills covered in the next section.
Internal business tool: £3,000–£12,000 a year
A workflow or admin tool used by staff, behind a login, with one or two integrations. Low public exposure and a forgiving user base. Most of the software maintenance cost here is adaptive and perfective — dependency updates plus a steady trickle of small changes as the process evolves.
Customer-facing web application: £9,000–£40,000 a year
Public exposure changes everything. You now need real monitoring, faster response times, accessibility and browser compatibility, and a security posture that assumes hostile traffic. Expect the software maintenance cost to rise sharply with transaction volume and with how much revenue depends on the thing staying up.
Mobile application on two platforms: £12,000–£45,000 a year
Two operating systems on independent release cycles, two store review processes, and mandatory SDK updates that arrive whether you have budget or not. Apple and Google both enforce minimum target versions, so a mobile software maintenance cost is never truly optional — miss a deadline and the app is delisted, not merely dated.
Integrated platform with multiple dependencies: £30,000–£120,000+
Three or more connected systems, a shared data model, and business logic spanning all of them. Every external party can break you with a release you did not choose. If this is your architecture, read the maintenance section of our API integration cost guide before signing anything — integration upkeep is usually the largest single component.
Regulated or payment-handling systems: add twenty to forty per cent
Card data, health records, financial services or anything under formal audit brings evidence obligations: patch windows with deadlines, access reviews, penetration testing, and documented change control. The engineering is similar; the surrounding process is not, and it is the process that adds the percentage.
Recurring bills that arrive whether you change anything or not
A large part of every real software maintenance cost is not engineering at all. It is the standing charges that keep the product switched on, and they are almost never included when a supplier quotes “maintenance”. Price them separately and you will stop being surprised in month four.
Hosting, storage and bandwidth
Cloud hosting for a modest business application runs roughly £60–£400 a month; a busy customer-facing platform with redundancy, managed databases and a content delivery network can reach £800–£3,000. Storage grows monotonically, so this part of the software maintenance cost rises every year even if the code never changes.
Third-party APIs and licence tiers
Mapping, messaging, e-signature, identity, payment, address lookup, email delivery. Each has a free tier that ends and a per-transaction price that scales with your success. Growth quietly raises the software maintenance cost through this route more often than through development hours.
Certificates, domains and monitoring
Small individually, awkward when forgotten. TLS certificates, domain renewals, uptime and error monitoring, log aggregation and alerting typically total £40–£300 a month. The expensive failure mode is an expired certificate on a Saturday, not the subscription itself.
App store fees and developer accounts
Apple charges $99 a year, Google a one-off $25, and both require a maintained developer account with valid signing credentials. Losing access to those accounts when an employee leaves is a recurring, entirely preventable cause of emergency spend.
Backup, disaster recovery and log retention
Backups you have never restored are a hope, not a control. Budget for tested restores, off-site copies and whatever retention period your sector requires. This is a modest line that becomes the only line that matters roughly once per decade.
Security patching and the price of falling behind
Security is the part of the software maintenance cost with the worst risk profile: cheap to do continuously, ruinous to do late. Every month you defer patching, you are borrowing against an incident at an interest rate you do not control.
Dependency updates and vulnerability windows
A typical modern application carries hundreds of transitive dependencies. Advisories appear weekly, and the gap between disclosure and exploitation is now measured in days. Automated dependency scanning plus a scheduled monthly update window is the cheapest cybersecurity control available, and it belongs inside the base software maintenance cost rather than in a separate contract.
Framework end-of-life and forced upgrades
Every framework has a support horizon. When it passes, security fixes stop, and you are facing a major version upgrade under pressure. A planned framework upgrade is a few weeks of scoped work carried inside the normal software maintenance cost; the same upgrade done reactively after an incident costs multiples of that and lands with no testing time.
Penetration testing and remediation
An annual external test for a mid-sized application runs roughly £3,000–£8,000, and the remediation work afterwards is a separate budget that people forget to set aside. Book the fix time in the same quarter as the test, or the report becomes a document rather than an improvement.
Incident response readiness
Knowing who to call, where the logs are, how to roll back and who tells customers is preparation, not paperwork. An hour a quarter keeps it current. Without it, the software maintenance cost of a single bad afternoon can exceed a whole year of retained support.
Why deferred patching compounds
Skipped updates do not queue politely. They interact, so the eventual catch-up is not the sum of what you missed but something considerably worse — and it typically arrives at the least convenient moment, driven by an external deadline rather than your roadmap.
Support models and the software maintenance cost of each
How the arrangement is structured matters as much as the number. Each model shifts risk somewhere different, and the difference only becomes visible on your worst week rather than your average one.
Ad hoc time and materials
You pay for what you use, at £450–£750 a day in the UK. It looks like the cheapest software maintenance cost and often is, until you need somebody urgently and discover they are booked for a fortnight. There is no reserved capacity and no reason for anyone to know your system well. Suitable for genuinely stable, low-stakes internal tools only.
Retained hours per month
A block of hours — commonly eight to forty — reserved each month at a discounted rate, with proactive work included. This is where most mid-market businesses land, because it buys availability as well as effort. Watch two clauses: whether unused hours roll over, and whether emergencies come out of the same block.
Fixed-fee managed support with an SLA
A single monthly fee covering defined maintenance, monitoring and response times. This is the most predictable way to carry a software maintenance cost, and the right one where downtime has a real price attached. Read the exclusions carefully — most fixed fees cover corrective and adaptive work but treat enhancements as extra, which is reasonable provided everyone agrees in advance. Our support plans follow this shape.
In-house developer versus a retained partner
A mid-level developer in the UK costs £45,000–£65,000 plus employment overheads — call it £60,000–£85,000 all-in for a single person with one skill set, no cover during holidays and no second opinion. That is a rational software maintenance cost only when the workload genuinely fills the role. Below roughly two days a week, a retained partner buys more capability for less.
The blended arrangement that usually wins
One internal owner who knows the business, plus a retained partner supplying engineering depth and cover. The employee protects context and priorities; the partner absorbs peaks, holidays and specialisms. It is the most common shape among businesses that have been running custom software for more than three years.
The overruns are rarely caused by the work everybody anticipated. They come from the assumptions nobody tested until the day they mattered.
Knowledge loss when the original team leaves
The single largest hidden driver. When the people who built the system move on, the next team spends weeks reading code instead of fixing it. Onboarding a new maintainer onto an undocumented codebase costs two to six weeks — a software maintenance cost you pay purely for the absence of a handover document.
Undocumented deployment and environments
If releasing requires one specific person and a sequence of steps that lives in their head, you do not have a deployment process, you have a dependency. Documenting and automating it is a few days of work that removes an entire category of emergency.
The staging environment nobody funded
Testing changes against production data on production infrastructure is how small fixes become outages. A staging environment costs a fraction of the live one and pays for itself the first time it catches something. Sound DevOps practice makes this routine rather than exceptional.
Data growth and query degradation
Software that performs well at ten thousand records can crawl at two million. Nothing changed except time. Query tuning, indexing and archiving are a predictable software maintenance cost — but only if somebody is watching the trend rather than waiting for complaints.
Change requests disguised as bugs
“It’s broken” often means “it does not do what I now need”. Without a shared definition of a defect, either you absorb unfunded work or you argue with your users. Write the definition into the contract and the software maintenance cost stops being a monthly negotiation.
How to estimate your software maintenance cost in an afternoon
You can reach a defensible figure without a single supplier conversation. The method below takes a couple of hours and typically lands within twenty per cent of the eventual annual spend — close enough to fund, and close enough to recognise a quote that has left something out.
Start from the true build cost
Use the full delivered cost: discovery, design, development, integration, testing and project management. If you inherited the system, estimate what it would cost to rebuild today. That figure is the base for every percentage that follows.
Score the four risk multipliers
Give the system a point for each of: more than two external integrations, a public-facing user base, regulated or payment data, and a business process that changes more than quarterly. Zero or one point means twelve to fifteen per cent; two points, eighteen to twenty-two; three or four, twenty-five to thirty-five.
Price the fixed recurring bills separately
Add hosting, third-party APIs, monitoring, certificates and store fees as their own annual number. Keeping them separate from engineering hours is what stops platform inflation from silently eating your development budget — and it makes genuine cost optimisation possible later, because you can see which line is actually growing.
Add a change budget, not a change process
Set aside ten to twenty per cent of the maintenance figure explicitly for enhancements. Businesses that do this ship improvements; businesses that do not spend the same money more slowly and less happily through change requests.
Worked example: a £90,000 customer portal
Build cost £90,000. Public-facing and two integrations scores two points, so eighteen to twenty-two per cent gives £16,200–£19,800 of engineering. Add £4,200 hosting and monitoring, £2,400 third-party APIs, and a £3,000 change budget. Total software maintenance cost: roughly £26,000–£29,000 a year — about £2,300 a month, and a number you can defend in a board paper.
Reducing the bill without letting the product rot
There is a real difference between lowering a software maintenance cost and simply deferring it. These five moves reduce the underlying work; cancelling patching merely postpones a larger invoice.
Automate the release path
Manual deployment is a recurring tax charged in hours and mistakes. A build-and-deploy pipeline usually pays back its share of the software maintenance cost within a year on any product shipping more than monthly, and it removes the release-day risk premium entirely.
Retire features nobody uses
Every feature carries maintenance weight forever. Instrument usage, find the ones nobody has touched in twelve months, and remove them. Deleting code is the only change that reliably reduces future software maintenance cost with no downside.
Consolidate dependencies
Three libraries doing similar jobs mean three update cycles and three vulnerability feeds. An annual dependency review that removes the redundant ones cuts patching work permanently, and it is straightforward to schedule alongside a normal release.
Buy monitoring before you buy headcount
Good alerting turns a two-hour outage into a ten-minute one and converts guesswork into evidence. It is far cheaper than the extra support capacity you would otherwise need, and it tells you where the maintenance effort is genuinely going.
Fund a small refactor every quarter
A fixed, modest allocation for internal improvement — a few days each quarter — keeps technical debt flat instead of compounding. It is the cheapest available insurance against the rebuild conversation arriving three years early.
Frequently asked questions about software maintenance cost
How much should we budget in year one?
Plan for the full annual figure — fifteen to twenty per cent of build cost for a typical business application — from the month you go live. Year one is frequently the busiest, because real usage finds what testing did not.
Is maintenance included in a fixed-price build?
Almost never beyond a short warranty, typically thirty to ninety days, covering defects against the agreed specification only. Anything else is a separate arrangement. Ask for the maintenance proposal at the same time as the build quote, so the total software maintenance cost is visible before you commit.
What happens if we do nothing for a year?
Nothing visible, then everything at once. Dependencies drift out of support, a browser or OS update breaks a workflow, and the accumulated upgrade lands as a single unbudgeted project. Twelve months of neglect typically produces a software maintenance cost two to three times what the same work would have taken spread across the year.
Should we keep a developer in-house?
Only if the workload genuinely fills the role — roughly two days a week or more of sustained work. Below that, a single employee is an expensive software maintenance cost with no cover for holidays, illness or the skills they happen to lack.
How do we compare two maintenance quotes fairly?
Ask both suppliers to price the same five things: response and resolution times, what counts as a defect, whether platform bills are included, how many enhancement hours are covered, and what happens to unused time. Most apparent price differences dissolve once those are aligned.
When is a rebuild cheaper than maintaining?
When annual maintenance exceeds roughly forty per cent of a rebuild estimate for two consecutive years, or when the platform is out of support and the upgrade path is blocked. At that point you are funding decline. Our build versus buy framework is the right place to start that conversation.
Making maintenance a decision, not a surprise
The businesses that run custom software well are not the ones that spend least on it. They are the ones that decided the number in advance, wrote down what it buys, and reviewed it on a schedule instead of after an incident.
Put the figure in the original business case
A build approved without its maintenance line was approved on incomplete information. Add five years of software maintenance cost to the capital figure and the comparison against an off-the-shelf product becomes honest — sometimes the custom option still wins, and now you can prove it.
Agree what “maintained” means in writing
Response times, resolution targets, patching cadence, included hours, exclusions, and who owns the credentials and the code. Four pages of clarity prevent four years of disagreement, and they make the software development company you work with easier to hold to account.
Review the number every six months
Usage grows, integrations multiply and platform bills creep. A twenty-minute review twice a year catches drift while it is still small, and it keeps the software maintenance cost a managed line in your budget rather than a recurring surprise in your inbox. If you are still choosing a delivery partner, our MVP development cost guide covers how to keep the first release small enough to maintain.
