What it really costs to build an app like HungerStation, Mrsool or Talabat

HungerStation, Mrsool and Talabat are shorthand for a category: a three-sided delivery marketplace with an operations team in the middle. I am not describing how those companies built their systems, only what any team must build to run that category in Saudi Arabia, and where the money and the risk sit.

What are you actually building when you ask for "an app like HungerStation"?

You are building four products on one real-time backend: a customer app, a courier app, a merchant app and an operations dashboard. The screens are the visible part; the logic that moves one order between three parties and your own team is most of the work.

The minimum anatomy I expect in any serious scope:

• Customer app: merchant and menu browsing, cart, checkout, live tracking, order history, ratings and help.
• Courier app: onboarding and identity checks, online status, accepting or declining offers, navigation, proof of delivery, earnings.
• Merchant app: incoming orders, accept or reject, preparation time, sold-out items, menu edits, payout reports.
• Operations dashboard: a live order board, manual reassignment, refunds, merchant and courier onboarding, zones and delivery fees, promotions, an audit log.
• The shared backend: dispatch and assignment, including what happens when no courier accepts; real-time tracking and maps; payments through a local gateway (mada, Apple Pay, STC Pay and cards) with refunds, merchant settlement, courier earnings and commission; notifications, two-way ratings and support tickets tied to the order.

The business model shifts the weight: a restaurant aggregator, a grocery service and a courier-on-demand "deliver anything" model put complexity in different places, so settle the model before anyone estimates.

Which modules drive the cost and the risk?

Dispatch, payments, real-time tracking and the operations dashboard drive most of the cost and nearly all of the risk. Login, menu and checkout screens are predictable; anything that coordinates three parties in real time is not.

Underneath it all sits the order state machine: placed, accepted, courier assigned, picked up, delivered, cancelled, refunded, and every transition between them. If nobody writes those states down first, each app invents its own version and the bugs live in the gaps. Design for the peak too: the iftar rush in Ramadan packs orders into a narrow window, and dispatch and payments must hold under that load.

Why do published price ranges disagree so much?

Because each vendor prices a different scope, and a published range is marketing, not an estimate. Even one vendor's guides disagree with each other.

These are the vendors' figures, not mine; I do not publish prices. The spread is the lesson. Creole Studios published its two Saudi guides three weeks apart, and their headline ranges still do not line up: SAR 150,000 to 500,000+ for a full food delivery app in one, and SAR 75,000 to 280,000+ for an on-demand delivery app, MVP included, in the other. The reasons are ordinary:

• "MVP" means different things. TekRevol describes its MVP tier as a customer app, a basic admin, one city and one platform: no courier app, no merchant app, so not yet a three-sided marketplace.
• Module and platform counts differ. iOS, Android or both; a merchant tablet app or a web panel; your own courier app or a contracted fleet.
• The business model differs. An owned fleet needs dispatch, shifts and earnings; a commission marketplace needs split payments and payouts.
• Some costs sit outside the headline. Discovery, QA, infrastructure, map and SMS usage, store reviews and the operations dashboard often are not in the first number.

Will a clone script or white-label kit get you there?

A white-label kit can test demand in a small area; it will not carry a real operation for long. You are licensing someone else's product, and the parts that make delivery work in Saudi Arabia are exactly the parts you cannot change.

Even TekRevol, which prices white-label builds at $12,000 to $40,000, presents them as a way to validate a market and warns that you cannot ship a differentiating feature on someone else's roadmap. In my experience, this is where clones break once real orders start:

• Dispatch is naive. "Nearest free courier" ignores preparation time, so couriers queue at kitchens while other orders wait.
• Payments assume another market. Local methods through a local gateway, partial refunds and merchant settlement are bolted on, if they exist at all.
• Arabic is an afterthought. Right-to-left layouts, Arabic search and menu names that mix Arabic and English break in ways a demo never shows.
• Nobody reviewed the code. You are about to put customers' addresses and phone numbers into software whose security you have not checked.
• The regulator moves faster than the vendor. When courier verification rules change, you need the change this quarter, not on the kit's release schedule.

If you start on a kit, give it an end date, read the licence for code ownership and data export, and keep your records in a form you can take with you.

What should a single-city MVP include, and what should wait?

One city, one vertical, a few neighbouring zones, four thin surfaces, and a manual override for everything not yet automated. Automate a task only after doing it by hand has started to hurt.

A hypothetical: a founder in Jeddah starting with restaurants only, in a few neighbouring districts, with a few dozen partner kitchens. I would scope this, and nothing more:

• One cross-platform customer app for iOS and Android, Arabic first and English second.
• A courier app with identity verification, online status, offer acceptance, navigation handed off to Google or Apple Maps, and photo proof of delivery.
• A merchant web app that runs on an inexpensive tablet: accept the order, set preparation time, switch off sold-out items.
• An operations dashboard with a live order board, manual assignment and reassignment, refunds that need a reason code and a second approver, and an audit log.
• Rules-based dispatch: nearest free courier, adjusted for preparation time, with a timeout and a fallback to a human dispatcher.
• One payment gateway that covers mada, Apple Pay and cards, plus a deliberate decision on cash on delivery, because cash creates courier balances you must reconcile every day.
• Push notifications, SMS one-time passwords, simple ratings, and support tickets tied to the order.
• Logging and monitoring from the first release, so anyone on the team can answer "what happened to this order?" in minutes.

What waits: more cities, subscriptions, ads, loyalty wallets, AI-predicted arrival times, order batching, scheduled orders and multi-store carts. Each is real work, and none of it tells you whether customers in your first districts will order again.

Which Saudi rules change the architecture?

The Personal Data Protection Law (PDPL) shapes how you store, keep and move personal data; the Transport General Authority (TGA) shapes much of the courier side. This is engineering guidance, not legal advice; confirm the legal position with a Saudi lawyer. My full engineering checklist is in the PDPL checklist for apps.

• The PDPL reaches you abroad. Article 2 applies it to any processing of personal data that takes place in the Kingdom, including processing by any party outside the Kingdom of personal data about individuals residing there. Offshore hosting or an offshore team does not take you out of scope.
• Remote access counts. SDAIA's February 2025 risk-assessment guideline, which it says is not legally binding, lists remote access among the forms a transfer abroad can take. If your vendor's engineers can query production from abroad, use least-privilege roles, masked data outside production and access logs.
• A 72-hour breach clock. The Implementing Regulation requires the controller to notify the competent authority within 72 hours of becoming aware of a breach that may cause harm (Article 24). You cannot meet that clock without logs that show what was accessed and when.
• Tracking and automated assignment invite an impact assessment. Article 25 lists processing that by its nature requires constant monitoring of data subjects, and decisions based on automated processing, among the cases that can require a written impact assessment. Live courier tracking and automated dispatch sit close to both.
• Courier identity is a product feature. TGA's January 2024 decisions required delivery apps to use face recognition to verify a driver's identity and required non-Saudis to work only through light transport companies, according to the Saudi Press Agency. Your courier data model needs the courier's employer, not just a phone number.
• Licensing and integration are requirements, not paperwork. Okaz reported in September 2025 that TGA's new executive regulation for order delivery bans the activity without a licence, requires companies seeking a licence to connect their systems to TGA's electronic platform, requires Nafath verification when registering Saudi drivers, allows a bike courier one order at a time, and requires showing the price and cancellation terms before confirmation. Each is a backlog item; check the current official text with TGA before you freeze scope.

How do you get a defensible estimate instead of a range?

Write the scope down before anyone quotes: a requirements document that fixes the model, the flows, the order states and the non-functional targets. Then compare quotes against that one document, not against each vendor's adjectives.

1. Choose the model: an aggregator with partner couriers, an owned fleet, or courier-on-demand.
2. List the four surfaces and, for each, what ships in version one and what waits.
3. Write the order state machine, including cancellations, partial refunds and no-courier cases.
4. Set measurable targets: peak orders per hour, how often courier location updates, acceptable error in arrival estimates, uptime.
5. Name every integration: payment gateway, maps, SMS, TGA's platform, Nafath, and any merchant point-of-sale system.
6. Turn the regulatory items above into requirements, each with a named owner.
7. Send the same document to two or three vendors for a line-by-line price, and have someone who is not bidding review the quotes for missing modules and optimistic assumptions.

The SRS guide covers writing that document, and before you sign with a software company covers the contract. Whoever reviews the quotes, a technical co-founder or an independent reviewer, should first check whether the operations dashboard is in the price. When a delivery app quote looks cheap, that is usually the missing module.