Food Delivery · Cloud Kitchen · Aggregator · Dark Store
Food Delivery App Development in India — Three-App Systems Built to Ship, Not to Demo
Zomato and Swiggy-style multi-restaurant apps, cloud-kitchen ordering apps, hyperlocal food aggregators, and dark-store delivery builds — customer app, restaurant panel, delivery-partner app, and admin dashboard delivered as one system. Priced fixed in INR, built from Ahmedabad, shipped for restaurants and food brands across India and the Gulf since 2014.
- ✓Customer, restaurant, and delivery-partner apps built as one system, not three unrelated builds
- ✓Petpooja, POSist, Restolabs, and custom POS integrations for live menu, stock, and KOT sync
- ✓Google Maps live tracking, Mapbox routing, geofencing, and driver GPS breadcrumbs built in
- ✓Razorpay, PayU, Cashfree, PhonePe, UPI, wallets, and COD checkout in one flow
- ✓FSSAI display, GST invoicing, e-way bill logic, and DPDP-Act consent wired at launch
Why a food delivery app is a different build from a generic ecommerce app
A food delivery product is not one app — it is a live three-sided marketplace running on a phone. The customer wants a tap-and-eat flow with real-time tracking and a 30-minute promise. The restaurant wants an order printer, a KOT flow that mirrors the way the kitchen runs today, and a menu editor that does not need an IT person. The delivery partner wants a route that respects one-way traffic and geofenced pickup, a payout screen that reconciles daily, and a login that works on a ₹9,000 Android phone. And the operator on the admin side wants live coverage of every order, every rider, and every restaurant, plus a payments dashboard that reconciles to Razorpay settlements without a spreadsheet.
That is the wall a generic ecommerce template collapses at. A Shopify or WooCommerce mobile app cannot handle live-order state machines, driver assignment, KOT integration, or delivery pricing that changes by distance, time of day, weather, and surge. Cloning a template from a marketplace like CodeCanyon buys a ten-week head start and then two years of firefighting when the state machine breaks under load — orders stuck in "picked up" for hours, riders assigned to the wrong pickup, refunds that never process, and reviews on the Play Store that say "app not working".
Fruxinfo has been shipping custom mobile apps from Ahmedabad since 2012 and food-delivery projects since 2016. What we ship today is a proper three-app system — customer, restaurant, delivery — on one shared backend, wired to the POS the restaurant already runs, priced in INR up-front, and handed over with source code you own. The apps go through App Store and Play Store review with our team on the paperwork, not left as a checklist for the founder.
What an MVP food delivery app actually includes — the minimum that ships
Every founder who calls us about a food delivery app arrives with a feature list that reads like a Zomato roadmap on year five. The right first move is the opposite — cut the scope to what a real customer can order from on launch day, what a real restaurant can fulfil, and what a real delivery partner can pick up. Everything else is a version-two problem.
The MVP we ship for a single-city launch is a working three-app system with the modules below. It goes live in twelve to sixteen weeks and lets you take real orders from real customers the day it hits the store — not a beta that needs six more months of polish.
- ›Customer app (Flutter iOS + Android) — sign-up with phone OTP, restaurant list with search and filter, menu with variants and add-ons, cart, checkout, live tracking, ratings
- ›Restaurant panel (web + tablet-optimised) — menu editor, live order queue, accept / reject with reason, KOT print, mark-ready, daily settlement view
- ›Delivery-partner app (Flutter Android, optional iOS) — login, availability toggle, order accept, pickup navigation, drop navigation, cash reconciliation, daily payout view
- ›Admin dashboard (web) — live order map, restaurant onboarding, delivery-partner onboarding, payment and settlement reconciliation, coupon and discount engine
- ›Backend and API — Node.js or Laravel with WebSocket order events, Firebase push, PostgreSQL or MySQL, Redis for live state, S3 for assets
- ›Payments — Razorpay or Cashfree checkout for online, cash-on-delivery flow with delivery-partner reconciliation, refund flow to source
- ›Location and routing — Google Maps SDK for customer tracking, Directions API for driver navigation, geofencing for pickup and drop confirmation
- ›Compliance — FSSAI licence display on every restaurant page, GST invoice per order, DPDP Act consent capture, T&C and privacy screens
Cost to build a food delivery app in India — the real INR ranges
Food delivery app pricing is the single most-asked question on the first call, and the honest answer is: it depends on how much of the three-app system you actually need on day one. Below are the ranges we quote after a proper discovery — not a range pulled from a marketing blog. Every number assumes a Flutter build (one codebase, iOS + Android), a Node.js or Laravel backend, source code in your Git, and App Store plus Play Store submission handled by us.
A single-restaurant ordering app — one restaurant, one menu, customer app plus admin, no delivery-partner app, no multi-vendor logic — starts at around ₹2.5 lakh and ships in eight to twelve weeks. A cloud-kitchen ordering app with two to five brands under one operator, one customer app that shows all brands, and a shared kitchen dashboard sits in the ₹4-9 lakh range and ships in ten to fourteen weeks. A hyperlocal single-city multi-restaurant aggregator — customer, restaurant, and delivery-partner apps plus admin, ten to fifty restaurants, live tracking, distance-based delivery pricing — lands in the ₹9-22 lakh range and ships in fourteen to twenty weeks. A full Zomato or Swiggy-style multi-city aggregator with hundreds of restaurants, surge pricing, subscription plans, ads, and a dark-store module is quoted after discovery and starts at ₹22 lakh.
Recurring costs are honest and small. Google Maps runs about USD 200-800 per month at launch scale, climbing with active-user growth (the Places, Directions, and Distance Matrix APIs are the meters that move). Firebase for push and analytics is free for most launch traffic and rarely crosses USD 100 per month before the fifty-thousand-MAU mark. Razorpay charges 2 percent on domestic cards and UPI is free for merchants under the current MDR rules. WhatsApp Business API conversation cost runs ₹0.85-2.85 per notification. App Store fees are USD 99 per year for Apple, USD 25 one-time for Google — we set up both developer accounts under your business name.
Everything is fixed-scope. The number in the quotation is the number you pay, and every change request during the build is estimated in writing before work starts. Post-launch, an optional support retainer covers bug fixes, dependency upgrades, iOS and Android version updates, and a 24-hour SLA on standard tickets.
- ›Single-restaurant ordering app — ₹2.5-5 lakh, 8-12 weeks
- ›Cloud-kitchen multi-brand app — ₹4-9 lakh, 10-14 weeks
- ›Hyperlocal single-city aggregator (10-50 restaurants) — ₹9-22 lakh, 14-20 weeks
- ›Zomato/Swiggy-style multi-city aggregator — from ₹22 lakh, quoted after discovery
- ›Dark-store or 10-minute grocery add-on module — ₹6-14 lakh on top of a delivery app
- ›iOS + Android via one Flutter codebase — no separate native quotation unless the brand insists
- ›App Store USD 99/year + Play Store USD 25 one-time — accounts opened under your business name
- ›Google Maps + Firebase + Razorpay MDR — real running cost of ₹15,000-60,000 per month at launch scale
Feature list by module — what actually gets built in each app
The three-app system is not three copies of the same screen with the colour swapped. Each app does one job for one user, and the value of the build lies in how tightly they talk to each other. Below is the module-by-module feature list we ship on a standard hyperlocal aggregator build — the reference scope every food-delivery quote starts from.
Customer app is where 90 percent of the visible product lives. Sign-in runs on phone OTP with Google and Apple sign-in as backup. Home screen shows nearby restaurants ranked by prep-time-plus-distance, filter chips for cuisine and dietary preference, and a search bar wired to a Meilisearch or Typesense index for typo-tolerant results. Menu screens carry variants, add-ons, spice level, and cross-sell suggestions. Cart handles multi-restaurant blocking, coupon stacking, delivery-fee preview, and tip. Checkout shows UPI as the default rail, wallets and cards below, EMI when the cart crosses ₹1,500, and COD with an OTP confirmation. Live order tracking is a Google Maps view with driver breadcrumb, ETA, and a call-driver button. Order history, saved addresses, saved cards (tokenised), and referral share close the loop.
Restaurant panel runs on a tablet or web browser in the kitchen. Live order queue with sound alerts is the anchor screen. Menu editor lets the owner or manager toggle availability, edit price, adjust prep time, and mark items sold out — with the change reflected on the customer app in under two seconds. KOT print is wired to a Bluetooth or LAN receipt printer. Daily settlement view shows gross, commission, refunds, and net payout with a downloadable PDF. Weekly and monthly settlement reports export to CSV or Tally. Menu import from a Petpooja or POSist POS is a one-click sync.
Delivery-partner app runs on the driver's Android phone, tuned for cheap devices and patchy 4G. Availability toggle, current order card, pickup navigation, delivery navigation, cash collection reminder, and end-of-day payout view. Every screen is one-tap, high-contrast, and works with the phone locked in a bike mount.
Admin dashboard is the operator's control room. Live order map of every open order across the city. Restaurant onboarding with FSSAI licence upload, bank details, and commission plan. Delivery-partner onboarding with Aadhaar (via DigiLocker if possible), driving licence, and vehicle verification. Coupon engine with stackable rules, first-order caps, and restaurant-specific promos. Payments and settlement reconciliation against the Razorpay settlement report. A refund console with source-back-to-card support. A dispute queue for orders where the customer, restaurant, or driver flags a problem.
Tech stack and integrations a live food-delivery product runs on
A food delivery product lives on the reliability of about eight integrations. Miss one and the app fails the launch-week fire drill. Below is the reference stack we ship, and the integrations Indian food brands actually ask for on the first call. Every line item plugs in through the vendor's official API, so nothing is a scraped hack that breaks at their next release.
The frontend is Flutter for iOS and Android (one codebase, native performance), with Next.js for the restaurant panel and admin dashboard on the web. The backend runs on Node.js (NestJS or Express) or Laravel, depending on the team you plan to grow later. Realtime order state is a WebSocket layer (Socket.IO or Laravel Reverb) with Redis pub-sub underneath so a state change on the restaurant panel reaches the customer's live-tracking screen in under a second. Storage is PostgreSQL or MySQL for transactional data, Redis for live state, and S3-compatible object storage for menu images and driver documents. Push runs on Firebase Cloud Messaging plus Apple Push Notification Service, wired to templates in a single messaging service.
POS integrations decide whether the restaurant will actually use the app. Petpooja and POSist have public partner APIs we plug into — menu, stock, and KOT flow in both directions. Restolabs, LimeTray, and Torqus have similar hooks. If the restaurant runs a custom POS, we ship an adapter — a two to four-week task, quoted separately from the main app scope. For restaurants without a POS, the restaurant panel we ship doubles as their KOT and settlement system.
Payments plug into Razorpay, Cashfree, PayU, PhonePe, and Paytm — one primary gateway with an optional secondary fallback so a gateway outage does not stop orders. UPI, cards, netbanking, wallets, and EMI are surfaced in one checkout. COD is handled with an OTP verification on WhatsApp Business API and cash reconciliation on the delivery-partner app. Refunds fire back to the original payment method inside 3-5 working days.
Maps and location run on Google Maps SDK for customer tracking and the Directions API for driver routing. Mapbox is an option when the Google bill starts to hurt at scale. Geofencing on pickup and drop points is standard — the driver has to be inside the geofence before "picked up" or "delivered" can be marked, cutting fake status changes. Distance Matrix API prices delivery fees dynamically based on real driving distance, not straight-line kilometres.
Compliance and messaging round out the stack. FSSAI licence display on every restaurant page (rule 2.1.1(3) of the FSS Regulations for e-commerce food operators). GST invoicing on every order with GSTIN, HSN codes, and place-of-supply logic. WhatsApp Business API through AiSensy, Interakt, Gupshup, or Wati for order confirmation, ETA nudges, and reviews. Analytics wires GA4, Meta Pixel + CAPI, Firebase Analytics, and either Mixpanel or Amplitude for funnel and retention reporting. DPDP Act 2023 consent capture and a data-deletion route are built at launch, not retrofitted.
- ›Flutter iOS + Android (customer and driver apps), Next.js web (restaurant panel + admin)
- ›Node.js (NestJS / Express) or Laravel backend with Socket.IO or Laravel Reverb realtime layer
- ›PostgreSQL or MySQL + Redis + S3 — the boring, battle-tested data stack
- ›Petpooja, POSist, Restolabs, LimeTray, Torqus POS — official APIs, two-way sync
- ›Razorpay, Cashfree, PayU, PhonePe, Paytm — dual-gateway fallback available
- ›Google Maps SDK + Directions + Distance Matrix, or Mapbox — with pickup/drop geofencing
- ›Firebase FCM + APNS push, WhatsApp Business API (AiSensy / Interakt / Gupshup / Wati)
- ›FSSAI display, GST invoicing, DPDP Act consent, RBI card tokenisation — compliance built in
Monetization models — how food-delivery apps actually make money in India
A food delivery app has more revenue levers than most first-time founders realise, and picking the right mix at launch protects the unit economics for the next two years. Below are the models we architect for, with real India-market ranges. Most successful builds use two or three of these in combination, not just one.
Commission on order value is the standard aggregator model. Zomato and Swiggy charge restaurants 18-25 percent on every order, and a new city-level aggregator typically starts at 12-18 percent to win supply. The commission is deducted before settlement and appears on the restaurant's daily payout view. This model needs volume to work — expect a burn phase to build order density.
Delivery fee to the customer is the second lever. Standard range is ₹15-60 per order depending on distance and time of day, with surge pricing during peak hours or bad weather. The pricing engine we ship supports distance-based, flat, and surge tiers, and lets the operator experiment on the admin panel without a code deploy.
Subscription plans are the retention lever — Zomato Gold and Swiggy One are the reference examples. A ₹99-299 monthly plan that removes delivery fees, adds a discount, and reserves early-access slots. We wire subscription as a Razorpay Subscriptions or Stripe Billing product with a customer-facing manage-plan screen. Subscription revenue is the highest-margin line item once the base grows.
Restaurant advertising is a mature-market lever. Sponsored placements at the top of the home feed, category-page banners, and search-result promotions — priced on cost-per-thousand-impressions or cost-per-click. We ship the ad slot infrastructure at MVP and turn it on when order volume justifies a sales conversation with restaurants.
Cloud kitchen commissions and dark-store margin are the frontier levers. A cloud kitchen brand launched inside the app captures 40-60 percent gross margin instead of the 12-25 percent aggregator take. A dark-store module (10-minute grocery, essentials, or private-label food) opens a second SKU stream on the same delivery fleet. Both are architected as add-on modules on the same three-app system.
Card-linked or wallet-linked cashback partnerships, first-order coupons funded by restaurants, referral credits, and small transaction fees on UPI (soon, when MDR returns) round out the mix. The right combination depends on the city, the price point, and the density — we walk through the P&L math on the blueprint call before the build starts.
- ›Commission per order — 12-25% of order value, deducted before restaurant payout
- ›Delivery fee to customer — ₹15-60 flat or distance-based, surge pricing at peak times
- ›Subscription (Zomato Gold-style) — ₹99-299 monthly, no delivery fee + reserved slots
- ›Restaurant advertising — sponsored home / category / search placements
- ›Cloud kitchen operator margin — 40-60% gross vs 12-25% aggregator commission
- ›Dark-store add-on — 10-minute grocery/essentials on the same delivery fleet
- ›Referral credits, first-order coupons, and partner cashback — retention levers
- ›Small future UPI transaction fee when MDR returns — architecturally supported
Timeline and delivery process — how we ship a food-delivery build
We work in fixed-scope, milestone-billed sprints with a weekly demo. The clients we ship for know what will be on staging every Friday, and they know exactly which invoice covers which milestone. Below is the standard timeline for the three most-common food-delivery scopes.
Weeks 1-2 are the blueprint phase. On-site or Zoom discovery with the founder, kitchen head, and operations lead. We walk the current order flow — how a WhatsApp or phone order arrives today, how it hits the kitchen, how it gets dispatched, how the money moves back. We come out with a written scope document, a wireframe deck for all three apps, a data model, a POS-integration plan, a payment-and-refund flow, and a fixed-price quotation. Nothing gets coded until the scope is signed.
Weeks 3-6 are backend and admin. The backend, database, admin dashboard, restaurant onboarding, menu editor, and Razorpay integration are the first modules built and demoed. The restaurant panel goes live on staging by end of week 6, and the pilot restaurants can start entering menus and testing accept-reject and KOT flows.
Weeks 7-12 are the customer app. The Flutter customer app is built module by module — onboarding, home, restaurant, menu, cart, checkout, live tracking, order history, ratings. Each module hits a weekly Friday demo. Google Maps, push, deep links, and payments wire in as horizontal capabilities. By end of week 12 the app is on internal-test tracks on TestFlight and Play Internal Testing.
Weeks 13-16 are the delivery-partner app and the launch hardening. Delivery-partner sign-up, availability, order accept, pickup / drop flow, and cash reconciliation. End-to-end soak tests with real riders in a live cluster. App Store and Play Store review submission on week 14. Launch checklist — FSSAI display audit, GST invoice sample audit, DPDP Act consent audit, App Store review reply, Play Store review reply — signed off before go-live.
Post-launch, the first month is a hyper-care sprint — daily standup, live production monitoring on Sentry and Datadog, and same-day patches on P0 issues. From month two, the app moves to the standard retainer cadence — a fortnightly release, a monthly analytics review, and a quarterly roadmap conversation.
Who this build is for — the four food-delivery client types we ship for
Every food-delivery enquiry that lands on our contact form fits into one of four patterns. The scope, the timeline, and the price map to the pattern — knowing which one you are running lets the first call move quickly to numbers.
The single-restaurant founder wants their own ordering app so they stop losing 20-25 percent of every Zomato and Swiggy order to commission. Scope is a customer app plus a simple restaurant panel — no delivery-partner app, delivery handled through Dunzo or Porter for Business. Typical build is ₹2.5-5 lakh, ships in eight to twelve weeks, and pays back inside six months at a moderate order volume. We have built this pattern for a bakery chain in Ahmedabad, a Gujarati-thali restaurant in Vadodara, and a South-Indian tiffin service in Rajkot.
The cloud-kitchen operator runs two to six brands out of one kitchen and wants a single customer app that shows all brands, a shared kitchen dashboard, and analytics per brand. Scope is a customer app, a brand-aware restaurant panel, and admin — delivery-partner app optional. Typical build is ₹4-9 lakh, ships in ten to fourteen weeks. The kitchen keeps 40-60 percent gross margin on every direct order instead of 15-25 percent on aggregator orders.
The hyperlocal city aggregator is a founder who has spotted a supply-side gap — a college town, a business district, a Tier-2 city where Zomato coverage is thin. Scope is the full three-app system, ten to fifty restaurant partners at launch, and a real go-to-market plan for driver recruitment. Typical build is ₹9-22 lakh, ships in fourteen to twenty weeks. Success depends less on the app and more on supply density — we point every founder in this bracket at the operating challenges before the build starts.
The multi-city or dark-store operator is an existing food business, a retail chain, or a well-funded startup building a broader delivery platform — sometimes on top of a 10-minute grocery play. Scope is a full aggregator plus a dark-store module, surge pricing, subscription plans, ads infrastructure, and a serious admin. Quoted after discovery, starts at ₹22 lakh. Timelines run six to nine months for the first production city, then a copy-and-scale cadence for city-two onwards.
If your build does not fit cleanly into one of these four, that is normal — most real projects sit at the boundary between two. The blueprint call is where we place the project on the map and quote against the closest reference.
The next step — book a food-delivery blueprint call
The fastest way to know what your food-delivery app should actually cost and what should be in scope is a 30-minute conversation. We will ask about the model (single-restaurant, cloud kitchen, aggregator, dark store), the city, the launch order volume you expect, the POS you run or plan to run, the payment mix your customers prefer, and the timeline you are working against. At the end of the call you get a written blueprint — recommended scope, module list, integrations, indicative timeline, and a fixed-price quotation — with no obligation to move forward.
Call +91-99245-12890 or drop an enquiry through the contact form. We reply the same working day.
Food delivery app questions we hear on the first call
What restaurant founders, cloud-kitchen operators, and hyperlocal aggregator teams ask before starting a food-delivery build. If yours isn’t here, we will answer it on the discovery call.
Explore Related Services
Combine these services with what you just explored for a complete digital strategy from Fruxinfo.
Mobile App Development
Native and cross-platform iOS, Android, and Flutter apps for modern business needs.
Learn more →Restaurant Website Development
Restaurant websites with online ordering, table booking, Petpooja POS sync, and Zomato + Swiggy integration — built in Ahmedabad, shipped worldwide.
Learn more →CRM for Hotels & Restaurants
Hospitality CRM built for booking pipelines, guest 360, banquet BEO, PMS + POS sync, OTA channel parity, and WhatsApp confirmation and rebooking flows.
Learn more →
