What are you actually building in delivery app development for Saudi Arabia?
You are building a small logistics system with three front doors. The customer app places the order, the driver app moves it, and the admin panel decides who takes which job and keeps the money straight. Behind them sits one backend with the orders, zones, drivers, prices and payment records.
Most first-time founders underestimate the admin side. The customer app is what investors see, but the dispatch rules, cash settlement and exception handling (driver cannot find the building, customer not answering, item out of stock) are where operations succeed or fail. In our scoping calls we spend as much time on what happens when things go wrong as on the happy path.
A realistic first version for the Saudi market covers ordering, payments including cash, automatic or manual assignment, live tracking, proof of delivery, ratings and daily cash reconciliation. Loyalty, subscriptions, multi-drop batching and demand-based pricing can wait for version two.
Which delivery model are you: own stock, marketplace, courier or on-demand service?
Decide this first, because it changes the data model and the money flow. There are four common shapes in the Kingdom.
Own stock
You sell and deliver your own products: bottled water, groceries from your dark store, pharmacy items, flowers. One seller, one inventory, simpler payments.
Marketplace
Many restaurants or shops sell through your app and you deliver. You need vendor onboarding, menus per vendor, commission rules and payouts.
Courier or parcel
You move items between two addresses for businesses or individuals. Pricing by distance or weight, pickup scheduling and proof at both ends.
On-demand service
Laundry pickup, gas cylinder refills, car wash at home. Slots and service time matter more than speed.
Each shape asks a different question of the software. Own-stock apps care about inventory accuracy and delivery slots. Marketplaces live or die on vendor onboarding and payout accuracy. Courier apps need pricing that handles distance, weight and waiting time. On-demand services need calendars and service durations. When we scope delivery app development in Saudi Arabia, the model decides which of these gets the most build time.
Mixed models are possible, but start with one. A grocery app that later adds third-party shops is easier to extend than a platform that tries to be everything on day one.
What does the customer app need?
It needs to get someone from hungry or out-of-water to paid order in under a minute. That means a fast home screen, search, a clear cart, saved addresses, one-tap reorder and a checkout with mada and Apple Pay at the top.
Tracking is the second job. After payment, the customer should see order status, the assigned driver's name and vehicle, a moving dot on the map when the driver is on the way, and an estimated arrival that updates. A call or chat button that masks both phone numbers protects driver and customer privacy.
Arabic is the default for most Saudi users, with English one tap away. We build the interface right-to-left from the start rather than mirroring a finished English app, which avoids the broken icons and misaligned prices common in retrofitted apps. You supply or approve Arabic text; we handle the layout and testing.
- Sign-in by mobile number and one-time code
- Address book with national address and map pin
- Order status, live map and estimated arrival
- Ratings, tips and complaints linked to the order
- Order history and reorder
What does a driver app need to survive a real shift?
The driver app lives on a mid-range Android phone, mounted on a dashboard, in afternoon heat, with patchy data between districts. Design for that phone, not the one in the investor pitch.
Core screens: go online or offline, incoming job with pickup and drop-off distance, accept or decline within a timer, navigate (handing off to Google Maps or Waze rather than building navigation), confirm pickup with a photo or code, confirm delivery with OTP, photo or signature, and log cash collected. A daily summary shows trips, earnings and cash to hand in.
Background location is the technical heart. The app must keep sending position while the screen is off, without draining the battery by lunchtime. Google Play requires apps using background location to complete a permissions declaration, show a prominent in-app disclosure and justify it as core functionality, and Apple reviews location use too. We build and document this so your store submission passes.
Driver language matters. Many delivery drivers in the Kingdom are more comfortable in a language other than Arabic or English; the driver app can carry extra languages if you supply the translations.
How does dispatch logic work in a delivery app?
Dispatch decides which driver gets which order, and it is where a delivery app earns or loses money. Start simple and add intelligence only when data proves you need it.
Level one is manual: an operator sees new orders and available drivers on a map and assigns by hand. It works for the first few hundred orders a day and teaches you your real patterns. Level two is automatic nearest-available: the system offers the job to the closest online driver, then the next if declined. Level three adds rules: zones, driver capacity, vehicle type, order readiness times at restaurants, and batching two orders going the same way.
Restaurant and shop readiness is the variable most teams forget. Sending a driver the moment an order is placed means the driver waits fifteen minutes at the counter; sending him too late means cold food. For marketplace apps we let vendors set a preparation time per order, and dispatch offers the job so the driver arrives close to when the bag is ready. For own-stock models the warehouse marks the order packed, which triggers assignment.
Whatever the level, operators need an override button, a view of late orders, and alerts when a job sits unaccepted. We build dispatch as configurable rules in the admin panel so you can change radius, timers and priorities without a developer.
How does live tracking work, and what does it cost to run?
The driver app sends its position every few seconds while on a job; the server stores the latest point and pushes it to the customer's app, which animates the marker. When the order is delivered, tracking stops and the route is saved for dispute checks.
Running costs come mainly from map services. Showing maps, geocoding addresses and calculating distances through Google Maps Platform or a similar provider is billed per use to your account. We keep calls down by caching geocoded addresses, calculating distance only when needed, and updating the customer map at a sensible rate. We will estimate usage for your expected order volume before launch, but the bill comes from the provider, not us.
Real-time messaging needs an always-on connection layer on the server. On a modest cloud setup this is inexpensive at launch volumes; the architecture section below explains how it scales.
How should a delivery app handle Saudi national addresses?
Accept all three ways Saudi customers describe where they are: the full national address, the short address code, or a pin on the map. Drivers lose minutes on every job where the address is a vague district name and a phone call.
The Saudi Post national address has six parts: building number, street, secondary number, district, postal code and city, plus a short address of four letters and four numbers. Saudi Post also offers a National Address API through its data services, which a business can subscribe to for lookups. Where the client has that access, the app converts a short address into coordinates; otherwise we store the pin and the typed address together.
We also save a "notes for the driver" field (gate colour, floor, landmark) and a building photo from past deliveries where your privacy notice allows it. Repeat customers never type their address twice.
How do cash on delivery, wallets and card payments work together?
Offer card and wallet payment up front and cash as an option, then track cash like inventory. Cash on delivery is still expected by many Saudi customers, but it creates two problems: failed deliveries with nothing paid, and cash sitting with drivers.
Card payments (mada, Apple Pay, Visa, Mastercard) go through a licensed provider you contract with; money settles to your company. An in-app wallet lets you issue refunds as credit instantly, and customers can top up. For cash, the driver app records the amount collected on each job, the admin panel keeps a running balance per driver, and the operator marks hand-ins at the end of the shift. Differences show up the same day instead of at month end.
A common rule we implement: cash only for customers with a completed past order, or only below a certain basket size. Your finance team sets the rule; the system enforces it. More detail on provider choice is on our payment gateway integration page.
Do you need a TGA licence to run a delivery app in Saudi Arabia?
Delivery activity in the Kingdom is regulated, and the Transport General Authority (TGA) oversees delivery applications and the drivers who work through them. Which permit your business needs depends on your model, so check directly with TGA and a Saudi lawyer before launch. Getting licensed is your company's responsibility; we are software developers and do not apply for permits or advise on them.
Where rules affect the software, we build to them once you tell us what applies. Typical examples: storing driver identity and vehicle documents with expiry dates, blocking drivers whose documents lapse, keeping trip records for a set period, and exporting reports in a format an authority requests. These are ordinary features for us; what they must contain is decided by your legal adviser.
Personal data is the other rule set. Customer names, phone numbers, addresses and live locations are personal data under Saudi Arabia's Personal Data Protection Law, supervised by SDAIA, and location history in particular deserves care. Our PDPL compliance guide lists what we build to support you: consent screens, minimal retention, access control and deletion requests.
What does delivery app development in Saudi Arabia cost, component by component?
With BtechWaleTech, the customer and driver apps in Flutter start from US$600, and the admin and dispatch backend starts from US$900. A single-seller MVP combines those two; a marketplace adds vendor tools and payouts. Every figure is a starting point confirmed in your itemised quote.
Why a quote can grow: automatic dispatch with batching instead of manual assignment; scheduled delivery slots; multi-vendor commission and payouts; in-app chat; wallets and promo codes; deep reports; several cities with different pricing. Why it can stay lean: launch in one city, manual dispatch, card and cash only, no chat, simple reports.
Running costs belong to you: cloud hosting, map and geocoding usage, SMS for sign-in codes, push notifications, payment fees and developer accounts (Apple US$99 per year, Google Play US$25 once). After two free months of maintenance, care plans start from US$120/mo.
How long does it take to build a delivery app?
Plan roughly eight to twelve weeks for a first version of all three parts, followed by a pilot in one district. Store review adds a few days, sometimes more for a first submission with background location.
- Weeks 1–2: workflows, screens, data model and dispatch rules agreed
- Weeks 3–6: backend, admin panel, customer app core flow
- Weeks 5–8: driver app, tracking, payments, cash ledger
- Weeks 8–10: pilot with real drivers, fixes, store submissions
- Weeks 10–12: launch in the first zone, monitoring and tuning
The pilot is not optional. Ten real drivers for a week will surface more issues than a month of office testing: dead zones, confusing buttons in gloves, address formats nobody expected. We plan fix time for it.
Which technology suits a Saudi delivery app?
Flutter for the customer and driver apps, one codebase for iOS and Android. A Node.js or Python backend with a relational database, a real-time channel for tracking, and a queue for notifications. A web admin in React. This stack is common, well documented and easy to hand to another developer later.
Hosting is your decision with your lawyer, because data location can matter under Saudi rules and for enterprise customers. Major cloud providers now offer regions in or near the Kingdom; we set up on whichever your counsel approves. Maps come from Google Maps Platform or an alternative provider through your own billing account.
Scaling is planned, not bought up front. At launch one application server, a managed database and a small real-time service handle a single city comfortably. As orders grow, the parts that feel pressure first are location updates and notifications, so those sit behind a queue and can be scaled on their own without touching ordering or payments. We add read replicas for reports, cache menus and zone data, and set alerts for slow checkout or unassigned jobs. Spending on heavy infrastructure before you have the orders to fill it is one of the quieter ways delivery start-ups run out of money.
We avoid exotic choices. A delivery platform will be maintained for years, possibly by people who are not us, and boring, popular tools make that possible. If you want the mobile side explained further, see hiring a Flutter developer for Saudi projects.
How are the apps published on the App Store and Google Play?
Under your company's developer accounts, never ours. You open an Apple Developer account (US$99 a year) and a Google Play Console account (US$25 one-time) in your company name; we are added as team members to upload builds.
Delivery apps get extra scrutiny on location. For the driver app we prepare the background location declaration and demonstration video Google Play asks for, write the in-app disclosure, and state the reason in plain words. For the customer app, location is only used while the app is open. Store listings can be in Arabic and English; you approve the Arabic text.
Plan one to two weeks for first-time reviews. After that, updates usually pass faster because the declarations are already on file.
What is it like to build a Saudi delivery app with a team in India?
The overlap is generous: India is two and a half hours ahead of Saudi time, so a 9 am Riyadh stand-up is 11:30 am for us and a late issue reported at 7 pm your time reaches us at 9:30 pm. We plan sprint reviews on Sundays or Mondays to match your working week and avoid shipping driver-app updates right before the weekend rush.
During the pilot we watch dashboards in your peak hours. Pricing is in US dollars, the invoice comes from India, and payment is by Wise or bank wire at the milestones set in the written quote. We do not have a Saudi office or entity and cannot visit your warehouse, so field testing is done by your drivers with us on a call.
The first fortnight: a long scoping call on your model and operations, an itemised quote within about two working days, then after approval a clickable prototype of the three apps by the end of week two. One of us builds, another of us sets up cloud, maps and data, and the third of us keeps the plan and your weekly review on track.
What are the red flags when hiring for delivery app development in Saudi Arabia?
The most expensive mistake is buying something you cannot change or leave. Be wary of any offer for delivery app development in Saudi Arabia that shows a finished app on day one at a surprisingly low price, then licenses you encrypted code, charges yearly renewals, or keeps the store accounts in the vendor's name.
- Store accounts or servers registered to the developer
- Source code you cannot read or move
- No plan for background location approval in the stores
- Dispatch that cannot be changed without paying the vendor
- No cash reconciliation, only card payments demoed
- No pilot phase in the plan
- Promises about licences or permits a developer cannot give
A good sign is the opposite: a developer who asks about failed deliveries, cash differences and driver churn before talking about colours and logos. Ask to see how a previous admin panel handles a cancelled order after pickup, and ask who will fix the driver app when a new Android version changes location permissions. If the answers are vague, the maintenance bill later will not be.
Example: a bottled-water delivery start-up in Riyadh
Picture a hypothetical start-up delivering bottled water and dispensers across four Riyadh districts from one warehouse, with twelve drivers on vans. Orders are heavy and repeat weekly; many customers pay cash; apartment deliveries need floor numbers and building access notes.
Version one: a customer app with subscription reorder every week or two, address book with national address and building notes, card, Apple Pay and cash; a driver app with route order for the day, proof of delivery photo and cash log; an admin panel with manual assignment by district, daily cash settlement and empty-bottle returns tracking. Mobile apps from US$600 plus the backend from US$900, about ten weeks including a one-week pilot.
Version two, once weekly volumes justify it: automatic route ordering by district and time slot, and WhatsApp reminders before scheduled deliveries. The founder handles the TGA and commercial licensing questions with a local lawyer in parallel with the build.