The short answer
A custom system is an ongoing commitment, not a purchase. Dependencies need updating, security issues need patching, hosting needs paying for, and the business will want changes. Budget for it in the original business case rather than discovering it in year two.
The alternative is not zero cost. It is deferred cost, and deferred maintenance compounds.
What maintenance covers
- Security patching of the application and everything it depends on
- Dependency and framework upgrades, which cannot be deferred indefinitely
- Hosting, backups and whatever the system runs on
- Monitoring, and someone who receives the alerts
- Fixing defects that surface in real use
- Small changes as processes shift
The second item is the one businesses underestimate. Frameworks reach end of life, and an upgrade deferred for three years is a project rather than a task.
What happens without it
| Deferred | Consequence |
|---|---|
| Security patching | Known vulnerabilities, and eventually an incident |
| Dependency upgrades | Upgrades become migrations |
| Small fixes | Workarounds accumulate, trust erodes |
| Monitoring | Failures found by users |
| Documentation | Nobody can safely change it |
The pattern is consistent: each deferral is individually reasonable and the accumulation is not. Two years of skipped upgrades turns a day of work into a quarter.
Who does it
- The people who built it, on a retainer. Fastest, and keeps the knowledge with someone else.
- Your own team, after a proper handover. Best long-term, needs the capacity.
- A different supplier. Workable if the documentation is real, slower at first.
- Nobody, until something breaks. The most expensive option in the end.
The fourth is more common than anyone admits. It is worth naming at the start, because choosing it deliberately is different from drifting into it.
Make it maintainable while building
Maintenance cost is largely determined during the build. Conventional technology choices, documentation written as work proceeds, tests that catch regressions and infrastructure defined as code all reduce what it costs to keep running.
A system built with unusual technology by people who have left, with no tests and no documentation, is expensive to maintain regardless of who does it.
Reviewing whether to keep it
Periodically ask whether the system is still worth running. Business processes change, platforms catch up, and a system built for a process you no longer follow is a cost with no benefit.
That is a reasonable outcome rather than a failure. Software has a useful life, and deciding to retire something is better than maintaining it out of habit.