What actually drives the cost of a mobile app

You describe your app to three companies. One quotes X. One quotes double. One quotes triple. Everyone sounds confident, nobody shows their working, and you are left guessing who is overcharging and who is about to disappear halfway through.

Usually none of them is lying. They have quoted three different apps, because you described a product and they each imagined a different one.

Here is what actually moves the number.

1. How many kinds of user there are

This is the single biggest multiplier, and almost nobody asks about it early enough.

An app with one kind of user — a customer who browses and buys — is one app. An app with a customer, a vendor, a delivery rider and an internal admin is four applications that happen to share a database. Each role needs its own screens, its own permissions, its own edge cases, its own testing.

When we built a multi-category delivery product, the customer-facing app was the part everyone pictured. The vendor dashboard and the rider coordination behind it were the part that took the time. Nothing about the customer app got harder; there was simply three times more product than the original description implied.

Count your roles before you ask for a quote. If the answer is more than two, say so up front.

2. What it has to talk to

An app that stands alone is predictable work. An app that has to talk to something else is not, because you no longer control both ends.

Payment gateways, government or regulatory systems, an existing ERP, a hospital records system, SMS providers, shipping APIs — each one adds an unknown. Some are well-documented and take days. Some have no sandbox environment, no English documentation, and a support channel that answers in a week. You cannot tell which from the outside, and the honest answer at quoting time is a range, not a number.

Integrations are also where fixed-price projects go wrong most often. The agency prices the happy path; reality arrives later.

3. Whether it is bilingual

If your app needs to work in Arabic and English, that is not a translation task. It is an architectural decision, and taking it late is expensive.

Right-to-left layout is not a mirror image of left-to-right. Numbers, dates, currency and mixed Arabic-Latin strings all behave differently. Fonts that look correct in one language break shaping in the other. Every screen needs designing and testing twice.

Decided at the start, this is a modest overhead. Retrofitted onto a finished app, it is close to a rebuild of the interface.

4. Whether anyone decided what it does

The cheapest project is one where the scope was settled before the build started. The most expensive is one that gets designed while it is being built.

This is not a moral point about discipline. It is arithmetic. Changing a screen in a design file costs an hour. Changing it after it has been built, tested and connected to a backend costs a week, and the week is spent unpicking work that was already paid for.

How to read a quote

A quote you can trust does three things:

It gives a range, not a single number. Anyone quoting one exact figure for something they have not scoped is either padding heavily or about to come back with change requests.

It names its assumptions. How many user roles. Which integrations. Which platforms. Whether it is bilingual. If those are not written down, they were guessed, and the guess is the part that will cost you.

It says what is not included. App store submission, content, ongoing hosting, post-launch fixes. The gap between "built" and "live and running" is real, and it belongs in the conversation early.

The question worth asking

Ask each company: what would make this more expensive than you have quoted?

An agency that has genuinely thought about your project will answer in specifics — that integration, that role, that unclear flow. One that has not will tell you it is all included and there is nothing to worry about.

The second answer is more comfortable. The first one is the one you want.