Talabat Clone Features: A Market Is a Zone, Not a Deployment
Most delivery platforms treat a country as a fork. Here a market is a polygon drawn on a map carrying its own charges, its own cash ceiling, its own subset of the thirteen gateways, its own language and its own notification wording. Cairo, Riyadh and Dubai can run different rules on the same codebase, and adding the fourth is an afternoon in the console rather than a second engineering programme.
Request a Live Demo →Full OverviewFeature Set by Role
Five surfaces over one Laravel backend, each of them aware of which market it is currently in.
The Customer
They set an address and get only the restaurants that deliver there, with the charge that applies in that area rather than a national figure. Search by dish, restaurant or cuisine with filters for rating, price and delivery time, then order for delivery, collection or a table, paying by card, wallet or cash depending on what their market offers.
The Restaurant
Menus, variations and add-ons edited by the restaurant itself, its own opening hours and holiday schedules, items marked sold out in one tap, staff logins beneath the owner, and its own earnings and payout history. A restaurant in one market never sees or affects a restaurant in another.
The Cash Rail
Cash on delivery treated as a first-class payment method rather than a fallback, because in much of this region it is what makes a first order possible at all. Ceilings are set per zone and per delivery partner, and what was collected is reconciled against what was expected instead of assumed.
The Delivery Partner
Assigned orders within their own zone, navigation to pickup and drop-off, proof of delivery at the door, and a running view of earnings and the cash they are carrying against their limit. Partners are filtered by zone before assignment, so dispatch cost stays bound to the area rather than to the size of your fleet.
The Country Manager
Console roles scoped so a manager reaches their own market and nothing beyond it. They draw coverage, set the charges, choose which gateways their customers see, edit the notification wording in their own language, and watch dispatch and cycle time for the area they are accountable for.
The Group Finance Desk
Scheduled disbursement across every market, computed from what was actually charged at the time, with overlap locks so a slow run never pays twice. Sales, commission, payout and tax reports export per market or across the estate, and a rate changed in one country leaves every other country's history untouched.
Staff accounts carry granular module permissions on top of market scope, so support sees orders, finance sees payouts, and nobody reaches everything by default.
Clone vs Generic Script vs a Fork per Country
Most routes to a multi-market delivery platform hold up until the second country.
| What decides it | Miracuves Talabat Clone | A deployment per country |
|---|---|---|
| Opening a new market | Draw a polygon, set its charges | Another install, another upgrade path |
| Different payment mix per country | Enable a subset of thirteen per zone | Whatever each fork happened to configure |
| Arabic and right-to-left | In the storefront build already | Retrofitted, usually badly, per fork |
| Cash on delivery | Ceilings per zone and per partner, reconciled | A checkbox, with exposure nobody measures |
| Changing a rule everywhere | One settings key, one deployment | The same change made three times |
| Group-level reporting | One schema, so the estate adds up | Three databases and a spreadsheet |
| App store presence | A listing per market from one codebase | Separate codebases drifting apart |
| Source code | Yours outright, no per-order royalty | Often limited, sometimes encrypted |
Talabat itself is the reference for what this category looks like in the region; it is not a product you can buy or self-host. The useful comparison is the second column against the third, and against a custom build, which is covered on the Development Cost page.
How It Works, End to End
Seven stages, each one aware of which market the order belongs to.
The address decides the market
Coverage resolves from zone polygons rather than from a city field on a form. Which restaurants appear, what delivery costs, which payment methods show at checkout and which riders can be assigned all follow from the geometry the customer is standing inside.
They read it in their own language
The storefront runs on Next.js with MUI and Redux Toolkit carrying internationalization and right-to-left support in the build. Push, mail and SMS wording lives in editable templates keyed by message and user type, so an Arabic-first market is a language pack and a content pass rather than a second front end.
They build an order
Sizes, crusts, toppings, extras and allergen notes are modelled as variations rather than separate products, with daily stock counters and one-tap sold-out. The same catalogue machinery carries groceries, pharmacy lines and parcels when a market wants more than restaurants.
They pay the way their market pays
Thirteen gateways ship, and which subset a market offers is a setting. A country where cards dominate and a country where cash does can run side by side, with wallets and operator-defined offline methods alongside. Split tender is recorded as separate payment legs rather than one blended total.
Cash is counted, not assumed
Where the order is cash, a ceiling applies per zone and per delivery partner, and a partner over their limit stops being assigned cash orders until they settle. Collected cash is reconciled against what was expected, so exposure is a number on a screen while it is still small.
The restaurant and the rider work it
The order lands on the store board, is accepted and prepared, and each transition writes its own named timestamp. Delivery partners are filtered by zone before assignment, follow navigation to both ends and close the job with proof of delivery at the door.
The market settles on its own terms
Commission percentage and discount split are frozen onto the transaction row, and item revenue reads the order line rather than the current menu price. Disbursement runs on your cadence with overlap locks, and a rate you change in one country next month leaves every completed order in every country exactly as it was.
Offers, loyalty points, wallet credit and campaigns run alongside the whole loop, and a campaign can be scoped to a single market rather than fired across the estate.
Every Feature Earns Its Place
Each row is here because a multi-market operator stops working without it, not because a competitor lists it.
| Module | Why it is in the base build |
|---|---|
| Zones as coverage geometry | A city stored as a string cannot tell you whether an address is inside your delivery area. A polygon can, and it is what makes a customer outside the map unable to place an order you would lose money carrying. |
| Payment methods per market | The rail that works in Cairo is not the rail that works in Kuala Lumpur. Enabling a subset of the thirteen per zone is what lets one platform trade in both without either market seeing a checkout full of options it cannot use. |
| Cash ceilings and reconciliation | Where card penetration is low, cash is the majority of orders rather than an edge case. Limits per zone and per partner, checked against what was actually collected, is the difference between an operating model and an unmeasured liability. |
| Right-to-left in the storefront | Retrofitting right-to-left after launch touches every layout decision already made. Shipping it in the build is the reason an Arabic-first market costs a content pass instead of a rebuild. |
| Notification templates as data | Every market reads in its own language and its own tone. Wording held as editable templates keyed by message and user type means a translation is admin work rather than a release. |
| Commission frozen at settlement | A group operating in four countries changes rates constantly. Freezing the percentage onto the transaction row is what stops one market's pricing decision rewriting another market's closed quarter. |
| Overlap locks on payout runs | Disbursement across an estate touches every restaurant and rider at once. A lock is the difference between a slow run and paying an entire country twice. |
| Market-scoped staff access | A country manager needs their market and no more. Console roles scoped that way are what let you hire locally without handing every new manager the whole group's payouts. |
Three additional Laravel modules sit beside the core and matter differently across an estate: tax computed per order and exported per market, an ordering assistant, and a short-video feed whose content can be scoped to the country it was made for.
The Technology Behind the Features
Conventional and easy to hire for in every market you are likely to operate in.
Every business rule lives in the one Laravel application, with the five surfaces sitting over a single versioned API. That means one deploy, one schema and one set of rules across every country, which is exactly what a fork per market gives away.
What Is Not Included in the Base Package
A fixed price only means something if the boundary around it is stated, and on a multi-market build two of these matter more than the rest.
A zone is not a legal entity
The platform models markets, not companies. If your Egyptian operation must invoice as an Egyptian entity with its own tax registration and its own numbering, that is a corporate structure question the software does not answer, and it is scoped work rather than a settings tab.
Balances in several currencies
Pricing and collection per market are handled. Holding operator or vendor balances in more than one currency at once, and reconciling movements between them, is a genuine extension rather than a configuration choice, and it is the first thing to raise if your group settles centrally.
Hardening before you go live
The documentation names its own gaps: the platform ships in test mode with one-time passcodes exposed for testing, cross-origin rules permissive, and transport and frame headers not emitted. Switching to live mode, narrowing origins to your domains and rotating credentials is a pre-launch pass, quoted separately.
Somebody else's riders
The delivery partner app assumes you run your own fleet. In a country where you would rather not, connecting a third-party courier means mapping their states onto ours and handling their callbacks, which is integration work shaped by whatever API that company publishes.
A listing per country, maintained
The three Flutter applications build for iOS and Android from the source you receive. Signing them, and especially maintaining a separate store listing in every market with its own review cycles and its own metadata, is ongoing work outside a six-day deployment.
What is built is real
Zone geometry with per-market charges, cash ceilings and payment mixes, right-to-left in the storefront, notification templates per language, commission frozen at settlement, disbursement with overlap locks, market-scoped staff roles, and a security posture published against OWASP categories rather than asserted.
Also outside the build: single sign-on and a second factor for console staff, feeding order and payout rows into your own data warehouse, and standing behind an external assessment. Each is named here rather than discovered later, and each is quoted before it starts.
See how Miracuves compares to agencies and freelancers
The deployment process, the nine questions worth asking anyone bidding on a multi-market build, the red flags, and the Flyereats engagement we delivered in 2025 - on the Development Company page.
Frequently Asked Questions
How does one platform run several countries?
Is Arabic and right-to-left actually supported?
How is cash on delivery handled?
Can different markets offer different payment methods?
Do I need a separate app listing in each country?
Can one market sell groceries while another sells only food?
Set an address and watch the market resolve
On the live demo, change the delivery address and watch coverage, charges, restaurant list and payment methods all change with it, then open the same order in the console.
Explore the Talabat Clone
One codebase. As many markets as you can staff.
Customer, restaurant and delivery apps plus your console over one Laravel backend, with every market's charges, cash rules, gateways and language held as configuration you control.
Talk to Us →Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by Talabat.
“Talabat Clone” is used descriptively. It is how the software industry refers to building a platform with functionality similar to Talabat, and how clients search for it.
The entire design and codebase is built by our own team. The product contains no code, design, graphics, or content originating from the Talabat website or applications.
Talabat and all other third-party names and marks are the property of their respective owners, referenced here solely to describe the category of software offered.
