Software Maintenance Cost UK: What Keeping Custom Software Alive Really Costs (2026)

Quick answer

Custom software is a living asset: plan for 15–25% of the original build cost per year to keep it healthy. A £20,000 system therefore carries £3,000–£5,000/year of ongoing cost — hosting, dependency updates, security patching, bug fixes and small improvements. This isn’t a failure of the build; it’s the nature of software, whose surroundings (browsers, operating systems, APIs, security threats, your own business) never stop moving. The businesses that get burned are the ones who budget the build and treat year two as free.

Where the money actually goes

The same structure applies down the scale: a custom WordPress plugin might need £200–£800/year of compatibility care, while a full web application sits in the ranges above.

Why neglect is the expensive option

Unmaintained software doesn’t fail gracefully — it accrues risk silently, then fails all at once. The pattern we see: a system runs untouched for three years, then a server OS reaches end-of-life, a payment API retires a version, or a security hole in an old framework gets exploited — and the “quick fix” is now a £5,000–£15,000 catch-up project because three years of dependency updates must land at once, against a codebase nobody has touched. Continuous maintenance is genuinely cheaper than periodic rescue: small updates are small precisely because they’re frequent. (The rescue scenario has its own name — the legacy trap — and it’s half the argument for choosing maintained off-the-shelf tools where they fit.)

Retainer vs pay-as-you-go

• Retainer (£150–£800/month typical): a monthly allowance of developer time covering monitoring, updates and small changes, with agreed response times. Right for systems the business depends on daily — the point isn’t the hours, it’s that someone competent already knows your codebase when something breaks at 9am.
• Ad-hoc (£400–£900/day): call when needed. Cheaper for genuinely stable, low-stakes internal tools — but you’re at the back of the queue in an emergency, and “we’ll batch the updates” quietly becomes the neglect pattern above.
• The hybrid most SMEs land on: a small retainer covering monitoring and quarterly update rounds, with project pricing for real new features. That split — maintenance as insurance, features as investment — keeps both honest, and it’s how we structure our own software support.

When to stop paying: the sunset test

Maintenance should protect value, not embalm it. Reassess when: annual upkeep approaches 40–50% of replacement cost; the platform it’s built on is end-of-life (forcing a rebuild-scale migration anyway); or the business has outgrown the workflow the software encodes. Sometimes the right answer is migrating to a maintained SaaS product and retiring the custom system with honours — and sometimes it’s a rebuild that resets the maintenance clock with modern foundations and the same data, via a proper integration and migration plan. Ask the question annually; the wrong answer is only ever “we haven’t thought about it”.

Cutting future maintenance at build time

A third of maintenance cost is determined before launch, by decisions made during the build. Questions to put to your developer at sign-off — each one cheap to answer now and expensive to discover later:

• “What’s the update story?” Mainstream, boring technology choices (a current LTS framework, a managed database) have years of patches ahead; exotic stacks orphan you when the one developer who knows them moves on.
• “Where’s the documentation and can another developer take over?” A README, environment setup notes and a deployment script are the difference between a £500 handover and a £5,000 reverse-engineering project.
• “Do I have the keys?” Source code in a repository you own, hosting and domain accounts in your name, credentials in your password manager. Maintenance quotes double when the incumbent controls access.
• “What’s monitored?” Error tracking and uptime alerts cost pounds and catch problems while they’re small — a system that fails silently gets maintained reactively, which is the expensive way.
• “What happens at year three?” A build quoted with its realistic maintenance line is an honest quote; one quoted without it is 20% cheaper and 100% misleading.

Builders who answer these fluently are the ones whose systems cost 15% a year rather than 25% — the selection is itself a maintenance decision.

A worked three-year model for a £20,000 system

Percentages are easy to nod at and hard to budget against, so here is the same rule expressed as a cash-flow a finance director would recognise. Assume a £20,000 internal job-management system built in 2026 for a 25-person business, hosted on a small cloud instance, integrating with an accounting API and a payment provider. The costs are illustrative rather than measured, but the shape is what UK SMEs consistently see.

Two patterns are worth noticing. Bug-fix spend is front-loaded — year one carries the defects that only surface when 25 people use the thing in anger, and it falls sharply once the rough edges are sanded. Improvement spend moves the other way: the more a system is trusted, the more people want from it, and by year three the “maintenance” budget is really a small product budget. That is a healthy signal, not a problem, but it needs to be named in the plan rather than discovered mid-year when someone asks why the developer’s invoices have gone up.

What belongs in the agreement, in writing

Most maintenance disputes are not about money; they are about undefined expectations meeting a bad morning. A one-page schedule attached to the retainer settles almost all of them. Insist that yours states:

• Response versus resolution. “We reply within four working hours” and “we fix it within four working hours” are different promises at very different prices. Agree a response window you can plan around, and a target resolution window per severity band.
• Severity definitions with examples. Nobody agrees on “urgent” in the abstract. Write it down: P1 is nobody can invoice; P2 is one team is working round it; P3 is a cosmetic annoyance. Two lines each and the 9am phone call gets shorter.
• Cover hours and the out-of-hours position. If your system is used on Saturdays, weekday-only cover is a gap you have accepted rather than a gap you have discovered.
• What the monthly allowance rolls over into, and what it does not. Unused hours typically expire or roll one month; either is fine, provided it is stated.
• The exit clause. Notice period, handover deliverables, and a fixed price for the handover itself. Agree this while everyone is happy, because you will only ever use it when they are not.
• Where backups live and who has tested a restore. An untested backup is a belief, not a control. Ask for a documented restore test at least annually.

The costs that never make it onto the maintenance quote

Budget the visible lines and you will still be short, because several real costs sit outside the developer’s invoice altogether. Third-party licence creep is the quiet one: a mapping API, a document-signing service, an SMS gateway and a monitoring tool can each look trivial at £15–£60 a month and collectively add £900–£2,400 a year, with price rises arriving on their timetable. Internal time is the larger one — someone in your business tests the changes, chases the bugs, writes the specs for the improvements, and onboards new staff to the system. Half a day a month at a loaded internal rate is a genuine £1,500–£3,000 a year that never appears anywhere.

Then there is the regulatory line. If your system stores customer or employee data, UK GDPR obligations do not pause between projects, and the practical work of keeping business software compliant beyond the cookie banner — access reviews, retention jobs, subject-access exports, a breach process someone has actually read — belongs in the maintenance plan rather than in an annual panic. It is small, recurring work. It becomes expensive only when it is done retrospectively under a deadline set by somebody else.

When the original developer disappears

Freelancers change careers, agencies get acquired, and the developer who knows your codebase takes a permanent role in Manchester. The cost of that event is set entirely by decisions you made earlier, which is why the question of whether an agency or a freelance developer should build the project is partly a continuity question rather than a pure price comparison. A takeover with a clean repository, a written environment setup and a running staging site costs a new developer perhaps one to three days of orientation — call it £500–£2,000. The same takeover with no documentation, credentials scattered across personal accounts and a production server nobody can reproduce locally routinely costs £4,000–£10,000 before a single new feature is delivered, and the incoming developer will quite reasonably price the unknown into everything afterwards.

The defensive move is undramatic: once a year, ask a second pair of eyes to attempt a cold start. Clone the repository, follow the setup notes, and see whether the application runs. If it does not, you have found the handover problem while it is still a documentation task. This is also the moment to check the surrounding estate — domains, DNS, certificates and the hosting and management arrangements around the system are frequently in someone else’s name for years without anyone noticing until a renewal fails.

Finally, keep a candid eye on the age of the foundations. A system on a supported framework with current dependencies stays in the 15% band almost indefinitely; one drifting toward end-of-life quietly climbs, and at some point maintenance spend is subsidising a decision nobody has made. That transition — and how to plan it in stages instead of one heroic rewrite — is the subject of modernising the older system your business still runs on, and the businesses that handle it well are simply the ones who started costing it a year before it became urgent.

Sources & Further Reading

• Vulnerability Management Guidance — NCSC
• Software End-of-Life Tracking — endoflife.date
• UK GDPR Guidance — Information Commissioner's Office