We built a food ordering and delivery platform for a cloud kitchen operator running 8 kitchens across Bengaluru. Before our platform, they relied entirely on Swiggy and Zomato — paying 25-30% commission per order. Our system: direct ordering via app and WhatsApp, their own delivery fleet for 3 km radius (outsourced beyond), and a kitchen display system that reduced average preparation time from 22 minutes to 14 minutes. Within 6 months, 35% of orders came through their own platform — at zero commission. The math is simple: on 5,000 orders/month at ₹400 average, saving 27% commission = ₹5.4 lakh/month saved. The platform paid for itself in 3 months.
What We'll Cover
The Three-Sided Platform
Food delivery is a three-sided marketplace: customers, restaurants, and delivery riders. Each side has fundamentally different needs, and the platform must coordinate all three in real time. This is harder than building an e-commerce store — because the product is perishable and the delivery window is minutes, not days.
| Component | Users | Key Requirements | Tech Challenge |
|---|---|---|---|
| Customer app | End consumers | Browse menus, order, track, pay, rate | Sub-second search, real-time tracking, smooth UX on low-end phones |
| Restaurant dashboard | Kitchen staff, owners | Accept/reject orders, manage menu, prep timing, analytics | Reliable order notification (cannot miss orders), offline handling |
| Rider app | Delivery partners | Accept deliveries, navigate, update status, earnings | Continuous GPS, battery optimization, works on ₹8,000 phones |
| Admin panel | Operations team | Fleet monitoring, restaurant onboarding, pricing, analytics | Real-time dashboards, bulk operations, financial reconciliation |
Customer App: From Browse to Bite
- Restaurant discovery: Location-based listing (show restaurants within delivery radius). Filters: cuisine, rating, delivery time, price range, veg/non-veg, offers. Personalized recommendations based on order history and time of day (breakfast suggestions at 8 AM, lunch at 12 PM)
- Menu and ordering: Photo-heavy menu with item descriptions, customizations (spice level, add cheese, no onion), and allergen info. Cart with add-ons and combos. Minimum order value enforcement. Schedule orders for later
- Search that actually works: "Butter chicken near me" should work. So should "biryani under 200." Use Elasticsearch with fuzzy matching, synonym handling (paneer = cottage cheese), and location awareness. Auto-suggest popular items in the user's area
- Real-time tracking: Order status: Placed → Confirmed → Preparing → Ready → Picked up → On the way → Delivered. Live rider location on map. Accurate ETA that updates as rider moves. Push notification at each status change
- Offers and promotions: Coupon engine: flat discounts, percentage off, BOGO, free delivery, first-order specials. Wallet credits for referrals. Dynamic pricing during peak hours (surge pricing). Restaurant-funded offers vs platform-funded offers — track who pays
Restaurant Dashboard: Kitchen Operations
- Order management: New order notification with alarm sound (must be unmissable). Auto-accept or manual accept based on restaurant preference. Prep time estimation — kitchen sets realistic time, customer sees it. "Mark Ready" button triggers rider assignment
- Kitchen Display System (KDS): Tablet-based display showing active orders sorted by priority. Color-coded: new (blue), in-progress (yellow), ready (green), late (red). Print ticket option for kitchens that prefer paper. Multi-station support: starters on one screen, mains on another
- Menu management: Add/edit items with photos, descriptions, prices. Mark items as "out of stock" in real-time (critical during peak hours). Category management. Day-parting: different menus for breakfast/lunch/dinner. Bulk price updates during festivals
- Analytics: Daily/weekly/monthly sales, popular items, average preparation time, cancellation rate, customer ratings breakdown, peak hours analysis. Revenue vs commission report. Comparison with previous periods
Delivery Optimization: The Logistics Brain
Rider Assignment Algorithm
The assignment algorithm is the heart of delivery economics. Bad assignment = late deliveries + unhappy riders + high costs. The algorithm must consider:
- Proximity: Rider's current location relative to the restaurant. Not just straight-line distance — actual road distance and traffic
- Current load: Is the rider already carrying an order? Can this be batched? Batching (2 orders from nearby restaurants to nearby customers) reduces per-delivery cost by 30-40%
- Rider earnings fairness: Don't always assign to the nearest rider — rotate fairly so all active riders earn. Track daily earnings and factor into assignment
- Estimated completion time: If the food won't be ready for 15 minutes, assign a slightly farther rider who can arrive just in time rather than having a nearby rider wait idle
Delivery Fleet Models
| Model | Cost | Control | Best For |
|---|---|---|---|
| Own fleet (full-time) | ₹15,000-20,000/month per rider | High — uniform, training, schedule control | Premium brands, cloud kitchens, consistent demand |
| Gig riders (freelance) | ₹30-60 per delivery | Low — availability varies, quality varies | Scaling up/down, peak hour coverage, new city launch |
| Third-party logistics | ₹40-80 per delivery | None — fully outsourced | Starting out, testing markets, overflow during peaks |
| Hybrid | Variable | Medium | Most operators — own fleet for base demand, gig for peaks |
Real-Time Technical Architecture
- WebSocket for live updates: Order status changes, rider location, ETA updates — all push-based via WebSocket. Polling fallback for unreliable connections. Socket.IO with Redis adapter for multi-server setup
- GPS tracking pipeline: Rider app sends location every 10 seconds → MQTT broker → stream processor (Kafka/Redis Streams) → update rider location in Redis (hot cache) → push to customer tracking screen. Store in TimescaleDB for historical analysis and route optimization
- Order state machine: Every order follows a strict state machine. Invalid transitions are rejected (can't go from "Placed" to "Delivered" without "Picked up"). Each state change is an event — triggers notifications, analytics, and downstream actions
- Notification reliability: Restaurant order notifications must be 100% reliable. Use Firebase Cloud Messaging + SMS fallback + alarm sound in app. If restaurant doesn't acknowledge in 60 seconds, escalate: ring again, then alert admin for manual intervention
India-Specific Food Delivery Considerations
- FSSAI compliance: Every restaurant must display FSSAI license number. Platform must verify and display it. Non-compliant restaurants face ₹5 lakh penalty — and your platform can be held liable for listing them
- Cash on Delivery: Still 15-25% of food orders in tier 2-3 cities. Rider must collect cash, platform must reconcile daily. Cash collection creates security risk and accounting complexity — but refusing COD loses significant order volume
- Veg/Non-veg segregation: India-specific requirement: clear veg (green dot) / non-veg (red dot) marking on every item. Some customers want veg-only restaurants or separate delivery (don't pack veg and non-veg together). Respect this — it's cultural, not optional
- Low-end device optimization: Rider phones are typically ₹8,000-15,000 Android devices with 2-3 GB RAM. Your rider app must work smoothly: minimize background services, optimize GPS battery drain, work on Android 10+. Test on Redmi and Realme, not iPhone
- Address challenges: "Near the big temple, opposite the blue building" is a real Indian address. Support landmark-based addresses, Google Plus Codes, and pin-drop on map. Let riders call customers for last-mile navigation (built-in calling with number masking)
- GST on delivery: Food delivery attracts 5% GST (no input tax credit). Platform commission attracts 18% GST. Your invoicing must correctly separate food value, delivery charges, packaging charges, and applicable GST on each
Frequently Asked Questions
How much does it cost to build a food delivery app?
Single-restaurant ordering app (customer + kitchen): ₹10-20 lakh (2-3 months). Multi-restaurant marketplace (customer + restaurant + rider + admin): ₹40-80 lakh (4-6 months). Cloud kitchen platform with own delivery fleet: ₹25-50 lakh (3-5 months). Ongoing costs: hosting ₹30K-1L/month, maps API ₹10K-50K/month, SMS/notifications ₹5K-20K/month.
Should I compete with Swiggy and Zomato?
Don't build a general food delivery marketplace — Swiggy and Zomato have spent thousands of crores on logistics and restaurant relationships. Instead, niche down: build for a specific city/locality (hyperlocal), cloud kitchen ordering (direct brand-to-customer), corporate catering, tiffin/meal subscription services, or specialized cuisines. The highest-ROI use case: helping existing restaurant chains or cloud kitchens take orders directly and reduce aggregator commissions.
How do food delivery apps handle peak hour scaling?
Lunch (12-2 PM) and dinner (7-10 PM) peaks see 5-10x normal traffic. Auto-scaling on cloud (AWS ECS or Kubernetes with HPA) handles compute. Redis caching for menu and restaurant data prevents database overload. Queue-based order processing (Kafka/SQS) absorbs burst writes. Pre-warm CDN for images. The real bottleneck is usually rider supply, not server capacity — incentivize riders for peak hours with surge pay.