Deep dive
Aggregator or direct ordering?
An aggregator lists many restaurants and runs its own delivery fleet or uses third-party riders. It needs density in both restaurants and riders before it is useful, which makes it a capital-intensive business as well as a software project. A direct ordering channel belongs to one restaurant or chain, needs no rider marketplace and can launch in weeks.
If you run restaurants, a direct channel with QR ordering, online orders and a loyalty programme often pays back faster than building an aggregator; NexEats and our restaurant ordering system cover that path. If you are building a delivery network for a city, a campus, a corporate park or a cuisine niche, the rest of this guide applies.
How an order flows through the system
When a customer places an order, payment is authorised and the order goes to the restaurant app with a loud alert. The restaurant accepts and sets a preparation time. The dispatcher looks for a nearby available rider and assigns them so they arrive close to when the food is ready. The rider app guides them to pickup and drop, and the customer sees each step in real time.
Every step can fail: the restaurant rejects, an item is out of stock, no rider is available, the customer is unreachable. Each failure needs a defined outcome, such as an automatic refund, a substitution prompt or escalation to the operations team. Writing these down in discovery saves weeks of rework later.
The restaurant side deserves as much design attention as the customer app. Kitchens are loud and busy, staff change often and the device is usually a shared tablet or an old phone. Large buttons, an alert that cannot be missed, a one-tap way to mark an item out of stock and a printed kitchen ticket where needed reduce rejected and late orders more than any feature in the customer app.
- Treat the order as an event log, not a single status column, so you can replay what happened.
- Use idempotent payment and assignment calls so retries never charge twice or double-assign.
- Give operations staff tools to reassign riders and refund in two clicks.
Riders, dispatch and live tracking
Rider apps send location every few seconds while on duty. The backend stores the latest positions in a geospatial index and picks candidates near the restaurant. In the MVP, a rule-based dispatcher that considers distance, rider load and preparation time is enough. In the scale tier, models that predict preparation and travel time, plus batching of nearby orders, reduce cost per delivery noticeably.
Location tracking must work with the screen off and survive aggressive battery savers on budget Android phones. Budget for native modules and testing on the devices riders actually use. Our mobile app testing team keeps a device lab for exactly this.
Payments, settlements and payouts
The customer pays the platform, which pays the restaurant its share after commission and pays riders per delivery plus incentives. Weekly or daily settlements need a ledger that records every order, fee, tax, refund and adjustment. Cash on delivery adds rider cash balances that must be deposited or deducted from earnings.
In India, payment aggregators such as Razorpay or Cashfree offer split settlements and payouts; elsewhere, Stripe Connect or Adyen for Platforms do similar jobs. Your ledger, not the gateway dashboard, should be the source of truth for what each party is owed.
Scaling to many cities
Expansion is mostly operations: zones, fees, taxes, restaurant onboarding teams and support rosters per city. Design the data model for multiple cities from the first release so expansion is configuration. Load is spiky by nature, with lunch and dinner peaks and festival days, so autoscaling and load testing are not optional.
At scale, the main software investments are dispatch optimisation, personalised discovery, restaurant advertising and fraud detection, built by our machine learning and data engineering teams. Budget 15-20% of the build cost per year for maintenance, plus usage-based maps, messaging, cloud and payment fees.