This guide is for anyone who has just commissioned custom software, is about to, or is two years into owning one and trying to make sense of the ongoing costs. By the end you will know what maintenance actually covers, how to size the annual budget against the build cost, the line items that almost always get forgotten, and how to tell whether you are spending too much or too little.
Who This Guide Is For
Founders, finance leads, and operations heads who own software that the business depends on and need to understand the true cost of keeping it running. This applies whether the software was built in-house, by an external partner, or inherited from a previous team — the maintenance bill exists either way, and pretending it does not just means it surfaces as a crisis a year in.
Before You Start
You should know roughly what the software does and the rough cost of the original build. If you do not have the original build cost, estimate it from the current scope — replacement value gives you a usable proxy. You should also have a sense of whether the software is critical to daily operations or a peripheral tool, because that changes the maintenance calculus significantly.
If you have not yet commissioned the software, How to Write a Software RFP covers the procurement side and How to Scope an Internal Software Project covers what you are building. Budget the maintenance at the same time as the build — it is a planning failure to discover the maintenance bill three months after launch.
Step 1: Understand What Maintenance Actually Covers
Software maintenance is not one thing. It is at least six distinct categories of work, and lumping them together is why budgets go wrong. The categories:
- Infrastructure: hosting, databases, storage, CDN, backups, third-party services the software depends on
- Security updates: patching frameworks, libraries, and operating system components as vulnerabilities are disclosed
- Bug fixes: things that broke that nobody knew about until users found them
- Small improvements: tweaks to flows that are not strictly broken but are no longer optimal
- Compatibility updates: keeping pace with browser changes, OS updates, third-party API changes
- Monitoring and incident response: someone is watching, and someone is available when it breaks
You will spend on all six, even if your contract only names “support”. A maintenance budget that does not account for at least four of these categories is going to surprise you.
Step 2: Size the Annual Budget Against the Build Cost
The rule of thumb that holds up across most custom software projects: annual maintenance runs between 15% and 25% of the original build cost. So a £100,000 build typically costs £15,000–£25,000 per year to maintain.
The variance depends on a handful of factors. Software with many third-party integrations skews higher (more APIs to keep up with). Software with a small user base and stable scope skews lower. Software handling payments, personal data, or anything regulated skews higher because the security and compliance overhead is non-trivial. Software still being actively developed has a blurred line between maintenance and new feature work; budget both separately or the maintenance number becomes meaningless.
A concrete worked example. A £60,000 client portal with Stripe integration, Google SSO, and connection to two business systems. Reasonable annual maintenance: £12,000–£15,000. Hosting and infrastructure runs £150–£200/month (£2,400/year). Security updates and dependency upgrades, two days a quarter (£3,200). Bug fixes and small improvements at three to four hours a month (£3,500). Monitoring and incident response (£2,000). Buffer for the unexpected (£2,000). That lands at £13,100 — within the 20% rule.
Step 3: Separate “Keep the Lights On” From “Continuous Improvement”
Maintenance budgets get muddled because two different kinds of spend get filed together. The first is keep-the-lights-on: hosting, security patches, the bug fixes that are not really optional. The second is continuous improvement: the small refinements that make the software more useful month by month.
Treat them as separate lines. Keep-the-lights-on is the floor — the cost of not letting the software degrade. Continuous improvement is discretionary — the cost of letting the software get steadily better. Some businesses choose to invest heavily in continuous improvement; others run with the floor and reserve their development budget for new projects.
Mixing them produces a maintenance line item that looks expensive (“we’re spending £30,000 a year just to keep it running?”) when in fact half is being invested in genuine improvements. Or worse, it produces a maintenance line item that looks cheap (“we’re only spending £8,000 a year”) because continuous improvement has been quietly cut and the software is slowly rotting.
Step 4: Budget for the Line Items That Get Forgotten
The categories that almost always get missed in maintenance budgets:
- Third-party service price increases. SaaS prices go up, sometimes substantially. Budget a 10% annual increase across all the services the software depends on.
- Backups and disaster recovery testing. Backups are cheap; testing that they actually restore is not free. Budget two days a year to verify recoverability.
- Domain renewals, SSL certificates, code signing certs. Small line items that get forgotten until something expires and breaks production.
- Dependency upgrades. Frameworks like Laravel, React, or Node have major version releases roughly annually. Major version upgrades can take days to weeks of work each. Budget for one major upgrade per year per significant dependency.
- Browser and OS compatibility. New Safari or Chrome versions occasionally break things. Budget a few days a year for fixing what breaks.
- Documentation updates. Internal documentation drifts from the code. Once a year, fixing this is worth half a day per major area.
Add these up across the categories that apply and you will find another £3,000–£8,000 a year on most projects — money that gets spent regardless, but only painfully if it was not in the budget.
Step 5: Decide Who Holds the Budget and How It Is Spent
A maintenance budget that has no owner gets spent ad hoc and runs over. The patterns that work are: a retainer with the build partner (predictable monthly cost, defined hours), an internal developer (predictable cost but you carry the holiday cover and turnover risk), or pay-as-you-go (cheapest if usage is genuinely low, but expensive when something urgent breaks).
The retainer model is cheapest in total cost of ownership for most businesses with critical software, because the partner already knows the codebase. The pay-as-you-go model is cheapest on paper but typically 30–50% more expensive in practice because emergency work commands premium rates and ramp-up time for a new contractor each engagement is significant.
A real pattern from our retainer clients: a quarter to a half of monthly retainer time is keep-the-lights-on (the necessary updates and bug fixes); the rest is small improvements the business chooses based on priority. The retainer becomes a budget line that can be deployed against whatever matters most that month, rather than a fixed list of tasks.
Step 6: Reconcile the Budget Against Reality at the End of Year One
The first year is the data point. At twelve months, look at what was actually spent versus what was budgeted, in each of the categories. The picture you want to see: spending tracks the budget by category, not just in total. If the total is in line but you spent £8,000 on emergency bug fixes and zero on continuous improvement, the software is degrading and the budget structure is wrong even though the headline number is fine.
Adjust year two based on what year one taught you. If hosting costs ran higher than expected, look at whether the system can be right-sized. If security and dependency updates were larger than expected, look at whether the framework choices were stable enough. If continuous improvement was entirely consumed by reactive work, add capacity or accept that the software is in maintenance-only mode and budget accordingly.
This reconciliation is the difference between a software portfolio that compounds in value and one that compounds in technical debt.
Common Mistakes
- Budgeting maintenance as a single number. “We will spend £15,000 a year on maintenance” tells you nothing. Break it into the six categories or you will overspend on one and underspend on another.
- Forgetting infrastructure inflation. SaaS prices rise. Cloud costs rise. Budget a 10% annual increase, not zero.
- Treating the build as one-off and maintenance as an afterthought. The maintenance budget should be agreed at the same time as the build budget. Otherwise the maintenance gets cut to zero and the software starts to rot from month four.
- Counting new features as maintenance. If it is new functionality, it is a project, not maintenance. Separate them in the budget or the maintenance line becomes a black hole.
- No reserve for the unexpected. Something will break unexpectedly every year. Budget 10–15% of the maintenance number as a reserve, not as a free-money line.
- Buying the cheapest support contract on the assumption it will not be needed. It will be needed. The cheapest contract usually means the slowest response times. The economics work out badly the first time the software is down for three days.
What Good Looks Like
A well-budgeted maintenance line for custom software looks like this. The number is between 15% and 25% of the original build cost, broken into six categories: infrastructure, security, bug fixes, small improvements, compatibility, and monitoring. Continuous improvement is a separate line, not lumped in. There is a 10–15% reserve for the unexpected. The budget is owned by a named person, spent against a clear plan, and reconciled at the end of each year so year two is informed by what year one taught you. The software is in better shape at the end of each year than the start — not worse.
Next Steps
If the question is whether to spend the maintenance budget on the existing system or invest in a replacement, When to Modernise vs Replace covers that decision. For sizing the build budget itself, How to Scope an Internal Software Project is the right starting point. For a structured ongoing partnership, see Software Support Retainers or get in touch.