Quotes for what sounds like the same app routinely differ by a factor of five. That is not because someone is overcharging — it is usually because the two quotes describe genuinely different pieces of software.
Why we will not put a number at the top
Any figure quoted before understanding scope is marketing. What we can do is explain what actually moves the cost, so you can read quotes critically and understand why they differ.
What drives the number
| Factor | Effect on cost | Why |
|---|---|---|
| Backend requirements | Usually the largest | An app talking to an existing API costs a fraction of one where the backend has to be built too |
| Authentication and accounts | Moderate | Signup, login, password reset, roles and account deletion are a real body of work, not a checkbox |
| Offline support | Large | Working without connectivity and reconciling afterwards is significant engineering |
| Payments | Moderate | Gateway integration, failure handling, refunds and reconciliation add scope wherever money is involved |
| Real-time features | Large | Live updates, chat and location tracking need infrastructure a simple app does not |
| Design | Moderate | Platform defaults are cheap; a distinctive custom design system is a separate workstream |
| One platform or two | Significant | Cross-platform is not half the cost of two native apps, but it is well below double a single one |
What a cheap quote is usually leaving out
- Testing beyond the happy path.
- Store submission, and the rejections that are a normal part of it.
- Error handling, empty states, and loading behaviour — much of what makes an app feel finished.
- Any backend work, assumed to already exist.
- Post-launch support, which is where the surprise arrives.
How to get comparable quotes
Give every vendor the same written scope, including the parts you consider obvious. Then ask each one directly what they have excluded. The useful signal is not the number — it is whether they can explain what drives it.
Be wary of anyone who quotes confidently without asking about your backend, your users, or what happens offline. They are either guessing or planning to raise it later.
How to spend less, honestly
- 1Cut scope, not quality. A smaller app built properly beats a large one built carelessly, and you can add to it.
- 2Launch on one platform first if your users are concentrated there.
- 3Ask whether you need an app at all — a progressive web app may serve the same purpose for considerably less.
- 4Use platform design conventions instead of a bespoke design language for version one.