Shimira ITBudget 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.
- Whoever maintains it, you should always hold the keys: repos, accounts, credentials, and documentation.
- 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 · by product type · security patching · costs that aren't maintenance · contract checklist · what you should own · lowering the cost · 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.
The first year after launch often runs toward the top of the range: real users find the edge cases testing missed, and early feedback drives small changes. After that, the mix shifts from fixing toward keeping up with updates and making improvements.
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.
Maintenance by type of product
The 15–25% rule is an average. Where the effort goes depends on what you're running:
| Product type | What needs regular attention |
|---|---|
| Web app or SaaS | Framework and dependency updates, database performance as data grows, browser changes, integrations with other services |
| Mobile app | Yearly iOS and Android releases, store policy and target-SDK requirements, device-specific bugs, push notification services |
| E-commerce | Payment provider changes, checkout performance, security, plugin or extension updates, seasonal traffic peaks |
| Internal tool | Access and permission reviews, integrations with the systems it reads from, backups; usually the lightest to maintain |
| Product with AI features | Model retirements and upgrades, re-running accuracy tests, prompt tuning, cost monitoring, re-indexing changed documents |
AI features deserve a special mention: providers retire models on their own schedule, and each change means re-testing accuracy before switching. Our AI app development cost guide covers those running costs in detail.
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.
Security patching: what to agree
Most breaches of small and mid-sized products don't involve sophisticated attacks. They exploit known vulnerabilities in outdated dependencies that nobody updated. A maintenance agreement should make patching explicit:
- Monitoring. Automated alerts when a dependency you use has a published vulnerability, reviewed at least weekly.
- Patch targets by severity. For example, critical vulnerabilities in exposed components within a few days, and lower severities in the next monthly update. Agree targets that fit your risk; what matters is that they're written down.
- Secrets and access. Rotating API keys and passwords when people leave, and a quarterly review of who has access to what.
- Backups that restore. Regular backups, plus a real restore test on a schedule. The day you need a backup is the wrong day to find out it doesn't 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
What you should always own, whoever maintains it
The most expensive maintenance situations we see start with a client who can't get into their own product. Keep these in accounts you control, and check that you still can once a year:
- The code repository, with admin access in your name
- Cloud and hosting accounts, and the billing for them
- The domain registrar and DNS settings
- App Store and Google Play developer accounts
- Third-party service accounts: payments, email, analytics, and any APIs the product depends on
- A password manager or vault holding every credential
- Documentation: how to deploy, how the system fits together, and where backups live
If a provider resists putting these in your name, treat it as a warning sign. Good maintenance partners keep clients by doing good work, not by holding the keys.
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
How to lower maintenance costs without cutting corners
- Automate dependency updates. Tools like Dependabot or Renovate open small, regular update requests, which are far cheaper to handle than one giant upgrade every two years.
- Test the paths that make money. Automated tests on sign-up, login, checkout, and other critical flows let engineers update with confidence instead of manually re-checking everything.
- Use fewer, better dependencies. Every library is something to update. Removing ones you barely use pays off for years.
- Prefer managed services. A managed database or auth provider shifts patching and scaling to a vendor whose whole job is doing it well.
- Keep documentation current. The cheapest fix is the one an engineer doesn't have to rediscover.
- Pay down debt deliberately. Set aside a small share of each month's hours for cleaning up the parts of the code that slow every change down.
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.