App maintenance cost: what are you still paying developers for?

Your app is finished and live, and the build contract has ended. Then someone brings up maintenance, and in our experience it's the developers. Founders rarely raise it themselves, because many don't know it's something they need to care about. You can decide not to have any.

So what does app maintenance cost? There isn't a number I could give you that would mean anything, because the work depends on how big your platform is and what it relies on. By platform I mean the app and everything behind it. What I can do is show you what that work is, why it turns up even when nobody touches the code, and how to read any support offer you're given.

Your app plays by the stores' rules

A mobile app reaches its users through the App Store or Google Play, two markets you don't own, and their rules are the ones you play by. They change those rules on their own schedule, and your app has to keep up.

Every Android app declares which version of Android it's built for, its target. Google counts versions by SDK level, the number of Android's software development kit (SDK), the tools apps are built with: Android 14 is level 34, Android 16 is level 36. Say your app targets level 34. Since 31 August 2026, Google Play only accepts a new phone or tablet app, or an update to one, if it targets level 36 or higher. So when you want to ship a small feature, the first job is raising the target to 36. If that changes how parts of Android your app uses behave, the code that uses them has to be rewritten before the feature can go out. That's how a small feature turns into a fair amount of rewriting.

And if nobody raises it? The app doesn't disappear. Apps that aren't updated are held to a minimum one level below the one for updates, and level 34 is below that too. That minimum decides who can still get the app: people who already have it keep it and can reinstall it, but a new user whose phone runs a newer Android version than the app targets can't find or install it. From where you're sitting, nothing looks wrong, which is why this is easy to miss.

What changes when nobody touches the code

A live app needs work even when nobody touches its code, because the things it depends on keep changing. We've seen each of these create work:

• Store requirements. Since 28 April 2026, Apple only accepts uploads built in Xcode 26 or later, Apple's tool for building apps, with the iOS 26 SDK. The app usually stays listed, but before Apple accepts your next update, the app has to be rebuilt with the new tools and anything that breaks has to be fixed.
• New iOS and Android versions. iOS and Android both get a new version every year, and if nobody tests the app on the new one, you may not know what changed until a user tells you.
• Libraries. Apps are built on libraries, ready-made code other people maintain. Sooner or later one needs upgrading because of a compatibility problem, and whatever that problem breaks stays broken until someone does the upgrade.
• End-of-life versions. Databases, runtimes (the software your server code runs on) and other parts behind the app have a date when they stop getting security updates. After that, flaws found in them stay open.
• Third-party APIs. Payments, maps, login: your app talks to other companies' services through their APIs, the interfaces they offer other software. APIs change, and some close down. If nobody is watching, the feature that depends on one can stop working.
• Certificates. Apple's distribution certificate is what lets you upload new versions of the app. If it expires, the app already in the App Store isn't affected as long as your Apple developer membership is valid, but you can't upload updates until it's replaced. The TLS certificate behind the https in your server's address proves the server is yours. One issued since 15 March 2026 lasts at most 200 days, and from 15 March 2027 at most 100, so someone has to renew it more and more often. If it runs out unnoticed, the app can't talk to its server.

What app maintenance includes

Between releases, app maintenance is mostly regular checking. This is what I'd expect a support agreement to cover:

• Libraries and frameworks. Watching and updating the ones the platform uses, security updates first. If your server runs on Spring Boot, a Java framework, that needs updating every so often.
• Monitoring and logs. Reading what the systems record about themselves, such as errors and how much disk space is left, to see the platform is healthy.
• Status check. A report on the state of the whole platform.
• Backups. Either someone checks that they exist, or someone actually restores one to see that it works.
• Access reviews. Going through who can still get into what, from the servers to the Apple and Google developer accounts, and removing access people no longer need.

When something does need changing, I'd expect it to go through the same routine as any new work. It goes to a test environment first, to check it's reasonably stable and doesn't crash. Then it goes live when there's as little load as possible, not at the busiest time of day. Afterwards someone checks the main feature and anything it touches: if a feature has two smaller ones hanging off it and the main one changed, those get tested too.

How much you hear about all this is up to you: a status report with every release, a message when it's live, or just a tag on the ticket in Jira.

A response is not a fix

A support offer's response time is not a promise that the problem is fixed by then. Response time is how quickly someone looks into it and proposes a next step. Resolution time depends on what needs fixing. That could be one setting or a rewrite, and nobody knows which until they've looked.

When a routine check finds something, is the fix included, or quoted separately? I'd expect routine updates to libraries and frameworks to be part of the regular work, and really small fixes, like a simple configuration change, can be too. Anything bigger that a check uncovers is fair to quote separately. Find out where a supplier draws that line before anything turns up.

How much maintenance does your app need?

A small app needs the same things looked after as a big platform does, just less of each. What it can usually do without is someone on call at night and at weekends, and checks and status reports more often than it needs.

To get a feel for your own app, list what it relies on: outside services such as payments or login, the server behind it, and what it was built with. Ask the developers for whatever you can't list yourself. "I don't know" is a fine first answer.

I don't buy the rule of thumb that maintenance costs a fixed share of the build cost every year. The work follows how big the platform is and what it relies on, not what it cost to build. Two apps with the same build cost can depend on very different numbers of libraries, APIs and certificates, and it's those that create the work.

The other common advice is that the app is done at launch, so you can let the developers go. It isn't done, but you can let them go. It's a risk you can choose to take. If you do, at least read what Google and Apple send you through Google Play Console and App Store Connect, where the app is managed, about new requirements and deadlines.

If you choose not to spend money on maintenance, choose which problems you want to live with.

Questions to put to any app support offer

We look after live apps and the systems behind them as part of application management. Whoever you ask, put these questions to them. The stores will keep changing their rules either way, and everything else your app relies on will keep changing too. What you'd be paying for after launch is someone keeping up with all of it.