Why an app cannot be priced from one line
"We need a delivery app" describes many different products. One is a menu with a checkout. Another is three apps in one: the customer's app, the driver's app with live tracking, and a control panel where your team assigns orders and watches them move. Two quotes for "a delivery app" can sit far apart simply because they price different things, and neither company is wrong.
So a figure given before anyone has asked who uses the app and what it must do is a guess. The useful order is the reverse: settle what the app has to do, then price exactly that. A quote that lists the features it covers can be compared with another one. A quote that names only a total cannot.
The five decisions behind the cost of an app
Each of these decisions adds work the others do not cover, so each one shows up in the cost of developing the app.
The last one is particular to this market. An app for customers in the UAE usually needs Arabic and English, and Arabic reads right to left, so every screen has to work in both directions and be tested in both. Added at the end, Arabic becomes a second project. Planned from the first screen, it is part of the first.
- 01Decide who uses itCustomers alone, or customers plus drivers, technicians or staff, with a control panel for your team. Each group needs screens of its own.
- 02Choose the phonesiPhone, Android, or both. One cross-platform app serves both from a single code base; two native apps mean two builds.
- 03Define what it must doSign-in, payments, maps and live tracking, chat, bookings, notifications. The features with a server behind them cost the most.
- 04List what it connects toA payment gateway, your accounting system or ERP, your stock system, a delivery partner. Each connection is work on both ends.
- 05Settle the languagesArabic and English, with right-to-left screens designed from the start rather than translated at the end.
The part nobody sees: the server and the control panel
The app on the phone is the part everyone looks at, and in most business apps it is the smaller part. Behind it sits a server that keeps the accounts, the orders and the content, sends the notifications, and talks to your other systems, such as your accounting or your ERP. Next to it sits a control panel, where your team adds products, handles orders, sees who signed up, and changes what the app shows without waiting for a new release.
Quotes that leave these two out look cheaper, and they are not. The app still needs both; the bill simply arrives later, from whoever builds them. So ask two questions of every quote: does it include the server side and the control panel, and where will the server run once the app is live?
Ready-made, custom-built, or a first version (MVP)
A ready-made app is a template shared by many businesses: a store, a booking app or a delivery app, set up with your logo and your products. It is the quickest and cheapest way into the stores, and you pay for it every month. You work within what the template allows, your data lives on the provider's platform, and leaving later can mean starting again.
An app built for you follows your process instead of asking you to follow the template's. It costs more at the start, and in return you own the result: the code, the design and the store listing. It is the right call when the way you work is part of what customers pay you for.
Between the two sits a first version, often called an MVP: only the few things a user must be able to do, built properly, put in front of real customers, then extended by what they actually use. When you are not yet sure people will use the app, it is the cheapest way to find out, and none of it is thrown away if the answer is yes.
- Quickest to launch
- A monthly subscription
- Limited to what the template allows
- Your data on the provider's platform
- Follows your process
- A larger cost at the start
- You own the code and the listing
- Can start as a first version (MVP)
What an app costs to run and maintain after launch
The build is paid once; running the app is paid every year, and it helps to know the lines before the first invoice arrives. Apple and Google Play both charge a developer account fee, and the accounts should be in your company's name. The server, meaning the hosting behind the app, costs more as the number of users grows. The services the app leans on, such as maps, text messages for sign-in codes, notifications and the payment gateway, charge by use, so they rise as the app succeeds.
Then there is upkeep. Apple and Google release new versions of their systems every year and raise what they require of the apps in their stores, so an app nobody updates eventually stops working properly, or stops reaching new users. Budget for maintenance from the start as a recurring line rather than a surprise: fixes, small changes, and a new release whenever the phones change underneath it.
One point about the stores' share, because it is often misunderstood. Their commission applies to digital content sold inside the app, such as subscriptions and features unlocked by payment. An order for physical goods, or for a service delivered in the real world, paid through an ordinary payment gateway, usually falls outside it.
How to get app development quotes you can compare
Write one page before you ask anyone for a price: who uses the app, the three to five things each of them must be able to do, which phones and languages it needs, which systems it connects to, and who will run it after launch. That page does more for the accuracy of a quote than any negotiation, because every company you send it to is pricing the same app.
Then ask every company the same questions. Which features does the price cover, and does it include the server side and the control panel? Who owns the code, and in whose name are the store accounts? What happens after launch, and how is maintenance priced? Is the price fixed for the agreed scope? A company that answers all four in writing is quoting a project. One that cannot is quoting a guess.
This is also why we start with a prototype you can tap through on your own phone before a line of code is written. It is the cheapest place to find what is missing, and once the prototype is agreed, the build price is fixed to it.