Cloud Kitchen Software India 2026: Multi-Brand POS Pricing
Founder & Lead Developer, Codingclave · 200+ projects since 2017
Cloud Kitchen Software India 2026: The Founder's Operating Manual
India's cloud kitchen market crossed Rs 9,747 crore in 2024 and is on track for Rs 24,498 crore by 2030 at a 16.7 percent CAGR (IMARC, IBEF). The sector is one of the few inside Indian foodtech still growing at 25-28 percent year-on-year. But here is the brutal counterweight nobody puts in the funding deck — about 68 percent of new cloud kitchens shut within their first year. Most do not fail because the food was bad. They fail because the operating system underneath was wrong.
I am Ashish Sharma, founder of Codingclave, based in Lucknow. We have shipped 16-plus restaurant POS deployments since 2019 — single cafes, multi-outlet QSR chains, fine dining, and several cloud kitchen groups running between 3 and 9 virtual brands out of one physical kitchen. This guide is the real operating manual: what cloud kitchen software actually needs to do, what it costs in 2026, where Petpooja and Restroworks fit, and when you should commission a custom build instead.
If you only have 60 seconds, skip to the features section, watch the 5-minute Saffron POS demo, and WhatsApp me at +91 92771 84741.
What Cloud Kitchen Software Actually Is
A cloud kitchen — also called a dark kitchen, ghost kitchen, virtual kitchen, or delivery-only kitchen — is a restaurant with no customer-facing space. There are no tables, no waiters, no walk-ins, no dine-in. Every order arrives through an aggregator like Swiggy or Zomato, a direct ordering channel like WhatsApp or your own app, or in some cases through corporate-cafeteria contracts. The kitchen is optimised for throughput, packing, and rider hand-off — not for hospitality.
This shifts what your software has to do. A normal restaurant POS is designed around tables — KOT prints per section, billing per table, walk-in customer profiles, dine-in versus takeaway tax slabs. None of that matters for a cloud kitchen. What matters instead:
- Unified order feed from every aggregator you are listed on, in one screen, never missed
- Clear separation between virtual brands sharing the same kitchen
- Brand-coded packing flow so the packer never grabs the wrong box or sticker
- Rider hand-off coordination so orders do not sit cooling for 8 minutes
- Brand-wise cost and profit reporting so you actually know which brand earns
- Recipe-level inventory that deducts correctly when 5 brands share the same raw materials
A generic restaurant POS bolted with aggregator add-ons can be made to work for 1-2 brands at under 150 orders a day. Above that, the cracks show. Above 3 brands or 300 orders a day, generic POS becomes a liability — duplicate orders, missed tickets, packing errors, brand-mixed reports, and a kitchen team that cannot tell why margin keeps slipping.
The 9 Features Cloud Kitchen Owners Actually Need
Stop reading the 47-feature comparison tables from POS vendors. For a cloud kitchen, only 9 things matter. If your software does these well, you survive year one. If it does not, no amount of marketing or hero dish quality saves you.
1. Unified Aggregator Order Feed
Every order from Swiggy, Zomato, Magic Pin, EatSure, ONDC, and direct WhatsApp must land in one POS screen, time-stamped, brand-tagged, and acknowledged in under 5 seconds. No tablet juggling. No manual entry. No staff checking 4 different dashboards.
2. Multi-Brand Menu Separation
Each virtual brand owns its menu, prices, modifiers, photos, tax slabs, and aggregator listings independently. Changing the biryani price on Brand A does not touch Brand B. Brand A's KOT prints with Brand A's logo and SKU codes, never Brand B's.
3. Brand-Coded Packing Checklist and KOT
The packing station receives a KOT with the brand name and brand colour prominent at the top, the items listed in brand-specific SKU codes, the packaging type pre-printed (foil container, paper box, biodegradable bowl), and the brand sticker code so the packer pulls the right sticker without thinking.
4. Prep Time and Kitchen Routing per Brand
A biryani brand prep time is 12 minutes. A dessert brand is 4 minutes. A health-bowl brand is 6 minutes. Software must promise different prep times to the aggregator depending on which brand the order is for, and route the order to the right kitchen station automatically.
5. Recipe-Level Inventory Across Brands
When Brand A sells a chicken biryani and Brand C sells a chicken curry, both deduct from the same chicken stock. Inventory deduction is recipe-level, not menu-level. When chicken hits the low-stock threshold, every menu item across every brand using chicken auto-marks unavailable on every aggregator within 30 seconds.
6. Brand-Wise P&L
End of day, the system shows revenue, cost of goods, aggregator commission, packaging cost, allocated rent, allocated labour, allocated overhead, and net profit per brand. Brands earning money and brands losing money are visible at a glance. This is the single most undervalued feature in cloud kitchen software.
7. KOT Routing by Brand and Station
A single order containing items from Brand A and Brand B is split into 2 KOTs printed at the correct stations, with both expected at the same packing time so the rider does not wait. Multi-brand order coordination is a software problem, not a kitchen-discipline problem.
8. Multi-Outlet Central Management
Cloud kitchen groups running 3, 5, or 12 locations need one central menu management system that pushes price changes, new items, and aggregator stock updates to every location in one click. Per-outlet performance dashboards roll up to a group-wide view.
9. Packaging Cost Tracking
Packaging is 8-14 percent of cost-of-goods for cloud kitchens and most operators have zero visibility on it. Software must track packaging consumption per item, alert when packaging hits low stock, and roll packaging cost into brand-wise P&L.
If your current POS does even 6 out of 9 of these well, you are ahead of 80 percent of Indian cloud kitchens. If it does fewer than 4, you are operating blind.
Saffron POS: The Reference Build
Before we talk pricing, watch what cloud-kitchen-ready software actually looks like. This is Saffron POS — our reference cloud kitchen and restaurant build, 5 minutes, every screen recorded from a live deployment.
Saffron POS ships 11 cloud-kitchen-relevant modules out of the box — PIN-pad login for staff, real-time order dashboard, touch POS for direct ordering, KDS for kitchen stations, packing station console, brand-tagged KOT, recipe-level inventory, menu management with multi-brand isolation, order history with brand and aggregator filters, GSTR-ready reports, and central menu management for multi-outlet groups. Every feature you saw in that demo is the starting point of a Codingclave custom build — your version inherits all of it on day one.
For the full walkthrough with screenshots, read the Saffron POS feature deep-dive.
Real 2026 Pricing: Petpooja vs Restroworks vs Custom
The cost reality for an Indian cloud kitchen running 3-5 virtual brands at one physical location.
| Software | Monthly Cost | One-Time | 5-Year TCO | Owns the Code |
|---|---|---|---|---|
| Petpooja Cloud Kitchen plan | Rs 6,000-14,999/outlet | Rs 0 | Rs 3.6-9 lakh | No |
| Restroworks (Posist) | Rs 12,000-25,000/outlet | Rs 0 | Rs 7.2-15 lakh | No |
| Sapaad | Rs 7,000-12,000/outlet | Rs 0 | Rs 4.2-7.2 lakh | No |
| UrbanPiper middleware on top of any POS | Rs 4,000-9,000/outlet | Rs 0 | Rs 2.4-5.4 lakh add-on | No |
| Codingclave Saffron POS SaaS | Rs 4,000/outlet | Rs 0 | Rs 2.4 lakh | No (white-label) |
| Codingclave Custom Cloud Kitchen Build | Rs 4,000 hosting | Rs 1.5 lakh starter | Rs 3.9 lakh | Yes, full ownership |
A few notes on the numbers. Petpooja's headline pricing of Rs 6K starts looking honest only at the basic plan with 1-2 brands and a single aggregator. Add Swiggy plus Zomato plus Magic Pin, add KDS, add analytics, add multi-brand, and you are at Rs 12-15K per month before you have grown. Restroworks is a serious enterprise platform but priced for chains with 8-plus outlets, not for a 4-brand single-kitchen operator. Sapaad sits in the middle. UrbanPiper is not a POS — it is middleware that sits between your POS and the aggregators, often layered on top of Petpooja or your custom build to handle aggregator complexity centrally.
The Codingclave model is different. SaaS at Rs 4,000 per outlet per month covers everything for a single-location 1-3 brand operator who wants a working system tomorrow with no upfront cost. Custom build at Rs 1.5 lakh one-time is for the operator who wants to own the code, customise the workflow, and never pay per-outlet or per-brand licence fees again — typically pays back in 9-14 months versus SaaS, and dominates 5-year TCO.
Aggregator Integration: The Real Decision
For a typical Indian cloud kitchen in 2026, Swiggy and Zomato together drive 70-80 percent of orders. Magic Pin is growing fast, especially in Tier-1 cities after the Zomato Gold restructuring. EatSure is owned by Rebel Foods and is closed to non-EatSure brands. ONDC is around 2-5 percent of order volume for most cities outside Bengaluru and Delhi NCR. Direct WhatsApp ordering is 5-15 percent for brands with strong customer relationships.
Three integration paths to choose from.
Path A — Native POS integration. Your POS provider has direct integration with Swiggy and Zomato. Petpooja, Restroworks, and Sapaad all do this. You pay Rs 2-5K per outlet per month per aggregator. Pros — set-up is days, support is built in. Cons — you are locked to whatever the POS provider supports, new aggregator launches take months to integrate, menu sync errors are common.
Path B — Middleware (UrbanPiper, Deliverect). Middleware sits between your POS and every aggregator, handles menu sync, stock sync, price changes, and order routing from one console. UrbanPiper costs Rs 4-9K per outlet per month. Pros — every aggregator including new ones in one place, fewer sync errors, central reconciliation. Cons — extra monthly cost, additional vendor relationship to manage.
Path C — Direct aggregator APIs in a custom POS. Swiggy and Zomato both publish partner APIs. A custom build can integrate directly, bypassing middleware. Pros — zero per-outlet middleware fees, full control, custom logic for stock and price changes. Cons — developer time to build, ongoing maintenance when aggregators change their APIs.
Decision rule: 1-2 brands and under 200 orders a day use Path A. 3-plus brands or 300-plus orders a day use Path B if SaaS or Path C if custom. We default to direct API integration on every Codingclave custom build to remove the Rs 50-100K per year middleware tax permanently.
Aggregator Commission Reality and Brand-Wise P&L
This is the section that decides whether your cloud kitchen makes money. Real 2026 commission economics for an Indian cloud kitchen.
Swiggy base commission ranges from 18 to 25 percent of order value. Zomato base sits at 18 to 30 percent. Add 2 percent collection fee. Add platform fee of Rs 17.58 per order (hiked March 2026). Add Swiggy One and Zomato Gold customer surcharges that platforms recover from you. Add 50-100 percent of any visible discount you run on the platform. Effective all-in commission lands at 28-38 percent of menu price for a typical cloud kitchen.
Worked example for a Rs 300 biryani.
- Customer pays Rs 300 (or Rs 270 if 10 percent off)
- Aggregator takes Rs 95-115 in combined commission, fees, and discount funding
- You receive Rs 185-205 before food cost
- Food cost at 30 percent of menu price is Rs 90
- Contribution margin per order is Rs 95-115 before rent, labour, packaging, gas, electricity, software
Now picture this happening across 4 brands sharing one kitchen, where Brand A has 25 percent food cost and 28 percent effective commission, Brand B has 32 percent food cost and 33 percent commission, Brand C has 38 percent food cost and 35 percent commission, and Brand D has 28 percent food cost and 30 percent commission. Without brand-wise P&L, the operator looks at the kitchen-level number — say, Rs 6 lakh net profit on Rs 28 lakh revenue — and concludes everything is fine. With brand-wise P&L, they discover Brand A and Brand D earned Rs 8 lakh while Brand B and Brand C lost Rs 2 lakh. The two profitable brands are quietly subsidising the two loss-makers.
We have seen this pattern in every single multi-brand cloud kitchen we have audited. Every one. Brand-wise P&L is the most undervalued feature in cloud kitchen software, and almost nobody builds it well out of the box.
Multi-Brand Cost Allocation Rules
For brand-wise P&L to be honest, shared costs need fair allocation. Direct costs roll up cleanly. Shared costs need rules.
| Cost Bucket | Default Allocation Rule | Why |
|---|---|---|
| Rent | Share of revenue | Higher-revenue brands consume more brand-attention and packaging-rack space |
| Labour | Share of prep-minutes | A biryani brand uses far more labour per order than a dessert brand |
| Gas + electricity | Share of cook-minutes | Tandoor brands consume more energy per order than salad brands |
| Packaging (shared materials like foil) | Share of orders | Each order consumes roughly the same foil regardless of brand |
| Packaging (brand-specific boxes, stickers) | Direct to brand | Already brand-coded |
| Software cost | Equal split | Software supports each brand equally |
| Aggregator commission | Direct to brand | Already aggregator-tagged per order |
| Marketing spend | Direct to brand | Always brand-specific |
In Saffron POS, these allocation rules are configurable per-deployment. We set defaults that match Indian cloud kitchen economics, then tune them based on the operator's actual brand mix. Brand-wise P&L runs every night and lands in the founder's WhatsApp the next morning.
FSSAI Compliance for Cloud Kitchens in 2026
The licensing reality is simpler than most legal blogs make it sound. Three tiers.
Basic Registration. Rs 100 per year. For food businesses with annual turnover under Rs 12 lakh. Almost no real cloud kitchen running 3-plus brands stays under Rs 12 lakh, so this is rarely the right answer.
State Licence. Rs 2,000-5,000 per year. For turnover Rs 12 lakh to Rs 20 crore in a single state. This is what most Indian cloud kitchens need. Each physical kitchen address needs its own State Licence — running 4 virtual brands out of one Delhi kitchen needs one Delhi State Licence, not four. Virtual brands do not need separate FSSAI numbers.
Central Licence. Rs 7,500 per year. Mandatory if your annual turnover crosses Rs 20 crore, or if you operate cloud kitchens in two or more states, or if you have a registered head office separate from your kitchens. Most chains with 3-plus locations across states end up needing this in addition to a State Licence per kitchen.
Application is online through the FoSCoS portal (foscos.fssai.gov.in). Documents — kitchen layout, rental agreement, owner ID, water-test report, NOC from municipality if home-based, list of food categories. Processing time is 14-21 days for State, 30-60 days for Central.
The compliance trap most cloud kitchens miss in 2026. Swiggy and Zomato both verify FSSAI numbers at onboarding and during routine audits. Brand names on the aggregator must list the FSSAI number on the brand page. Packaging inserts must display FSSAI plus kitchen address. Hiding or fudging this triggers delisting — not warnings, immediate delisting, which kills the brand overnight. If you run 5 virtual brands and three of them are listing wrong FSSAI on Swiggy, you are one platform audit away from losing 60 percent of your revenue.
The Dark Kitchen Real-Estate Model
Cloud kitchen operators in 2026 split into three broad real-estate models. Your software stack needs to match.
Independent Kitchen Operator. You rent your own 500-1,200 sq ft commercial kitchen, build out your stations, hire staff, run 2-6 virtual brands. You own everything, including the operational headache. Saffron POS or any decent POS with multi-brand support works.
Cloud Kitchen Aggregator Tenant. You rent a station inside a cloud kitchen complex like Kitopi, Rebel Foods (Faasos kitchens), EatClub (formerly Box8), CloudBox, Curefoods. You get prep space, KDS hardware, sometimes shared dispatching. The host's software often handles aggregator integration and rider coordination. Your POS feeds into theirs through APIs or sometimes you run on their POS. Constraints vary widely — read the contract on data ownership before committing.
Virtual Brand Operator on a Host Kitchen. You run only the brand layer — menu, photography, marketing, aggregator listings. The actual cooking happens through a contract kitchen that you do not own. Brands like FreshMenu, Behrouz Biryani, Faasos, and many newer D2C food brands operate this way. Software needs are lighter on the operations side and heavier on brand-management, recipe transmission, and royalty reconciliation.
For Codingclave custom builds, we have shipped to operators in all three models. Independent kitchen is the cleanest fit for a single deployment. Aggregator tenant works if you negotiate API access into the contract. Virtual brand operator needs a different software stack focused on royalty reconciliation and recipe IP protection.
Codingclave's Cloud Kitchen Build at Rs 1.5 Lakh
Real deliverable scope for the Starter Cloud Kitchen Build, fixed price Rs 1.5 lakh one-time, 6-8 week delivery.
Included.
- One physical kitchen location, up to 6 virtual brands
- Multi-aggregator integration — Swiggy plus Zomato direct API, with UrbanPiper option if preferred
- Kitchen display system for 3 stations (configurable per kitchen layout)
- Packing station console with brand-coded labels and sticker SKU codes
- Recipe-level inventory shared across brands, auto stock-out push to aggregators
- Brand-wise P&L dashboard with configurable cost allocation rules
- GST-compliant invoicing per brand (separate brand legal entities supported)
- Daily, weekly, monthly reports per brand and consolidated
- Staff PIN login, role-based access for kitchen, packing, manager, owner
- Rider hand-off flow with pickup confirmation
- Packaging cost tracking per item and per brand
- WhatsApp ordering channel via WATI integration
Add-ons.
- Magic Pin integration — Rs 25,000 one-time
- EatSure integration — Rs 25,000 one-time
- ONDC integration — Rs 35,000 one-time
- Additional outlet — Rs 50,000 each with central menu management
- Loyalty programme with WhatsApp campaigns — Rs 40,000 one-time
- AI demand forecasting for inventory — Rs 60,000 one-time
Hosting and support. Rs 4,000 per month all-in. Cloud hosting on AWS Mumbai region, weekly backups, 24x7 monitoring, priority WhatsApp support, quarterly feature releases.
What you own. Full source code. No per-outlet licence fees ever. No per-brand fees. No order commission of any kind. No vendor lock-in. White-label option included at no extra charge. Detailed scope on the Restaurant POS product page.
Compare against 5 years of Petpooja at Rs 12K per month for one outlet — Rs 7.2 lakh — and the maths is clear above year two.
Anonymised Case Study: 6-Brand Bengaluru Cloud Kitchen Group
One of our recent deployments. Cloud kitchen group in HSR Layout Bengaluru, 6 virtual brands sharing one 900-sq-ft kitchen, 380-450 orders a day across all brands at peak. Before Saffron POS — Petpooja Pro plan plus Zomato and Swiggy tablets running side-by-side, plus a manual Excel sheet for brand-wise revenue. Three real problems.
Problem 1. Order misroutes between brands. Brand-mixed orders printed on one KOT, packer pulled wrong packaging for the smaller items roughly 4 percent of the time, customer ratings averaged 4.0-4.1 with most one-star reviews citing wrong-brand packaging.
Problem 2. Brand-wise profit invisible. Owner believed all 6 brands were profitable because total kitchen P&L was positive at Rs 4.2 lakh monthly net. No brand-level visibility.
Problem 3. Stockouts on aggregators. Chicken inventory low alert never auto-pushed unavailable status to Swiggy and Zomato. Result — orders accepted that could not be fulfilled, customer cancellations, aggregator penalty.
After Saffron POS deployment, 7 weeks total including data migration.
Order misroutes dropped from 4 percent to under 0.4 percent because every brand prints its own KOT with brand colour, brand SKU codes, and brand sticker code. Customer ratings climbed to 4.4-4.5 within 8 weeks. Brand-wise P&L revealed that 2 brands earned Rs 5.8 lakh net while 4 brands collectively lost Rs 1.6 lakh — owner shut down 1 brand and repositioned a second, total kitchen profit climbed to Rs 6.1 lakh net within 11 weeks. Recipe-level inventory now auto-pushes stockouts to aggregators in under 45 seconds, aggregator cancellation penalty dropped by 78 percent. Total project cost was Rs 1.5 lakh starter plus Rs 25,000 for Magic Pin add-on plus Rs 4,000 monthly hosting. ROI in month 4 from the brand-mix correction alone.
When NOT to Hire Codingclave
Honest disclosure. A Codingclave custom build is not the right answer for everyone.
Use SaaS instead if. You run 1-2 virtual brands at 1 location, under 150 orders a day, no plans to scale beyond 1 location in the next 18 months, no in-house tech or operations leader, and you want to launch in 7 days. Petpooja or Sapaad will work, total cost Rs 7-12K per month all-in, and you will not feel the cracks until you grow.
Use Restroworks instead if. You run 12-plus outlets across multiple states, you need enterprise-grade compliance, audit logs, multi-language support, and your annual software budget allows Rs 25-50 lakh comfortably. Restroworks is built for that scale.
Use Codingclave Saffron POS SaaS if. You want our cloud kitchen software running tomorrow at Rs 4,000 per outlet per month, no upfront, no commitment, and you accept that the code belongs to us until you upgrade to a custom build.
Use Codingclave Custom Build if. You run 3-plus brands or have plans to scale to multi-outlet within 18 months, you want full code ownership and no per-outlet licence fees, you have Rs 1.5-3 lakh available upfront, and you want to never depend on a SaaS vendor's roadmap.
The decision is rarely about features — most modern cloud kitchen POS systems can be coerced into doing the same things eventually. The decision is about who owns the code, who controls the roadmap, and whose margin gets compounded by per-outlet licence fees as you grow.
Ready to Build
If your cloud kitchen is at the point where you are tired of duct-taping Petpooja, juggling aggregator tablets, and Excel-tracking brand revenue, here is what to do.
- Watch the Saffron POS 5-minute demo if you have not already
- Read the Saffron POS feature deep-dive for screenshots of each module
- Visit the Restaurant POS product page for the full scope, add-ons, and timeline
- WhatsApp me at +91 92771 84741 with your current order volume, brand count, and aggregator mix — I will respond personally with a fit-or-not assessment within a working day
No sales calls. No deck. No discovery questionnaire. Just a founder-to-founder conversation about whether your operation is at the right stage for a custom build, or whether Saffron POS SaaS or even Petpooja is a better fit for now.
Related Reading
- Saffron POS Restaurant Management Software Demo India 2026
- Best Restaurant POS Software India 2026
- How to Start a Restaurant in India 2026
- Restaurant POS Software Cost India 2026
- Digital Marketing for Restaurants India 2026
About the Author
Ashish Sharma is the founder of Codingclave, a software studio in Lucknow that has shipped 16-plus restaurant POS deployments since 2019, including independent cafes, multi-outlet QSR chains, fine-dining brands, and cloud kitchen groups running between 3 and 9 virtual brands. Saffron POS is the studio's reference build — used as the starting point for every Codingclave custom restaurant deployment.
WhatsApp +91 92771 84741 or connect on LinkedIn.
Frequently asked questions
Cloud kitchen software is restaurant POS rebuilt for a delivery-only, multi-brand, no-dine-in operation. A regular restaurant POS assumes tables, KOT printers per section, dine-in billing, walk-in customers, and one brand identity. Cloud kitchen software assumes the opposite — every order arrives from Swiggy, Zomato, Magic Pin, EatSure or your own ordering app, you run 3-8 virtual brands out of the same physical kitchen, packing is the bottleneck instead of table service, and your rider hand-off window decides whether the order is one-star or five-star. The features that matter shift completely. You need unified aggregator order feed, brand-wise menu separation, packing station orchestration, brand-tagged KOTs, recipe-level inventory shared across brands, and brand-level P&L. Most generic POS systems bolt these on as add-ons — they were never built for it. That is why 68 percent of new cloud kitchens that fail in year one cite operational chaos as the trigger, even when the food and the brand are strong.
Real prices for an Indian cloud kitchen running 3-5 virtual brands out of one location. Petpooja Cloud Kitchen plan starts at Rs 6,000 per month for one outlet and climbs to Rs 8,000-14,999 per month once you add aggregator integration, KDS, and analytics add-ons. Restroworks (formerly Posist) sits at Rs 12,000-25,000 per month per outlet for cloud kitchens, premium for the brand. UrbanPiper middleware adds Rs 4,000-9,000 per month per outlet just for the order aggregator layer if you build your own POS. Sapaad sits at Rs 7,000-12,000 per month. Codingclave Saffron POS SaaS starts at Rs 4,000 per month per outlet, white-labelled, with multi-brand built in. Codingclave custom cloud kitchen build is Rs 1.5 lakh one-time for a starter deployment with brand isolation, multi-aggregator sync, KDS, and brand-wise P&L. Over five years a 4-brand single-location cloud kitchen pays Rs 6-15 lakh on SaaS or Rs 2-4 lakh on a one-time custom build.
Multi-brand isolation is the single hardest cloud kitchen software problem. The minimum requirement is that every menu item, modifier, image, price, tax slab, and aggregator listing belongs to exactly one brand, even though the kitchen station handling it is shared. The KOT printed for the packing line must show the brand prominently so the packer pulls the right packaging, the right sticker, the right insert. The customer-facing invoice must show only the brand the customer ordered from, not your legal entity name or your other brands. Inventory must deduct from a shared raw material pool but report cost-of-goods by brand. Reports must show revenue, food cost, aggregator commission, packaging cost, and profit by brand separately. Most SaaS platforms do this poorly — they treat brands as cosmetic. Saffron POS treats brands as first-class objects, so a 6-brand operation looks like 6 independent restaurants in the data model while sharing one physical kitchen, one inventory, one staff.
For most Indian cloud kitchens, Swiggy and Zomato together drive 70-80 percent of order volume. Magic Pin (now a serious player after the Zomato Gold split), EatSure (Rebel Foods owned), and direct WhatsApp ordering split the rest. ONDC is growing but still only 2-5 percent of order volume for most cities outside Bengaluru and Delhi NCR. The decision matrix. If you run 1-2 brands and under 200 orders a day, Petpooja's native Swiggy plus Zomato integration is enough. If you run 3-plus brands or 300-plus orders a day, you need either a custom build with direct aggregator API access or a middleware like UrbanPiper or Deliverect on top of your POS. Middleware costs Rs 4,000-9,000 per outlet per month but gives you menu sync, stock sync, price change push, and reconciliation across every aggregator in one console. Direct API is free but you spend developer time. Anything that depends on a human pasting prices into 4 dashboards is broken at scale.
Swiggy 18-25 percent base commission, Zomato 18-30 percent base commission, plus 2 percent collection fee, plus platform fees of Rs 17 per order (hiked in March 2026), plus Swiggy One and Zomato Gold customer surcharges that platforms recover from you, plus 50-100 percent of any visible discount you run. Effective all-in commission for a typical cloud kitchen sits at 28-38 percent of menu price. For a brand selling a Rs 300 biryani, the cloud kitchen takes home Rs 185-215 before food cost. If your food cost is 30 percent of menu price, your contribution margin per order is Rs 95-125 before rent, labour, packaging, and gas. That is why brand-wise P&L matters — a brand with 25 percent food cost and 28 percent effective commission is wildly profitable, a brand with 38 percent food cost and 35 percent effective commission is silently bleeding you, and without software-level brand separation you cannot see which is which.
Depends on turnover and number of states. If your cloud kitchen operates from a single address and total annual turnover is under Rs 12 lakh, FSSAI Basic Registration at Rs 100 per year is enough — but almost no cloud kitchen running 3-plus brands stays under Rs 12 lakh, so this rarely applies. If turnover is Rs 12 lakh to Rs 20 crore and you operate in one state, you need State Licence at Rs 2,000-5,000 per year. If you operate cloud kitchens in two or more states, or your annual turnover is over Rs 20 crore, you need Central Licence at Rs 7,500 per year. Each physical kitchen address needs its own State Licence — running 4 brands out of one Delhi kitchen needs one Delhi State Licence, not four. Each virtual brand does not need a separate FSSAI. But each brand must display the same single FSSAI number on Swiggy, Zomato, and the packaging insert. Hiding it triggers delisting in 2026 — both platforms verify FSSAI on every onboarding.
Standard high-volume cloud kitchen workflow. Order lands from Swiggy or Zomato into your POS through middleware or direct API. POS auto-routes to a kitchen display screen tagged by brand and item type — wet curry station, tandoor station, biryani station, dessert station. Each station ticks off items as ready. Items flow to packing station. Packer scans brand-coded KOT, pulls brand-specific packaging from labelled racks, assembles, applies brand sticker, hands to dispatch tray tagged for the rider arriving in next 4 minutes. Rider scans pickup, system notifies aggregator, customer gets ready-for-pickup ping. Total target time from order to handover for a 400-orders-a-day kitchen is 12-18 minutes. Without KDS and brand-tagged packing flow, you hit 25-35 minutes, which drops your rating below 4.2 and gets you demoted in Swiggy and Zomato search rankings — a death spiral for a cloud kitchen.
Cost allocation across shared resources is where most cloud kitchen owners go wrong. Direct costs are easy — food cost per item rolls up to its brand, packaging cost is brand-specific, aggregator commission is brand-specific. Shared costs need allocation rules. Rent split by share of orders or share of revenue. Labour split by share of orders or share of prep time (we recommend prep-time-weighted because a dessert brand uses far less labour per order than a biryani brand). Gas and electricity split by share of cook-time. Packaging shared materials like foil split by share of orders. Software cost split equally. Once allocation is set up, the system computes brand-wise P&L every day. Brands losing money show up immediately. We have seen 6-brand kitchens where 2 brands earned 140 percent of profit and 4 brands together lost 40 percent — but the operator thought everything was fine because the kitchen as a whole was profitable. Brand-wise P&L is the most undervalued cloud kitchen software feature.
Starter Cloud Kitchen Build at Rs 1.5 lakh one-time fee covers one physical kitchen, up to 6 virtual brands, multi-aggregator integration via UrbanPiper or direct API (Swiggy plus Zomato, Magic Pin and EatSure on Rs 25,000 add-on each), kitchen display system for 3 stations, packing station console with brand-coded labels, recipe-level inventory shared across brands, brand-wise P&L dashboard, GST-compliant invoicing per brand, daily-weekly-monthly reports, staff PIN login, role-based access, rider hand-off flow, packaging cost tracking, and a customer-facing WhatsApp ordering channel. Delivery is 6-8 weeks. Hosting plus support after launch is Rs 4,000 per month. Built on the same Saffron POS codebase shown in our 5-minute demo. Owner keeps full code ownership — no SaaS lock-in, no per-outlet license fees ever, no commission of any kind on orders. For chains adding a second or third location, each additional outlet is Rs 50,000 with central menu management.
Real autopsy data from cloud kitchens we have rebuilt after a first-year failure. Roughly 30 percent failed because the food and the brand were never strong enough — software cannot fix that. Roughly 20 percent failed because aggregator dependence plus high commission squeezed unit economics — partly fixable with brand-wise P&L and aggressive cost allocation. Roughly 35 percent failed because of operational chaos — duplicate orders, missed orders, wrong packing, slow KOT, no inventory visibility, no idea which brand was losing money — this is the software-fixable bucket. The remaining 15 percent failed because of capital starvation or rent shocks. Software is not magic, but it is the single most controllable factor. The operators who survived past year one almost always had either a strong custom POS or an aggressively configured Petpooja, Restroworks, or Sapaad setup. The ones who failed almost always ran on a generic restaurant POS treating their cloud kitchen as if it were a normal restaurant with delivery on the side.