How much time and money a mobile app really takes — stage by stage, hidden costs included

You ask three agencies the same question: "We need a mobile app — how long will it take and what will it cost?" One quotes 3,000 manat, another 12,000, and the third dodges with "let's meet first, then we'll talk numbers." You try to line the figures up side by side, but they are not actually comparable — because none of the three asked you the same questions before naming a price.

The real problem is not the budget itself, it is the assumptions hiding behind the quote. One agency is picturing a simple app; another is picturing a system with payments, notifications and an admin panel — and neither says so out loud. Below is where the time and money actually go, which question moves the price, and the recurring costs almost no one mentions before you sign.

The question is not "how much" — it is "what"

"Mobile app" is not one product. The same two words cover everything from a digital business card to a banking app. So the first question is never price, it is scope:

• Does the app run on its own, or does it talk to a server? Showing static information and writing every action to a database are two very different amounts of work.
• Does a user log in? Registration, password recovery, social login — each one is its own module.
• Is there payment? Card payment integration needs more than code — it needs an account and a verification process behind it.
• Are push notifications sent? A push notification looks like a small feature, but a separate piece of infrastructure sits behind it.

Any price quoted without answers to these questions is a guess, not a proposal. Separating what the first release genuinely needs (an MVP — the smallest working version) from what can wait makes both the budget and the timeline real.

Where the time actually goes

A project moves through four stages, and each one takes its own share of time.

Discovery and design

The feature list and the screen flow get mapped first — which button leads where, which screen follows which. Rush this stage and the result gets reworked later, during development, which always costs more than planning it right the first time.

Development

Two things happen in parallel here: the interface people see, and what sits behind it — the server side handling user data, orders, notification logic. If the interface is written separately for iOS and Android, that work doubles, which is why the platform choice has a direct effect on budget (more on that below).

Testing and store review

A finished app is not a finished project. It first gets tested on real phones on real network speeds — everything always looks fine in a simulator. Then it goes to the App Store and Google Play, and each one runs its own review step, which turns the launch date into a variable that is not fully in your hands. The reason for a rejection is often not technical at all — a missing privacy policy page is a common one.

Native, or one codebase for both platforms

An app written separately for iOS and Android (native) fits each platform's own rules exactly and runs fast, but it means two separate codebases — every change gets made twice. A cross-platform approach, one codebase shipping to both stores, cuts both time and budget, especially at the MVP stage. The right choice depends less on the number of screens and more on how much device-level complexity the app needs — camera, sensors, offline behaviour — and that decision belongs in discovery, before development starts, not after.

The hidden line: costs that repeat every year

Most quotes name one number: what the build costs. But spending does not stop once the app reaches the store, and this part is rarely said out loud:

• Apple Developer Program — keeping an app listed on the App Store costs $99 a year, according to Apple's own program page.
• Google Play — the Android side works differently: per

A mobile app is not a building you pay for once and leave standing — it is a living product with an annual fee just to keep existing.

None of these lines are large on their own, but they need a place in the budget table. A business that plans only for the build cost and forgets them meets an "unexpected" bill a year after launch.

Who is responsible once the app is live

The project does not end on the day it reaches the store — a new stage starts. In the first months, real users find bugs a simulator never shows: on a specific phone model, under a specific network condition. Who owns that stage needs to be written down in advance:

• Bug fixes — how many days it takes to look at a user-reported problem, and who is responsible for it.
• Compatibility when the OS updates — when iOS or Android ships a new version, who checks that the app still works under it.
• Small changes — whether updating text, a price or an image counts as a new project or falls under monthly support.

If none of these three is written into the quote, the first real problem tends to come with "that wasn't part of our scope" — and finding a new contractor then starts with someone else learning your codebase from zero.

How to read a quote

Next time a quote lands in your inbox, ask three things: is the scope written down precisely — which screens, which features are included; how long does each stage actually take; and whose name is on the store account and who pays the server bill. Any number that skips these three questions is not one you can compare against another.

If you want to pin down your own project's scope together, see how we run mobile app projects — the accounts open in your name, and the code is yours from day one.