Three quotes, one brief
Send the same one-page app brief to three development companies in India and you will get three
numbers that look like they belong to different projects. One comes back at a few lakh. One is three
times that. One asks for a call before quoting anything.
None of them is necessarily wrong. They are answering different questions, and the brief did not
say which question to answer.
That is the real reason "how much does an app cost in India" has no single number attached to it.
What it has instead is a small set of decisions that move the price a lot, and a slightly larger set
that barely move it at all. Once you know which is which, a quotation stops being a mystery and
starts being something you can argue with.
What actually moves the number
How many screens do something. Not how many screens exist — how many of them have logic behind
them. A twelve-screen app where nine are static content is a small app. A five-screen app where
every screen syncs, validates, and handles failure is not.
Whether it needs an account system. Login, roles, password reset, session handling, and the
support burden that comes with all of it. Skipping accounts entirely, where the product allows it, is
the single biggest saving available in most briefs.
What it has to talk to. Payments, an existing ERP, a courier's tracking API, WhatsApp, Tally, GST
filing. Each integration carries its own documentation quality, its own sandbox, and its own habit of
behaving differently in production. Integrations are where estimates go wrong more often than
anywhere else, because the estimate is made from the API docs and the invoice is made from the API's
actual behaviour.
Offline behaviour. "It should work without internet" is one sentence in a brief and weeks of work
in a build. Local storage, conflict resolution when two people edited the same record, and a sync
queue that survives the app being killed mid-upload. Worth it for a field-force app. Expensive to add
to something that did not need it.
One platform or two. Android only, iOS only, or both. Cross-platform frameworks like Flutter and
React Native genuinely reduce this, which is why most projects here start there —
we have written about choosing between them.
But shared code is not shared work: design, testing and two separate store submissions do not
collapse into one.
Who designs it. An app built straight from a developer's understanding of a text brief costs less
and looks it. A wireframe and prototype stage
adds cost at the start and removes a category of expensive mid-build rework later, because arguments
about layout happen on a prototype instead of on working code.
What barely moves it
Some things people expect to be expensive are not.
The number of content screens — an About page, a T&C page, a static FAQ — is close to free once the
app exists. Changing colours and fonts is cheap. Adding a language is cheap if it was planned and
painful if it was not. Push notifications are usually a day, not a week, unless they need to be
personalised per user based on server-side rules.
And app store submission itself is not the cost people fear. Rejections are annoying, but the common
ones — missing privacy policy, an account you cannot delete from inside the app, a demo login that
does not work for the reviewer — are known and avoidable.
Rough bands, and why they should make you suspicious
Editor note — figures were deliberately left out of this section rather than shipped as
placeholders. If real ranges are ever approved from quoting history, add them as a sentence inside
each band below; do not reintroduce a table, the blog body has no table support.
Quotes cluster into three shapes, and the shape tells you more than the number attached to it.
- A single-purpose utility. One platform, no accounts, nothing of its own on a server — a
catalogue, a calculator, a form that reaches somebody. Small enough that design and the store
submission are a real fraction of the total rather than a rounding error. - A standard business app. Accounts and roles, a few integrations, an admin panel somebody in
your office actually uses, and a backend behind it. Most enquiries land here, and the range is
widest here, because "a few integrations" covers both a payment gateway with good documentation
and a twelve-year-old ERP with none. - A multi-role platform. Several kinds of user seeing different things, payments, offline
behaviour, reporting that decisions get made from. What costs money is not the screen count — it
is that most features have to be built, checked and supported once per role, and the combinations
grow faster than the feature list suggests.
Treat any range you find online as a starting point for a conversation, not a budget. Ranges are
built from a distribution of past projects, and yours is one project. The useful question is not "is
this the market rate" but "what did they assume to arrive at this".
Reading a quotation properly
Four questions get you most of the way.
What is excluded? This finds more money than any other question. Design, testing, project
management, deployment, the admin panel, and the first months of maintenance are all things a quote
can silently omit.
Who owns the code and the accounts? The repository, the Play Console and App Store accounts, the
server, the domain, the Firebase project. These should be yours, in your name, from day one. Getting
them transferred later is a negotiation you do not want to be in.
What happens when scope changes? It will. A quote with no change process is a quote that will
become a disagreement.
What does month thirteen look like? Android and iOS both ship a major version every year and both
periodically raise the minimum SDK you must target to stay in the store. An app nobody maintains stops
being installable. This is not a scare tactic, it is a calendar.
The cheapest real app you can build
If the budget is genuinely tight, the answer is not to find someone cheaper. It is to build less.
Pick the one workflow that has to work — the thing the app exists for. Build that properly, on one
platform, for the users who need it most. Ship it. Watch what people actually do with it, which will
not be what the brief predicted.
A small app that works well gets a second version funded. A large app that works badly usually does
not, and the money spent on the features nobody opened is gone either way.
What to do next
If you have a brief, the fastest way to a number you can trust is to have someone read it and tell
you which of the drivers above it triggers. That conversation is short and it is worth having before
you compare quotes, not after.
Tell us what you are building and we will tell you honestly which parts of it are
expensive and which are not — including the parts you could drop.
