How much does it cost to develop a mobile app

In short, the prices look like this:

These are average figures for Moscow and Saint Petersburg. The total depends less on the number of screens than on what stands behind them: where the data lives, how many user roles there are, which systems the app exchanges information with. Let us go through the main cost items one by one.

A mobile app is more than screens

The user sees an interface on a phone. The client pays for the whole system, and that interface is only its top layer. The system usually includes:

• the app itself for iOS and Android;
• the backend — a server, a database and logic that keeps working when the app is closed;
• an admin panel — a web interface where the client’s staff manage content, orders and users;
• integrations — payments, CRM, accounting, delivery services, maps;
• infrastructure — servers, build and release of new versions, monitoring.

A simple app can do without its own backend if an existing system already serves the data over an API. That is why an MVP costs noticeably less: the team builds the screens and connects to what is already there. As soon as you need your own server with logic and an admin panel, the project moves into a different weight class.

Platforms: one codebase or two

iOS and Android are different operating systems with their own rules, languages and app stores. Historically, each got its own app, which nearly doubled the budget for the client side.

Cross-platform development solves this differently: one Flutter app is built for both iOS and Android. The code, design and logic are shared, though two versions still have to be tested and published. For most business apps — customer accounts, ordering, internal tools for employees — this gives users roughly the same result for noticeably less money than two native teams.

Native development is justified less often: when the app works deeply with the phone’s hardware, needs maximum graphics performance or has special platform requirements. This is worth discussing during the estimate, not after the first release.

Backend and admin panel

This is the most underestimated part of the budget. An ordering app looks like a dozen screens, but behind them are a catalogue, a cart, pricing, payment, statuses, notifications, staff roles and reports. All of it lives on the server.

The backend cost depends on:

• the number of roles — a customer, a courier, a manager and an administrator see and do different things;
• payments — connecting a payment provider, refunds, receipts;
• notifications — push, text messages, emails and the rules for when to send what;
• data exchange with your systems: the more of them and the worse their documentation, the longer the work;
• load — a hundred users a day and ten thousand at once need different architectures.

The admin panel is often seen as a minor thing “for internal use”. But that is where the staff spend their working day, and a clumsy admin panel eats the client team’s time every day after launch.

Design

Mobile app design is not only colours and fonts. It is scenarios: how many steps to an order, what the user sees without internet, what a failed payment looks like, where a push notification leads.

The cost of design depends on the number of screens and states, not on “beauty”. Every screen has an empty state, a loading state and an error state, and all of them need to be drawn — otherwise the developer will improvise. Good design saves money on development: decisions are made on a mockup, where moving a button takes minutes, not in the code, where it takes days.

What makes an app complex

A price tag from RUB 15 million does not come from a large number of screens. Usually the reason is one of these requirements:

• a marketplace — several parties to a deal, each with its own interface, settlements between them, disputes and refunds;
• financial operations — stricter requirements for security, audit logs and checks;
• offline mode — the app works without a connection and later syncs the data without losing or duplicating it;
• many roles and permissions — every role multiplies screens, checks and tests.

Such projects take eight months or more. It almost always makes sense to start them with an MVP and test it on real users before building the whole thing.

Life after launch

Publishing to the App Store and Google Play is not the end of spending. An app lives in an environment that changes without asking you: new versions of iOS and Android come out, stores update their rules, third-party services change their APIs.

After launch you usually need:

• bug fixes for issues found by real users; during the warranty period they are free — our warranty is 6 months;
• updates for new operating system versions and store requirements;
• development — new features based on analytics and user feedback;
• infrastructure — servers, storage, paid notification and map services.

Plan a development budget from the start. An app that is never updated starts to look abandoned within a year, and sometimes stops passing store review.

How to keep the budget in check

A few decisions help you stay within limits:

1. Start with an MVP. 5–8 screens around one main scenario, and in 2–3 months you have real users instead of assumptions.
2. Choose Flutter unless there is a reason for native development: one codebase for two platforms.
3. Use ready-made services for sign-in, payments, maps and notifications instead of building your own.
4. Approve the design before development. Changes in a mockup are cheaper than changes in code.
5. Watch the demo every two weeks. You see where the money goes and can change priorities in time.

We estimate the timeline and cost for free, within 1–3 days of talking about the task. More about how we build Flutter apps is on the mobile app development page.

The price of an app is made of what the user never sees. The screens are only the visible part. The rest is what decides how much the project costs.