Food Delivery Web App — Multi-Location Restaurant Chain

I built a white-label food delivery web app scoped to the chain's exact structure: 8 physical outlets, one dark kitchen running two virtual brands, a shared rider pool, and a head office admin with full visibility across all of them.

**Customer storefront:** When a customer opens the web app, it detects their location and shows them the outlet that covers their delivery zone — or offers a list if they are in a multi-outlet overlap zone. The storefront shows the outlet's live open/closed status based on its configured operating hours and any manually set holiday blackouts. The menu loads with dietary tags (veg/non-veg/egg/Jain), item photos, price variants, and add-on groups. Item availability is managed at outlet level and reflects instantly — when the kitchen marks an item as unavailable, it disappears from the customer view within seconds, with no support ticket required.

**Cart, customisation, and payment:** Customers build their order with item-level customisation — portions, add-ons, special instructions. The cart shows itemised pricing, packaging charge, delivery fee (calculated by zone and distance slab), and the GST breakdown before payment. Razorpay handles payment — UPI, cards, net banking, and cash on delivery. On payment success, the order is created in the system and sent to the restaurant's live order board immediately. Every completed order generates a GST-compliant tax invoice — restaurant GSTIN, FSSAI licence number, HSN code 9963, CGST + SGST split — and delivers it to the customer by email.

**Restaurant order board and kitchen display:** Each outlet has a live order board that shows incoming orders with a sound alert, status controls (confirm → preparing → ready for pickup), and a preparation timer. Orders that are not confirmed within 3 minutes trigger an escalation alert to the outlet manager's phone. The board also shows the assigned rider and their live ETA to the restaurant. For the dark kitchen, each virtual brand has its own order queue on the same screen — the kitchen team sees both queues side by side, avoids double-counting the same item across two brand orders, and dispatches them under the correct brand packaging.

**Rider management and auto-dispatch:** Riders log into a mobile web interface, toggle duty on, and become visible to the dispatch engine. When an order is confirmed, BullMQ evaluates all on-duty riders in the outlet's zone, selects the nearest available one by straight-line distance to the restaurant, and fires an assignment push notification via Firebase FCM. The rider accepts, sees turn-by-turn directions to the restaurant, then to the customer. If no rider accepts within 90 seconds, the assignment cascades to the next nearest. Zone managers can override auto-assignment manually from the admin panel. Rider onboarding covers Aadhaar, PAN, and vehicle RC upload — documents stored in GCS — with approval controlled by the admin before the rider can go live.

**Real-time order tracking:** From the moment a rider picks up the order, the customer sees a live map. Rider location is broadcast via WebSocket every 5 seconds. The customer sees the rider move. The estimated delivery time updates dynamically. Status notifications fire at each stage — order confirmed, being prepared, picked up, arriving soon, delivered — via browser push notification and SMS.

**Multi-outlet and dark kitchen management:** Head office has a chain-wide admin panel. Every active order across all 8 outlets and the dark kitchen appears on a single live screen — outlet name, order ID, customer name, items, status, and assigned rider. Menu changes are made once and pushed to the selected outlet(s) instantly — no 48-hour support ticket. Operating hours, delivery zones, minimum order values, and delivery fees are configurable per outlet by zone managers without touching the codebase. The dark kitchen's two virtual brands each have independent menus, operating hours, and brand identities on the customer-facing app while sharing a single kitchen dispatch queue.

**Customer accounts and repeat ordering:** Customers create accounts with phone-verified OTP login. Order history is saved — a returning customer can reorder a previous basket in two taps. The system builds a first-party customer database with name, phone number, email, delivery address history, and order frequency. This database belongs to the restaurant. The owner can export it, segment it, and use it for WhatsApp or email campaigns — without any aggregator intermediary.

**Promotions engine:** The admin panel has a promotions module. The owner creates discount codes (percentage off, flat discount, free delivery, minimum order conditions, per-customer usage limits) and publishes them with a validity window. Codes are applied at cart and validated server-side before payment. A happy-hour pricing rule can be set to automatically drop delivery fees during specific hours. Combo deals can be configured as product bundles with a bundle price. None of this requires an aggregator — promotions run on the chain's own terms, targeting their own customer database.

**Analytics:** Restaurant owners see their own dashboard — hourly order volume, daily revenue trend, top 10 items by order count, average preparation time, and cancellation reasons. The platform admin sees across all outlets — revenue by outlet, rider utilisation by zone, delivery time distribution, peak-hour heatmaps, and refund rate. The bestseller ranking updates hourly, giving the kitchen team actionable data the same day rather than the next morning. All reports are filterable by date range and exportable.