Illustrative blueprint: How a 3-outlet restaurant cut 28% delivery commission with a direct ordering system.
An illustrative planning scenario showing the shape and economics of a typical Big Helpers build for an Indian restaurant chain wanting to reduce dependence on Swiggy and Zomato.
Illustrative blueprint: This page is a planning scenario, not a named client engagement or an independently verified result. Names, figures, timelines and outcomes below are assumptions that show how we would scope and reason about a project of this shape.
Modelled starting situation
A small North Indian restaurant chain with 3 outlets in tier-2 Maharashtra was processing roughly 800 delivery orders per week, with about 78% coming through Swiggy and Zomato. Average order value was ₹520. The aggregator commission of 26-30% was eating ₹3.2-3.6 lakh per month across all three outlets. The owner had a strong WhatsApp following from regulars (~6,400 contacts collected over 4 years) but no way to take orders from them other than calls — which a single counter staff person juggled poorly between in-house customers and phone orders.
The business problem
Three problems compounded: (1) commission spend was higher than rent across all outlets combined; (2) regulars who explicitly asked to order direct were being routed back to aggregators because there was no other channel; (3) order errors over phone were running at ~6% (wrong items, wrong addresses), each costing a remake plus reputation. The owner needed a way to take orders directly — without competing on app downloads (which a tier-2 Maharashtra customer base wouldn't do) and without spending six months building.
Run a restaurant? Get a free 1-page direct-ordering plan.
Tell us your outlet count and aggregator commission. We send back a sketch of what a direct-ordering system would look like for you, and what it would cost to build.
The system we would design
We built a lightweight direct-ordering system in 5 weeks. The customer-facing layer was a no-app-needed WhatsApp + web flow: regulars get a WhatsApp message every 3-4 days with an outlet-specific menu link, tap to open a single-page web menu (no signup, no download), build a cart, pick delivery slot, and pay via Razorpay UPI. The order lands in a kitchen-facing tablet at the relevant outlet with a 60-second auto-print to the kitchen printer. Delivery is via the outlet's existing 2 in-house riders + a Dunzo fallback for overflow. Owner sees a single live dashboard across all 3 outlets — orders, prep time, rider status, day-end revenue. Total system: PHP/Laravel + PostgreSQL + a tiny React kitchen-display + WhatsApp Business API for outbound + Razorpay for payments.
Features delivered
- Single-page web menu per outlet (no app, no signup, mobile-first)
- WhatsApp Business API broadcast to opted-in regulars (DPDP-compliant)
- Razorpay UPI / card payment with QR fallback for cash-on-delivery
- Kitchen tablet with auto-print to existing thermal printer
- Live multi-outlet owner dashboard (orders, prep time, revenue, top items)
- Inventory-aware menu — out-of-stock items grey out instantly
- In-house rider tracking + Dunzo overflow integration
- Customer feedback loop — 1-tap rating after delivery
- Automated reorder reminder to customers idle for 30+ days
- Daily revenue + commission-saved digest WhatsApped to owner at 11 PM
Expected measurable outcomes
Within 90 days, 22% of total delivery volume shifted from aggregator-driven to direct, cutting roughly ₹2.4-2.8 lakh per month from commission outflow. Direct order errors dropped below 1% because customers built the cart themselves. Aggregator orders weren't killed — they're a useful customer-discovery channel — but the chain went from "aggregator-dependent" to "aggregator + direct" in one quarter. Payback on the ₹2.6L build was inside month two.
What we learned
- WhatsApp + a single-page menu beats a native app for tier-2 audiences who won't install another app to order food
- Auto-print to the existing kitchen printer was non-negotiable — no kitchen will accept staring at a tablet during peak hours
- Razorpay UPI handled 78% of payments; cash-on-delivery (with QR confirm) handled the other 22% without friction
- DPDP compliance for the WhatsApp broadcast list mattered — explicit opt-in capture in the cart, easy unsubscribe, and a documented retention policy were built from day one
- The owner's daily 11 PM digest was a tiny feature that drove behaviour change — they stopped checking the dashboard mid-shift, freeing 4-5 hours/week
- Don't try to kill aggregator volume — augment it. Customers come from aggregators, then convert to direct on the second order via the WhatsApp prompt
Frequently asked questions
Is this an actual client?
No. This is an illustrative planning scenario, not a report of one identified client engagement or an independently verified outcome. The workflow, scope, cost ranges and outcome ranges are planning assumptions that show how we would approach a project of this shape.
Will this work for a single-outlet restaurant?
Illustrative planning note: Yes — and it's cheaper. Single-outlet builds drop to ₹1.2-1.6L because we skip the multi-outlet dashboard layer. The economics still work as long as you have a regulars list (even 800-1,000 contacts is enough).
What about Petpooja / Restroworks integrations?
Illustrative planning note: We've integrated with both. Petpooja's API is solid; Restroworks needs a partner-API request. The integration adds ~1 week to the build and ~₹40K to the cost. Worth it if your kitchen team already lives in those systems.
Do we need WhatsApp Business API or will WhatsApp Business app work?
Illustrative planning note: For broadcast above 256 contacts you need the API (Meta's rule, not ours). The API costs ~₹0.40-1.20 per outbound message in India depending on category and provider. For a 6,400-contact list sending one message per week, that's ~₹10-15K/month — significantly less than the commission saved.
What's the maintenance like?
Illustrative planning note: Roughly ₹5,000-8,000/month for hosting + small fixes, or ₹0 if you self-manage on your own VPS. We hand over source code on day-1 of go-live, so any local PHP/Laravel developer can extend it. Most clients keep us on a 4-hour/month retainer for 6-9 months then move to ad-hoc.
Can it support cloud kitchen / multi-brand setups?
Illustrative planning note: Yes — we've built variants where one outlet runs 3 brands (e.g. North Indian + Chinese + dessert). The menu, kitchen routing, and dashboard handle that natively.
Related Big Helpers services
Ready to build your direct ordering channel?
Talk to a senior engineer in 24 hours — no juniors, no sales reps, no jargon. Just a clear scope, an honest estimate, and a build plan.