Software maintenance: what it actually covers and what it should cost

What software maintenance actually covers

The phrase covers several distinct kinds of work, and it's worth separating them because they're priced and prioritised differently.

Most support conversations focus on the first two because they're the ones that cause visible pain. In practice, adaptive maintenance is the one businesses most often forget to budget for, and it's the reason a system that worked perfectly for two years suddenly stops.

How maintenance is usually structured: retainer vs ad-hoc

There are two common commercial models, and each suits a different situation.

• Retainer - a fixed monthly or quarterly amount, usually covering a bank of hours or a set response time, plus security patching as standard. Predictable, and it means someone is watching the system even when nothing is visibly broken.
• Ad-hoc / time and materials - you pay for work as it's needed, with no ongoing commitment. Cheaper if genuinely little goes wrong, but there's no guaranteed response time, and whoever built it may have moved on to other work by the time you need them.

A sensible middle ground many businesses use is a small retainer that covers security patching and a guaranteed response window, with larger pieces of work quoted separately as they come up. This keeps the baseline cost low while making sure nothing critical is left unattended.

How much of the original build cost should maintenance be?

There's no fixed industry rule here worth quoting as fact, and we'd rather say that plainly than make one up. What we can say from running these arrangements is that maintenance is not a one-off percentage you set once - it should scale with how business-critical the system is and how much it's actively being developed further, and it's worth reviewing annually rather than assuming the first year's figure holds forever.

The more useful exercise is asking what happens if the system goes down for a day - lost orders, idle staff, a compliance breach - and sizing the maintenance budget against that risk, not against the original build invoice.

What should be in a maintenance agreement?

Whatever the pricing model, the agreement itself should answer a specific set of questions in writing rather than leave them implied.

1. 01Response times - how quickly will a critical issue (system down) versus a minor one (cosmetic bug) be acknowledged and fixed?
2. 02What's included as standard - security patching, hosting, monitoring - versus what's quoted separately.
3. 03Who owns escalation - if the supplier can't fix it, what happens next?
4. 04Access to source code - can you move the maintenance elsewhere if the relationship ends? See our note on who owns the code if this isn't already settled from the build contract.
5. 05Review point - a date to reassess the arrangement as the system and business change.

Does off-the-shelf software need maintenance too?

Yes, though it looks different. With SaaS products, the vendor handles most technical maintenance as part of your subscription, but you still carry the cost of configuration changes, integrations breaking when the vendor updates their API, and staff training as the product evolves under you. It's a real cost, just billed differently - worth reading alongside custom software vs off-the-shelf if you're still deciding between the two.

For any internet-facing system, the NCSC is a good, free reference on why keeping software patched isn't optional from a security standpoint - it's one of the most basic controls against being compromised.

If you already have a system running with no clear maintenance arrangement, that's worth fixing before it becomes an emergency. Get in touch and we'll look honestly at what a sensible arrangement would cost for your specific setup.