What Software Maintenance Really Costs After Launch
Key takeaway
Budget 15–20% of the original build cost per year for maintenance on a typical custom application — covering hosting, dependency and security updates, bug fixes, and small improvements. Skipping it doesn't save money; it defers the cost into a much more expensive rebuild.
Most software budgets stop at launch day, which is exactly where the real operating cost starts. Every application carries ongoing obligations: the platform it runs on changes, its dependencies ship security patches, browsers and mobile OSes move, and your own users find edge cases nobody scoped.
The rule of thumb, and what it covers
For a typical custom web or mobile application, plan on 15–20% of the original build cost per year. For a simple internal tool with few integrations, 10% may be enough. For a regulated or high-traffic platform, 25% is more honest.
- Infrastructure — hosting, storage, bandwidth, monitoring, backups.
- Dependency and security updates — framework upgrades, patched libraries, certificate rotation.
- Corrective work — bugs found in production, data fixes, incident response.
- Adaptive work — keeping up with third-party API changes, payment providers, and OS releases.
- Small enhancements — the steady stream of tweaks that keeps a product usable.
What pushes the number up
- Many third-party integrations — each one is an external contract that can change without warning.
- Compliance scope (HIPAA, PCI, SOC 2) — audits, evidence, and access reviews are recurring work.
- Mobile apps — app store policy changes force releases on someone else's schedule.
- Thin test coverage — without tests, every change needs manual regression time.
- Undocumented code — knowledge that lives in one person's head is a cost multiplier.
Deferred maintenance is a loan
Teams that cut maintenance to zero usually meet the bill three years later, when an unsupported framework version blocks a security fix and the only path forward is a rewrite. The interest rate on that loan is brutal: a rebuild routinely costs more than five years of disciplined upkeep.
A better model is a small, predictable retainer that guarantees patching, monitoring, and a fixed pool of improvement hours — so the product improves quietly instead of decaying quietly.
Questions to ask before you sign off on a build
- Who owns production support, and what is the response time for a critical issue?
- How are dependency updates scheduled — reactively or on a cadence?
- What documentation and runbooks ship with the code?
- What happens to the maintenance agreement if we move the work in-house?