On this page · 15 sections
- Who this is for
- The commission question, stated accurately
- What FSSAI makes you build
- The tax question that changes the architecture
- The order state machine is the actual product
- Kitchen, POS and menu synchronisation
- Where ONDC fits, and what is honestly knowable
- How we build
- Engagement models
- The stack
- Why eCorpIT
- Related work
- How eCorpIT can help
- FAQ
- References
Summary. Most food delivery builds are commissioned for one reason, and it is not technology. Restaurants want a channel they control. The two things that decide whether that channel works are rarely in the brief. First, tax: an e-commerce operator has been liable to pay GST on restaurant service supplied through it since 1 January 2022, must pay that liability entirely in cash with no input tax credit, and issues the invoice itself, under section 9(5) of the CGST Act. Local delivery services moved to 18% with effect from 22 September 2025. Second, food safety: FSSAI requires an e-commerce food business operator to hold a central licence, priced at ₹7,500 a year, to display each seller's licence on the listing, and to sign a compliance agreement with every restaurant it lists. Swiggy carried ₹9,490 crore of food delivery gross order value in the quarter ended 30 June 2026 at 3.1% adjusted EBITDA, so the margin in this category is thin by design. eCorpIT builds food delivery and restaurant ordering platforms from Gurugram. This page covers the parts that decide whether yours survives contact with an auditor.
Who this is for
Restaurant groups with enough repeat volume to justify their own channel. Cloud kitchen operators running several brands from one production line. Regional delivery startups in cities the national platforms serve thinly. Grocery and meal-kit operators whose fulfilment looks like food delivery even when their catalogue does not.
If you run one outlet and your problem is discovery rather than repeat orders, a listing does more for you than an app. We will say so.
The commission question, stated accurately
The reason most of these projects start is aggregator economics, and the public numbers deserve care.
| Figure | Source and status | How to treat it |
|---|---|---|
| Commissions "to the tune of 20% to 30%" | NRAI allegation recorded in the CCI's prima facie order of 4 April 2022 | An allegation on record, not a finding |
| Zomato ~27.8%, Swiggy 24% of order value | Same NRAI allegation | Same |
| CCI's own view on commission levels | The Commission declined to investigate the commission allegation, holding it did not prima facie affect competition | The regulator did not endorse the numbers |
| Restaurant margins of 5% to 10% | MediaNama investigation, June 2025 | Reported case work, not a survey |
| Rapido Ownly: zero commission, zero marketing fee, zero subscription; customer pays ₹30 delivery | Named on the record by Rapido's Head of New Initiatives, Vivek Vashishta, March 2026 | A published competitor price point |
An investigation into exclusivity, minimum business guarantees and price parity clauses remains before the Competition Commission of India, and no final order has been issued. The practical point for a buyer is narrower than the litigation: a direct channel changes who owns the customer record and who sets the promotion, and it moves a variable cost into a fixed one. Whether that trade works depends on your repeat rate, not on anyone's commission percentage.
It is worth knowing what the incumbents keep. Eternal reported food delivery adjusted EBITDA of ₹532 crore, 5.5% of net order value, for the quarter ended 31 March 2026, and guides to 5% to 6%. Swiggy's food delivery segment ran at 3.1% of gross order value in the quarter ended 30 June 2026. Whatever restaurants are charged, single-digit margins are what survives at the other end.
Rapido's own pricing history is the more useful lesson. In June 2025 its proposal charged restaurants ₹25 to ₹50 per order. By the August 2025 pilot that was ₹29.50 to ₹59. By March 2026 all restaurant-side fees were gone and the customer pays ₹30. Any business case built on a competitor's current fee has a shelf life of about two quarters.
What FSSAI makes you build
Food safety rules are product requirements, not a policy annexe. The operative text is regulation 2.2 of the FSS (Licensing and Registration of Food Business) Amendment Regulations, 2021, as operationalised by FSSAI, reinforced by the advisory of 3 December 2024.
| Requirement | What the rule says | What it means in the product |
|---|---|---|
| Platform licence | An e-commerce FBO that facilitates orders needs a central licence; ₹7,500 a year per the April 2026 fee schedule | A compliance task before launch, not after |
| Licence on the listing | Sellers must display their FSSAI licence or registration and any hygiene grading assigned | A required, validated field on the restaurant record |
| No listing without a licence | "No e-commerce FBO shall list any food business operator on its platform without displaying their valid FSSAI License or Registration" | Onboarding gate in the merchant console, enforced in code |
| Compliance agreement | A signed agreement with each seller averring FSS Act compliance, with liability resting on the seller | Contract state stored against the restaurant, blocking activation |
| Shelf life | Packaged food must have 30% of shelf life or 45 days remaining at delivery; restaurants and caterers may deliver fresh food only | Matters the moment you add packaged goods to a restaurant catalogue |
| Last-mile handling | Last-mile delivery by trained personnel, with food safety preserved at delivery | Training records, and food kept separate from non-food consignments |
| Delisting | Non-compliant products delisted immediately | An admin action that must work in seconds, not a support ticket |
Two 2026 changes reduce the burden. FSSAI moved to perpetual validity for registrations and licences, removing renewals, and from 1 April 2026 raised the registration threshold from ₹12 lakh to ₹1.5 crore of turnover, with State licensing to ₹50 crore and central licensing above that. For a platform onboarding small kitchens, many of your sellers now need a registration rather than a licence. Your onboarding flow should collect both and know the difference.
The hygiene rating is a voluntary FSSAI scheme, so treat it as an optional display field rather than a required one.
The tax question that changes the architecture
This is the part restaurant groups discover late.
Under section 9(5) of the CGST Act, restaurant service supplied through an e-commerce operator is taxed in the hands of the operator. CBIC Circular 167/23/2021-GST of 17 December 2021 is explicit: with effect from 1 January 2022 the operator pays GST on restaurant services supplied through it, is liable even where the restaurant is unregistered, issues the invoice itself, and "shall pay the entire GST liability in cash," with no input tax credit available against it.
Then the 56th GST Council meeting of 3 September 2025 addressed delivery. Local delivery services are taxable at 18%. Where the person supplying local delivery is not liable to register under section 22(1), the service falls under section 9(5) and the operator pays. The rate changes took effect on 22 September 2025.
| Supply | Rate | Who pays |
|---|---|---|
| Restaurant service through an e-commerce operator | Restaurant service rate, without input tax credit | The operator, in cash, on its own invoice, since 1 January 2022 |
| Local delivery by a registered supplier | 18% | The registered supplier |
| Local delivery through an operator, supplier not liable to register | 18% | The operator, under section 9(5) |
| Local delivery supplied directly by a registered person | 18% | That person |
Three build consequences follow, and each is a schema decision rather than a screen.
Your invoice engine may be issuing the restaurant's invoice, not your own service invoice, which is a different document with different fields and a different GSTIN on it. Your order record needs the registration status of both the restaurant and the delivery partner at the time of the order, because that status decides who bears the liability. And your ledger needs to separate food value, delivery charge, packaging and platform fee at the line level from day one, because a single "order total" cannot be unpicked into these components after the fact. Retrofitting a tax split into a live orders table is the most expensive small change in this category.
None of this is advice on your tax position. It is a list of the fields your system will need, and eCorpIT builds to what your tax advisers confirm.
The order state machine is the actual product
Dispatch gets the attention. State gets the outages.
A food order is a distributed state machine across four parties: customer, restaurant, rider, platform. Placed, accepted, rejected, preparing, ready, picked up, in transit, delivered, cancelled, refunded, and the partial states nobody diagrams, such as accepted-then-item-unavailable at minute six. Every transition has a source of truth, a timeout, and a compensating action. The failure mode that kills a young platform is not a crashed server; it is two parties holding different beliefs about the same order.
Design rules that hold up in production:
The restaurant's tablet is not the source of truth, because it will be face down on a shelf during the dinner rush. The server owns state, the tablet holds a lease on it, and every acceptance carries an expiry.
Preparation time is an estimate with a distribution, not a number. Assign the rider against the predicted ready time rather than at acceptance, or your riders wait in kitchens and your cost per order rises. Swiggy reported 648,000 average monthly transacting delivery partners in the quarter ended 30 June 2026; at that scale, idle minutes are the whole margin.
Cancellation and refund are first-class flows, designed with the finance team, not bolted on. Every cancellation has a party who pays for it, and the ledger has to say who.
Rider allocation itself is the same class of problem as ride dispatch, and we set out that engine, its map cost and its regulatory limits in our on-demand app development page.
Kitchen, POS and menu synchronisation
The unglamorous integration decides whether operations adopt the product. A kitchen display driven straight from order state, with the printer as a fallback rather than the primary. Menu and stock synchronisation against the existing point-of-sale system, one way, with the POS as master, because two masters produce a dish sold at two prices. Item-level availability that a kitchen can toggle in one tap, since out-of-stock at acceptance is the largest single source of cancellations. And a daily reconciliation report the restaurant's accountant will actually open.
Where ONDC fits, and what is honestly knowable
ONDC's own site reports 616 or more cities live, 306 network participants and over 7.64 lakh sellers and service providers. Its headline order counter, at the time of writing, still shows the figure for May 2025, and it counts all domains rather than food alone. The network policy defines a commercial model in its own chapter, but no network participant fee figure is published in a form we could retrieve, and the 3% to 5% numbers circulating in vendor blogs have no primary source behind them.
Build for it if a network channel genuinely adds demand you cannot reach, and treat the economics as something to confirm with a network participant rather than to model in a spreadsheet. Our view on where network channels sit alongside owned ones is in retail digital transformation for D2C and quick commerce.
How we build
1. Discovery, 1 to 2 weeks. Outlet and menu structure, order volume and peak shape, POS and payment incumbents, the FSSAI position of every entity involved, and the tax treatment your advisers confirm. Written scope, including what version one deliberately excludes.
2. Architecture, 2 weeks. The state machine first, on a whiteboard, with every transition and timeout named. Then the ledger, the tax line split, the menu sync contract and the event schema.
3. Build, 10 to 16 weeks. Two-week increments with a working build at each end. Customer app, restaurant tablet application, rider app and operations console, with the console in scope from increment one. Framework choice is argued on maintenance cost, using our React Native versus Flutter hiring decision framework.
4. Test, 3 weeks, overlapping. A synthetic dinner rush against the dispatch and state services. Tablet offline behaviour. Refund and cancellation paths reconciled against the ledger. Menu sync run against real POS data rather than a fixture.
5. Pilot and stabilise, 4 weeks. Two or three outlets, real riders, a daily operations review, and a defect budget held back for the first month.
A first production release across the four surfaces typically lands in the 14 to 22 week range. A single-restaurant ordering app with no rider network is a much smaller build, and we will tell you if that is what you actually need.
Engagement models
Three shapes, quoted after discovery rather than before it. A fixed-scope pilot for a defined outlet count and feature list. A dedicated squad on a monthly retainer where the roadmap moves faster than a contract can. A build and transfer engagement for an operator who intends to run an in-house team within a year and wants the code, the infrastructure definitions and the runbooks handed over cleanly. We do not quote a number before seeing your menu structure and order volume, because the gap between a three-outlet ordering app and a multi-city delivery network with its own ledger is wide enough to make any advance figure marketing. The comparison against offshore alternatives is in India versus US app development cost.
The stack
Customer and rider apps in Kotlin with Jetpack Compose and Swift with SwiftUI where battery and location behaviour decide the product, Flutter or React Native where a shared codebase reduces total effort. Restaurant tablet as a resilient offline-first client. Order state as its own service with an append-only event log, because the log is what you reconcile and what you show an auditor. India-region AWS, Azure or Google Cloud, with data residency settled at architecture stage. Payments through a licensed payment aggregator with UPI-first collection, covered in our UPI multi-PSP checkout resilience work. Store submission planned against the current Android target API 36 deadline.
Why eCorpIT
We are a senior-led engineering organisation founded in 2021, headquartered in Gurugram, assessed at CMMI Level 5 and certified to ISO 27001:2022, and an MSME registered company. We are partners with AWS, Microsoft, Google and Shopify.
You get full IP and code ownership from day one, including repositories, infrastructure definitions and runbooks. The people who scope your build write it. We design applications aligned with DPDP requirements rather than claiming a certification we do not hold.
Related work
Neighbouring pages are on-demand app development for the dispatch and payout engine, ecommerce app development company for catalogue-led retail, and D2C mobile app development. Buyers who want a partner they can visit should read our mobile app development company in Gurgaon page, and anyone still shortlisting will get value from how to choose a mobile app development company.
How eCorpIT can help
eCorpIT builds food delivery and restaurant ordering platforms for Indian and global operators: customer and rider apps, restaurant tablet clients, order state services with an auditable event log, menu and stock synchronisation against existing point-of-sale systems, FSSAI-aware onboarding, and line-level ledgers that separate food value, delivery, packaging and platform fee. Our senior engineering teams work to CMMI Level 5 process discipline and ISO 27001:2022 controls. For a scoped estimate against your outlet count and order volume, contact us.
FAQ
References
Last updated 15 August 2026.
