Short answer: plan on 15–25% of the initial build cost per year to keep an app healthy, plus running costs for hosting and third-party services, plus a separate budget for new features. A $60,000 app therefore needs roughly $9,000–$15,000 a year in upkeep, or about $750–$1,250 a month. The percentage is a planning convention, not a law, and the sections below show how to build a more precise figure for your own app.
About these numbers. They are planning estimates based on the typical work involved and typical market rates. They are not survey data and not a BBR price list.
Why apps need maintenance at all
A mobile app depends on things its owner does not control: two operating systems that release a major version every year, two stores with changing policies, new phone sizes and hardware, dozens of third-party libraries, and the external services it calls. Each of these changes on its own schedule. The code you shipped does not decay, but its surroundings move, and the gap widens until something breaks.
Websites have some of the same pressures. Apps feel them more sharply because the stores enforce deadlines and because users cannot be moved to a new version instantly.
What maintenance consists of
Operating system updates
Apple and Google each release a major OS version annually, with betas available months earlier. New versions change permission behaviour, background execution rules, notification handling and interface details. Maintenance means testing on the beta, fixing what changed, and releasing an update close to the public OS launch.
SDK, framework and dependency updates
A typical app includes a framework such as React Native or Flutter plus libraries for navigation, networking, analytics, payments, push and ads. They release security fixes and compatibility updates continuously, and older versions lose support. Updating a little every month or two is routine work. Updating after two years of neglect is a project, because everything has to move at once and breaking changes stack up.
Store policy and technical requirements
Both stores change their rules regularly and enforce them with deadlines. Google Play requires apps to target a recent Android API level, and apps that fall behind can no longer publish updates and become unavailable to new users on newer devices. Apple requires submissions to be built with recent versions of its tools and periodically contacts developers about apps that have not been updated for a long time. Past policy changes on both stores have covered privacy disclosures, in-app account deletion, permission justifications and billing library versions. Each one takes anywhere from an hour to several days of work, and none is optional.
Bug fixes and crash monitoring
Real users on thousands of device models find problems that testing did not. Someone has to watch the crash reporter, prioritise, fix and release. The volume is highest in the months after launch and after each significant feature release.
Backend and infrastructure
If the app has a server, it needs operating system and runtime security updates, database maintenance, tested backups, SSL certificate renewal, monitoring and occasional scaling. It also costs money every month to run whether or not anyone is working on it.
Third-party API changes
Payment providers, maps, social login, messaging and data suppliers version and retire their APIs. When a provider announces a deprecation, you have a fixed period to adapt.
Security
Applying security patches, rotating credentials, reviewing access when people leave, and responding to vulnerability disclosures in libraries you use.
Small improvements and support
Copy changes, a confusing screen reworked, a report the operations team needs, answering “why did this user’s payment fail”. These are minor individually and continuous in aggregate.
Cost items at a glance
| Item | Frequency | Typical cost or effort |
|---|---|---|
| Apple Developer Program | Yearly | $99 |
| Google Play developer account | Once | $25 |
| Hosting, database, storage, backups | Monthly | Roughly $20–$300 for an early-stage app; rises with users and data |
| Metered services: SMS, email, maps, push, AI APIs | Monthly | Often small at first; scales with usage. Worth reviewing quarterly |
| Monitoring, crash reporting, analytics tools | Monthly | Free tiers cover many small apps; paid plans as volume grows |
| Domain and SSL | Yearly | Minor |
| Annual OS compatibility update (both platforms) | Yearly | About 1–3 person-weeks for a cross-platform app; more for two native codebases |
| Dependency and framework updates | Every 1–3 months | About 0.5–2 days each time when done regularly |
| Store policy compliance changes | A few times a year | An hour to several days each |
| Bug fixes and crash triage | Continuous | A few hours to a few days a month, heaviest after releases |
| Server patching and operations | Monthly | A few hours a month for a simple setup |
| Store commission | Per sale | 15–30% of digital goods and subscription revenue. Not maintenance, but belongs in the same financial plan |
How to budget it
There are two ways to reach a number. Use both and see whether they agree.
Method 1: percentage of build cost
Take 15–25% of what the app cost to build, per year. Use the lower end for a simple app with a thin backend and few integrations, and the upper end for an app with several integrations, payments, two user roles or two native codebases. It is crude, and it is usually close enough for planning a year ahead.
Method 2: hours multiplied by rate
Estimate a monthly baseline of engineering hours, add the annual OS update, and multiply by the hourly rate of whoever does the work.
| App | Monthly baseline | Annual OS / framework update | Hours per year | At $50/hour | At $150/hour |
|---|---|---|---|---|---|
| Simple utility app, thin or no backend | 4–8 hours | 40 hours | About 90–140 | $4,500–$7,000 | $13,500–$21,000 |
| Mid-complexity app with backend, subscriptions, admin panel | 12–24 hours | 80 hours | About 220–370 | $11,000–$18,500 | $33,000–$55,500 |
| Complex multi-role app with payments and real-time features | 30–60 hours | 120 hours | About 480–840 | $24,000–$42,000 | $72,000–$126,000 |
Add running costs for hosting and services on top, then a contingency of 10–20% for the unexpected: a provider shutting down an API, a store policy with a short deadline, a security issue in a library.
Worked example
A subscription content app built for $54,000 at $50 an hour (example 2 in our app development cost guide). Method 1 gives $8,100–$13,500 a year. Method 2, using the middle row, gives $11,000–$18,500. The overlap, roughly $11,000–$13,500, is a sensible engineering budget. Add perhaps $1,200–$3,000 a year for hosting and services and a 15% contingency, and the first-year upkeep plan is about $14,000–$19,000, or $1,200–$1,600 a month. New features are additional.
What happens if you skip it
| Time without maintenance | Typical consequences |
|---|---|
| 0–6 months | Little visible. Known bugs stay unfixed; reviews start mentioning them |
| 6–12 months | A new OS version arrives. Some screens misbehave, notifications or permissions act differently, crash rate rises on new devices |
| 1–2 years | Store warnings about outdated target API level or SDKs. Updates may be blocked until the app complies. Libraries are several major versions behind, so even a small fix first requires a large upgrade |
| 2+ years | Reduced visibility or removal from the stores, a third-party API the app relies on is retired, unpatched security issues. Recovery often costs a meaningful fraction of the original build, and a rebuild may be cheaper |
The pattern is that maintenance deferred is not maintenance avoided. It comes back as one large, urgent, poorly timed project, usually at the moment you wanted to ship something else.
How to keep maintenance costs down
- Decide the approach with upkeep in mind. One cross-platform codebase is cheaper to maintain than two native ones; see native vs cross-platform.
- Keep the dependency list short. Every library is a future update.
- Prefer managed services for authentication, push and storage, so that someone else patches the servers.
- Update little and often. Monthly or quarterly updates are cheap; biennial ones are not.
- Have automated tests for the critical flows: sign-up, purchase, the core feature. They make updates safe and therefore quick.
- Set up crash reporting and uptime monitoring before launch, so problems are found by tools and not by reviews.
- Insist on documentation for building and releasing the app. Without it, every new developer spends days rediscovering the process.
- Own your accounts and repository, so you can change who maintains the app without starting again.
- Remove features nobody uses. Code that does not exist needs no maintenance.
Who should do the maintenance
- The team that built it is the cheapest option in hours, because they already know the code. Make sure the arrangement has a defined scope and response times, and that you could leave if you needed to.
- An in-house developer makes sense once the product justifies continuous feature work. Maintenance alone rarely fills a full-time role for a single app.
- A freelancer can work for a simple app, with the risk of availability when something urgent happens.
- A different studio is workable if you hold the code and accounts. Expect a paid onboarding review first.
When you evaluate a vendor for the original build, ask about maintenance terms before you sign, not after launch; our guide on choosing a mobile app development company lists the questions. At BBR, ongoing support is scoped separately from the build, as described on the how we work page. For apps we did not build, we start with a codebase review. The mobile app development page covers both cases, and product engineering describes an ongoing arrangement when maintenance and new features run together.