There is no honest national price for a mobile app in India in 2026. A shop that publishes one figure is averaging together projects that do not resemble each other. Selvi Infotech quotes after a written scope. This note is about what that scope has to contain, so you can compare two proposals without pretending they are the same job.
What you are actually buying
A phone screen is the visible part. The invoice also covers the decisions before it, the server behind it, the testing, and the store release.
A typical first release includes:
- A conversation that names the user, the first tasks, and what is explicitly out of scope.
- Interface work for those tasks, on a small phone and a larger one.
- The application itself, in Flutter, React Native, or native Android and iOS.
- Accounts, data, and often an admin view that is not on the phone at all.
- A pass through the paths that fail: a rejected login, a lost network, an empty list.
- Signing, listing text, and the review cycle on Google Play and the Apple App Store.
If a quote is far shorter than the others you have, check which of those lines it left out. Leaving out the admin side or the store release does not make the app cheaper. It moves the cost to the week after launch.
The decisions that change the size
One codebase or two. Flutter and React Native let one team ship Android and iOS together. Native Android and native iOS are two products that share a design. Both are legitimate. The shared toolkits are the wrong default only when the app depends on a platform behaviour they handle badly. We say which we would use, and why, before the build. The mobile app development page describes that choice.
How many roles. An app with one kind of user is smaller than an app with customers, staff, and an owner who needs reports. Each role is screens, permissions, and test cases.
Payments, offline use, and integrations. Taking money, working without a network, and talking to a system you already run are each their own piece of work. They are not a checkbox on a rate card.
Who already owns the backend. If you have an API, we integrate with it. If you do not, the server is part of the project. We build that side with Node.js, ASP.NET Core, Python, Java Spring Boot, or SQL Server, the same list we use for software development.
Who writes the listing. Store accounts should stay in your name. Preparing the build and sitting through review is still time, and it belongs in the quote.
Apple and Google charge their own developer-account fees. Those numbers change, and they are not our fee. Confirm the current figure on each store's own site before you budget.
What a usable quote looks like
Ask any vendor, including us, for a document that lists:
- The platforms in the first release.
- The screens or tasks that are in, and a short list of what is out.
- Whether a server and an admin view are included.
- How many review cycles you get before a change becomes new work.
- What happens in the first weeks after the store says yes.
A calendar without that list is a guess. A rupee figure without that list is also a guess. We would rather send the list late than send a number early.
After the first release
The first version is not the last invoice. Crashes show up on devices you do not own. A store policy changes. A dependency needs an update before the app will build again next year. Plan for a maintenance conversation when you plan the build. That is separate from a new feature, and it should be written that way.
If you are pricing training for your own developers instead of commissioning the app, the mobile course is a three-month program in React Native and Flutter. It is not a substitute for a client build, and a client build is not a substitute for the course.
How we start
Send who the app is for, whether you need Android, iOS, or both, and a rough list of tasks. WhatsApp or call +91 9500316716, or write through the contact page. We reply with questions. The quote comes after the scope, not before it.