App development
How much does it cost to make an app? The real drivers
How much does it cost to make an app: an honest breakdown of the scope, platform, backend, billing and maintenance drivers that move a mobile app development quote.
Short answer
There is no single price. App cost is driven by scope, platform count, backend complexity, third-party integrations, compliance work and design fidelity. The number most estimates miss is maintenance: 20.2% of the 6,634 apps Bright App Data audited went 180 days without an update, which is what an unfunded maintenance line looks like from the outside.
Why nobody can price an app from a one-paragraph brief
Two apps described identically — "a booking app with payments" — can differ by an order of magnitude in build cost, and the difference is never in the screens. It is in whether payments means one card charge or a subscription with trials, proration and refunds; whether booking means a form or a live availability engine; whether the app talks to one API or to a legacy scheduling system with no documentation.
Commonly quoted market ranges vary enormously by region, agency size and contract model, and any single figure you see quoted for "an app" is describing a specific project, not yours. What transfers between projects is the list of drivers below. Price the drivers, and the estimate stops being a guess.
The seven drivers that move a mobile app development cost
Every estimate I have seen go wrong went wrong on one of these seven. The right-hand column is what pushes a project from the cheap end of a driver to the expensive end.
| Cost driver | Cheap end | Expensive end |
|---|---|---|
| Scope | One core job, done well | Multiple user roles, admin panel, internal tooling |
| Platform count | One platform, or a shared codebase | Two native codebases plus tablet and large-screen layouts |
| Backend | Managed backend, standard auth, no custom logic | Custom services, real-time sync, migrations from an existing system |
| Integrations | One or two documented APIs | Legacy or undocumented systems, hardware, third-party schedulers |
| Billing | One-off purchase or no monetisation | Subscriptions with trials, tiers, proration and refunds |
| Compliance | Standard privacy policy and store data disclosure | Health data, finance, children's category, regional data residency |
| Design fidelity | Platform-default components | Bespoke motion, illustration, custom design system |
Platform count is not a clean 2x, and it is not free either
A cross-platform build shares most application code but not the parts that break: push notifications, in-app purchase, permissions, background behaviour, and anything touching the camera or location. Those are per-platform work in every stack, which is why a second platform tends to add meaningfully less than a full second build but far more than the "write once" pitch implies.
The larger effect is on the maintenance line, not the build. Two platforms means two annual OS releases, two sets of store policy changes, and two review queues to answer. If you cannot fund that, ship one platform.
Billing is the most expensive feature per screen you will build
A paywall is one screen and several weeks. The screen is trivial; the plumbing behind it is not. Server-side receipt validation, restore purchases, entitlement state that survives a reinstall, upgrade and downgrade proration, and correct handling of Google Play's billing retry and grace periods are each individually small and collectively the reason billing estimates slip.
The audit data backs the priority: payment complaints appear on 1,900 of 6,634 audited apps (28.6%) — the most common complaint cluster of any kind — subscription complaints on 1,448 (21.8%), and refund complaints on 433 (6.5%). If your app charges money, this line item deserves its own estimate rather than being folded into "payments integration".
The backend is where estimates quietly double
Client work is visible and therefore gets estimated carefully. Backend work is invisible and gets estimated with a shrug. The specific things that expand: any requirement for offline-first sync, any migration from an existing database with real user data, anything needing a background job scheduler, and any admin surface that a non-technical person is expected to operate.
A useful test before you request quotes: write down every piece of data the app reads or writes and mark which system owns it. If more than two systems appear, the backend is the largest line in the estimate, whatever the design deck implies.
Maintenance is the cost people forget, and the data shows it
Of the 6,634 apps we audited, 1,341 (20.2%) have not been updated in 180 days, 622 (9.4%) in a year, and 302 (4.6%) in two years. Those are not finished apps. Both stores raise their minimum target API and SDK requirements on a rolling annual schedule, and both ship a major OS release annually, so a codebase that nobody touches for two years is a codebase that will need paid remediation before it can be updated at all.
The other half of the maintenance line is human. 3,143 audited apps (47.4%) have never replied to a single review, and the average reply rate is 28.0%. Review response, crash triage, and dependency upgrades are recurring work with a recurring cost, and leaving them out of the first budget is the single most common reason an app that launched well is unusable eighteen months later.
What the listing costs, which is almost nothing
One line in the estimate is cheap enough to be worth naming: the store listing. 84.1% of audited apps have no preview video, the average app uses 13.1 screenshots, and titles average 21.5 of the 30 available characters. The average ASO score is 77.6 out of 100, with 22.7% at grade C, 3.8% at D and 0.2% at F.
That work costs hours, not sprints, and it changes install rate without touching the build. If your budget is tight, this is the item with the best ratio in the whole project. A free public check is at /app-audit and the scoring signals are documented at /methodology.
How to get an estimate that means something
Hand any agency these six things and the range you get back will narrow sharply. Without them, you are being quoted a placeholder.
- The one job the app must do at launch, in a single sentence
- Platform decision, and whether tablet or large-screen layouts are in scope
- Every external system the app must read from or write to, named
- The monetisation model, including trials and tiers if any
- Any regulated data involved — health, financial, children's category
- The monthly maintenance budget you can commit to after launch
Where these figures come from
Every catalog figure above uses the method set out under "How this data was collected" in /blog/mobile-app-development-tips, and in full at /methodology. Sample: 6,634 apps audited, 6,144 with stored reviews — a snapshot taken on 3 August 2026, and the catalog grows continuously, so live totals are higher. No pricing figure in this article is derived from that dataset; cost drivers are described qualitatively on purpose. Reports are published at /app-reports, and scoped estimates come from /services.
Clear answers
Frequently asked questions
How much does it cost to build an app?
Commonly quoted ranges vary widely by region, agency and contract model, so a single number is not useful. The honest answer is that cost tracks seven drivers: scope, platform count, backend complexity, integrations, billing, compliance and design fidelity. Specify those and any competent shop can quote a real range.
What is the most underestimated app development cost?
Maintenance. 20.2% of the 6,634 apps we audited have gone 180 days without an update and 4.6% have gone two years. Both stores raise their target API requirements on a rolling schedule, so an untouched codebase accrues remediation work that has to be paid for before any new feature ships.
Is cross-platform development cheaper than native?
For the build, usually yes, because most application code is shared. The savings shrink around push notifications, in-app purchase, permissions and hardware access, which stay per-platform. The maintenance line does not shrink at all: two platforms still means two OS releases and two review queues each year.
Why do subscription features cost so much to build?
Because the paywall screen is the smallest part. Receipt validation, restore purchases, entitlement that survives reinstall, proration, and billing retry and grace-period handling are all separate work. Payment complaints appear on 28.6% of audited apps and subscription complaints on 21.8%, which is what skipping that work looks like afterwards.
What should I budget for maintenance each month?
Set it as a standing line rather than a percentage guess, and size it to cover dependency and SDK upgrades, annual OS releases, crash triage, and review response. If no number can be committed, reduce launch scope until one can — an app with no maintenance budget has a shelf life.
Can I lower cost without cutting features?
Sometimes, by cutting a platform rather than features, using platform-default UI components instead of a bespoke design system, and deferring the admin panel to a spreadsheet plus a simple API. The store listing work should never be the thing you cut; it costs hours and affects installs directly.