Send the same one-page brief to five studios and you will get five numbers that do not resemble each other. This is the single most disorienting part of commissioning an app, and it makes founders assume someone is padding.
Usually nobody is. The quotes differ because the brief did not constrain the things that drive cost, so each studio silently assumed a different version of your app. Understanding which assumptions those are lets you compare quotes on the same footing — and cut your own cost without cutting quality.
What actually drives the number
Screens are not the unit. States are.
A brief that says “about twenty screens” tells an estimator almost nothing. A single screen might be static text, or it might be a live list with search, filters, pagination, offline caching, empty state, loading state, error state, pull-to-refresh and per-row actions. That is one screen and ten pieces of work.
When you write a brief, describe the states, not the screen count. It is the fastest way to make five quotes comparable.
Authentication is rarely just a login screen
Email and password is a day. Email, Google, Apple, phone OTP, biometric unlock, password reset, email verification, session refresh, account deletion, and an admin able to disable an account — that is closer to two weeks, plus the security review it deserves.
Anything involving money doubles its own estimate
Payments are not an integration; they are a set of failure modes. What happens when the network dies after the charge succeeds but before your server records it? What does a refund do to the in-app state? How do you reconcile Apple’s subscription receipts with your own database when a user changes tier mid-cycle?
The happy path is a week. The unhappy paths are the rest of it, and skipping them is how a fintech app ends up with a ledger nobody trusts.
Realtime is a different architecture, not a feature
“Live tracking” or “instant chat” changes the shape of the backend, the data layer and the testing strategy. Estimating it as a feature added to a request-response app understates it every time.
Admin tooling is real software
Almost every app needs somewhere for a human to look at data, moderate content, issue refunds or fix a bad record. It is invisible in the brief because users never see it, and it is routinely 15–25% of total build cost. A quote that omits it is either incomplete or assumes you will use the database directly — which works until the first non-technical hire.
Content and data migration
Moving an existing user base, importing a catalogue, mapping legacy records to a new schema. Never in the brief; frequently weeks of work.
The four assumptions that explain quote spread
When two quotes differ by 4×, it is nearly always one of these:
1. One of them scoped v1 and the other scoped everything you mentioned. The cheap quote may be the honest one, if it comes with an explicit list of what was excluded. A cheap quote with no exclusion list is the dangerous kind.
2. One includes backend and admin; the other assumes you have them. Ask explicitly whether the number covers APIs, infrastructure, and the tooling to operate the thing.
3. One includes store submission, assets and review defence; the other stops at handing you a build file. That gap is real work and it is the work most likely to delay a launch.
4. One prices a maintainable codebase and the other prices a demo. Tests, error handling, accessibility, monitoring and documentation are roughly 20–30% of build effort. An app without them is cheaper on day one and considerably more expensive in month eight, because every change risks breaking something nobody can detect.
Questions that make quotes comparable
Ask every studio the same five things and the spread usually collapses:
- What is explicitly excluded from this number?
- Does it include backend, infrastructure and admin tooling?
- Does it include store submission and handling rejections?
- What is the test coverage and error-handling standard you are pricing?
- What does month thirteen cost — upgrades, monitoring, support?
That last one matters more than people expect. A mobile app is not a project with an end date; it is an asset with a running cost. Two OS releases a year, SDK deprecations, certificate renewals, changing store policy. Budget somewhere between 15% and 25% of build cost annually to keep an app healthy. Budget zero and you will pay it anyway, in a rescue project, at a premium.
How to spend less without buying less
Cut features, not quality. Halving the feature list halves the cost. Halving the engineering standard doubles it, eighteen months later.
Ship one platform first, when it is honest to do so. If your users are 80% on one platform, launching there first buys you real feedback before you spend the second half of the budget. Note that this argument is weaker on cross-platform stacks, where the second platform is cheap — which is itself a reason to choose one.
Use boring, proven infrastructure. Managed authentication, managed databases, off-the-shelf payments. Building these yourself is rarely a differentiator and always a cost.
Pay for discovery. A paid scoping phase costs a small fraction of a build and routinely removes more than its own cost from the build by killing features that would not have earned their place. It also gives you a document that makes every subsequent quote comparable.
Do not skip the admin panel. You will build it eventually, under pressure, badly.
The honest summary
A focused, well-scoped v1 on both platforms — real authentication, a working backend, a handful of core flows, proper testing, submitted to both stores — is a substantial piece of engineering, and anyone quoting it as trivial has either misunderstood the brief or is planning to hand you something that will need rebuilding.
The way to get a number you can trust is not to collect more quotes. It is to tighten the scope until the quotes have nothing left to guess about.
That is what our product sprint produces: a written scope, a prototype, and one fixed number. It is yours to take to any studio, including not us. Start there.