What a mobile app costs, broken down by module

Every agency publishes an article about what a mobile app costs, and almost none of them put a number in it. We are not going to either, and it is worth saying why before you read further.

A number without a scope attached is not information. Any figure wide enough to be honest is too wide to help you, and any figure narrow enough to help is a guess about a product nobody has described yet. We price every project individually, after the scope is agreed, broken down module by module.

What we can usefully publish is the shape — which parts of an app are expensive relative to each other. That is what nobody tells you, it is stable across projects, and it is the thing that actually lets you make decisions about version one.

The screens are the cheap part

This surprises people and it is the single most useful thing on this page.

The visible interface — the thing you have been imagining, the thing the designs show — is typically one of the lighter items in the estimate. Screens are well-understood work. A list, a form, a detail view, a settings page: these are things every mobile developer has built dozens of times, and building them again is predictable.

What costs money is almost entirely invisible in a design file. Which is why an app can look simple and be expensive, and why two apps that look alike can differ by a factor of three.

What is actually heavy

Roughly in order, and these are relative weights rather than prices.

Offline capability and sync

Consistently the heaviest single item, and the one most often omitted from an early estimate because it does not appear on any screen. A real local database, a queue of pending changes that is safe to repeat, rules for what happens when two people edited the same thing, and tests that exercise the transitions rather than the states. If your app genuinely needs to work without a connection, expect this to be comparable to several screens on its own. We wrote about why this is the expensive part.

More than one kind of user

A second user role is not twice the work, but it is far more than a flag in a database. Different permissions, different navigation, different states, and — the part that gets missed — every screen now needs testing in both roles. A third role is less again than the second, because by then the structure exists. The jump from one role to two is the expensive one.

Anything with video or audio

Recording, playback, upload, compression, resumable transfer, and behaviour when any of that fails mid-way. Media is where the edge cases live and where storage and bandwidth costs start, which makes it a running expense as well as a build one.

Payments

The happy path is a well-documented integration. The cost is everything around it: failed payments, refunds, partial refunds, subscription state when a card expires, what the app shows when the payment provider is down, and the reconciliation nobody specifies until the first month of real transactions.

Integration with systems you do not control

The most variable item on this list, and the reason we scope it separately rather than folding it into a total. A well-documented API is modest work. An undocumented in-house system, or a vendor whose sandbox behaves differently from production, can exceed everything else in the project. This is why we will ask what it has to talk to before giving you any figure at all.

Real-time anything

Live updates, presence, collaborative editing, chat. Each needs a persistent connection, reconnection handling, and a decision about what the user sees while it is re-establishing. Chat in particular is wildly underestimated because everyone has used one and assumes it is a solved shape.

What is lighter than people expect

For balance, because the point is to help you choose rather than to make everything sound hard.

• More screens of the same kind. Once the patterns exist, the tenth list view is a fraction of the first.
• Push notifications, if they are announcements rather than a system with its own preferences, scheduling and segmentation.
• Sign-in with an established provider, compared with building accounts, recovery and session handling yourself.
• Supporting both stores. With one cross-platform codebase, the second platform is release work rather than a second build. That is the whole argument for building that way.
• Analytics, where it means instrumenting events rather than building reporting.

The parts that are never in the first estimate

Not hidden costs — real work that clients are routinely surprised by, because it does not look like features.

• Store submission and release management. Signing, certificates, listings, screenshots, review responses, and resubmission after each OS release.
• QA across a real device range, not one current flagship. On mobile this is where most of the surprises are.
• Migrating existing data into the new app, which is frequently its own project.
• Accessibility. We scope WCAG 2.1 AA as real work with hours against it, because that is what it is.
• Everything after launch. Both platforms ship a major version every year and will break something. Every project we build includes one month of bug fixing; the years after that are a support arrangement, and that is a running cost rather than a one-off.

How to use this

Take your feature list and sort it by the weights above rather than by how important it feels. The result is usually uncomfortable in a productive way: one or two items that nobody considered central are carrying a disproportionate share of the budget.

Then ask of each heavy item whether version one genuinely needs it. Offline capability is either essential to how the product is used or it is not — there is rarely a middle. A second user role can often wait for version two. Video can sometimes start as a link to something hosted elsewhere.

That conversation is the one worth having, and it is much easier to have while the scope is still a document.

How we actually price it

A rough estimate as soon as we understand what you want to build, which is usually enough to tell you whether the project is worth taking further.

The detailed number comes after the scope is agreed with you, broken into modules and priced individually. That breakdown is the useful artefact: you can see what the offline layer costs, or the second role, or the integration, and decide what belongs in version one with real figures rather than instincts.

There are no packages, because the work does not arrive in packages.

If you have a list and want to know what it implies

Send it over. We will come back with a rough estimate and an honest view of which parts are carrying the weight, before anyone signs anything.

Related reading

• Mobile App Development — what we build and how
• Building an app that keeps working when the connection drops — the heaviest item, explained