What an app really costs to build and run
Most people asking “how much does an app cost” are really asking two questions at once, and only one of them tends to get answered. There is the cost to build the thing, which is what a quote covers, and there is the cost to keep it alive after launch, which is the part almost nobody puts in writing. We build our own apps and run them for years, so we see both numbers up close. Here is the whole picture, as honestly as we can put it.
Before the figures, the caveat that applies to every line below: it depends. A simple app with a few screens and no backend is a different animal to something with accounts, payments and a live data feed. Treat everything here as a range to reason with, not a quote.
The build: the one-off number
This is the number people expect. Design and build is the biggest single cost, and it is genuinely a one-off. You are paying for someone to turn an idea into a designed, working app on both iOS and Android, then get it through review and onto the stores.
The spread here is enormous and mostly honest. A small, focused app is a different order of cost to a marketplace with accounts, payments and a live backend. Anyone who quotes you a firm price before understanding what the app actually does is guessing. The thing that moves this number most is scope: every extra screen, every “can it also do”, every integration with someone else’s system adds build time, and build time is the cost.
What matters more than the headline figure is what the build leaves you with. A cheap build that nobody can maintain afterwards is not cheap. It is a bill you have not been handed yet.
The platform tolls: small, fixed, unavoidable
These are the easy ones to plan for because they barely move. To publish on Apple’s App Store you need an Apple Developer account, which is roughly 99 USD a year, every year, for as long as the app is live. To publish on Google Play there is a one-off registration fee of around 25 USD, paid once.
That is it for the stores themselves. They are small numbers, but they are the toll gates: no account, no app, and the Apple one keeps recurring, so it goes in the yearly column and stays there.
Running it: the monthly bill nobody quotes for
Once the app is live it needs somewhere to run. If it has accounts, saves anything, or talks to a server, you are now paying for infrastructure. The usual buckets are hosting, a database, sending email (password resets, receipts, notifications), analytics so you can see what people do, and error monitoring so you find out when something breaks before your users tell you.
The honest news here is that at low scale this is often modest. The managed stack we use is built so that a small app with a few hundred or few thousand users costs very little a month to run, sometimes not much more than a few coffees. The reason to keep an eye on it is that these costs scale with use. The more people use the app, the more it costs to serve them, which is a nice problem to have but a real one. Nothing here is a fixed number we would put in a table, because it tracks your usage, not the calendar.
Third-party services: the percentage cut
If your app takes money, whether that is subscriptions, one-off purchases or anything in between, there is a layer that handles it, and it takes a cut rather than a flat fee. Payment and subscription handling is typically a percentage of what you earn, and the app stores themselves also take a share of purchases made inside the app.
We flag this separately because it behaves differently to everything else. It is not a bill you pay whether or not the app does well. It scales with revenue, so it only really bites once money is coming in, and by then it is coming out of income rather than out of pocket. Worth knowing about, not worth losing sleep over before launch.
The cost most people forget: keeping it alive
This is the one that surprises people, and it is the reason we work the way we do. An app is not a thing you build once and leave. Apple and Google ship new versions of iOS and Android every year, and each one can quietly break something. The stores change their policies, and an app that was compliant last year can need work to stay listed. Phones change shape. Libraries the app depends on get updated or retired. And users find bugs, ask questions, and need support.
None of that shows up in a build quote, but all of it costs time, and it never stops for as long as the app is live. An app with nobody maintaining it does not stay still. It slowly rots, then one day it stops working or gets pulled, usually at the worst possible moment. This is exactly why we do not hand an app over and disappear. We build the thing and we run it, so the OS updates, the store-policy changes and the 3am fixes are handled by the people who built it in the first place.
So what is the real number
The honest answer is that the build is a one-off you can scope and quote, the tolls are small and fixed, the running costs are usually modest until you grow, and the ongoing upkeep is the line that quietly runs for the life of the app. A founder weighing this up should budget for all four, not just the first, because the first is the only one that ends.
We would rather you knew that before you started than found it out a year in.