Budget 15–25% of the original build cost, every year. That is the industry rule of thumb for keeping production software healthy, and it holds up in practice: a $100,000 platform should plan for roughly $15,000–$25,000 a year. Mobile apps, products with many third-party integrations, and anything under compliance rules sit toward the top of the range. Companies that skip this budget don't save the money. They defer it, at interest. This guide shows what that budget buys, what it looks like month to month, and how to tell whether you're getting it.
Key takeaways
- Most of maintenance is preventive: updates, patches, and backups that stop emergencies from happening.
- Hosting and third-party services are separate running costs, not part of maintenance.
- Retainers are usually cheaper than ad hoc fixes, because an engineer who knows your system works much faster.
- Ask for a monthly report. If you only get invoices, the preventive work probably isn't happening.
In this guide: worked examples · what it pays for · maintenance calendar · monthly plans · costs that aren't maintenance · contract checklist · the cost of skipping it
The 15–25% rule, worked through
| Product | Build cost | Maintenance per year | Per month |
|---|---|---|---|
| Internal tool | $40,000 | $6,000 – $10,000 | $500 – $830 |
| Mobile app (toward the top of the range) | $60,000 | $9,000 – $15,000 | $750 – $1,250 |
| SaaS platform | $100,000 | $15,000 – $25,000 | $1,250 – $2,080 |
| Enterprise system | $250,000 | $37,500 – $62,500 | $3,125 – $5,210 |
For small products, the rule of thumb can land below a typical monthly retainer. In that case a bank of hours or a quarterly check-up is common, as long as security patching still happens promptly.
What maintenance actually pays for
- Fixing what breaks. Bugs, incidents, and the edge cases real users find, triaged and fixed within agreed response times.
- Preventing what would break. Dependency and framework updates, security patches, database upkeep, and backups that are actually restore-tested. This invisible work is most of why maintained software stays cheap to run.
- Keeping up with the world. New iOS and Android releases, browser changes, retired third-party APIs, and compliance-driven changes.
- Small improvements. The steady stream of tweaks and small features that keep a product feeling alive, without a new project negotiation every time.
What good maintenance looks like, week to year
| How often | What gets done |
|---|---|
| Continuously | Uptime and error monitoring, with alerts to a named engineer |
| Weekly | Review error logs and slow queries; triage reported bugs; check security advisories for your dependencies |
| Monthly | Dependency and framework updates, security patches, a health report, small improvements |
| Quarterly | Backup restore test, access review, performance check as data grows, cloud cost review |
| Yearly | Major framework or OS upgrades, mobile store compliance updates, certificate and domain renewals, architecture review |
What maintenance plans typically cost
Most teams buy maintenance as a monthly retainer sized to how much the product changes. For reference, these are our own plans:
| Product situation | What the plan covers | Monthly cost |
|---|---|---|
| Stable, low change | Monitoring, security patches, dependency updates, up to about 8 hours of fixes | $1,500 – $2,500 |
| Active, regular changes | The above plus up to about 20 hours of fixes and improvements, priority response, monthly health report | $3,000 – $5,000 |
| Continuous development | 40+ hours a month, an engineer who knows the codebase, roadmap participation, fastest response | $6,000 – $10,000 |
As a sanity check against the 15–25% rule: a $100,000 platform lands between the first two rows. If a vendor quotes dramatically less, look carefully at what their definition of maintenance leaves out.
Severity levels: what to agree up front
Response times only mean something if everyone agrees what counts as urgent. A common structure:
- Critical. Production is down, payments are failing, or data is at risk. Handled immediately.
- High. A core feature is broken for many users, with no workaround.
- Medium. Something is broken but there's a workaround, or it affects few users.
- Low. Cosmetic issues and small improvements, handled in the normal flow of work.
Costs that aren't maintenance
These run alongside maintenance but are paid to other providers, and they're often confused with it:
- Hosting and cloud usage, from a few hundred dollars a month for a small product to $20,000 or more at scale. Our cloud practice typically finds meaningful savings on unoptimized accounts.
- App store accounts: $99 a year for Apple's developer program and a one-time $25 for Google Play.
- Third-party services: email, SMS, maps, payments, monitoring, and AI APIs, usually billed by usage.
- Domains and certificates, small but easy to let lapse, with outsized consequences when they do.
What pushes the number up
- Mobile apps. App stores force OS updates on you every year, and Google Play regularly requires apps to target recent Android versions.
- Integrations. Every payment provider, CRM, or API you depend on can change or retire endpoints on its own schedule.
- Compliance. Regulated data means audits, access reviews, and documented processes.
- Growth. More users and more data expose performance problems that didn't exist at launch.
- Technical debt. Rushed or poorly documented code costs more to change safely, every single time.
What a maintenance contract should include
- What's covered, and what's explicitly not
- Response times for each severity level
- Included hours, and what happens to unused ones
- How work beyond the plan is quoted and approved
- Security patching commitments and timelines
- Backup frequency and how often restores are tested
- A monthly report of work done and hours used
- A clean exit: documentation, credentials, and access handed over if you leave
Signs maintenance isn't really happening
- You get invoices but no reports
- Your dependencies are more than a year out of date
- Nobody can say when a backup was last restored
- Users report outages before your provider does
- Every fix takes days because someone has to relearn the system
What happens if nobody maintains it
Unmaintained software degrades on a predictable curve. Security advisories pile up against outdated dependencies, then an OS, browser, or API change breaks something users can see. By the time someone looks, several major versions separate the code from current releases, and the catch-up work is larger than the maintenance that was skipped. It often turns into a partial rewrite. Deferred maintenance is a loan with bad terms.
Retainer, ad hoc, or in-house?
- Retainer. Predictable cost and an engineer who already knows your system, so fixes take hours instead of days. The right fit for most live products.
- Ad hoc. Cheapest on paper, but every request starts with someone relearning the codebase, and emergencies are billed at emergency rates.
- In-house. Makes sense once maintenance and new development add up to more than one full-time engineer's work.
Maintaining software someone else built
Many maintenance needs start with a departure: the developer left, or the agency moved on, and nobody knows how the system works anymore. That starts with a take-over audit, typically $2,000–$5,000, which maps the system, restore-tests the backups, and flags security issues before anyone commits to a plan. See software project rescue for stalled projects, or our support & maintenance plans for everything else.