Discovery before a line of code
What the app does, who uses it, what happens when they are offline, and what the smallest useful version is. Apps scoped without this become expensive iterations of somebody's guess.
Mobile apps
Mobile app development that survives launch day.
Most app budgets are spent getting to launch, which is roughly the halfway point. The apps that succeed are the ones that were resourced for what comes after.
Overview
How an app project actually works
Mobile app development covers iOS, Android and cross-platform builds. The decisions that shape cost are platform choice, whether you need native performance, how many systems the app integrates with, and whether there is a backend to build. Launch is not the end of the project, and budgeting as though it is the single most common reason apps fail.
Native or cross-platform
React Native and Flutter cover the large majority of business apps at roughly one build instead of two. Native is justified when you need heavy device access, demanding graphics or platform-specific performance. We tell you which yours is rather than defaulting.
There is almost always a backend
Accounts, data, notifications, payments and admin. Clients frequently budget for the app and not the server behind it, and that omission is the most common cause of a project doubling in scope.
Store review is a real stage
Apple's review process rejects apps for reasons that are not obvious in advance: incomplete metadata, missing account deletion, unclear subscription terms. Build time for it rather than discovering it at launch.
Launch is halfway
OS updates, device fragmentation, crash monitoring, store listing maintenance and iteration on what users actually do. An unmaintained app degrades faster than a website and eventually stops working entirely.
Your accounts, your code
The app publishes under your Apple Developer and Google Play accounts, and the code and design files are yours. An app living in an agency's store account is genuinely difficult to move.
Pricing
What actually drives the cost
| Factor | Why it moves the number | What to ask |
|---|---|---|
| Platform choice | One cross-platform build against two native ones | Do we genuinely need native? |
| Backend and infrastructure | Frequently the larger half of the work | Is server-side included in this quote? |
| Integrations | Payments, maps, messaging, existing systems | What connects, and what happens when it fails? |
| Accounts and roles | Login, permissions, data separation | Who sees what? |
| Offline behaviour | Sync and conflict handling is real engineering | What happens with no signal? |
| Design depth | Template patterns against a custom design system | How much of this is bespoke? |
| Post-launch | Monitoring, OS updates, iteration | What does month two cost? |
We quote fixed scope after a discovery conversation. Anyone quoting an app from a paragraph is guessing, and the number will move.
Detail
What to ask before you hire
| Ask them | A good answer sounds like | Walk away if |
|---|---|---|
| Who owns the code and the accounts? | You do, in your own Apple and Google accounts | The app ships under their developer account |
| Can I open three apps you built? | Store links you can download today | Screenshots and mockups |
| What is explicitly not included? | A written list with change pricing agreed | Everything is included, which means nothing is defined |
| What happens after launch? | A named maintenance arrangement | Not discussed until it breaks |
The store account question is the one people forget. An app published under an agency's developer account is very difficult to move.
Limits
When you do not need an app
A responsive website would do
If the value is content or a straightforward transaction, a website reaches everyone with no install friction and no store review. Most businesses that want an app need a better mobile website.
Nobody will open it twice
Apps earn their place through repeat use. If the interaction happens once or twice a year, the install is a barrier rather than a convenience.
There is no plan for month two
An app with no budget for maintenance and iteration is a depreciating asset. We would rather tell you that before the build than after.
FAQ
Common questions
What does a mobile app cost?
It depends on platform choice, whether there is a backend to build, how many integrations are involved and what happens after launch. We quote fixed scope after a discovery conversation, because a number given from a paragraph of description will move.
Should we build native or cross-platform?
Cross-platform, using React Native or Flutter, covers the large majority of business apps at roughly one build instead of two. Native is justified for heavy device access, demanding graphics or platform-specific performance.
Do we need a backend?
Almost always, if the app has accounts, stores data, sends notifications or takes payment. This is the most commonly under-budgeted part of an app project and frequently the larger half of the work.
How long does an app take?
Three to nine months for a genuine product, depending on scope and integrations. If someone quotes an app in four weeks, they are describing a template or a wrapped website rather than an application.
Who owns the app and the store listings?
You do. The app publishes under your Apple Developer and Google Play accounts, and code and design files transfer to you. An app published under an agency's account is very difficult to move later.
What happens after launch?
OS updates, device testing, crash monitoring, store listing maintenance and iteration. Agree this before the build, because an unmaintained app degrades faster than a website and eventually breaks on new OS versions.
Do we actually need an app?
Frequently not. If the value is content or a simple transaction, a responsive website reaches everyone without install friction or store review. Apps earn their place through repeat use, and we will say so if yours does not have it.
Next step
Tell us what you need.
Send us what you are trying to fix and we will tell you what it takes, what it costs, and whether we are the right people for it. If we are not, we will say so.