What it costs to maintain an app after launch, and what the money actually pays for
Plan on roughly 15 to 20 percent of the original build cost per year to keep an app working, plus fixed store fees: 99 USD per year for the Apple Developer Program and a one-time 25 USD for Google Play (Apple, Google). That percentage is an industry rule of thumb repeated by development firms, not a measured study, so use it as a starting budget and adjust for what your app depends on.
Where the 15 to 20 percent comes from
Several development firms publish the same range. Cleveroad puts annual maintenance at 15 to 20 percent of the build cost and attributes it to CISQ, but we could not find the original CISQ publication (Cleveroad, updated June 2026). Space-O uses the same percentage and works it through: a 30,000 USD build leads to about 4,500 to 6,000 USD per year, a 100,000 USD build to 15,000 to 20,000 USD (Space-O, updated October 2026).
In dollar bands, Cleveroad estimates 6,000 to 20,000 USD per year for a small app, 20,000 to 80,000 USD for a mid-size app and 80,000 to 300,000 USD or more for a complex one, and suggests a 20 percent buffer in the first year (Cleveroad, 2026).
All of these come from firms that sell maintenance. No survey-grade data on app maintenance costs was found.
What maintenance actually pays for
| Item | Why it cannot be skipped | How often |
|---|---|---|
| OS updates | New iOS and Android versions change APIs, permissions and screen sizes | Every major release |
| Store requirements | Google Play requires apps to target a recent Android API level, and the bar keeps moving (Google, target API); Apple updates its App Review Guidelines and SDK requirements | Ongoing |
| Dependency updates | Libraries, SDKs and frameworks (React Native, Expo, payment SDKs) get security fixes and drop old versions | Monthly to quarterly |
| Bug fixes | Real users find what testing missed | Ongoing, heavier after launch |
| Privacy forms | App Privacy details on Apple and the Data safety form on Google must stay accurate when SDKs change (Apple, Google) | Whenever data use changes |
| Backend and hosting | Servers, database, email, storage, monitoring | Monthly bill |
| Subscriptions and paywall | Price changes, new offers, receipt validation, restore issues | As needed |
| ASO and store listing | Keywords, screenshots and descriptions per language | Periodic |
| Small features | Requests from users that keep them subscribed | Planned releases |
Maintenance is not the same as new development. A big new feature is its own project and should be quoted as one.
Fixed costs you will pay no matter who maintains it
- Apple Developer Program: 99 USD per membership year, shown in local currency in some regions; fee waivers exist for eligible nonprofits, educational institutions and government entities (Apple).
- Google Play: a one-time 25 USD registration fee (Google).
- Store commission on sales: Apple's Small Business Program charges 15 percent on paid apps and in-app purchases for developers under 1 million USD in proceeds (Apple). Google Play changed its service fees in 2026 for the US, UK, EEA, Australia and Japan, with auto-renewing subscriptions at 10 percent plus a 5 percent billing fee; other markets still use the earlier 15 percent model until the global rollout (Google).
- Hosting and services: depends entirely on your backend. An app that stores data on the device can have close to zero server cost; an app with accounts, sync and AI features will not.
What drives the cost up or down
Cheaper to maintain:
- Data stored on the device, no accounts, no server.
- Few third-party SDKs.
- One codebase for both platforms.
- Code and build setup documented, in a repository you control.
More expensive:
- Custom backend with user accounts and sync.
- AI features that call paid APIs per request.
- Many integrations with other services that change their APIs.
- Several apps or white-label variants sharing one codebase.
- Code that only one person, who has since left, understands.
How to budget for year one
- Take the build cost and set aside 15 to 20 percent as a starting maintenance budget, per the vendor rule of thumb above, and more in year one when most bugs surface.
- Add the fixed fees: Apple yearly, Google once, plus monthly hosting.
- Ask your developer for a list of every third-party service and its billing model.
- Agree on what counts as maintenance (fixes, OS and SDK updates, store compliance) and what counts as new work.
- Decide on a release rhythm, for example a small update after each major OS release and as needed in between.
- Make sure the code, build setup and store accounts are yours, so maintenance can move to someone else if it has to. See who owns your app code and developer accounts.
What ODEL's own updates look like
ODEL maintains its own live apps, so this list is practical, not theory. Recent examples from the store release notes:
- ChairBook 1.1.0 added Home Screen shortcuts, made paywalls show store-loaded prices and improved purchase and restore checks.
- BidCraft 1.1.0 added shortcuts, clearer subscription management and safer CSV exports.
- DishBook 2.2.0 shipped a redesign, personalized onboarding and fewer, smarter notifications.
Most of that is maintenance in the sense above: store rules, purchase reliability and small changes that keep users subscribed.
When ODEL fits, and when it does not
ODEL fits if you need an existing iPhone or Android app kept current, a rejected update fixed, or someone to take over an app whose original developer is gone: see app rescue and maintenance and subscription apps and paywalls. Work is quoted after a short look at the code and accounts.
A better option might be:
- an agency with on-call staff if you need 24/7 incident response or an uptime contract,
- your original developer, if they are reliable and documented the code,
- an in-house developer, if the app is your core product and changes every week.
To get a maintenance estimate, share what the app is built in and where it is published. For build costs before launch, see how much it costs to build an app.
