How much does a mobile app cost?

It depends mainly on scope, which is why any figure quoted before a scope exists is a guess. The cost of a mobile app is the sum of a few decisions: what the app does, which platforms it runs on, how much design it needs, what sits behind it on the server, how secure it must be and how long you plan to keep it alive. This article shows how each decision moves the cost, how to estimate it yourself and how to reduce it without making the product worse.

We do not print prices on this page, and we think a page that does is not helping you: one number hides the drivers behind it. Learn the drivers and any quote, from us or from anyone else, becomes something you can test.

What drives the cost of a mobile app

Cost follows effort, and effort follows the factors below, roughly in the order they matter.

Every feature has to be designed, built, tested and maintained. Some look small on a list and are not: sign-in with password reset and multi-factor authentication, push notifications, offline mode, payments, in-app chat, search and maps. Two apps with the same number of screens can differ widely in effort because one shows content and the other handles real-time data.

iOS, Android or both. A single codebase built with Flutter or React Native usually costs less than two separate native apps, but nowhere near half: design, backend, testing and store release are shared work, and platform-specific features still need native code. [Native or cross-platform](/blog/native-or-cross-platform) covers the trade-off in detail.

A standard interface built from familiar components is quicker than custom motion and bespoke illustration. Research and usability testing add time at the start and remove expensive rework later. A design system costs more at first and saves effort as the app grows.

Most apps are the visible part of a larger system: an API, a database, accounts, an admin panel, analytics. Each integration, such as a payment gateway, an identity provider, a mapping service or a partner's API, brings its own documentation, sandbox, approval process and ways to fail. Integrations are often the least predictable line in an estimate.

Storing tokens safely, encrypting traffic, handling personal data carefully, modelling threats and reviewing security before launch all take time. Regulated sectors add questions about where data lives and who can see it. It is cheaper to design this in than to retrofit it. Confirm any legal obligations with qualified counsel; this article is not legal advice.

English and Arabic means a right-to-left layout, mirrored icons, Arabic typography and copy written natively, ideally planned from the first screen. See [designing bilingual products](/blog/designing-bilingual-rtl-products). Content has to be written or migrated, and testing grows with every device size, operating system version and language you support.

How estimates are made, and why quotes differ

A reliable estimate breaks the product into features, sizes each one for design, build and test, adds the shared work (setup, backend, release, project management) and states its assumptions. When two vendors land far apart, the cause is usually different assumptions rather than different skill.

Before you compare totals, check whether the quotes differ in any of these:

• Scope: one includes an admin panel, the other assumes you will build it.
• Platforms, and the oldest operating system versions supported.
• Design: a few standard screens, or custom motion, research and a design system.
• Testing and a security review: included, optional or missing.
• Backend and hosting: included, or left to you.
• Support after launch: none, a fixed period or an ongoing plan.
• A risk allowance: some vendors add a margin for unknowns, others pass the unknowns on later as change requests.

The cheapest quote often leaves out something the others included. Line quotes up feature by feature, not total by total.

Fixed scope or flexible team

With a **fixed scope** you agree the features, the timeline and the cost up front. It suits a product whose requirements are clear and stable. The weakness is change: anything new goes through a change request, and vendors protect themselves against unknowns by padding the estimate.

With a **flexible team** you pay for capacity, usually monthly, and steer priorities every week. It suits a product you are still learning about. The weakness is that it needs a product owner on your side and has no built-in end date. [Pricing models](/company/pricing-models) compares the two in more depth.

A common middle path is to scope first. For us that is the discovery sprint: about two weeks, fixed, ending in a clickable prototype, a technical approach, a threat model of the core flows and a written roadmap. It turns 'it depends' into a plan that can be priced. The three engagement shapes are described on the [pricing page](/pricing).

How to cut scope without cutting quality

What to ask in a quote

A good quote lets you answer these without guessing:

• Which features are included, listed one by one?
• Which platforms, operating system versions and languages?
• How much design is assumed: screens, custom animation, research, a design system?
• Who builds the backend and the admin panel, and where does it run?
• What testing and security review happen before launch?
• What happens when scope changes, and how is the change priced?
• What do I receive at the end: source code, documentation, store submission, access to every account?
• How often will I see working software?

Ask for the developer accounts, the source code and the store listings to be in your name from the start. It costs nothing at the beginning and a great deal if you ever change vendors.

The costs people forget

• **Maintenance.** Apple and Google release new operating system versions every year, libraries need updates and store requirements change. An app that is not maintained slowly stops working. Budget for it as a recurring line, not a one-time cost.
• **Store accounts.** Apple's developer programme carries an annual fee and Google Play a registration fee. Organisation accounts need the legal entity verified, which can take time. Check current terms before you fix a launch date.
• **Store commissions.** Both stores take a share of in-app purchases of digital goods. Whether that applies to you depends on what you sell.
• **Third-party services.** Hosting, push delivery, maps, SMS and email, analytics and crash reporting often charge by usage, so the bill grows with your success.
• **Content and translation upkeep.** Every new screen needs Arabic and English copy.
• **Support.** Someone has to answer users and triage bugs.

For a wider view of how the build approach changes the bill, read the guide on [choosing how to build your product](/guides/choosing-how-to-build-your-product), or see how we approach [mobile development](/services/mobile-development).