What decides the cost of building a mobile app

Start from the first version, not the price

People often ask me what an app costs before telling me what it does. There is no honest answer to that yet. The cost of building a mobile app is mostly the cost of its features, plus the parts users never see: the server, the admin dashboard, store publishing and testing.

That is why two quotes for "the same app" can be far apart. One developer pictured a login screen and a list. Another pictured three user roles, online payments and live tracking. They are simply pricing different apps.

So the first job is to decide what the first version must do on launch day, and write it down. The rest of this article helps you do that.

User roles: one app is often four

A user role is a type of person with their own screens and permissions. Take a delivery app, which most people describe as one app. It usually needs:

• A customer side to browse, order, pay, track the order and rate it
• A driver side to go online, accept a job, follow the route and confirm delivery
• A store or restaurant side to receive orders and update the menu and stock
• An admin dashboard to manage users, orders, refunds, driver payouts and reports

Screens and flows: count journeys, not pages

Each role is close to a separate product, with its own screens, rules and testing. Check whether the first version needs all of them. The store side, for example, can often start as a page in the admin dashboard.

Then count flows rather than screens. A flow is a full journey, such as "sign up, verify the phone number, add an address, place the first order". One checkout screen can hide address checks, delivery fees by area, promo codes and failed payments.

Think about the unhappy paths too: no internet, a declined card, a driver who cancels. Handling those is a big part of the work, and a quote that ignores them will grow later.

The backend and admin dashboard you don't see

Most apps are the front of a bigger system. Behind them sits a backend: a server and database that store users, orders and content, apply your business rules and send notifications. For a new product, the backend is often as much work as the app itself.

The admin dashboard is where your team adds products, handles support and issues refunds. A basic one with tables and forms is fairly quick. Detailed reports, staff permission levels and Excel exports add work, so list what your team will do there every day.

If you already have an ERP, a POS or a website with an API, the app may connect to it instead. That saves a lot only if the API is documented and does what the app needs, so share it early. Services such as Firebase or Supabase can also shorten common parts like sign-in and file storage.

Integrations: payments, maps, SMS and notifications

Every outside service adds setup, testing and often a monthly bill. The common ones:

• Payments: a gateway such as Paymob in Egypt, Tap, HyperPay or Moyasar in the Gulf, or Stripe in Europe needs a merchant account, refunds and handling of failed payments. Digital content and subscriptions sold inside the app usually have to use Apple's and Google's in-app purchase instead, which takes a commission.
• Maps: showing a map is simple. Address search, delivery zones, routes and live driver location are each extra work, and map services charge by usage beyond a free allowance.
• SMS and OTP: paid per message, at a price that depends on the country. Sending under your brand name in Saudi Arabia or the UAE usually needs a registered sender ID, which takes time.
• Push notifications: Firebase Cloud Messaging is free, but targeting the right users and a dashboard screen for campaigns is real work.
• Google and Apple sign-in, email, analytics, crash reporting and support chat: each one is small, but they add up.
• Shipping, accounting or e-invoicing systems: these depend on the other side's API, so get its documentation first.

Real-time features and offline support

Anything that updates live costs more than something that loads once. Chat, live tracking and a dashboard that shows new orders instantly all need a constant connection to the server: more backend work, more cases when the connection drops, and running costs that grow with your users.

Chat sounds small. Text between two people is one thing; add images, voice notes, read receipts, group chats and moderation, and it becomes a project of its own.

Offline support is similar. Showing the last loaded data is fairly cheap. Editing offline and syncing later is not, because the app must handle the same record changing in two places. If your users work in warehouses, on the road or with weak coverage, say so in the scope.

Arabic, English and right-to-left layouts

Apps for Egypt and the Gulf usually need Arabic and English. Flutter mirrors the layout for Arabic well, as long as the code uses direction-aware spacing and alignment. The cost is in everything around that.

Every text needs both languages, including errors and notifications. Back arrows flip, while media controls and phone numbers should not. Dates, numbers and currency need the right format. Content added through the dashboard, such as product names, needs two fields per item, which changes the database and the admin screens.

My advice: even if you launch in one language, ask for the app to be built ready for both. Adding right-to-left support later means going back through every screen.

Design: a standard look or a custom one

Design cost depends on how far you move from familiar patterns. Standard components with your colours, fonts and logo can look clean and professional and cost less. A fully custom look with unusual layouts, illustrations and detailed animations takes more time, because every custom piece must work on many screen sizes.

Either way, finish the design before development starts. A clickable prototype in Figma lets you tap through the main flows and change your mind while changes are cheap. If someone else designed your screens, check that they cover empty lists, errors and loading states, which are often missing.

iOS and Android: one Flutter codebase or two native apps

You almost always need to reach both iPhone and Android users. Two native apps means one codebase in Swift for iOS and another in Kotlin for Android, usually by two developers or teams. Every feature is built twice, tested twice and kept in sync for the life of the app.

With Flutter, which is what I use, one codebase produces both apps, so features and fixes are written once. That is the main reason it usually costs less for the same scope. Each platform still needs its own setup for notifications, permissions, signing and store listings, and both apps need testing on real devices.

Native still makes sense for apps that depend heavily on brand-new platform features or deep hardware access. For most business apps, such as booking, delivery, e-commerce and internal tools, one Flutter codebase is the sensible way to spend the budget.

Store accounts and the review process

Publishing has its own fees and rules. Plan for these:

• Developer accounts: Apple charges a yearly fee and Google a one-time registration fee. Open both in your name or your company's name, not the developer's.
• Company accounts need a D-U-N-S number on both stores, which can take a while to get. Start early.
• New personal Google Play accounts must run a closed test with real testers for a set period before publishing to everyone. Organisation accounts skip this step.
• Both stores need a privacy policy link and a data form that matches what the app really does.
• If users can create an account, they must be able to delete it inside the app. If you offer Google or Facebook sign-in on iOS, Apple generally expects an equivalent privacy-focused option such as Sign in with Apple.
• Reviews are often quick, but a rejection means another round. Store text, screenshots in both languages and a demo account for the reviewer all take preparation.

Testing on real devices

An app that works on the developer's phone is not finished. Your users have older Android phones, small and large screens, different system versions and unstable internet. Testing on a range of real devices is part of the build, and it should be in the quote.

During the project you should be able to install test versions yourself, through TestFlight on iPhone and an internal or closed testing track on Google Play. Ask who tests, on which devices, and whether there is a short warranty after launch for bugs in the agreed features.

Running costs after launch

The build is paid once. These keep running for as long as the app is live:

• Servers, database and file storage, which grow with users, images and traffic
• Services billed by usage: SMS, maps, email, and sometimes chat or video
• Payment gateway fees on every transaction
• Apple's yearly developer fee
• Updates for new iOS and Android versions: Google Play requires a recent target Android version for apps to stay available to new users, and Apple periodically requires new builds to use a recent Xcode
• Bug fixes, small changes and keeping packages up to date
• A domain and a simple web page for the privacy policy and support

How to write a scope that gets accurate quotes

You don't need a technical document. One or two pages that every developer receives make the quotes comparable, and the questions they ask back tell you a lot.

Write features as what a user can do. "Chat" can mean anything. "The customer and the assigned driver can send text messages during an active order, with no images in the first version" can be priced. Add a short out-of-scope list too. Here is a structure you can copy:

App name and one-line goal:
Who it is for, and in which countries:

User roles:
- Customer (iOS and Android app)
- Driver (iOS and Android app)
- Admin (web dashboard)

Main flows, written as what each role can do:
- Customer: sign up with phone number, browse, order,
  pay by card or cash on delivery, track the order, rate it
- Driver: go online, accept an order, navigate, confirm delivery
- Admin: manage orders, users, refunds and daily reports

Integrations (and the provider, if you know it):
- Payments:
- Maps:
- SMS / OTP:
- Existing systems or APIs:

Languages: Arabic and English, with right-to-left layouts
Design: brand guide? existing screens? apps you like, and why
Out of scope for the first version:
Deadline, and why that date matters:
Budget you have in mind (optional, but it helps):
Ownership: store accounts, servers and code in my name

Fixed price or paid by time

A fixed price commits the developer to an agreed scope. It suits a first version with a clear scope and finished designs. You know the cost upfront, but anything outside the scope becomes a priced change request, so a vague scope leads to arguments.

Time-based pricing means paying for the hours or days actually worked, often against a monthly estimate. It suits products that will change as you learn from users, and ongoing work after launch. You get flexibility, but you need to set priorities every week.

A mix often works best: fixed for design, fixed for the first version in milestones, then monthly for updates. Tie payments to things you can test, such as a working build of a flow, and agree in writing how changes are estimated and approved.

Red flags in a quote

Warning signs I would take seriously, whoever you hire:

• A single number with no feature list, or a price before any questions about your app
• No mention of the backend, the admin dashboard, testing or store publishing
• The app published under the developer's store account, or the code and servers kept in their name
• No test builds you can install during the project, only screenshots and a final delivery
• A large upfront payment that is not tied to milestones
• A very short timeline for a big scope, such as "an app like Uber in a few weeks"
• A ready-made template sold as custom work without saying so
• No written answer on bug fixes, updates and how changes are priced after launch
• No published apps you can download and try yourself
• No clear person to talk to during the project

How to phase features, and where to start

The cheapest feature is the one you don't build yet. For each item, ask: would a user refuse to use the first version without it? Ratings, loyalty points, referral codes, advanced reports and in-app chat can often wait. A call button or a WhatsApp link can stand in for chat at first.

Some things are cheap to add later: content screens, settings, promo banners. Others are expensive: Arabic and English support, offline sync, multiple vendors and the structure of your order and payment data. Decide those early, even if part of them ships later.

A smaller first version costs less, reaches users sooner and gives you real data for the next decision.

What to do next: write your one or two pages, mark each feature "now" or "later", and send the same page to two or three developers. Compare what each one asks and includes, not only the final number. If you want me to look at your scope, send it through the contact page and I will tell you what I would build first.

Common questions

How much does it cost to build an app?

There is no fair single number, because the cost depends on scope: user roles, flows, backend, integrations, languages and design. The reliable way to get a figure is a clear written scope sent to a few developers.

Is Flutter cheaper than native app development?

For the same scope it usually is, because one Flutter codebase builds both the iOS and Android apps. You still pay for platform setup, store publishing and testing on both systems.

How long does it take to build a mobile app?

It depends on the same things as the cost. A focused first version is much faster than a full product. Ask each developer for a timeline split into milestones, with a test build you can install at each one.

What are the ongoing costs of an app after launch?

Servers and storage, usage-based services such as SMS and maps, payment fees, Apple's yearly developer fee, updates for new iOS and Android versions, and bug fixes. Ask for these to be listed in the quote.

Does my app need a backend and an admin dashboard?

Almost any app with accounts, orders, bookings or changing content needs a backend, and your team needs a dashboard to manage it. If you already have a system with an API, the app may connect to that instead.

Who should own the app store accounts and the source code?

You should. Open the Apple and Google developer accounts in your own or your company's name and add the developer as a team member. Make sure the contract says the code and servers are yours.