What a mobile app actually costs

Six things account for most of the distance between a $20,000 app and an $80,000 one. Screen count barely registers next to any of them.

1 week

A modern documented API

1 month

A twenty-year-old ERP, same integration

Whether a backend already exists

The single biggest lever most people are holding without knowing it. A finished, documented API collapses the server-side work down to integration, roughly a third of what building one costs. A partial API is the far more common answer, and it saves much less than people expect, because the missing piece is usually the piece your app needs most.

How many distinct kinds of user there are

One kind of user is the baseline every project already pays for. The second one costs extra: its own screens, its own permission rules, its own test pass. Roles multiply design and QA faster than they multiply engineering, so a two-role app runs well short of twice a one-role app and well past 1.2 times it.

Whether it has to work without a network

Storing data on the device is the easy half. The other half is deciding what happens when two people edit the same record on different devices and one of them was underground for six hours. Then it has to be tested on bad networks, which is harder to arrange than testing on no network. Offline plus background synchronization is routinely the largest single line item in a field application.

What hardware it talks to

Bluetooth peripherals, scanners, printers, and card readers bring connection lifecycle management, pairing and permission flows, protocol work, and a test pass on real devices in the states they fail in. No simulator reproduces a scanner with a dying battery or a printer that answers and then stops.

Which systems it has to integrate with

Integration cost has almost nothing to do with your app and everything to do with the system on the other side. A modern documented API is a week. A twenty-year-old ERP with no test environment and one person left who understands it is a month, and the risk lands on your schedule rather than on the developer’s.

Whether it carries regulated data

HIPAA, SOC 2, and formal accessibility conformance change how the software is built, along with what gets documented at the end. Designed in from the start they add somewhere in the range of 10% to 20%, depending on the regime. Retrofitted afterward they are a rebuild, so the question belongs in the first conversation.

A build breaks into eight kinds of work. Two of them get forgotten in most quotes, and those two scale with everything else.

Discovery and design come first and produce no working software, which makes them the easiest things to cut and the most expensive things to have cut. Application development is the app itself: screens, navigation, state, device behavior, release builds. Backend and data covers the server, the data model, storage, authentication infrastructure, environments, and deployment. Integrations is everything that talks to a system you already run. And an admin application, if you need one, is a separate product with its own screens and its own testing.

10–13%

QA and release, as a share of everything there is to test

7–10%

Project management, as a share of the whole

Then there are the two that are shares rather than sums. QA and release runs at 10–13% of everything there is to test, because more built means more to test. Project management runs at 7–10% of the whole; a longer project needs more coordination, whatever anybody thinks of meetings. An estimate that omits both is roughly 20% short before it starts, and it will find that 20% later, from you.

When two quotes for the same brief differ by a factor of three, the cheap one is usually a smaller scope described in identical words. Four omissions account for most of the gap.

$9K – $15K

What the admin application costs when somebody actually builds it

The admin side

Almost every business app has an office-facing companion for managing users, reviewing data, and controlling what the app displays. It gets described in one sentence and built as a second application, with its own screens, its own permission model, and its own test pass. It is the most underestimated item in this category, and usually the whole difference between two quotes.

App store review

Submission starts a queue you do not control. Reviews get rejected over metadata, privacy disclosures, a missing account deletion path, or a permission prompt that does not explain itself. Every round trip is calendar time, and staffing does nothing to it.

Testing on real devices

Simulators do not reproduce low memory, a bad network, a denied permission, or a three-year-old handset that has never been updated. Real-device QA is where you find the defects your customers would otherwise have found for you. It is also the first thing cut from a number that has to look competitive.

The year after launch

Apple and Google ship operating systems every year whether or not your budget does. An app nobody touches for eighteen months is drifting, and the bill arrives all at once when something finally breaks.

The reliable ways to cut a mobile budget are structural. They change what has to be built.

30%

Of the backend work survives if you already have a documented API

35%

Of the design work survives if the screens are already drawn

If you already have an API, say so early and in detail. A documented, working backend takes the server-side work down to roughly a third. Finished designs do the same to the design workstream. And if you are describing four types of user, ask whether the first release needs more than two; the rest can be added once you know how the first two behave.

Then there is the list of things that are easier to add after launch than before it: push notifications, subscriptions, in-app chat, AI features, video, and additional languages. None of them prove the product works, and several are better designed once you have real usage data to design against. Deferring them ships the part that answers the question first.

Budget the year after launch separately, and settle that budget before you commit to the build. A live application accumulates obligations: annual OS releases on both platforms, dependency and SDK updates, store policy changes that arrive with a deadline attached, bugs that only appear at real volume, and the small changes real usage always suggests.

15–20%

Of build cost per year — an industry convention, not a calculator output

A common planning figure is 15–20% of the build cost per year for an app in active use, less if it is stable and nobody is asking for anything. That is a convention rather than an output of this calculator; the estimate here covers building the thing rather than running it. Put a number in the slot anyway. A plan with nothing there gets surprised around month eight.