Mobile appsData
What a business app costs: what drives the price
- Published
- Read
- 5
- Topics
- costs · mobile-apps · mvp
What drives the price of a business app: scope, backend, publishing and maintenance, and what is worth leaving for the second version.
Every app conversation starts with the same question: how much does it cost? The honest answer is not a range. It is the set of decisions you are buying. Two apps with the same home screen can differ enormously because of what happens behind it.
An app is not quoted by screens. It is quoted by decisions: what data it stores, who administers it and what happens when something fails.
Why there is no list price
The cost of an app is split into four blocks. The first is scope: what the app does and, above all, who uses it. A tool for your team does not cost the same as an app for your customers. The first usually has less design and more permissions; the second has more states, more support and more edge cases.
The second is the backend (the system that stores the data and answers the app): where it lives, who reads it and how it stays in sync. The third is publishing: accounts, store review and minimum system versions. The fourth is maintenance: updates, support and the changes the business will ask for after launch.
The decisions that move the price
Before talking about numbers, you have to choose how the app is built. This is not a technical debate: it changes the initial cost, the time to a first version and what you can do later. The three options are native, cross-platform and a PWA, which is a website installed on the phone that behaves like an app.
| Criterion | Native | Cross-platform | PWA |
|---|---|---|---|
| Initial cost | High | Medium | Low |
| Publishing | Two stores | Two stores | Web, no store |
| Camera, GPS and Bluetooth | Full | Almost full | Limited |
| Updates | Store review | Store review | Immediate |
| When it fits | Specific sensors or heavy use | Two platforms and one team | Validating or internal use |
Cross-platform is not free: it saves a team, not the work. And a PWA is not a disguised app: it is a product decision. If the business needs reliable notifications, camera or Bluetooth, it is better to know before choosing.
The fixed costs you can actually verify
Two payments do not depend on the vendor or the scope. The Apple Developer Program membership costs USD 99 a year. Google Play charges a one-time USD 25 developer account fee.
Those are the only figures I can give you without knowing your scope. Everything else —backend, screens, integrations, testing— depends on what the app has to solve.
Store review also takes time: an app can be rejected over privacy, payments or a poorly explained feature. That does not add a fee, but it does add weeks.
The backend is half the app
An app is a screen that talks to a system. If that system does not exist, it has to be built: authentication, database, files, notifications, payments and a panel so someone can administer everything without asking a programmer for help.
If the business already runs a sales or inventory system, the question changes: does the app connect to what exists, or does it need a new backend? Connecting is usually cheaper, but it depends on the current system exposing an interface. When it does not, the cost still shows up, only later.
What to leave for the second version
Making the first version cheaper is not about cutting features at random. It is about leaving out what does not change the core loop: order, pay, receive and order again. Everything else can wait if the business can handle it by hand in the meantime.
- Dark mode, extra languages and animations do not change the core loop.
- A loyalty program, in-app chat and advanced analytics can run outside the app at first.
- Offline mode only makes sense if the work happens where there is no signal.
- A tablet version can wait for real demand.
What should not wait: sign-in, permissions, payments, notifications and the admin panel. If one of those is missing, the app cannot operate.
What to ask for in an app quote
A comparable quote is not the one with the lowest total: it is the one that lets you understand what you are buying. Ask for these six points in writing.
Scope with names
Which flows are included and which are not. “An ordering app” is not a scope; “catalog, cart, payment and history” is.
Platforms and versions
iOS, Android or both, and from which system version. That defines testing and devices.
Backend and ownership
Where the data lives, who administers the system and who owns the accounts.
Publishing and review
Who uploads the app, who answers if the store rejects it and how much time is reserved for that review.
Maintenance
What is included after launch: system updates, fixes and support. And what is not.
Acceptance criteria
How each flow is proven to work, with real data and on a real device.
Frequently asked questions
Is a web app cheaper than a native app?
Almost always, when the use case does not depend on phone hardware. A PWA skips the stores and their reviews, but loses distribution and part of the hardware access.
Can I start with an Android-only app?
Yes. For an internal tool, Android is often enough; for customers, the decision depends on where they are, not on a market share number.
Does the app stop costing money once it is published?
No. Developer accounts, operating system updates, the backend and support remain. It is a living product, not a file.