What drives the cost of an app
Why mobile app quotes vary so widely, the seven factors behind the number, and the two that get underestimated.
The short answer
App quotes vary widely because “an app” can be anything from a wrapped website to two native applications with a back end serving thousands of users offline. Seven factors set the number: which platforms and how they are built, what type of app it is, the back end behind it, offline and device features, design and accessibility, store publication, and the year after launch. Two are underestimated in almost every business case. The back end, the API, database, authentication and integrations, is most of the work in any app that does more than display information. And the ongoing cost: store requirements, operating system updates that break things annually, hosting, monitoring and support. There are no amounts here, because the factors are what you control, and the question that sizes the project is what the app must do that a well-built mobile website cannot.
The seven factors
| Factor | What raises cost | What lowers it |
|---|---|---|
| 1. Platforms and approach | Two native codebases | One hybrid codebase, or a progressive web app with no stores |
| 2. Type of app | Transactions, accounts, real-time features, complex workflows | Content and simple forms |
| 3. Back end | API, database, authentication, integrations, background jobs, admin | Reusing existing systems through their APIs; a managed backend |
| 4. Offline and device features | Full offline operation, sync, camera, sensors, background processing | Read-only offline; standard capabilities |
| 5. Design and accessibility | Custom interactions, animation, platform-specific patterns | A design system; standard components; accessibility built in |
| 6. Store publication | Review cycles, compliance, privacy declarations, per-platform assets | Progressive web app; or a clean first submission |
| 7. The year after | Operating system updates, store policy changes, security, support, feature changes | Mainstream stack; a maintenance contract; small releases |
The two underestimates
- The back end. An app that shows bookings needs a system that holds bookings, authenticates users, syncs with the office and notifies people. That system often costs more than the screens, and it is what the app is worth without.
- The year after. Both major operating systems ship annual releases that change behaviour and requirements; stores tighten policies; devices change. An app not updated for a year risks removal or breakage. Maintenance is a monthly line, not a contingency.
Sizing the project honestly
Ask what the app must do that a mobile website cannot: work offline, use the camera or sensors in a specific way, send notifications on every device, sit on the home screen for a field team. If the honest answer is none of those, a fast mobile website or a progressive web app delivers the outcome at a fraction of the cost, with no stores and one codebase. If the answer is specific, that answer chooses the approach and sizes the back end, and the quote should show both.
What this means for you
An app’s cost is set by platforms, type, back end, offline and device needs, design, stores and the year after, with the back end and the ongoing line most often underestimated. Decide first what the app must do that a mobile website cannot; that answer picks native, hybrid or progressive web app and sizes the back end. Then read quotes for the back end and the maintenance line, because those are where the number is really decided.
Frequently asked questions
Why is an app so much more expensive than a website?
Because an app is usually several things: one or two native front ends, a back end with an API and a database, authentication, notifications, store publication and a maintenance obligation that operating systems enforce with every annual release. A website is one thing. The question that sizes an app project is what it must do that a mobile website cannot, because that answer decides how many of those parts are needed.
Do we need native apps for both platforms?
Only if the app needs device capabilities or performance that the alternatives cannot provide. Hybrid frameworks build both platforms from one codebase; progressive web apps avoid the stores entirely and cover offline, notifications on most devices, camera and location. Two native codebases double the front-end cost and the maintenance forever; choose them for a reason.
What ongoing costs should we expect?
Store developer accounts, updates required by operating system releases, back end hosting and monitoring, security updates, support, and changes as the business moves. An app that is not updated stops being accepted by the stores or breaks on new devices within a year or two. Budget a monthly line from the start; it is not optional.