Delivery app development in Saudi Arabia: the parts the customer never sees, and that decide the project

When a client comes to us wanting "a delivery app", the first thing they show me is the customer app design: the home screen, the menu, the basket, the order button. Nice. But that is the part the customer sees, and it is the part that least decides whether the project succeeds.

What decides it: does the driver receive the order quickly, or does it get lost? Does operations know where every driver is? Does the cash the driver collected match the orders at the end of the day? Does the customer see the order on a map, or call to ask?

We have built apps with a customer side, a technician side and an operations dashboard, and this post is about the parts you should think through before drawing a single customer-app screen. And if you are still asking "how much does it cost?", read how much mobile app development costs first.

A delivery app is three apps, not one

1. The customer app: orders, pays, tracks.
2. The driver app (or courier, or technician): receives the order, navigates, delivers, proves delivery.
3. The dispatch dashboard: sees everything, assigns, resolves problems, reports.

Under all three sits one backend that holds orders, states, locations and payments. Any proposal that talks about "an app" in the singular has not understood the project.

Part 1: the driver app

This is where we start, because without it there is no delivery. The driver uses it all day, on a mid-range phone, sometimes in the sun with a weak connection. What it must do:

• Receive orders with a clear notification, accept or decline, and a time limit to respond.
• Order details readable at a glance: address, customer, items, payment method.
• Navigation with one tap that opens Google Maps or similar at the right location.
• Status updates with big buttons: picked up, on the way, arrived, delivered.
• Proof of delivery: a photo, a signature, or a code the customer gives.
• Cash: how much collected today, how much to hand in, end-of-day settlement.
• Works on a weak connection: stores updates and sends them when the connection returns.
• Background location for tracking, with battery in mind.

Screens here must be few and large. The driver does not read; they tap.

Part 2: the dispatch dashboard

The operations centre. Whoever sits at it sees:

• Live orders on a map and a list, with their states.
• Drivers, where they are, who is available, who is loaded.
• Assignment: manual (drag the order onto a driver), automatic (nearest available driver), or a mix.
• Zones and pricing: delivery boundaries, price per zone, surcharges.
• Problems: a late order, a driver not responding, a customer not answering.
• Reports: today's orders, average delivery time, cash collected, performance per driver.

The dashboard runs in the browser and works on a phone, because the operations manager is not always at a desk.

Part 3: the customer app

Now the part people see. Deliberately simple:

• Phone sign-in with a verification code, no long forms.
• Ordering: products or a service, the location on a map (with saved addresses), a delivery time if there is a choice.
• Payment: mada, Apple Pay and cards, or on delivery. We covered the options in payment gateways in Saudi Arabia.
• Tracking: order status, the driver's location on the map, and the expected time.
• Notifications: in the app and on WhatsApp. Many customers never open the app but do read WhatsApp.
• Rating after delivery.

And at the start you can skip it: customers order from WhatsApp or the website while the driver app and dashboard run in full. We discussed this in app or website.

Part 4: the backend and integrations

• Order states mapped clearly: new, accepted, on the way, done, cancelled, failed, and who may move an order from one state to another.
• Payment with server-side confirmation rather than the browser, and reconciliation.
• Maps for distance, time and price.
• Messaging for verification and notifications.
• A link to Odoo or your accounting and inventory system if you have one, so an order produces an invoice and reduces stock with no manual entry.

Is a ride (passenger) app the same?

Roughly. A rider instead of a customer, a driver, and operations. The differences are live distance and time pricing, matching the nearest driver quickly, and transport regulator requirements you must confirm before you start, because they dictate things inside the app itself.

The mistakes we see

• Starting with the customer app and leaving the driver for last. The result: a pretty app with nobody to deliver.
• Complex automatic assignment from day one. Start manual with suggestions, and automate once you understand order patterns.
• Ignoring cash. Most delivery in Saudi Arabia still involves payment on delivery, and settlement that does not reconcile eats the margin.
• Assuming the driver app always has a connection.
• Launching across the whole city at once. One district or a small driver team first.

The short version

A delivery app is three apps on one system: driver, dispatch, customer, in that order. The parts the customer never sees (the driver app, assignment, cash settlement, tracking) decide the project, and the customer app comes last, sometimes later.

See the delivery and transport apps page for what we build, or book a free consultation and we will map your order journey from start to delivery.