What actually drives the cost of a delivery or booking app here?

The number of sides, and the obligations attached to the one that does the work. A customer app on its own is the smallest piece; add a worker app and an operations console and you have three surfaces sharing one order state, which is where the engineering is. Then add what the platform has to hold about a licensed worker, and a ledger that reconciles cash as well as cards. We scope the two sides separately so you can fund the one you do not have, rather than paying for both at once.

We were quoted a clone of a well-known delivery app. What is wrong with that?

It copies the half that was never the hard part. A clone reproduces a customer app and a driver screen from a product as it looked years ago, and the company being copied has moved on a long way since: the best-known one here has been listed on the Dubai Financial Market since December 2024, with published accounts and a scale a template does not reproduce. What a clone does not carry is your operation: the permit and training records of the people doing the work, a ledger that reconciles, and a dispatch rule you can change. Where you are still testing whether anyone wants this, a template is a defensible way to find out. Once there are riders on the road it is not.

Do our riders need permits, and is that our problem or theirs?

Both, and the platform ends up holding the record. In Dubai a delivery rider needs an RTA Delivery Driver Qualification Certificate, obtained through training at an authorised institute, available to drivers aged 21 to 55 and valid for one year. The vehicle is a separate obligation on the registration renewal cycle, so there are two dates per rider rather than one. Since 1 November 2025 delivery riders are also kept out of the two leftmost lanes on roads of five lanes or more, and out of the leftmost lane on roads of three or four lanes, with no restriction where there are two lanes or fewer. An operator who cannot show a current certificate has a problem the app should have prevented.

Can we launch with the customer app first and add the worker app later?

Only if you already have the supply and a way of dispatching it. A customer app in front of a WhatsApp group works for a while and it is a reasonable first release, because the jobs still reach someone. The reverse does not: a worker app with no demand behind it is a tool nobody opens. So the build order follows whichever side you already have, and we ask which that is on the first call rather than assuming a consumer launch.

We hold a free zone licence. Does that change what the app may do?

It can, and it is worth settling before the build rather than after the first delivery. The federal law on trade by modern technological means brings free zone entities into scope where goods or services bought through the platform are supplied outside the zone, so a free zone operator delivering into the mainland is not outside the rules by virtue of the licence. What the licence permits you to sell, and to whom, is the operating fact underneath the whole product. We ask for it on the first call, because it shapes the categories before it shapes the code.

Should we build our own app or stay on the aggregator?

Stay, unless you already have repeat customers and either a fleet or a credible way to get one. An aggregator sells you demand and keeps the customer relationship, which is a fair trade while you have no other way to reach people. Your own app changes that and hands you an operation to run, including the licensed half. The honest test is whether enough of your orders come from the same people twice, and we will do that arithmetic with you and say so if it does not add up.

How do payouts to drivers and vendors work here?

As a ledger, and it is the part most platforms get wrong first. Money comes in on one order and goes out in two directions, to the vendor and to whoever delivered, with a commission retained in between and cash collected on the road complicating all of it. The workable shape is to record movements rather than balances, so a disputed payout is answered by reading back the history of an order instead of trusting a total on a screen. Which gateway moves the money is a separate decision and it follows your banking rather than our preference.

On-demand app development · UAE

On-demand apps that handle drivers and dispatch.

The customer app is the half every quote covers. The operation behind it decides whether the product can run, and in this market the people doing the work are licensed before they are user records.

Scope the two sides separately

What on-demand app development is

What on-demand app development involves.

A booking, a job and a settlement, in that order. The middle one is an operation rather than a screen, and it is where a quote is usually silent.

The customer app.

The customer app, and the aggregator that already holds the customer you are trying to reach. This is the half every quote covers, and it is the half a clone script can genuinely imitate.

The driver app.

The rider, driver or technician doing the work. Here they are a certified, trained person before they are a record in your database, and what the regulator asks of them becomes something your platform holds, on the regulator’s renewal cycle rather than yours.

Getting everyone paid.

Money arrives in one direction and leaves in two, to the vendor and to the person who delivered. That is a ledger, not a payment integration, and it is the part that has to reconcile every week.

The scope

Six kinds of on-demand app.

Six models, and the customer app is the least different thing about them. What separates them is who does the work and what that person needs before they can.

Rides and transport.

A live map, a dispatch rule and a fare the passenger sees before they accept it

Output

a matching engine, and a driver register that can show a permit is current

DispatchLive map

Delivery and courier.

Assignment, routing and proof of delivery against a place rather than a written address

Output

an order whose state is the same on the rider’s phone and in the office

RoutingProof

Home and field services.

Booked slots, a technician with the right trade and a job sheet signed on site

Output

dispatch that replaces a supervisor deciding by phone each morning

SlotsJob sheets

Healthcare on demand.

Home visits and consultations booked against a licensed practitioner, with the record kept where the health authority expects it

Output

a booking product a clinic can actually operate

LicensedRecords

Grocery and quick commerce.

Live stock, a picker queue and a delivery slot the customer chose rather than one you promised

Output

the operations side of a fast order, which is the side that fails

Live stockSlots

Many vendors, with payouts.

Several vendors, one order, and a weekly split that has to agree with what was collected

Output

the ledger, which is the part of a marketplace nobody demos

VendorsPayouts

Purpose-built, or a clone

What a clone script misses here.

A clone demonstrates well, because the customer app is the copyable half. The five rows below are the half that decides whether it can be operated here.

	A clone scriptA template, named after the incumbent	A purpose-built stackBuilt around the operation you run
When the rules change	A vendor release, if the vendor has other customers who care.	A change you schedule, because the rule is a field you already hold.
The permit register	A text field, if there is one, and nobody watching the expiry.	Certificate and vehicle renewal held per rider as two dates, with expiry alerts.
The payout ledger	A payouts screen that shows totals and cannot be audited back.	Every movement traceable from the order to the transfer, and reconciled.
A second emirate	A configuration nobody documented, changed by the vendor.	A zone, its own rules and its own supply, added without a rebuild.
Who owns the dispatch	The vendor. The matching logic is the product they sell to everyone.	You do. The rule that decides who gets the job is yours to change.

When a clone makes sense.

When you are testing whether anyone wants this at all, and you would rather find out for the price of a template than the price of a build. That is a real answer and we will give it. It stops being the right call the moment there are riders on the road, because from then on the platform is holding obligations a template was never designed to carry. Whether this needs to be an app at all is a question before either, and the pillar sets out what year two costs.

What we find on on-demand work here

The regulated half most quotes leave out.

Webzenia has worked with Gulf clients since 2018. Four things about running an on-demand product here, and only one of them is software.

01of 04
The supply side is licensedBefore it is a user record
Delivery riders here need certification and permits.
Dubai’s RTA issues a Delivery Driver Qualification Certificate after training at an authorised institute, valid one year. The vehicle is a second obligation on its own renewal cycle. A Deira logistics and courier operator on a mainland licence tracks two expiries per rider, and a platform showing neither has a compliance gap.
Our methodCertificate and vehicle renewal held per rider as two dates, with expiry surfaced.
02of 04
A clone of what, exactlyThe incumbent has moved
Clone scripts copy a feature list from years ago.
Talabat has been listed on the Dubai Financial Market since December 2024, with published accounts and a scale no template reproduces. A Business Bay facilities-management company on a mainland DET licence, quoted a home-services clone, is being sold a 2019 interface rather than a business model.
Our methodThe model argued from your own unit economics, never from an incumbent’s screens.
03of 04
Cash is still on the roadAnd it has to reconcile
Cash on delivery means riders carry float.
A Sharjah grocery chain on a mainland licence running its own delivery is reconciling collected cash against orders every shift, by hand. That is a ledger problem wearing a delivery app, and a platform that only records card payments has quietly left the hardest half in a notebook.
Our methodCash collected, float held and settlement recorded per rider, per shift.
04of 04
The two sides are never equalAnd that sets the order
You will start with one side, not both.
An operator with technicians and no customers is buying a booking product; a brand with customers and no fleet is buying an operation it may not want to own. The failure modes are opposite, and a quote that prices both sides at once has not asked which one is already there.
Our methodThe two sides scoped and costed separately, in the order the business needs them.

What the engagement covers

Inside a two-sided build.

Six stages, and the first two are about the operation rather than the interface. The screens are quick once the model and the obligations are settled.

Your model and its obligations.

Who does the work, on whose licence, under which regulator, and what has to be held about them. That list prices the build and sets the date more than the feature list does.

Model
Obligations

Two apps and one console.

The customer app, the worker app and the operations console, built as one system with one order state. Three products with three views of an order is how a dispatch board and a phone disagree.

Two sides
One state

Matching, tracking and payouts.

The rule that assigns a job, the live state both sides can see, and money in one direction and out in two. The ledger is built with the reconciliation in mind rather than after the first dispute.

Dispatch
Ledger

Tested on the road.

Real handsets, a real route and a real handover, because a dispatch product fails on a lift with no signal and a phone at 4% rather than in a browser on a laptop.

Real routes
Real handsets

Launch in one emirate first.

Both store submissions, then a deliberately narrow start: one category in one emirate, with a person watching the dispatch board, so the first exceptions are found by us rather than by a customer.

Narrow start
Watched

Handover, then widen carefully.

Code, documentation and the dispatch rules written down, then a second category or a second emirate added against evidence rather than ambition. Each widening is a decision, not a default.

Documented
Widened

Our stack

The dispatch tools we use.

A place, a live state, a way to reach each other, a ledger and a worker app. Select one to see what it has to survive.

Google Maps

Why Google Maps

Every part of this product is a place: where the job is, where the worker is, and how long between them. In a country with no postal codes that has to be a coordinate rather than a written address.

How we excel

We route against the place the worker will actually navigate to, and store it as a location rather than a paragraph, so a delivery point survives being handed from one rider to another.

Routing qualityWorks without a postcodeLocation

Google MapsA place

MapboxA place

A typed addressText

A phone callA person

How the build runs

From the rules to a live fleet.

The first fortnight is spent on the operation rather than the product. What the regulator asks of your workers sets the date before the feature list does.

01Weeks 1 to 2Scoped

Settling the model and the rules.

We establish who does the work and on whose licence, what the regulator requires of them, and what the platform therefore has to hold and check. In the same fortnight we settle which side you already have, because a business with a fleet and no customers is a different build order from one with customers and no fleet. Both answers price the work more than the screens do.

Obligationsnamed before a date is given
Build orderset by the side you have
Ledgerdesigned with the model

02Weeks 3 to 12Built

Building both apps and the ledger.

The customer app, the worker app and the operations console are built as one system, so a job has one state rather than three opinions of it. The matching rule is written down and yours to change. The ledger records movements rather than balances, and it is proved by reconciling a week of test orders including cash, before anything reaches a customer.

Order stateone, shared by both sides
Dispatch rulewritten down and yours
Ledgerreconciled on test orders

03Month 4 onwardRunning

Launching in one emirate.

The launch is narrow on purpose: one category, one emirate, with somebody watching the dispatch board so the first exceptions are found by the team rather than reported by a customer. Widening is then a decision each time. A second emirate is a new supply pool and its own rules rather than a configuration change, and a second category is a different operation wearing the same app.

Launchone category, one emirate
Exceptionswatched, not reported
Wideninga decision, never a default

Costed as two products, so the fleet half is a line you can read rather than an assumption.

Both sides, in writing

Two sidesPermit registerReconciled

Our commitment

Four promises about the fleet.

An on-demand product fails on the road and in the ledger, not in the interface. These four are written into the scope because that is where it fails.

We name the licensing rules before quoting.
What the regulator asks of the people doing the work, and what the platform therefore has to hold, is established in the first fortnight. A date quoted before that is a date neither of us can hold.
Payouts reconcile and you can audit them.
Every movement is traceable from the order to the transfer, cash included. A payouts screen that shows a total and cannot be read backwards is not a ledger, and it is the thing a vendor dispute lands on.
The dispatch logic belongs to you.
The rule that decides who gets the job is written down, documented and yours to change. On a template that rule belongs to the vendor and is the same one every one of their customers runs.
We say when an aggregator suits you better.
For some operators the listing is the least expensive demand they will ever buy, and their own app would not pay for the fleet behind it. That answer comes with the arithmetic, at the end of the first fortnight.

Common questions

On-demand apps, answered.

The number of sides, and the obligations attached to the one that does the work. A customer app on its own is the smallest piece; add a worker app and an operations console and you have three surfaces sharing one order state, which is where the engineering is. Then add what the platform has to hold about a licensed worker, and a ledger that reconciles cash as well as cards. We scope the two sides separately so you can fund the one you do not have, rather than paying for both at once.
FAQ · 01
It copies the half that was never the hard part. A clone reproduces a customer app and a driver screen from a product as it looked years ago, and the company being copied has moved on a long way since: the best-known one here has been listed on the Dubai Financial Market since December 2024, with published accounts and a scale a template does not reproduce. What a clone does not carry is your operation: the permit and training records of the people doing the work, a ledger that reconciles, and a dispatch rule you can change. Where you are still testing whether anyone wants this, a template is a defensible way to find out. Once there are riders on the road it is not.
FAQ · 02
Both, and the platform ends up holding the record. In Dubai a delivery rider needs an RTA Delivery Driver Qualification Certificate, obtained through training at an authorised institute, available to drivers aged 21 to 55 and valid for one year. The vehicle is a separate obligation on the registration renewal cycle, so there are two dates per rider rather than one. Since 1 November 2025 delivery riders are also kept out of the two leftmost lanes on roads of five lanes or more, and out of the leftmost lane on roads of three or four lanes, with no restriction where there are two lanes or fewer. An operator who cannot show a current certificate has a problem the app should have prevented.
FAQ · 03
Only if you already have the supply and a way of dispatching it. A customer app in front of a WhatsApp group works for a while and it is a reasonable first release, because the jobs still reach someone. The reverse does not: a worker app with no demand behind it is a tool nobody opens. So the build order follows whichever side you already have, and we ask which that is on the first call rather than assuming a consumer launch.
FAQ · 04
It can, and it is worth settling before the build rather than after the first delivery. The federal law on trade by modern technological means brings free zone entities into scope where goods or services bought through the platform are supplied outside the zone, so a free zone operator delivering into the mainland is not outside the rules by virtue of the licence. What the licence permits you to sell, and to whom, is the operating fact underneath the whole product. We ask for it on the first call, because it shapes the categories before it shapes the code.
FAQ · 05
Stay, unless you already have repeat customers and either a fleet or a credible way to get one. An aggregator sells you demand and keeps the customer relationship, which is a fair trade while you have no other way to reach people. Your own app changes that and hands you an operation to run, including the licensed half. The honest test is whether enough of your orders come from the same people twice, and we will do that arithmetic with you and say so if it does not add up.
FAQ · 06
As a ledger, and it is the part most platforms get wrong first. Money comes in on one order and goes out in two directions, to the vendor and to whoever delivered, with a commission retained in between and cash collected on the road complicating all of it. The workable shape is to record movements rather than balances, so a disputed payout is answered by reading back the history of an order instead of trusting a total on a screen. Which gateway moves the money is a separate decision and it follows your banking rather than our preference.
FAQ · 07

Keep exploring

Explore Mobile App Development

Part ofMobile App Development

iOS App Development

Native Swift, and the entity Apple publishes as seller.

Android App Development

Kotlin, and the five manufacturer skins this market runs.

Cross-Platform Apps

One codebase, and the parts written per platform.

Flutter Development

One widget tree, and an Arabic screen that mirrors itself.

React Native Development

For teams that already write React and have to hold it.

eCommerce App Development

A shopping app costed against the repeat order.

Enterprise App Development

Internal apps for staff who are not at a desk.

SaaS App Development

Subscription products whose customer is a licensed company.

App UI/UX Design

A component system engineering builds from, in both directions.

Next step

Get your on-demand app scoped.

Send us what has to move and who moves it today. We will come back with the two sides costed separately and the obligations that sit outside the code.

Tell us what you need.

What on-demand app development involves.

The customer app.

The driver app.

Getting everyone paid.

Six kinds of on-demand app.

Rides and transport.

Delivery and courier.

Home and field services.

Healthcare on demand.

Grocery and quick commerce.

Many vendors, with payouts.

What a clone script misses here.

The regulated half most quotes leave out.

Delivery riders here need certification and permits.

Clone scripts copy a feature list from years ago.

Cash on delivery means riders carry float.

You will start with one side, not both.

Inside a two-sided build.

Your model and its obligations.

Two apps and one console.

Matching, tracking and payouts.

Tested on the road.

Launch in one emirate first.

Handover, then widen carefully.

The dispatch tools we use.

From the rules to a live fleet.

Settling the model and the rules.

Building both apps and the ledger.

Launching in one emirate.

Four promises about the fleet.

On-demand apps, answered.

Explore Mobile App Development

iOS App Development

Android App Development

Cross-Platform Apps

Flutter Development

React Native Development

eCommerce App Development

Enterprise App Development

SaaS App Development

App UI/UX Design

Get your on-demand app scoped.