Own Delivery App vs Aggregators: The Real Cost for UAE Restaurants
Aggregators bring volume and take a heavy cut. Your own app keeps the margin but needs demand, riders and technology. Here is how the maths actually works.
By Baxance Team
Product
Forex CRMForex CRM SoftwareForex CRM FeaturesForex Broker CRMForex Broker SoftwareBrokerage SolutionsWhite-Label CRMAll FeaturesSolutions
Trader’s RoomForex Back OfficeIB ManagementLead ManagementAffiliate ManagementCRM for Prop FirmsAggregators bring volume and take a heavy cut. Your own app keeps the margin but needs demand, riders and technology. Here is how the maths actually works.
By Baxance Team
Every restaurant and grocer that does volume on a delivery aggregator eventually does the same sum. They look at a month of orders, multiply by the commission rate, and the number is large enough to fund something. The obvious conclusion — "we should build our own app and keep that" — is sometimes right and sometimes an expensive mistake. The difference comes down to a question most people skip: where does your demand actually come from?
This is not an argument for or against aggregators. It is the honest maths of what you keep, what you give up, and what you have to replace if you leave.
Aggregator commission feels like a tax, but it is not only a fee — it is payment for three things bundled together: demand, riders, and technology. The commission buys you a stream of hungry customers who found you in the app, a fleet that delivers without you employing anyone, and the ordering-and-tracking software that makes it all work.
When you decide to leave, you are not only reclaiming margin. You now need all three of those yourself. Miss any one and the economics collapse. This is why "build our own app" fails so often: teams budget for the app and forget they have also just taken on marketing and logistics.
Everything turns on this. If most of your orders come from customers who discovered you inside the aggregator — who were browsing for "burgers near me" and picked you — then leaving is a demand problem before it is anything else. Take those customers off the app and most of them do not follow you; they order the next burger in the list. You would be walking away from the very thing the commission pays for.
If most of your orders come from customers who already know you — regulars, a strong local brand, people who would happily order direct if it were easy — then the aggregator is largely charging you commission to serve customers you brought. That is the case where your own channel pays off quickly, because you keep the margin on demand you already own.
Most established restaurants and grocers are somewhere in between, which is why the smart move is usually not "leave" but "add."
An aggregator sends you customers; your own app does not, until you make it. You will need marketing to drive installs and repeat orders — and the most valuable tool here is the one an aggregator never gives you: a direct line to your customers through push notifications, which reach the phone for free where every aggregator message and paid ad costs money. But that only works after people have installed the app, which is itself a marketing job.
You now need delivery to happen. That is either your own riders (employed or contracted) or a third-party logistics provider you pay per drop. Either way you need the software to dispatch and track them — which is a real system, not just a map. This is the part that most surprises restaurants: a customer app is the visible half; the rider and dispatch side is where the operation actually runs or fails.
The customer ordering app, the rider app, and the dispatch dashboard behind them. Built as one system they connect; bought as three disconnected pieces they leak orders. This is buildable and increasingly standard, but it is a project with a running cost, not a one-off.
Forget the headline commission number and run three figures instead. First, cost per delivery on your own channel — rider time, vehicle or contractor fee, and the amortised technology. Second, deliveries per rider-hour, because a rider standing idle between orders is pure loss. Third, and most important, how much batching lifts that number — combining several orders heading the same way into one trip is where delivery economics are usually won.
Then compare cost-per-delivery on your own channel against the aggregator's commission per order. If your own cost is comfortably below the commission and you can keep riders busy, building pays. If your orders are sparse and spread across a wide area, riders sit idle, cost-per-delivery balloons, and the aggregator's shared fleet is genuinely cheaper than yours will ever be. Dense, clustered demand favours building; thin, scattered demand favours staying.
The framing as a binary is where restaurants go wrong. Aggregators are excellent at one thing you cannot easily replicate: discovery. New customers find you there. Your own app is excellent at a different thing: retention at full margin from customers who already chose you.
So the pattern that works for most established brands is a hybrid. Keep the aggregators for discovery and the occasional order — treat that commission as a customer-acquisition cost. Push your regulars to your own app with better prices, loyalty and speed, and serve them there at full margin. Over time the share of orders on your own channel grows, and you have moved the profitable half of your business off the tax without losing the discovery engine. You are not leaving the aggregator; you are refusing to pay it commission on customers it did not bring.
The app itself often is, but the app is only one of the three things the commission pays for. You also take on demand generation and delivery logistics. Count all three before comparing to commission — leaving out marketing and riders is the most common budgeting error.
Three connected products: a customer app to order and track, a rider app to accept and complete jobs, and a dispatch dashboard to assign work and handle exceptions. Built together they share one source of truth; see delivery app development.
No. Both can run on the same catalog, stock and orders. An online store serves browsers and scheduled orders; a delivery app serves on-demand local orders; a shopping app drives repeat purchase. See the full picture in e-commerce solutions.
Batching and sensible dispatch. Combining nearby orders into one trip lifts deliveries per rider-hour sharply, which is the number that decides whether your own delivery is cheaper than an aggregator's shared fleet. It has to be balanced so the last customer in a batch still gets fresh food.
Get in touch
Whether you’re researching or ready to move, there’s a way in that fits.
See it working
A live walkthrough with a specialist, set up around how your business actually operates.
Book a demoPlan your setup
Discuss your requirements, timeline and what launching would involve — before committing to anything.
Start a conversationJust one question?
Get a straight answer from a person, with no form to fill in and no follow-up sequence.
Open WhatsAppA store sells your inventory. A marketplace sells inventory from other sellers and takes a cut. The operational and software differences, and how to tell which you are.
ComparisonsAn app is not a better mobile site. It is a bet on repeat purchase. How to tell whether your customers will ever install one, before you pay to build it.
GuidesA marketplace is not a bigger store — it is a supply, payout and trust problem wearing a storefront. Here is what it actually takes to build one that works.