Mobile app cost
What a mobile app actually costs
The quotes vary wildly because the word app covers everything from a single-platform pilot to a product with offline sync, payments and a support rota behind it.
Get a scoped estimateWhy two quotes for the same app differ so much
The word app hides most of the work. One quote is costing a set of screens against an API someone else already built. The next is costing that API, the accounts, the payment flow, the admin panel and the store submission as well, and both are answering the question honestly.
The question that moves the number most is not which platform, or how many screens. It is whether the app has to keep working with no signal. Reading from a live API is routine work; letting people edit offline and reconciling those edits on reconnect is a different product with a different budget.
Cost drivers
What actually moves the number
Each of these is a decision you control, and each one settled early is cheaper than the same decision made in month three.
One platform or two
Shipping iOS and Android together roughly doubles testing and store work, even on a shared React Native codebase. One store first is the honest cut.
Offline mode and sync
A local-first data layer with conflict resolution on reconnect, built in Room or Core Data, is weeks of work and close to impossible to retrofit.
Integrations with your systems
Every system the app writes back to, such as your ERP or a warehouse tool, needs its own API contract, error handling and test environment.
Payments and subscriptions
StoreKit and Play Billing take a platform cut and impose their own review rules. A card gateway such as Stripe or Razorpay is separate work again.
Accounts, roles and permissions
One user account is quick. Organisations, invited team-mates and an admin who can act on someone else's behalf is a backend project in itself.
Regulated or health data
Medical records or KYC documents bring encryption at rest, audit logging and a data-processing review that adds weeks before a line of app code changes.
Design and prototyping
A clickable prototype on a real handset before build usually shortens the feature list, which is the cheapest saving available anywhere on the project.
Store review and release
Signing, listings, screenshots and a phased rollout are days of work per release, and Apple can reject a build for reasons unrelated to your code.
Migrating existing users
Moving current users, their history and their files into the new app is a project of its own, and it is almost never in the first quote.
Scope tiers
Four honest scope tiers
Every project is scoped and quoted to your budget, so what follows is scope and timeline — not a price list. Find the row you recognise, then read the line about what it leaves out.
- TIER 1 — PILOT
- One platform, one core journey. Ships in 4–6 weeks
- ₹2L – ₹3L$2.3k – $3.4k
- A single-platform app doing one thing properly: sign in, the main flow, and a small backend behind it. Right for testing whether anyone opens it twice. Does NOT include offline mode, payments, an admin panel or a second store.
- TIER 2 — LAUNCH BUILD
- Both stores, accounts and payments. Ships in 3–4 months
- ₹10L – ₹14L$11k – $16k
- Both platforms from one codebase, user accounts, push notifications, payments through store billing or a gateway, an admin panel, and submission handled end to end. Right for a first real product. Does NOT include offline editing or deep integration with internal systems.
- TIER 3 — CONNECTED PRODUCT
- Offline sync and system integrations. Ships in 5–8 months
- ₹24L – ₹40L$27k – $45k
- Everything in the launch build plus a local-first data layer, conflict resolution on reconnect, and integrations into the systems you already run. Right for field, logistics and retail teams. Does NOT include regulated-data work or a bespoke design system.
- TIER 4 — REGULATED PLATFORM
- Multi-org access and audit trails. Ships in 9–14 months
- From ₹60LFrom $68k
- Role-based access across organisations, audit logging, encryption review, and the documentation a security assessment asks for. Right for health, finance and identity products. Does NOT include the legal or certification work itself, which your counsel and auditor own.
Indicative ranges for scoping conversations, not quotes. They reflect what work of this shape has cost us to deliver — your figure comes out of a paid discovery, against a written scope, and is fixed before any code is written. Gas, licences, cloud and third-party audit fees sit outside these numbers.
How we scope it
How a mobile budget gets settled
The number firms up as the unknowns close. We would rather narrow the scope in week two than find out the budget was short in month four.
Discovery and platform decision
1–2 weeksWe settle native or cross-platform, one store or both, and whether offline is in scope. Those three answers set most of what follows.
Prototype on a real handset
2–4 weeksScreens you can tap on your own phone. This is where features get cut, and where we say plainly if the budget will not cover the list.
Scope doc and the honest cut
1 weekA written scope with the exclusions named. Some projects shrink to a pilot here and a few stop, which is far cheaper than stopping in month five.
Build, submit and maintain
Ongoing after launchIncrements to TestFlight and the Play internal track, then submission and a phased rollout, then upkeep for the OS releases Apple and Google ship yearly.
Should you budget for this now?
Worth reading before you take a number back to whoever asked you for one.
Worth budgeting for now if…
- People already do this work on their phones, badly, in WhatsApp
- The app needs the camera, location or push, not just a browser
- You have a user who would open it weekly, not once
- Someone internally owns the app after launch and has time for it
Wait, if…
- A responsive web app would do the same job this year
- Requirements are still changing weekly and nobody is deciding
- There is no budget left for maintenance after the launch push
- You want an app because a competitor has one, not because users asked
Frequently Asked
Questions
Common questions about scoping a mobile app, cutting scope, and keeping it running after launch.
Five things, in roughly this order: building for both stores instead of one, offline editing with sync, integrations into systems you already run, payments, and anything holding regulated data. A camera feature that reads a document, for example, brings image handling, on-device or hosted OCR, and a sensible fallback for when it misreads. Screen count matters far less than people expect. Two apps with the same number of screens can differ by months once one of them has to work with no signal.
The second platform, first. Shipping to whichever store your users actually carry removes a large share of testing and submission work, and it can be reversed later from the same codebase. After that: offline mode, the admin panel, and in-app purchases where a payment link in a browser would hold for now. Cutting screens saves less than cutting capabilities, because the cost sits in what the app has to guarantee rather than in how much of it you can see.
Store submission and the review queue, which is days of work per release and occasionally a rejection for something unrelated to your code. Then migrating existing users, their history and their files into the new app, which is a project on its own. Also push certificates, screenshots for every device size, crash monitoring, and design for the empty states nobody specs. And the fortnight after launch, when you find out what actually broke on real handsets.
Three buckets. Hosting and third-party services for the backend, push and analytics, which scale with active users rather than downloads. Store developer accounts, renewed yearly on each platform. And maintenance, which is the one teams skip. Apple and Google ship an OS release every year that breaks something, and an app left untouched long enough is eventually pulled from the store. Plan for a retainer sized to how much the app does; ours stay flexible with no lock-in.
Almost always, yes. Ship one platform with one core journey, watch whether people come back a second week, then spend the rest of the budget on what they actually used. The alternative is paying to build a feature list assembled before anyone held the app, and most of those lists are wrong in places. Phasing also protects you from the worst outcome, which is a full build launching to nobody. Our MVP Development for Startups track exists for this.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.