What it takes to keep an app running after launch

App budgets are often planned up to launch day. But launch is not the end of the work — it is the point at which steady work begins that does not depend on your decisions. Even if you decide to change no features, the platforms change their own rules, and their schedule is not your schedule. So it helps to know in advance which cost categories appear even under a "we change nothing" scenario.

In short

• There is no zero-work scenario: platform requirements force a rebuild and a fresh submission every year.
• Google Play requires apps to target a recent enough Android API level, and the requirement moves annually.
• Miss it and what you lose first is not the app itself but the ability to update it and to reach new users on newer devices.
• Store accounts, signing keys and certificates have an owner and an expiry date — an administrative cost rather than a development one.
• The largest unplanned cost is usually not a feature but support: answering users and investigating faults.

Why "we change nothing" still costs something

A mobile app lives in somebody else's environment. Operating systems ship annually, and the stores decide which build tools produce an acceptable package. Google Play's policy requires new apps and updates to target an API level within one year of the latest major Android release; at the time of writing that is Android 16 (API level 36) or higher, with the requirement taking effect each year on 31 August. Existing apps face a separate threshold: below it, the app stops being available to new users on devices running a newer system. Extensions can be requested, but that is a deferral rather than an exemption.

The practical conclusion is simple: at least once a year the app has to be rebuilt with newer tooling, tested and resubmitted, even if no user sees any change. That is not a feature or a preference — it is the condition for staying in the store. It is also worth checking, around that update, whether system changes have altered permission behaviour, notifications or background execution.

Cost categories across twelve months

Use this as a worksheet: against each category, write who does it and how often. There are deliberately no amounts here — they depend on the app's scope and its number of users, so any figure written down would be an assumption rather than an estimate.

• Platform compliance: the annual rebuild with newer tooling, testing, and resubmission to both stores.
• Store administration: the annual developer programme fees, account management, and updates to listings and screenshots.
• Certificates and signing keys: tracking expiry and renewing in time — an expired certificate blocks releasing entirely.
• The server side: hosting, database, backups, and verifying that a restore actually works.
• Dependency updates: security patches in the components you use, even when features do not change.
• Bug fixing: the things that only surface on real devices and real networks.
• User support: replying to messages and store reviews, and investigating what they report.
• Monitoring: capturing crashes and errors so you notice a problem before your users do.
• Device testing: checking new phone models and new system versions.
• Legal and privacy: updating privacy disclosures when your data collection or the store requirements change.

What should belong to you rather than the supplier

This part is not technical, but it decides whether you can ship an update independently in a year's time. Store accounts should be in the company's name, and signing keys held on your side with a backup. The practical consequence is plain: if the key is only available to the supplier, shipping an update depends on their availability. That is not a question of trust but of continuity.

• App Store and Google Play developer accounts in the company's name.
• Signing keys and their backups on your side, stored securely.
• The app's source code and its history handed over to you, not only a compiled package.
• Server and database access under your control.
• The original listing copy, screenshots and icons.

An illustrative example

Illustrative scenario, not a description of a client project. Imagine an app that launches and runs for a year with no visible problems, so no maintenance budget was planned. A year later the store refuses an update because the package was built with tooling that is now too old. At the same moment the signing certificate expires, and its only copy is held by somebody no longer on the project. The technical work here is not large — but it becomes urgent, and it happens at a time nobody chose. That is precisely why the annual update belongs in the plan as routine work rather than as an incident.

Planning without invented numbers

It is more useful to plan the rhythm and the responsibility than the total. Once it is clear who performs the annual compliance update, who tracks certificate expiry and who answers users, the budget becomes a calculation rather than a guess — and it can be requested as a quote with a scope attached.

• Write down when the annual compliance update happens, and put it in the plan as standing work.
• Agree who tracks certificate and key expiry, and where the backups live.
• Decide how quickly crashes are responded to — this defines the support scope more than anything else.
• Define which devices and system versions count as supported, and which do not.
• Agree who replies to store reviews, because that is continuous rather than one-off work.
• Ask for maintenance as its own line with a scope in the quote, rather than a general phrase.

What this guide does not tell you

It contains no amounts, no percentages and no typical maintenance rate. Costs follow the app's scope, its server side, its number of users and how many platforms you support, so a general figure would be an assumption. The specific platform deadlines and API levels also move every year — what matters here is not today's number but that the requirement returns annually and has to be planned for.

If you settle just one thing after launch — that the annual compliance update is planned work with a named owner — most of the urgent, badly-timed situations simply stop happening.