What It Costs to Run an App Every Month After You Launch
A straightforward small business app usually costs somewhere between $0 and $40 a month to keep running, plus $99 a year to stay in the App Store and a one-time $25 to stay in Google Play. That is the infrastructure bill, and for a lot of apps it never gets much bigger than that.
The four-figure monthly numbers you find when you search this question are almost entirely labour — paying a team to keep changing the app. That is a decision you make, not an invoice that arrives on its own. Separating the two is the whole point of this post, because they behave completely differently.
The two store fees you cannot avoid
Apple charges $99 a year for the Apple Developer Program, listed on Apple's own enrollment page as of September 2026. It renews annually. If you let it lapse, your app comes off the App Store until you pay again, so treat it as a standing bill rather than a setup cost.
Google charges $25 once, per Google's Play Console registration page, also as of September 2026. There is no renewal. Pay it at launch and you are done.
Both of those should sit on accounts you own, not your agency's. We publish everything under the client's own developer accounts, and we explain why in detail here — the short version is that a renewal you cannot pay yourself is a renewal that can strand your app.
Add a domain if your app has a marketing page or handles deep links, which is usually $10 to $20 a year.
What a backend actually costs at small scale
This is where people expect a big number and usually do not get one, because the two services most small apps run on have generous free tiers.
Firebase's no-cost Spark plan includes 1 GiB of stored data in Cloud Firestore, 50,000 document reads and 20,000 writes a day, 10 GiB of monthly network egress, and 50,000 monthly active users on Authentication. Cloud Messaging — push notifications — is listed as no-cost on both the free and paid plans. Those figures are from Firebase's pricing page as of September 2026.
Supabase's Free plan includes a 500 MB database, 50,000 monthly active users, and 5 GB of egress, with the Pro plan at $25 a month. Those are from Supabase's pricing page as of September 2026.
Read those limits against what your app really does. An app used by a few hundred customers a few times a week, storing text records and sending the occasional push notification, sits comfortably inside either free tier. The first real bill usually arrives when you cross onto a paid plan for reasons of support and backups rather than raw usage.
Some apps have no backend bill at all
A calculator, a reference guide, a checklist, an offline field tool, a product catalogue that ships with the app — none of those need a server. They store data on the device, they work on a plane, and their monthly infrastructure cost is genuinely zero. The only recurring money is Apple's $99.
If your feature list has no user accounts, no shared data between people, and nothing that has to change without a new app release, ask your developer directly whether a backend is needed. It is a fair question and the answer changes your running costs for the life of the app.
The costs that do grow
Four things reliably turn a small bill into a real one, and all four are usage-based rather than fixed:
- Video and audio. Media is heavy, and you pay for every gigabyte sent to a phone. This is the single most common reason an app outgrows a free tier.
- Maps and geocoding. Priced per request, so a delivery or field-service app with constant lookups adds up faster than a booking app with one map view.
- SMS and email. Text message verification and transactional email are billed per message. A hundred customers is pennies; a hundred thousand is a line item.
- AI features. Anything calling a language model is billed per request. Useful, but budget it as a variable cost from day one rather than discovering it in month three.
None of these are reasons to avoid a feature. They are reasons to know which features carry a meter before you commit to them, which is exactly what the app cost calculator is for.
The bill people forget: someone to make changes
Your app will need work even if you never add a feature. Apple and Google both ship a major OS release every year, and Google sets a hard deadline each year for the API level your app must target to stay updatable in the Play Store — we covered what that deadline does to an app that misses it when the last one landed.
You have two honest options here.
The first is to pay nothing and fix things when they break. Plenty of small apps run this way successfully for a year or more. It works when your app is simple, your customer base is patient, and you have a developer you can call. It stops working the moment a store deadline arrives while you are busy.
The second is a monthly plan. Ours run $199, $399, or $799 a month depending on how much change you want included, and the pricing page sets out what each covers. Every build we do also comes with a 30-day launch warranty, so the first month after go-live is not the thing you are paying for.
We are not going to tell you the plan is mandatory. If your app is a static reference tool with no backend, buying a monthly retainer for it is a waste of your money.
Why a share of your build cost is a bad estimate
Search this question and most results answer with a rule of thumb: set aside some fixed fraction of what the build cost, every year, forever. It is a tidy formula and it falls apart at small scale.
That formula came out of enterprise software with dedicated teams, where upkeep genuinely does scale with the size of the original project. A $7,500 app does not have a $1,500-a-year server bill hiding inside it. It has a $99 Apple renewal, possibly a $25-a-month database, and a decision about whether you want someone on retainer. Adding those up gives you a number you can plan against. Multiplying your build cost by a fraction gives you a number that is either far too high or quietly ignores the labour question entirely.
An illustrative example
Take a hypothetical appointment booking app for a two-location clinic, built at our $7,500 tier. This is a worked scenario, not a specific client.
Year one: $99 to Apple, $25 once to Google, $15 for a domain, and a backend that sits inside Supabase's free tier because a couple of hundred patients booking a couple of times a month is nowhere near 500 MB or 50,000 monthly active users. That is roughly $140 for the entire first year, or under $12 a month.
Year two, the clinic adds SMS appointment reminders and moves to a paid database plan for daily backups. Now it is $99 to Apple, $300 to Supabase, and perhaps $200 in text messages. Still under $55 a month, and every dollar of the increase bought something the clinic chose.
The variable in both years is not infrastructure. It is whether the clinic wants a developer making changes every month.
Where this leaves you
If you are budgeting for an app you have not built yet, put the running costs on a separate line from the build. They are small, they are predictable, and they should not be the thing that decides whether you go ahead. What deserves the scrutiny is the build itself and whether the app earns its keep — we wrote about how to tell whether your business actually needs one and what a build costs in 2026.
If you already have an app and the running costs are a mystery, ask whoever holds your accounts for the last twelve months of charges from Apple, Google, and your hosting provider. Three statements will tell you more than any estimate.
And if you want a real number for something you are planning, the app brief wizard takes about five minutes and comes back with a scoped quote rather than a range.
Your app. In the stores. Done for you. US APP Team designs, builds, and launches your iOS and Android app for a fixed price. Start your app brief or book a free intro call — both are free.
Want to poke around first? Every tool in our free tool library runs in your browser with no signup: an app cost calculator, an app name generator, and a privacy policy generator.
