On this page · 12 sections
Summary. The day a restaurant chain launches its own ordering app, it stops being only a restaurant in the eyes of the regulator. FSSAI's kind-of-business schedule, updated 1 April 2026, puts e-commerce in its own category with a central licence at Rs 7,500 per annum and, unlike restaurants, no turnover threshold at all. A single-outlet cafe with Rs 40 lakh turnover pays Rs 100 per annum for its restaurant registration, as of 1 April 2026, and Rs 7,500 per annum for the app. A mid-size chain on a Rs 5,000 state licence pays the same Rs 7,500 as a Rs 500 crore group. Late renewal costs Rs 100 for each day of delay under the FSS Regulations. Separately, the Competition Commission of India's director general has concluded that three categories of Zomato's restaurant contracts, including wide price-parity clauses, contravened Section 3(4) of the Competition Act, 2002, which is directly relevant to whether your own app is allowed to be cheaper than the aggregator listing. We build ordering apps, POS integrations and ONDC seller nodes from Gurugram. This page sets out what the work involves and what the compliance actually costs.
The licensing table nobody puts in the proposal
FSSAI's fee schedule is public and specific. These are the annual figures from the kind-of-business eligibility document updated 1 April 2026.
| Kind of business | Turnover criterion | Licence type | Fee per annum |
|---|---|---|---|
| Restaurant | Above Rs 50 crore | Central licence | Rs 7,500 |
| Restaurant | Rs 1.5 crore to Rs 50 crore | State licence | Rs 5,000 |
| Restaurant | Up to Rs 1.5 crore | Registration | Rs 100 |
| E-commerce | No turnover threshold | Central licence | Rs 7,500 |
| Head office (two or more states) | No turnover threshold | Central licence | Rs 7,500 |
| Home-based canteens and dabba services | Up to Rs 1.5 crore | Registration | Rs 100 |
| Caterer | Up to Rs 50 crore | State licence | Rs 5,000 |
Read the e-commerce row against the restaurant rows. A restaurant pays according to size. An e-commerce food business operator pays the top rate regardless of size, because the category carries no turnover criterion. FSSAI defines e-commerce broadly, as the buying and selling of goods or services using the internet including the transfer of money and data to execute those transactions. An own-brand ordering app that takes payment falls inside that definition.
The head-office row matters for chains. A food business operator with activities in two or more states or union territories has to declare one head office or registered office, on a central licence at Rs 7,500. A three-city chain that starts taking orders through one national app has crossed that line whether or not it noticed.
The renewal rule that should be a feature in the app
Licence validity is not annual by default. Under regulation 2.1.7 of the FSS (Licensing and Registration of Food Businesses) Regulations, a registration or licence is valid for a period of one to five years as chosen by the food business operator, subject to the fee for that period.
The renewal mechanics are strict and they are the reason licence expiry belongs in the ordering platform, not in someone's calendar:
- A renewal application must be filed not later than 30 days before the expiry date shown on the licence.
- A licence stays in force until orders are passed on the renewal application, and in no case beyond 30 days from the date of expiry.
- A renewal filed late but still before expiry carries a late fee of Rs 100 per day of delay.
- If no renewal is applied for within those windows, the licence expires and the operator has to stop all business activity at the premises and apply afresh.
An operator holding a valid certificate from an accredited food safety auditor is not normally inspected before renewal, though the designated officer may order one for reasons recorded in writing.
For a 40-outlet chain running one central app, tracking per-outlet licence numbers, validity periods and the 30-day filing window inside the outlet master is cheap to build and expensive to omit. We treat it as a core data model requirement, not an add-on.
Price parity is the commercial question, and it is live
The reason most chains want their own app is margin. The reason it often disappoints is a clause.
The CCI ordered a director-general investigation into Zomato and Swiggy in 2022, following a complaint by the National Restaurant Association of India covering platform neutrality around cloud kitchens and private labels, price-parity clauses, exclusivity arrangements and other vertical restraints on restaurant partners. As Business Standard reported on 14 July 2026, the director general concluded that three categories of Zomato's contractual arrangements, namely exclusivity conditions, minimum business guarantees and wide price-parity clauses, contravened Section 3(4) read with Section 3(1) of the Competition Act, 2002.
Two qualifications matter and both are in the same report. The director general's conclusions are investigative findings, not the CCI's final decision. And a source aware of developments at the company told the paper that "Zomato does not have exclusivity built into its standard agreements and removed price parity requirements in April 2026 or earlier in 2026." The NRAI's application, heard on 22 July 2026, asked the CCI to hold Zomato to that position while proceedings continue. In a parallel matter, the Karnataka High Court in April extended interim protection to Swiggy, staying proceedings before the commission.
The practical instruction for anyone commissioning an ordering app in 2026 is narrow and worth stating plainly. Read your current platform agreement for a price-parity term before you set the price list in your own app, and price the app on the basis of what your contract says today rather than what a news headline says. Neither the aggregators nor the associations publish restaurant-partner commission rates, so any percentage you see quoted in a comparison blog is an estimate, not a disclosure.
What actually gets built
A restaurant ordering app is four systems that have to agree with each other, and the integration is most of the cost.
| Component | What it does | Where projects go wrong |
|---|---|---|
| Ordering front end | Menu, cart, scheduling, payment | Menu modelled as a flat list instead of item, variant, modifier and combo |
| POS integration | Pushes the order to the kitchen | Two-way sync missing, so the app cannot see 86'd items |
| Menu and price master | One source of truth per outlet | Per-outlet price and tax overrides bolted on later |
| Fulfilment | Own riders, third-party fleet, or ONDC logistics | No fallback when the fleet API is down at peak |
| Compliance data | FSSAI numbers, licence validity, GST per outlet | Held in a spreadsheet, not the outlet master |
The POS layer decides the project. A menu item in a restaurant POS is rarely a simple product. It is a base item with variants, modifier groups with minimum and maximum selection rules, combo mappings and per-outlet availability. If the app models it as a catalogue entry with a price, every promotion and every out-of-stock event turns into a manual reconciliation. Two-way synchronization matters as much as the push: staff mark items unavailable at the terminal, and an app that cannot read that state sells food the kitchen does not have.
ONDC is the third route, alongside aggregators and direct ordering, and it is worth understanding structurally. ONDC defines four participant roles: buyer network participant, seller network participant, gateway and technology service provider. A seller network participant connects sellers to the network through a seller application, digitises the catalogue and disperses payments. ONDC further separates a Marketplace Seller Node, which carries no inventory of its own, from an Inventory Seller Node, which is an application operated by a seller selling its own inventory. A restaurant group publishing its own outlets is the second of those. Deciding which node you are is the first architectural decision, not a later one, because it determines catalogue ownership and settlement.
How we deliver
- Menu and outlet modelling, two weeks. We model items, variants, modifiers, combos, per-outlet availability and tax treatment before anyone writes screen code. This is the step most vendors skip and every rework traces back to.
- POS integration proof, two to three weeks. We prove two-way sync against your actual POS in a staging outlet, including item availability, price overrides and order status callbacks, before committing to the full build.
- Ordering application build in fortnightly increments, covering scheduling, payments, loyalty and address handling with offline data synchronization for weak-signal delivery zones.
- Fulfilment and channel integration. Own rider tracking, third-party fleet APIs, or an ONDC seller node with the participant role chosen deliberately.
- Pilot in a small outlet cluster through one full weekend peak, then phased rollout with runbooks, dashboards and source code handover.
The stack
React Native or Flutter for the customer application, chosen on your existing team's skills rather than ours. Node or Python services with Postgres for the order and menu domain, on AWS or Google Cloud in an Indian region. Redis for the availability cache, because the read pattern at dinner peak is heavily skewed. A queue-backed integration layer for POS and fleet calls so a partner API outage degrades the app instead of failing the order. Server-side tagging for analytics, so the marketing stack never receives raw customer contact data from the client.
India-specific considerations
An ordering app holds names, phone numbers, delivery addresses and order history, all of which are personal data under the Digital Personal Data Protection Act 2023. We design applications aligned with DPDP requirements: consent capture separated from the order flow, purpose limitation on marketing use of order history, retention rules on delivery addresses, and access control on the customer table so outlet staff see the order without seeing the full profile.
Regulatory attention on food platforms is not theoretical. Business Standard reported on 11 July 2026 that FSSAI issued notices to Swiggy Instamart after complaints about expired food, and the same publication reported Swiggy expanding its Food on Train offering to 180 cities. Traceability fields such as batch, prepared-at timestamp and outlet licence number cost little to capture at order time and are difficult to backfill.
Engagement model
We work in three ways: a fixed-scope discovery covering menu modelling and a POS integration feasibility assessment; time and materials for the build where scope will move, which it usually does once the POS is real; and fixed price for a defined phase against a signed specification.
We do not publish a rate card. An ordering-app quote given without knowing your POS vendor, outlet count, whether you run your own riders and whether you intend to join ONDC is a number designed to be revised. What we will tell you on a first call is which of those four decisions will dominate your cost, which is usually the POS.
Why eCorpIT
eCorpIT is eCorp Information Technologies Private Limited, founded in 2021 at Sector 83, Gurugram. We are a senior-led, multi-disciplinary organisation holding CMMI Level 5, ISO 27001:2022 and MSME certification, and we are partners of AWS, Microsoft and Google. Our adjacent commercial pages cover food delivery app development company work, on demand app development company engagements, grocery delivery app development company builds, and the wider mobile app development company in India practice.
FAQ
How eCorpIT can help
We start by modelling your menu and outlet data and proving two-way POS synchronization in one staging outlet, because that is where an ordering-app budget is won or lost. From there we build the customer application, the fulfilment integration and, where it fits, an ONDC seller node with the participant role chosen deliberately rather than by default. Licence numbers and validity dates go in the outlet master from day one. Tell us your POS vendor, outlet count and whether you run your own riders through /contact-us/ and we will tell you which decision dominates your cost.
References
Last updated: 16 August 2026.
