What mobile app development actually costs in India

Ask five agencies what mobile app development costs in India and you will get five numbers that do not resemble each other. Buyers usually read that as a market problem. It is closer to a language problem.

App is not one product. It describes a booking screen wrapped around an existing website, and it describes a payments platform with its own backend, offline behaviour and compliance load. Those are different engineering projects that happen to share an icon on a phone.

This piece sets out what actually sits on an app invoice, which decisions move the number most, and which costs arrive after launch rather than before it. There are no figures here, and that is deliberate. A number without a scope attached is worth nothing to you, and any agency that leads with one before understanding your brief is guessing.

What follows is how we scope this work, written so you can hold any quote up against it — including ours.

Three different things called an app

Almost every disagreement about app cost dissolves once you name which of these three you are buying.

A wrapper. Your existing web experience, presented inside an app shell, with push notifications and a home-screen icon. It is the cheapest route by a wide margin and it is the right answer more often than agencies admit. If your users mainly browse and buy, and you already have a fast mobile site, this may be all you need.

A native product. Screens built for the phone, with the device doing real work: camera, location, offline storage, background sync. This is a genuine software build with its own release cycle.

A platform. An app plus the system behind it — accounts, roles, payments, an admin panel, reporting, and integrations with whatever you already run. The app is the visible tenth of it.

Most briefs describe a wrapper and quietly expect a platform. The gap between those two expectations is where the surprise lives.

What is actually on the invoice

An honest app quote has six lines, and only one of them is writing app code.

Discovery and scope. Turning a brief into screens, states and rules. Skipping it does not save money; it moves the cost into rework later.

Design. Flows, screens and a component library the developers build from. Covered properly further down.

Build. The app itself, and usually a backend.

Testing. Real devices, not just a simulator. Android in particular needs a spread of screen sizes, OS versions and manufacturers.

Release. Store accounts, listings, review submissions, and the fixes that come back from review.

Project management. Someone keeping the sequence honest and telling you when a decision is late.

If a quote shows one line for the whole thing, the other five have not been removed. They have been absorbed into an estimate somebody will have to defend later, usually by cutting testing.

One codebase or two

The single biggest lever on an app budget is whether one codebase serves both platforms.

Cross-platform frameworks let one team write once and ship to Android and iOS. For most commerce, booking, content and internal-tool apps, this is the sensible default. You are not sacrificing much, and the saving is real: one build, one test cycle for shared logic, one set of fixes.

Where it stops being the obvious answer. Heavy camera or sensor work. Real-time audio or video. Complex background processing. Anything where the app has to feel indistinguishable from the operating system. In those cases the workarounds cost more than writing native code twice.

The honest test is not technical, it is behavioural. If your users will spend hours a week inside the app and judge it against the best apps on their phone, native earns its cost. If they will open it to check something and leave, it does not.

Android and iOS are not the same bill

Even with one codebase, the two platforms do not cost the same to finish.

Android costs more to test. The device landscape in India is wide: many manufacturers, many screen sizes, many OS versions still in daily use, and aggressive battery management that silently kills background work. A build that behaves on a recent flagship can fail on a three-year-old midrange handset that a large share of your users actually carry.

iOS costs more to release. Review is stricter and slower, and rejections arrive for reasons that are hard to predict from the guidelines alone. Budget for at least one round of review feedback on a first submission.

If you are launching on one platform first, pick it from your own analytics rather than from habit. For most Indian consumer audiences that means Android first. For products sold to businesses, or to a higher income band, iOS often carries more of the revenue.

The features that move the number most

Feature lists are misleading, because a few items carry most of the weight while the rest are close to free.

Payments. Not the integration, which is well trodden, but everything around it: failed states, retries, refunds, reconciliation, and the testing each of those needs.

Offline behaviour. The most underestimated item on any brief. Working offline means deciding what happens when two devices change the same record, and that is a design problem before it is a coding one.

Real-time anything. Chat, live tracking, collaborative editing. Each brings its own infrastructure and its own failure modes.

Roles and permissions. One user type is simple. Four user types with different views of the same data multiplies the testing.

Everything else — onboarding, listings, search, profiles, notifications — is ordinary work. When a quote jumps, it is almost always one of the four above that did it.

The backend nobody quotes for

Ask what happens on the server and you will learn more about a quote than any feature list will tell you.

Unless your app is purely a reader of public content, it needs somewhere for accounts to live, somewhere for data to sync, and an admin view for your own team. That is a second product. It has its own design, its own security work and its own hosting.

The cheapest quotes usually assume you already have one. Sometimes that is fair — if you run a Shopify store or an existing platform with a usable API, much of it exists. Often it is not, and the omission surfaces halfway through the build as a change request.

Two questions settle it. Where does user data live, and who builds the screen your team uses to manage it. If a quote cannot answer both, it is not a complete quote yet.

Design, and when it pays for itself

Design is the line buyers cut first and regret most, though not for the reason they expect.

The value is not that the app looks better. It is that a designed app has already answered questions the developers would otherwise answer for themselves, one at a time, inconsistently, at the point of writing each screen. Empty states, error states, loading behaviour, what happens on a slow connection — those decisions get made either way. Making them in design is far cheaper than making them in code.

A component library is the part that compounds. Build one and the second wave of screens costs a fraction of the first. Skip it and every screen is drawn from scratch, including the twenty you add next year.

Where design can safely be trimmed: exploration rounds, and polish on screens users see once. Where it cannot: the flows people repeat daily.

What the app stores add

Two stores, two sets of rules, and a recurring obligation most first-time buyers do not plan for.

Accounts and listings. Developer accounts in your own company name, not the agency’s. Screenshots for several device sizes, a privacy policy that matches what the app actually collects, and store copy that is itself a small piece of marketing work.

Review. Expect feedback on a first submission. Common causes are account deletion requirements, unclear permissions, and payment rules where digital goods are involved.

The recurring part. Both platforms ship a major OS release every year, and both periodically raise the minimum build requirements. An app nobody touches for two years will eventually stop being installable. That is not a defect, it is the cost of being on a phone.

Ask any agency to confirm the accounts will be registered to you. It is the single clause that decides whether you can change supplier later.

The costs that start at launch

Launch is the point where the spending changes shape, not the point where it stops.

Keeping it running. Hosting, monitoring, crash reporting, and the certificates and keys that expire on their own schedule.

Keeping it installable. OS updates, deprecated libraries, and payment or login providers changing their requirements. This work is unglamorous, unavoidable, and cheap when done continuously.

Keeping it useful. The first version teaches you which assumptions were wrong. Acting on that is the whole point of shipping, and it needs budget you have not already spent.

A reasonable planning assumption is that the first year after launch carries meaningful ongoing work, and that the second version is not a rewrite but a continuation. Teams that treat launch as the finish line usually pay for a rebuild inside three years.

Where geography changes the price

Indian development rates are genuinely lower than in the UK, the US or Western Europe, and that gap is real rather than a marketing claim. It is also the least useful thing to compare on.

Within India the spread between a competent senior team and a cheap one is wider than the spread between countries. The variable that matters is who actually writes your code and how much of their attention you get, not the postcode on the invoice.

What geography does not change. Store review timelines, OS release cycles, payment provider requirements, and the number of devices Android needs testing on. Those are fixed costs wherever the team sits.

If you are comparing an Indian quote with an overseas one, compare the seniority of the people named on it and the hours they are committing. That comparison is meaningful. Day rate on its own is not.

How to brief so quotes are comparable

Most quote variation is caused by the brief, not the agencies. Four additions remove nearly all of it.

Say which of the three apps you want. Wrapper, native product, or platform. If you are unsure, say that too, and ask each agency to quote the smallest version that would prove the idea.

List the integrations by name. Payment provider, logistics, CRM, whatever runs your business today. Integrations are where estimates diverge most.

State what exists. An API, a design system, a backend, brand assets. Every one of those removes a line from the quote.

Name the first success measure. Not the vision — the one thing the first release must do. It lets a good agency tell you what to leave out, which is the most valuable thing they can do at this stage.

Five questions that separate a good quote from a cheap one

What is not included? The most revealing question you can ask. A confident team answers it immediately and in detail.

Who writes the code, and what else are they on? Named people and their availability. A quote from a senior team and a quote fronted by one is the same document until you ask.

What happens when scope changes? It will. You want the process described before you need it, not invented under pressure.

How is it tested, and on what? Ask for the device list. If the answer is a simulator, the testing line has been cut.

What do we own, and how do we leave? Repository access, store accounts, backend credentials, design files. The answer should be uncomplicated. If it is not, that is the answer.

What we would cut, in order

If a build has to fit a smaller scope, this is the order we would reduce it — and it is close to the reverse of what most teams cut first.

Cut the second platform. Launch on the one your users are actually on, learn, then add the other. Nothing else saves as much for as little damage.

Cut user types. Ship for the primary user. Additional roles can wait for a version that has real usage behind it.

Cut offline. Unless the app is used somewhere with genuinely poor connectivity, this can follow later.

Cut the admin panel, carefully. A spreadsheet and a developer can cover the first months of a small user base. This is a deliberate debt, not a saving, and it should be written down as such.

Do not cut testing, and do not cut discovery. Both reappear later at a multiple of what they would have cost.

What it comes down to

The cost of an app in India is decided by four things, in this order: which of the three apps you are actually building, whether one codebase can serve both platforms, how many systems it has to talk to, and whether a backend already exists.

Everything else — screen count, feature lists, the length of the proposal — is noise by comparison. An agency that starts with those four questions is scoping. One that starts with a number is guessing, and you will pay for the guess either way.

If you want a second opinion on a brief or a quote you have already received, we will read it and tell you what we would ask. There is no obligation attached to that, and we will say plainly if the quote in front of you is a fair one.