Every agency pitch ends at launch. The deck shows the happy path: discovery, design, build, ship, champagne. Then the deck stops, because the next slide is the one nobody wants to present — the part where the software you just paid for begins, immediately and silently, to decay.
This is the guide for that slide. Not the marketing version where "maintenance" means a support inbox and a quarterly check-in, but the engineering reality: software is a depreciating asset that loses value the moment it stops being touched, and the cost of pretending otherwise is paid all at once, usually at the worst possible time.
Here's the position this whole piece argues from: maintenance is not the thing you do after the project. Maintenance is the project. The build is just the expensive first sprint of a system you'll run for years. Teams that internalize this spend less, sleep better, and rebuild far less often than teams that treat launch as the finish line.
Why software rots
Code doesn't wear out. The bytes on disk are identical the day after launch as the day of. And yet working software that nobody touches stops working — not because the code changed, but because everything around it did. This is software rot, and it has four engines, all of them external to your codebase.
The world moves under you
Your app depends on things you don't control: an operating system, a language runtime, a database, a hosting platform, payment APIs, OAuth providers, browsers. Every one of those ships breaking changes on its own schedule. A TLS version gets deprecated. A payment processor sunsets an API version. A browser drops support for a cookie behavior your auth flow quietly relied on. None of this is in your code, and all of it breaks your code.
Dependencies drift toward end-of-life
A modern web app pulls in hundreds of transitive dependencies. Each one has a maintainer, a release cadence, and a security lifecycle. Left untouched for eighteen months, a package.json or a requirements.txt becomes a museum: half the packages have newer major versions with security fixes you can't easily adopt because you skipped four breaking releases. The longer you wait, the larger the jump, and the larger the jump, the more it looks like a rebuild.
Security debt compounds silently
This is the dangerous one because it's invisible until it isn't. A CVE published against a library you use is a public, indexed, automated invitation. Scanners find unpatched systems within hours. The gap between "vulnerability disclosed" and "vulnerability exploited at scale" is now measured in days. Software that isn't patched isn't stable — it's a countdown.
Knowledge evaporates
The most underrated rot of all. The engineer who built it remembers why the retry logic has that weird 1,100ms delay. Two years later they've left, the comment was never written, and the next person to touch that file is doing archaeology. Undocumented systems don't just get harder to change — they get scary to change, and scary-to-change is how a perfectly good system becomes "legacy" without a single line of code going bad.
The 60% rule
Here's the number that reframes every software budget conversation we have: across the full life of a typical business system, roughly 60% of total cost arrives after launch, not before. Some studies of long-lived enterprise software put maintenance at 60–80% of total lifetime cost. The build is the cheap part. The decade of keeping it alive is where the money actually goes.
This isn't waste. It's the cost of the asset continuing to be an asset. But it's almost never budgeted, because the build has a quote and the maintenance has a shrug. So let's put numbers on the shrug.
For most of the systems we build and run, ongoing maintenance lands between 10% and 20% of the original build cost per year. A simple, stable marketing site sits near the bottom; a transactional system with integrations, auth, and compliance obligations sits near the top. That maps cleanly onto our published app maintenance cost guide, which puts real-world retainers in the $1,500–$15,000 per month band depending on system complexity and how much active development is bundled in.
~60%
of lifetime cost is post-launch
10–20%
of build cost, per year, to maintain
$1.5K–$15K
typical monthly retainer (2026)
days
from CVE disclosure to mass exploitation
The mistake isn't spending this money. The mistake is not planning for it — building a $120,000 system with $0 budgeted to keep it running, then being shocked eighteen months later when it needs $20,000 of catch-up work to be safe to deploy again. That catch-up bill is the 60% rule collecting interest.
Maintenance is not one thing
"Maintenance" gets used as a single word for four genuinely different activities, and conflating them is how retainers go wrong. The classic engineering taxonomy splits it cleanly, and it's worth keeping straight because each type has a different trigger and a different urgency.
| Type | What it is | What triggers it | Roughly how much |
|---|---|---|---|
| Corrective | Fixing bugs and outages | Something broke | 15–25% |
| Adaptive | Keeping up with the outside world — runtime, OS, API, dependency, browser changes | The environment changed | 20–30% |
| Perfective | Improving what already works — performance, UX, small features | Users and the business ask | 35–50% |
| Preventive | Reducing future risk — refactoring, test coverage, dependency upgrades, docs | You decided to, before it bites | 10–20% |
The counterintuitive finding, consistent across decades of software-engineering research, is that corrective work — fixing bugs — is the smallest slice. Most maintenance spend is adaptive and perfective: keeping the system current and making it incrementally better. Teams that think maintenance means "we'll deal with bugs when they happen" have budgeted for the smallest quadrant and ignored the three that actually consume the time.
Preventive is the quadrant everyone cuts first and regrets most. It's the only one that's optional in the short term, which is exactly why it gets skipped, which is exactly why systems rot. Skipping prevention doesn't remove the work — it converts cheap, scheduled, preventive work into expensive, unscheduled, corrective work, usually at 2am.
Retainer models, and which one to pick
Once you accept that maintenance is continuous, the question becomes how to buy it. There are four common structures, and they fail in different ways.
Our strong default, and the way we structure our own maintenance and support engagements, is a fixed monthly retainer with explicitly reserved preventive hours. The reservation is the whole trick. A retainer that's "20 hours a month, use them however" always gets consumed by whatever's loudest, which means preventive work — the dependency upgrades, the test coverage, the docs — never happens, and you're back to break-fix with extra steps.
What a real retainer should include
A maintenance retainer worth paying for is not a help desk. At minimum it should cover:
- Monitoring and alerting that pages a human before your customers notice — uptime, error rates, and the slow-burn stuff like queue depth and disk.
- A security patching cadence (see below) with a defined SLA for critical CVEs.
- Dependency upgrades on a schedule, not a panic — small, frequent bumps instead of one terrifying annual leap.
- Reserved preventive hours that can't be raided for feature work.
- Documentation upkeep so the knowledge-evaporation engine stays off.
- A named engineer who actually knows the system, not a rotating ticket queue.
Security patching: the cadence that keeps you out of the news
Of the four rot engines, security debt is the one that turns a maintenance lapse into a front-page incident. So it deserves its own discipline, and that discipline is mostly about cadence — patch on a rhythm, not on a fright.
A workable patching policy for most business systems looks like this:
- Critical / actively-exploited CVEs: patch within 24–72 hours. This is the one with a hard SLA. The window between disclosure and automated exploitation is now days, sometimes hours, so "we'll get to it next sprint" is not a policy, it's a breach with a delay.
- High-severity CVEs: within the current sprint, two weeks at the outside.
- Routine dependency bumps: a standing monthly window. Small, boring, automated where possible. The whole point of doing this monthly is that no single upgrade is ever large enough to be scary.
- Major version upgrades: planned quarterly, scoped like small projects, because they sometimes are.
The infrastructure that makes this survivable is unglamorous and non-negotiable: automated dependency scanning (Dependabot, Renovate, or equivalent), a CI suite you trust enough to merge a patch on green, and a staging environment that actually mirrors production. Without that machinery, every patch is a manual risk assessment, so patches get skipped, so the system rots — the same loop again, just with security stakes.
One more uncomfortable truth: a system you can't safely deploy is already unmaintained, even if someone's on retainer. If patching requires a two-week regression cycle because there are no tests and the deploy is a ritual, you will not patch on a 72-hour SLA. Maintainability is a property you build in, and the preventive quadrant is where you keep it.
When to stop maintaining and rebuild
Maintenance is the default, and the cheaper default far more often than people want to believe — a system you're afraid of is usually a candidate for the strangler-fig modernization approach, not a demolition. But there's a real line where continuing to maintain costs more than replacing, and pretending it doesn't exist is its own kind of denial. Four signals, and you generally want three or more before you reach for the rebuild.
Notice what's not on the rebuild side: "it's old," "it's not the framework I'd pick today," "a competitor uses something shinier." Those are aesthetic reasons, and aesthetic rewrites are how teams spend eighteen months reproducing functionality they already had. The honest rebuild signals are economic and operational: maintenance cost outrunning the asset's value, an unpatchable platform, change velocity hitting zero, and knowledge gone.
And even when you do rebuild, the answer is rarely a big-bang rewrite — it's incremental replacement while the old system keeps the lights on, which is its own discipline and its own legacy modernization budget, typically $40,000–$400,000 depending on size and coupling. The rebuild that fails is the one that asks the business to hold its breath for a year. The rebuild that works never makes it stop breathing.
What good maintenance looks like in practice
To make this concrete: for a 40-location dental group we built and now run, "maintenance" is a fixed monthly retainer that covers a standing patch window, automated dependency scanning, uptime and error-rate alerting that pages an on-call engineer, a quarterly major-upgrade slot, and reserved preventive hours that go to test coverage and docs whether or not anything broke that month. In three years the system has never had an unplanned security-driven scramble — not because nothing was ever vulnerable, but because the patches landed on a Tuesday, on schedule, before they were urgent. That's the entire game. Boring, on a rhythm, before it bites.
The opposite pattern — the one we get called into after the fact — is the system that launched well, ran on autopilot, and went two years without a dependency upgrade because "it's working fine." It was working fine right up until a CVE in an auth library turned a quiet internal tool into an incident response. The catch-up bill to make it safely deployable again was larger than two years of the retainer they declined.
Frequently asked questions
How much should I budget for software maintenance?
Plan for 10–20% of your original build cost per year, trending toward the higher end for transactional systems with integrations, auth, and compliance obligations. In monthly terms that's commonly $1,500–$15,000, in line with our app maintenance cost guide. And remember the 60% rule: over the full life of the system, post-launch cost will exceed the build, so budgeting $0 for maintenance isn't saving money — it's deferring it into a bigger, worse bill.
Isn't maintenance just fixing bugs?
No — and that's the most expensive misconception in software budgeting. Bug-fixing (corrective work) is typically the smallest slice of maintenance. The majority is adaptive (keeping up with runtime, OS, API, and dependency changes you don't control) and perfective (improving what already works). Budget only for bug-fixing and you've planned for one of the four quadrants.
How often do I need to patch?
Critical, actively-exploited vulnerabilities should be patched within 24–72 hours — the gap between public disclosure and automated mass exploitation is now days. High-severity issues within the current sprint, routine dependency bumps on a standing monthly window, and major version upgrades planned quarterly. The cadence matters more than the heroics: small and frequent beats large and terrifying.
What's the difference between a retainer and break-fix?
Break-fix bills you only when something breaks, which structurally rewards letting things break — nobody's paid to prevent fires, only to fight them. A retainer is a standing relationship that includes prevention: scheduled patching, dependency upgrades, monitoring, and reserved preventive hours. Break-fix looks cheaper on the monthly invoice and is almost always more expensive over the life of the system. See how we structure maintenance.
How do I know it's time to rebuild instead of maintain?
Look for three or more of these together: maintenance cost climbing past 40–50% of the original build per year and accelerating; an end-of-life platform with no security updates available; change velocity near zero (every change takes weeks and breaks unrelated things); and nobody left who understands the system. "It's old" or "I'd pick a different framework now" are not on the list. And even then, prefer incremental replacement over a big-bang rewrite — legacy modernization keeps the business running while you replace it limb by limb.
Software is an asset that depreciates the moment you stop touching it. The teams that spend the least over a system's life are the ones that never let it sit still — small patches on a rhythm, preventive hours that can't be raided, and a clear-eyed view of the rare day when rebuilding genuinely beats maintaining. If you've got a system you're a little afraid of, that's the signal, not the verdict. Tell us what it runs and we'll tell you honestly whether it wants a retainer or a rebuild.
Read next:
- Modernizing legacy software without downtime
- What custom software actually costs in 2026
- Build vs buy: a framework for custom software
Related services: