How Much Does a Food Delivery App Like Jahez or Talabat Cost in Saudi Arabia in 2026?

Jahez and Talabat are examples of food delivery platforms that bring many restaurants together in one app. The names are used only to describe a kind of app; we have no connection with either company. What most readers of this guide want is much smaller: a restaurant group that wants a delivery channel it owns for its brands, or a local operator that wants to serve one city well.

Either way the project is three apps and a panel: the customer app, an app or screen for the restaurant, the driver app, and an admin panel that includes dispatch. These decisions move the number:

A practical first version: sign-up by mobile number, browsing restaurants and menus with modifiers, basket and payment, order tracking on the map, a restaurant screen for accepting the order and setting the preparation time, a driver app for taking the job and updating its status, and a panel where staff assign orders and see drivers on the map. This costs SAR 50,000–150,000 in the market and is enough to run a city.

What can wait: automatic dispatch, wallets, subscriptions, loyalty points, paid advertising for restaurants and multiple cities. What we do not recommend postponing: accurate preparation and arrival times shown to the customer, and a record of every money movement between customer, restaurant and driver. The first decides customer satisfaction; the second decides whether you know your profit per order.

If you are a restaurant group selling only your own brands, the project is simpler: no onboarding of outside restaurants and no settlements between parties. It sits in the mid-size app range of SAR 60,000–170,000.

The customer app is what everyone sees, but it is the least complex of the three. The driver app works in the hardest conditions: weak signal, a draining battery and one hand on the wheel. It must work in few taps, keep the job if the connection drops, and send location without killing the phone. The restaurant screen must alert with a sound nobody can ignore, and let staff switch off a sold-out item in one tap.

The dispatch panel is the operations room. Manual dispatch is enough at first: staff see new orders and available drivers on the map and assign the job. Automatic dispatch becomes necessary at hundreds of orders a day, and it needs clear rules: the nearest driver, the least loaded, or the one who will pass the restaurant anyway. Start manually, record the data, then build the rules on what you really see.

Every order uses services billed by usage: maps and routing, verification messages and notifications, and payment gateway fees. Market estimates put APIs at SAR 2,000 a month and up, and maps and tracking at SAR 15,000–40,000 depending on volume. Ask for a written estimate at 200 orders a day and at 2,000.

The largest cost is not technical: the driver’s pay on every delivery. Work it out before development: the delivery fee the customer pays, plus the commission or meal margin, minus driver pay, payment fees and services. If the result is negative at your expected volume, no app feature will fix it. Set aside 15% to 20% of the build cost each year for maintenance, and for support that covers evenings and holidays.

Ready-made (clone) solutions start in the market at about SAR 14,000 and launch in weeks. They suit testing a small city, or a restaurant that wants a quick channel. Ask before you buy: is the code yours or a shared licensed copy? Are the store accounts in your name? What does a change the solution does not support cost? Custom development usually starts at SAR 50,000; you own the code and build what sets you apart, such as POS integration in your restaurants or corporate meal delivery.

Transport activities, including order delivery through apps, have licences and requirements with the Transport General Authority and other competent bodies, covering the business, the drivers and the vehicles. Restaurants have their own health and municipal requirements. These rules change, and we do not give legal advice. Check with the regulator before you commit to a budget; we build into the system whatever data and reports it calls for.

The first is trying to cover several cities from day one. Delivery makes money on density: many orders in a small area let a driver complete more per hour. One district served well beats a city served slowly. The second is competing with the large platforms on everything, instead of a segment you serve better: one type of restaurant, districts they cover poorly, or corporate meals.

The third is launching before the restaurants are ready: menus with no photos, old prices, and a kitchen that ignores the screen. The fourth is generous opening offers that bring customers who vanish when the offers end. The fifth is neglecting customer and driver data: addresses, mobile numbers and driver locations are personal data under the Personal Data Protection Law, so decide what the restaurant and the driver see of the customer’s data, and how long it is kept.

Ask for a test with three phones: a customer orders, a restaurant accepts, a driver collects and delivers. Then switch off the internet on the driver’s phone for a minute and watch what happens. At Fortune Code we commit to a written delivery date, with fast technical support after launch. The code and accounts are yours, and we send a written proposal within 24 hours that prices each app separately.