White Label Food Delivery App Features: The Platform Underneath
Any vendor can sell you an ordering screen. What keeps a delivery business alive is the work that begins after checkout: your commission fixed onto a settlement record, restaurant and rider balances that move on a schedule, refunds that leave an approval trail, and payout runs that cannot pay anyone twice. This is the platform underneath the food delivery clones, listed role by role, with its limits written down next to its strengths.
Request a Live Demo →Full OverviewFeature Set by Role
Six kinds of user, one backend that holds every business rule, and no role that has to squint at another role's screen.
The Customer
Browse and search by dish, cuisine or restaurant, narrow by rating, price and delivery time, and see only kitchens that reach the address. Sizes, extras, allergens and nutrition sit on each dish. Checkout covers delivery, collection or a table, with a scheduled time, a tip, a coupon, loyalty points and wallet credit.
The Restaurant
An order board for accepting and preparing, a menu editor with photos, sizes, extras and bulk upload, one-tap sold-out switches, opening hours and closures, staff logins under the owner, and a single view of earnings and payout history instead of a monthly email from you.
The Counter
A till built into the restaurant panel rings up walk-in and phone orders, so trade that never touched the app still lands in your books. Table ordering and collection use the same order pipeline with the rider steps skipped, which leaves nothing happening outside your reports.
The Rider
Accept or decline the jobs assigned, follow navigation to pickup and to the door, close the drop with the delivery code, and watch earnings, incentives and the cash in hand add up. Cash collected is measured against a ceiling you set for each rider and each restaurant.
The Operations Desk
Approve restaurants and riders, draw delivery zones on a map with their charges, and step into any live order to reassign it, move it on, cancel it with a recorded authority or edit it before preparation locks. Refund requests are approved or rejected here, and the trail is kept.
The Finance Desk
Payout runs for restaurants and riders, with cadence, minimum amount, waiting period and week start all set by you. Overlap locks stop a slow run from repeating. Each restaurant gets a full statement, and sales, commission, payout and tax reports export on demand.
Staff roles carry module-level permissions, so support can see orders while finance sees payouts and nobody sees more than the job needs. A separate employee layer keeps restaurant staff scoped beneath the owner.
Rented Platform vs One-Time Script vs Miracuves Platform
Three ways to a branded delivery marketplace, and the point in each where the choice tends to start costing you.
| What decides it | Miracuves platform | Rented white-label platform | One-time script |
|---|---|---|---|
| Who holds the code | You, in full, on your servers | The vendor, who hosts it for you | You, though some vendors withhold source from every tier they publish |
| How you pay | $2,799 once, no per-order cut | Most published offers are monthly rentals | Roughly $250 to $1,500 on the open market |
| If you stop paying | Nothing changes, the platform is yours | The apps stop working with the invoice | Nothing changes, though there may be no upgrades |
| Mobile apps | Three separate Flutter builds, one per role | Varies by vendor, so ask to see each app | Cheaper tiers often ship web-view apps rather than native ones |
| What a rate change does to old orders | Nothing, the rate was frozen at settlement | Ask the vendor to show you, not tell you | Often recalculated from the current setting |
| Walk-in and phone trade | A built-in till feeding the same books | Depends on the plan | Usually outside the system |
| Adding a second city | Draw a zone and set its charges | Often another plan or another instance | A second install to maintain |
| Changing fees and payout timing | A setting among about 120 keys | Whatever the vendor exposes | Typically a developer and a deployment |
Rented platforms suit an operator who wants no servers to look after, and that is a reasonable need. A subscription often bundles hosting and licensing, so set a one-time cost against a recurring fee rather than assuming either is cheaper overall. The money side is worked through on the Development Cost page.
From First Address to Settled Payout
Seven stages, and every one maps to a named part of the code you receive.
An address goes in
Coverage is resolved from zone polygons instead of scanning every restaurant, so the customer meets only kitchens that serve the spot. The zone also decides which riders can be assigned and which staff may touch the order afterwards.
A basket takes shape
Dishes carry option stock, add-on groups, attributes, allergens, tags and a daily stock counter. Sizes, crusts and toppings live on the item, and a restaurant can mark something sold out itself, without opening a ticket with you.
Payment is taken
Thirteen gateways sit beside wallet credit, cash on delivery under a limit you set and offline methods you define, each with proof and approval. A basket can be part wallet and part card, and each part is stored as its own payment leg instead of one blended figure.
The kitchen cooks
The order reaches the board, gets accepted and prepared, and each status change is stamped with its own time. The till pushes counter and phone orders into the same pipeline, so they show up in reports rather than in a notebook.
A rider brings it
Riders are filtered by zone before assignment, follow the map, and finish the job with a one-time code the customer reads out. With verification switched on, a delivered status carries evidence and is not just a tap made on a doorstep.
The money is settled
Your commission percentage and the discount split are frozen onto the transaction row, and item revenue is read from the order line, not from today's menu price. Payout runs then pay restaurants and riders on your cadence, leaving a transaction history behind each run.
The books close
What the customer paid becomes what the restaurant is owed, which becomes what you pay out, all read from one order record. Reports show the figures as they were charged, so raising a rate next quarter leaves this quarter's numbers alone.
Loyalty points, wallet credit, cashback and referral rewards run alongside the whole loop, at rates you choose.
Every Feature Earns Its Place
Each row is here because a delivery marketplace breaks without it, not because a rival lists it.
| Module | Why it ships in the base build |
|---|---|
| Rate frozen at settlement | A rate read live lets any later change rewrite the past. Storing it on the transaction row keeps last quarter's figures true when this quarter's pricing moves. |
| Zones as the working unit | Coverage, dispatch, staff access, marketing and notifications all hang off the delivery area. It is the nearest thing to a tenant boundary in the data, so a new city becomes a setting. |
| Overlap locks on payouts | A payout is the one job where a repeat moves real money. The lock separates a run that is merely slow from one that pays every restaurant a second time. |
| The built-in till | Counter and phone orders are genuine revenue. Kept outside the platform, they never reach commission, reports or the restaurant's own statement. |
| Split payment as legs | Part wallet and part card is one order but two movements of money. A single total cannot be reconciled against either rail. |
| Cash ceilings per rider | A rider holding too much float is a risk you only spot after it goes wrong. The ceiling stops cash jobs being assigned before that point. |
| The business-model guard | Commission and subscription are held as a setting, and the console refuses to switch both off together, so restaurant economics are never left undefined by a stray click. |
| Isolated credentials per surface | Customer tokens cannot reach restaurant routes, and restaurant and rider tokens resolve through their own middleware, so no two surfaces share a trust boundary. |
Three further modules attach without threading through the core: an AI ordering assistant, a short-video food feed, and tax handling with per-order computation and exports.
The Technology Behind the Features
Deliberately ordinary, so the person you hire to extend it does not have to be us.
One Laravel application owns every rule and the five surfaces are presentation layers over a single versioned API. That is why the clients agree with one another about every order.
What Is Not Included in the Base Package
A fixed price means something only when the edge around it is written down, so here is the edge.
No restaurants, no riders, no fleet
No restaurants, menus, riders or delivery vehicles come with the platform. Signing and verifying restaurants, food safety and allergen accuracy, rider classification and insurance, and the tax and consumer rules of every market you serve are your responsibility.
The accounts behind it are yours
White label does not include the merchant account for each gateway, the SMS and push credentials, the maps keys, or your Apple and Google developer identities. They are opened in your name from the start, and it is not a monthly tenancy that switches your apps off when a payment lapses.
A hardening pass comes before launch
The documentation lists its own gaps. API origins ship wide open and need narrowing to your domains, browser hardening headers belong at the web server, and session cookies ship with the same-site attribute unset. Operator two-factor sign-in is not shipped. The pass is scoped work.
Search, fleets and iOS are extras
Discovery is database-backed by design, with an external engine documented as the extension point. Connecting an outside logistics provider is a scoped integration. The Flutter source builds for iOS, but signing, store listings and release management are delivery work.
Beyond thirteen gateways is integration
Stripe, PayPal, Razorpay, Paystack, Flutterwave, Paytm, PayTabs, MercadoPago, Paymob, SenangPay, SSLCommerz, LiqPay and bKash ship in the code. A fourteenth rail, or a warehouse feed into your reporting stack, is quoted against your own accounts.
What exists is real
About 300 tables over 378 migrations, 136 models, three separate Flutter builds, a server-rendered storefront, 764 console routes behind role gates, commission frozen at settlement, payout runs with overlap locks, per-order tax and credentials isolated by surface.
Also outside the build: a storefront design tailored to one vertical, courier shipping or cold chain beyond your delivery zones, and any regulatory certification for a controlled category. Fully custom work lives at our food delivery app development service. Miracuves is independent and not affiliated with any food delivery or restaurant ordering service.
Weighing up who should supply the platform?
Nine questions to put to any bidder, the delivery steps, the warning signs, and the Flyereats custom build we delivered in 2025, all on the Provider page.
Frequently Asked Questions
What does each of the three apps do?
What can carry my brand?
Which payment options are ready to connect?
Does a delivery leave proof behind?
Can I serve several cities from one platform?
Is it limited to restaurant food?
Place one real order, then follow the money
Order on the website, accept it as the restaurant, watch it travel through delivery, then open the same order in the console and see your commission and the restaurant's payout line calculated against it.
Explore the White Label Food Delivery App
Four apps. One set of books. Your source.
Customer, restaurant and rider apps plus your console, over a single backend and schema. The code is handed over outright and none of what the platform earns comes back to us.
Talk to Us →Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by Uber Eats, Talabat, Zomato, Grubhub, ChowNow, Goldbelly, or any other food delivery or restaurant ordering service.
“White label food delivery app” describes a category of product, not any one company. Brand names appear elsewhere on this site only to describe the kind of platform being built and the terms buyers search for.
The entire design and codebase is built by our own team. The product contains no code, design, graphics, or content originating from any third-party food delivery website or application.
No restaurants, menus, riders or delivery fleet are supplied with the platform. Onboarding and verifying restaurants, food safety and allergen accuracy, rider classification and insurance, and the tax and consumer rules for delivery in every market you operate in are your responsibility. All third-party names and marks are the property of their respective owners.
