The gap between a ₹2 lakh app and a ₹25 lakh app is rarely the number of screens. It is whether the app has a backend, whether it works offline, how many systems it talks to, and whether you are building one codebase or two.
Here is what those decisions cost, so you can work out which app you are actually asking for before anyone quotes.
What each band buys
| Type | Typical range | What it is |
|---|---|---|
| Simple app | ₹2,00,000 – ₹6,00,000 | Six to ten screens, content from an existing API or CMS, no accounts of its own. Catalogues, informational apps, event apps. |
| Business app | ₹6,00,000 – ₹20,00,000 | Accounts and roles, its own backend, push notifications, payments, an admin panel. Most commissioned apps live here. |
| Marketplace or platform | ₹15,00,000 – ₹40,00,000 | Two or more user types, matching or booking logic, payments in both directions, ratings, disputes. |
| Real-time or field app | ₹20,00,000 upward | Live tracking, chat, offline-first synchronisation, background location. The complexity is in state, not screens. |
The five decisions that set your number
1. One codebase or two
Native means separate Android and iOS builds — two codebases, two release cycles, roughly double the engineering. Cross-platform with React Native or Flutter means one codebase producing both, typically 30 to 40 per cent cheaper than two native apps and considerably easier to keep in step.
Cross-platform is the right default for business apps. Go native when the app leans on platform-specific capability — sustained background location, heavy camera or sensor use, deep OS integration — or when motion and responsiveness are the product rather than a detail.
2. Whether it needs a backend of its own
This is the decision people underestimate most. An app that reads from an existing system is a front end. An app that stores its own data needs a server, a database, authentication, an admin interface and somewhere to run — frequently 40 to 50 per cent of total project cost, and none of it visible in the app store screenshots.
If you already have a system, the honest question is whether it exposes a usable API. If it does, you have saved half the project. If it does not, that work belongs in the estimate.
3. Offline behaviour
"Works offline" is three different features at three very different prices:
- Read-only caching — the app shows what it last downloaded. Cheap, usually a few days' work.
- Queued writes — actions taken offline are stored and sent when the connection returns. Moderate, and needs careful handling of failures.
- Full offline-first with conflict resolution — two people edit the same record while both are offline and the system reconciles them. Genuinely hard, and it can add several lakh on its own.
Field apps in India frequently need the middle one, because agents work in places with patchy signal. Very few need the third. Decide which you are buying and say so in the brief.
4. Integrations
Each external system is separate work with its own testing burden. Payments, maps, SMS or WhatsApp messaging, analytics, accounting sync. Budget ₹40,000 to ₹1,50,000 each depending on how well documented the other side is — and note that integrating with your own legacy system is often harder than integrating with a commercial API, because the documentation is a person who has left.
5. Store submission and the long tail
Publishing is a real step: store accounts, listings, screenshots, privacy declarations, and the review cycle. Apple's review will reject things, sometimes twice, and each round is days. Budget for it rather than being surprised.
Then the ongoing part, which no build quote covers: Android and iOS both ship major versions annually, and an app left untouched for two years will start failing. Realistic maintenance runs 15 to 20 per cent of build cost per year, and it is not optional.
Get these five answers into any brief and quotes become comparable: which platforms, whether a backend is included, which of the three offline behaviours you need, the exact list of integrations, and who owns the store accounts and the code at the end.
Where app budgets are usually wasted
- Building an app where a website would do. If people use it once a month and it needs no camera, no location and no notifications, a fast mobile site reaches them without an install, usually for a fraction of the money. The install is the highest barrier in your funnel and you only get to ask once.
- Shipping both platforms at launch. Android first gets you to Indian users sooner and cheaper. Add iOS when the product has earned it — with cross-platform that is a release, not a rebuild.
- Specifying features nobody uses. The in-app chat, the social feed, the gamification. Ship the core job, instrument it, and let usage decide what comes second.
- Owning nothing at the end. If the developer holds the store accounts, the signing keys and the source, you have rented an app. Settle this in the contract, not after a disagreement.
A sensible sequence
- Write down the one job the app exists to do. If you cannot state it in a sentence, the scope is not ready.
- Check whether it needs to be an app at all. Camera, offline, notifications, location — if none apply, reconsider.
- Decide the backend question before asking for quotes, because it moves the number more than anything except platform count.
- Ship Android, cross-platform, with the core job only.
- Instrument it and read the data for a quarter before building version two.
Working out what your app should cost? Send us the brief and we will tell you which band it falls into, which of the five decisions is driving the number, and where the scope could be cut without damaging it. See how we approach mobile app development or start a conversation.
