Guide · Costs & timelines

App maintenance cost per month: what a live app really costs to keep running

App maintenance cost per month and per year, line by line: store fees, hosting, monitoring, forced OS updates and engineering time, from running 4 apps live.

By Akash Bansal, founding engineerUpdated 5 November 20267 min read

Most "app maintenance cost" pages are written by agencies selling maintenance contracts, so they lead with the scariest number. I ran Urban Culture's four apps (customer, partner, admin console and web) in production from 2020 to 2025, so here's the version from the side that pays the bills: what a live app costs each month, which costs grow with you, and which ones you can't skip.

How much does app maintenance cost per month?

For a small live app, the fixed fees and hosting usually come to tens or a few hundred dollars a month. Engineering time is the real cost, and it's the one most budgets leave out. The widely quoted rule of thumb is 15–20% of the build cost per year, so a $15,000 MVP needs roughly $2,000–$3,000 a year just to stay healthy.

That rule comes from agencies, not from a neutral survey. Chop Dawg's 2026 guide, for example, puts maintenance at 15–20% of the original build cost per year, rising to 30–40% for legacy or poorly built apps, and says many US apps land between $2,500 and $5,000 a month. Treat those as vendor numbers for apps much bigger than an MVP. The percentage is the useful part, because it scales with what you built.

The clearer way to budget is to split "maintenance" into three buckets, because they behave differently:

Most surprises come from mixing bucket 2 and bucket 3. A founder budgets "maintenance" at a few hundred dollars, then asks for a new feature every week, and the invoice looks like a build.

What are the fixed monthly costs of running an app?

The fixed fees are public and small. Here's what a lean app typically pays before usage grows, with each provider's published price.

Those prices change, so check each page before you budget. The point stands either way: at MVP scale, the bill for keeping an app online is usually smaller than one hour of engineering.

Which running costs grow as the app grows?

Anything priced per use: database reads and writes, map and location lookups, AI model calls, file storage and bandwidth, SMS and push messages. These are cheap per request and expensive per million, and they grow on exactly the axis you want to grow.

Two more grow with revenue rather than usage. Payment processing takes a percentage of every charge (Stripe lists 2.9% + 30¢ for US cards on its pricing page). And if you sell digital goods inside a mobile app, the stores take a commission; Apple's Small Business Program cuts it to 15% for developers earning up to $1 million a year.

At Urban Culture, the usage cost that grew fastest was Google's Distance Matrix and geocoding calls, because every booking needed distances between customers and partners. Replacing them with our own geolocation service cut that cost by 80% with accuracy held. That's the pattern to watch for: one usage-priced service quietly becomes the biggest line on the bill. I wrote up how we did it in cutting the Google Maps Distance Matrix bill by 80%.

The cheap defence is billing alerts on every cloud and API account from day one, set at a number that would surprise you.

What does "keeping an app healthy" involve?

It's the engineering work that keeps the app shippable: updates you didn't choose, bugs real users find, and small fixes that stop small problems compounding. Most of it isn't visible to users, which is why it's the first thing founders cut and the most expensive thing to catch up on.

1. Platform deadlines. Apple and Google raise their minimums every year. Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 and an iOS 26 SDK. On Google Play, new apps and updates must target Android 16 (API level 36) from 31 August 2026, and existing apps that don't target at least Android 15 stop being shown to new users on newer devices. You don't choose these dates.
2. Dependency and security updates. Frameworks, SDKs and libraries ship fixes. Skip a year of them and the next upgrade is a project, not a task.
3. Outside APIs changing. Payment providers, maps, auth and AI vendors deprecate versions and change limits. Each integration is a small permanent tax. Terms change too: Strava tightened its API rules in November 2024, which shaped the Strava-style club app build.
4. Bugs from real use. Real users find paths testing never tried, especially in year one.
5. Keeping the data useful. Backups you've actually restored once, and reporting that still works. At Urban Culture we piped Firestore into BigQuery so the business could ask questions without slowing the live app.
6. Outages. Someone has to be reachable when payments fail on a Saturday.

None of this is dramatic, and that's the trap. With several apps on one framework, as we had at Urban Culture, one upgrade touches every app at once. Done on schedule it's routine; deferred until a store deadline, it competes with everything else you wanted to ship that month.

How much does app maintenance cost per year?

Use the 15–20% rule for the keep-healthy bucket, add fees and hosting, and keep feature work separate. Year one usually runs higher than the rule, because launch is when the real bugs show up.

Those are rule-of-thumb figures, not quotes. They assume the app was built cleanly, the code is documented and in your repository, and nothing big changes. A poorly built app sits at the top of the range or above it, which is one reason handover documentation is worth paying for at build time.

Notice how small the MVP row is. That's honest: a focused app with few integrations doesn't need a large monthly retainer just to stay alive. What it needs is someone who can do the work when it's due.

Retainer, freelancer or in-house: who should maintain the app?

Match the arrangement to how often the app changes, not to how important it feels.

The one non-negotiable across all four: the code, the cloud accounts and the store accounts are in your company's name, so you can change who maintains the app without asking anyone's permission. I cover how to check that in who owns the code, and when a part-time technical lead makes sense in fractional CTO vs full-time CTO vs agency.

How do you keep app maintenance costs down?

Most maintenance cost is decided at build time. Each part you build is paid for three times: once to build, once to test, and then every month as something to update.

1. Fewer integrations. Every outside API is a permanent maintenance line. Add one only when it earns its keep.
2. Web first if you can. A web app has no store fees, no store review and no yearly mobile SDK deadlines.
3. One codebase for both stores. A cross-platform framework (we used Flutter) means one upgrade, not two.
4. Managed services over servers you run. Patching your own servers is maintenance you chose.
5. Billing alerts and error monitoring from day one. Cheap, and they turn surprises into notifications.
6. Upgrade on schedule. Small, regular updates cost less than one big catch-up before a store deadline.

What should a maintenance agreement include?

Whatever you choose, write down five things: what counts as maintenance versus new work, how fast someone responds to an outage, which upgrades are included (store deadlines especially), who holds the accounts, and how either side ends the arrangement with a clean handover. The contract side of that is in the plain-English SOW template.

If you're planning a build and want the running costs estimated before you commit, that's part of how I scope: the fixed quote comes with an estimate of what the app will cost to run. Here's how I work. For a rough build number first, try the app cost calculator.