What Drives the Cost of a Mobile App — and What Does Not
Screen count is a poor predictor of app cost. Integrations, state and compliance are what actually move the number. Here is how to read a quote.
Mobile Apps3 min read

Ask three agencies to quote the same app and you will get three very different numbers. That is not necessarily dishonesty. It usually means they made different assumptions about things the brief never specified.
Here is what actually drives the figure.
Integrations, not screens
A screen that displays static content costs very little. A screen that reads live stock from an ERP, reserves it, takes a payment and issues a compliant invoice touches four systems, each with its own failure modes.
When comparing quotes, count integrations rather than screens. Every external system is a negotiation with something you do not control: authentication, rate limits, sandbox environments that behave differently from production, and a support contact who may not answer quickly.
State is expensive
An app that shows information is straightforward. An app where the user does something — creates a draft, works offline, syncs later, or continues on another device — carries genuine complexity.
Offline support in particular deserves scrutiny. "Works offline" can mean caching the last screen, or it can mean full conflict resolution when two devices edited the same record. Those differ by an order of magnitude in cost, and briefs almost never distinguish them.
Accounts and roles
Login sounds like one feature. In practice it implies registration, verification, password reset, session expiry, account deletion, and — the expensive part — permissions. "Managers see all deals, salespeople see their own" is a sentence that becomes a permission model touching every screen and every API endpoint.
Compliance and payments
Taking money raises the floor. Payment integration, refunds, failure states and reconciliation are unavoidable work. In the Kingdom, add the invoicing obligation: if a purchase in your app generates an invoice, that invoice has to satisfy e-invoicing requirements, which usually means the app talks to a system that handles it rather than doing it itself.
Handling personal data raises the floor again — deletion requests, retention, and where data is stored.
Content and language
A bilingual app is not one app with a toggle. It is layouts that hold at two text lengths and both directions, content written twice, and a review process in both languages. Budget for the second language as ongoing content work, not a one-time translation.
Reading a quote properly
Ask these questions of any estimate:
- What is excluded? Store accounts, design, content, backend, third-party fees and post-launch support are frequently outside the number.
- What happens after launch? A build price with no maintenance line is an incomplete picture, not a cheap one.
- Who owns the code and accounts? Publishing under an agency's developer account is a lock-in you will regret.
- What is the smallest useful version? A vendor who cannot describe a smaller first release either does not understand the domain or is not incentivised to.
The cheapest real saving
Cut scope, not quality. Two well-built journeys beat eight half-finished ones — they are cheaper to build, far cheaper to maintain, and they tell you what to build next because real users are using them.
The most expensive app is the one that shipped with everything and taught you nothing.
Want a quote you can actually interrogate, with the assumptions written down? Start a project.