App Development
You have asked three companies what a mobile app costs and got three versions of “it depends”. That is frustrating, but it is not evasion — it is what happens when the same two-word request (“a booking app”) can mean four weeks of work or nine months of it. This article explains what genuinely moves the price, gives you a way to read any quote you are handed, and lists the questions that will get you a real number faster.
Why nobody gives you a number on the first call
An app is not a product on a shelf. The word “app” describes the thing your customer taps, but most of the cost sits behind it: the database, the admin screens your staff use, the connections to your accounting or inventory system, the rules about who is allowed to do what.
A vendor who quotes a firm price in the first ten minutes is doing one of three things. They are quoting a template they will bend to fit you. They are quoting low to win the work and will raise it later through change requests. Or they have guessed. None of those ends well.
The honest position is that a fixed price is possible — but only after a short, structured conversation about scope. That conversation usually takes under an hour. If a vendor cannot get to a fixed number after one, that is a different problem.
What actually moves the price
The number of different users
This is the single biggest driver and the one buyers underestimate most. An app with one type of user — a customer who browses and buys — is one app. An app with a customer, a driver, a branch manager and a head-office administrator is four applications sharing a database. Each role needs its own screens, its own permissions and its own testing.
Before you ask for a quote, write down every person who will log in and what each of them can see and change. That list alone will explain most of the variance between quotes.
Integrations with what you already run
Connecting to systems you already own is where projects quietly double. If your app must read stock levels from your ERP, push invoices to your accounting software, or check a customer against your CRM, the cost depends entirely on whether those systems have a documented, working API — and whether your current vendor will give you access to it.
Older, locally installed systems often have no API at all. That does not make the project impossible, but it changes it. Ask your existing software supplier this question before you brief anyone: “Do you have an API, is there a cost, and how quickly can you provide documentation?”
Native versus cross-platform
Native means writing the app twice, once for iOS and once for Android, in each platform’s own language. Cross-platform means writing it largely once and running it on both. Cross-platform is usually the more economical route and is a reasonable default for most business apps.
Native earns its extra cost when the app leans hard on the device — heavy camera or scanning work, background location tracking, offline-first field use, or demanding graphics. If someone recommends native for a straightforward booking or catalogue app, ask them to justify it. Our mobile app development approach is to pick the route the app actually needs, not the one that bills more hours.
Payments
Taking payment in the app adds three separate pieces of work: integrating the gateway, handling the states around it (failed payments, refunds, partial refunds, receipts), and passing the platform review that comes with it. There are several gateway options used in the region, and the right one depends on your bank, your settlement currency and what your business already uses.
The part that catches people out is timing, not code. Merchant account approval sits with the provider and your bank, not with your developer, and it is worth starting that application early rather than at the end of the build. Confirm the commercial terms — transaction fees, settlement periods, any setup charge — directly with the provider.
How much backend there is
If your app only displays information, the backend is small. If it holds bookings, calculates prices, sends notifications, generates reports and gives your team an admin panel, you are buying a piece of business software with a mobile front end. That is a legitimate thing to buy — it is often the more valuable thing — but it should be scoped and priced as what it is. This is the point where an app project becomes a custom software project, and where quotes diverge most sharply.
Language, design and local details
An Arabic interface is not a translation task bolted on at the end. Right-to-left layout affects nearly every screen, and doing it properly means designing for it from the start. Similarly, options like national digital identity sign-in, local SMS delivery for one-time passcodes, or Emirates ID capture each add real work. They may be worth it. They are not free.
The costs that begin after launch
A quote that stops at “delivery” is incomplete. Budget for these from day one:
- Store accounts. Apple bills an annual developer programme fee; Google Play charges a one-off registration fee. Both are minor next to the build — but insist the accounts are registered in your company’s name, not your agency’s. Business verification with Apple can take longer than people expect, so start it early.
- Hosting and infrastructure. Monthly, and it scales with usage. Ask whether the estimate assumes a hundred users or fifty thousand.
- Third-party services. Maps, SMS, push notifications, email delivery and payment fees are usually billed per use and are yours, not the developer’s.
- Maintenance. Apple and Google change their operating systems and their store rules every year. An app left untouched for two years will eventually break or be delisted. Expect an ongoing support arrangement, and expect it to be a meaningful annual figure rather than a rounding error.
How to read any quote you receive
Put the quotes side by side and check that each one answers these questions in writing:
- What exactly is being built? A feature list, screen by screen — not “customer app, admin panel”.
- What is excluded? The exclusions tell you more than the inclusions.
- Who owns the code and the accounts? Get this in the contract. If you cannot take the source code and the store listings elsewhere, you are renting, not buying.
- What happens when scope changes? It will. Ask how changes are priced and approved.
- What is the support arrangement after go-live, and what does it cost annually?
- Is VAT included? Compare like with like.
A quote that is dramatically cheaper than the others is not usually a bargain. It usually means the vendor scoped a smaller app than you described, and the difference will arrive later as change requests.
Questions to ask before you brief anyone
You will get faster, firmer numbers if you arrive with answers to these:
- Who logs in, and what can each of them do?
- What must the app connect to, and does that system have an API?
- Are you taking payment in-app, and who is your bank?
- Do you need Arabic at launch or later?
- What is the one thing this app must do for the business to be worth building? Everything else is phase two.
That last question is the most valuable. Most apps are quoted too high because the first version is scoped to include everything anyone has ever suggested. A smaller first release that reaches real users is almost always the better commercial decision.
If you want a straight answer
We quote a fixed price after a short discovery call, because that is the only honest way to do it. If you are collecting quotes and want a second opinion on what you have been sent — including quotes from other companies — we are happy to look and tell you what we think is missing.
Get in touch and bring your list of users and systems. That is usually enough to get to a real number.
