What happens after launch: the real cost of maintaining custom software
Launch is the middle of the story, not the end. Here is what maintenance actually involves, what it should cost, and what happens to systems that never get any.
Most conversations about custom software stop at launch, as though the project finishes when the system goes live. It does not. Launch is the point at which the software starts being useful, and also the point at which it starts ageing.
This post covers what maintenance actually involves, what a reasonable annual figure looks like, and what happens to systems that never receive any. It is the part of the cost conversation that gets skipped most often, and the part that determines whether your system is still serving you in year four.
What maintenance actually covers
Maintenance is a vague word that hides four quite different activities. It helps to separate them, because they carry different urgency and different costs.
1. Security patching
Every system is built on layers of other people's code, and vulnerabilities are found in those layers regularly. Patching them is not optional and it is not driven by your business. It is driven by whenever a problem is discovered and published.
This is the category people most often assume they can defer. It is the one they can least afford to.
2. Dependency and platform updates
The frameworks, languages and hosting platforms your system uses all move forward. Ignore them for long enough and you reach a point where upgrading requires rewriting significant parts of the system, because you are now several major versions behind.
Doing this steadily is cheap. Doing it after four years of neglect is a project in its own right.
3. Fixing things that break
Some of this is genuine bugs that survived testing. More often it is external: a third party API changes its response format, a supplier changes their file layout, an email provider tightens its rules. Your code did not change, but the world around it did.
4. Small changes as the business moves
A new service line, a changed VAT rule, a report someone now needs monthly. Individually minor, but they accumulate, and a system that cannot absorb them slowly stops matching how you work.
What it should cost
A reasonable annual budget is roughly 15 to 20 percent of the original build cost. That figure covers the four categories above for a system of typical small business complexity.
| Build cost | Annual maintenance | Roughly per month |
|---|---|---|
| £10,000 | £1,500 to £2,000 | £125 to £170 |
| £25,000 | £3,750 to £5,000 | £310 to £420 |
| £50,000 | £7,500 to £10,000 | £625 to £830 |
Hosting sits on top of this and is usually modest, in the region of £20 to £200 a month for a system of this size. The full cost picture is covered in what a custom CRM actually costs.
Two things push the figure higher: a large number of third party integrations, since each one is a moving part outside your control, and any compliance obligation that requires documented review.
What happens without it
Neglected software does not fail dramatically. It decays quietly, in a fairly predictable order.
- Months one to twelve. Nothing visible happens. This is the stage that convinces people maintenance is unnecessary.
- Year two. Small breakages appear where third party services have moved on. Individually annoying, easily dismissed.
- Year three. Security patches are far enough behind that updating one thing requires updating several. Costs rise noticeably.
- Year four and beyond. The system works but cannot be safely changed. Any developer looking at it recommends a rebuild, because modifying it is riskier than starting again.
That final stage is the expensive one, and it is entirely avoidable. The businesses that reach it are rarely careless. They simply never had maintenance presented to them as part of the cost.
Software does not break the day you stop maintaining it. It breaks the day you need to change it.
What a sensible arrangement looks like
You do not need an enterprise support contract. For a small business system, a workable arrangement covers four things.
- A response commitment for things that are actually broken, stated in working hours rather than vague promises. Same day for anything stopping work, a few days for everything else, is reasonable.
- Regular patching included, rather than billed each time. If security updates are chargeable extras, they will get deferred.
- A small monthly allowance for changes, so minor adjustments do not require a quote and a negotiation every time.
- Clear pricing for anything larger, so a new feature is a straightforward decision rather than an awkward conversation.
Make sure you hold the keys
Maintenance arrangements only work if you can change supplier without losing your system. That means the source code sits in a repository you own, hosting and domain accounts are in your name, and there is written documentation of how the thing is deployed.
This matters more for maintenance than for the original build. A developer who holds the keys has no real pressure to be responsive, because leaving is expensive for you. The contract points are covered in how to hire a developer.
Reducing how much maintenance you need
Some of this is decided at build time, which is why it is worth raising early rather than after launch.
- Fewer integrations means fewer moving parts. Each connection to an outside system is something that can change without warning. Connect what earns its place, not everything possible.
- Boring, widely used technology ages better than whatever is fashionable. It has more people who can work on it and a longer support life.
- Written documentation means a new developer can pick the system up in days rather than weeks, which directly reduces what you pay.
- Simpler scope. Every feature is a permanent maintenance obligation. Features nobody uses still need patching.
That last point is worth sitting with. The cheapest feature to maintain is the one you decided not to build.
Frequently asked questions
Budget roughly 15 to 20 percent of the original build cost annually, plus hosting of around £20 to £200 a month for a typical small business system. Systems with many third party integrations or compliance obligations sit at the higher end of that range.
Usually nothing visible at first, which is what makes it tempting. The cost appears later: security patches fall far enough behind that updates become interlinked and expensive, and eventually the system reaches a state where changing it safely is harder than rebuilding it.
Parts of it, if you have someone technical. Content changes and configuration are often manageable internally. Security patching and dependency updates need someone who can assess whether an update breaks anything, which is harder than it looks and is usually better contracted out.
Almost never, and you should assume it is not unless it is stated explicitly. Ask what is included, for how long, and what happens afterwards. A build quote with no mention of ongoing cost is an incomplete quote rather than a cheap one.