What an Android app actually costs to build — and to keep running

When someone asks what an app costs, they usually mean what does it cost to build. That is a fair question with an unhelpful answer, because the same brief can be quoted at two lakh or twenty depending on what is assumed. It is also the wrong question to stop at, because the build is a one-time cost and an app is not a one-time thing.

What actually drives the build number

Screens matter less than people expect. A ten-screen app that displays information is far simpler than a four-screen app where users log in, upload things, and pay for something.

Three features move the number more than anything else. Accounts and login, because that brings password resets, session handling and a support burden. Payments, because that brings a gateway integration, reconciliation, failure states and a compliance conversation. And anything real-time — live tracking, chat, notifications that must arrive within seconds — because that changes the architecture rather than adding to it.

An app with none of those three is a straightforward project. An app with all three is a different category of work, and a quote that treats them as line items has probably not thought about them properly.

The half nobody quotes for

Then the app ships, and the recurring costs begin.

Google requires you to keep up with the platform. Every year Android raises the API level apps must target to stay in the Play Store. Miss it and your listing stops accepting updates, then eventually stops being shown to new devices. This is not optional maintenance; it is the cost of remaining published.

Your backend runs on servers that bill monthly, and that bill grows with usage. Push notifications, SMS for OTP, storage for whatever users upload, and any third-party service you depend on all carry their own monthly costs. Individually small, collectively not.

Then there are the devices themselves. Android runs on an enormous range of screen sizes and manufacturer skins, and something that works everywhere in testing will break on a specific phone in a specific state. Someone has to fix that when it happens.

Budget for the first year of running costs at somewhere between a fifth and a third of the build. Less if the app is simple and stable, more if it is central to your operations.

Where projects actually go wrong

Not in the estimate. In the scope.

The pattern is consistent: a project quoted for a defined set of features grows steadily through small additions, each individually reasonable, until the original timeline is meaningless and everyone is unhappy. Nobody agreed to that; it accumulated.

The fix is not stricter contracts. It is building the smallest version that solves the actual problem, putting it in front of real users, and letting what they do decide what gets built next. That is uncomfortable, because the smallest version always feels embarrassing. It is also the only reliable way to find out which of the features on the list nobody wanted.

Before you ask anyone for a quote

Write down what a user must be able to do — actions, not screens. Write down what happens when each one fails. Say whether you need accounts, payments, or anything real-time.

A page of that will get you comparable quotes from three different developers. Without it, you will get three numbers that cannot be compared, and you will pick the lowest, and that is usually the one that omitted the hard parts.