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. What a backend is.

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. What a user role is.

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 offline mode is.

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

Decided by the other system. A modern cloud product with a documented way in is quick. An old system with nowhere safe to test is a project of its own, and your app is the same either way. What an integration is.

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’re 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. It’s the most underestimated item in this category, and usually the whole difference between two quotes. What an admin portal is.

App store review

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

Testing on real devices

Simulators don’t 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’s 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. That’s the job. 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’ve already got 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’re 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, and bugs that only appear at real volume. New features are a separate budget again.

15–20%

Of build cost per year. A planning convention the calculator doesn’t produce

A common planning figure is 15–20% of the build cost per year for an app in active use, less if it’s stable and nobody is asking for anything. That’s a convention, not an output of this calculator. The estimate here covers building the thing rather than running it. What app maintenance actually costs prices the year with the engine instead, and separates the part that keeps it working from the part that changes it. Put a number in the slot either way. A plan with nothing there gets surprised around month eight.