App maintenance: the cost nobody budgets and everybody pays
Fifteen to twenty-five per cent of build cost every year, and it is not discretionary. An unmaintained app stops working within about eighteen months whether you touch it or not.
Key takeaways
- Budget 15 to 25 per cent of build cost annually purely to keep the app working.
- Unmaintained apps break at a cliff edge, usually when a major OS version ships, not gradually.
- Agree maintenance alongside the build contract, including response times for store-blocking issues.
- Make sure someone currently employed holds the developer accounts and certificates.
Budget 15 to 25 per cent of the original build cost per year to keep a mobile app working. This is not improvement or new features; it is the work required for the app to continue functioning at all. Apple and Google release major operating system versions annually, deprecate APIs on their own schedule, and periodically raise minimum requirements for submissions. An app left alone stops working, typically within about eighteen months.
- 15–25%
- of build cost per year to keep an app functioning
- ~18 months
- typical interval before an unmaintained app breaks or becomes unsubmittable
- Annually
- frequency of major OS releases on both platforms
What the money goes on
- Operating system compatibility. Each major release changes behaviour, permissions and appearance. Testing and fixing is required whether or not you changed anything.
- Dependency and SDK updates, including security patches. A dependency with a known vulnerability is a liability in your app, not in someone else's library.
- Store policy compliance. Requirements around privacy, permissions and target versions change, and non-compliance eventually blocks updates.
- Certificate and account administration. Expired certificates and provisioning are a recurring, entirely avoidable cause of an app disappearing from a store.
- Backend hosting, monitoring and the fixes that real usage surfaces.
What happens when it is skipped
The failure is not gradual degradation, it is a cliff. The app works fine until a new operating system ships and a proportion of users find it crashes on launch. At that point you cannot make a small fix, because a year of accumulated dependency updates has to be applied at once, and the person who built it has moved on. A neglected app frequently costs more to revive than it did to build the equivalent again.
How to structure it
Agree maintenance as a retainer at the same time as the build contract, not afterwards when the relationship has cooled and the team has been reassigned. Specify what is included, response times for a store-blocking issue, and who holds the accounts and certificates. That last point matters more than it sounds; the most common cause of an emergency is that nobody currently employed can access the developer account.
The honest way to present it
Quote the app as a build plus an annual figure, in the same document. A supplier presenting only the build number is either inexperienced or is letting the client discover the ongoing cost later, and neither is a good sign.
The version support decision
How many operating system versions back you support drives real cost, and it should be a deliberate business decision informed by your own analytics rather than a default. Supporting one additional old version can add a meaningful share of testing effort, and if it covers two per cent of your users the trade may not be worth it. Look at your actual install base by version and country, since device replacement cycles differ substantially across the region.
What to fund beyond keeping it alive
Maintenance keeps the app working; it does not keep it worth using. A separate, smaller budget for continuous improvement, informed by crash reports, reviews and the funnel from install to first completed action, is what stops an app from being technically current and commercially dead. Teams that fund only maintenance end up with an app that runs perfectly and that nobody opens.
A neglected app often costs more to revive than building the equivalent again.
Sources