Why So Many Cloud Kitchens in India Are Shutting Down

Between 25% and 30% of cloud kitchens in India close within their first year of operation. An NRAI survey in 2023 found that nearly half the cloud kitchens in Delhi, Mumbai, and Bangalore were running at a loss (BBFT, 2024). Those are not small numbers for an industry that was supposed to be the low-cost, low-risk alternative to opening a restaurant.

The market itself is growing. India’s cloud kitchen segment hit USD 1.24 billion in 2025 and is projected to reach USD 3.69 billion by 2034 (IMARC Group, 2025). Money is flowing in, but a large chunk of operators aren’t surviving long enough to see any of it.

The reasons aren’t mysterious. They follow a pattern, and most of them come down to five operational mistakes that repeat across cities, cuisines, and price points.

Key Takeaways

• 25-30% of Indian cloud kitchens shut down within year one (BBFT, 2024)
• Aggregator commissions of 20-30% per order are the single biggest margin killer
• Bloated menus push food cost above 40%, making profitability nearly impossible
• Operators who shift 25-30% of orders to direct channels survive longer than those who don’t

Why Does Aggregator Dependency Kill Cloud Kitchens?

Swiggy and Zomato charge 20-30% commission on every order. To illustrate what that does to margins, take a typical Rs 400 biryani order. The kitchen receives Rs 280-320 after the platform takes its cut. Subtract food cost (Rs 120-140 at 30-35%), packaging (Rs 15-20), and the allocated share of rent, gas, and wages.

What’s left is roughly Rs 40-60 in profit on a good day. On days when the operator also runs a platform discount to stay visible, profit drops to Rs 10-15 or disappears entirely.

Commission rates alone wouldn’t be fatal if kitchens had other places to get orders. But most don’t. We see this across food businesses on Petpooja all the time: an operator at month six still pulling 100% of revenue from aggregators.

By that point, they’re paying more in commissions than they spend on ingredients, and nobody in the kitchen has noticed because the Swiggy dashboard shows “order count is growing.” It doesn’t show contribution margin per order. That number, the one that actually matters, lives nowhere in the aggregator’s reporting.

Rebel Foods, the largest cloud kitchen company in India with 450+ kitchens and brands like Faasos, Behrouz Biryani, and Oven Story, reported a net loss of Rs 336.6 crore in FY25 despite generating Rs 1,617 crore in revenue (Inc42, 2025). If a company operating at that scale with that kind of brand portfolio is still losing money, independent operators with no brand recognition and no direct ordering channel are fighting with both hands tied.

What Happens When the Menu Is Too Big?

Consider a typical scenario: 35 items on the Zomato listing across three cuisines. Indian, Chinese, Continental. Looks great on the app. Inside a 300 sq ft kitchen, the cook is switching between Schezwan sauce and biryani masala every other order, the mise en place for three different cuisines doesn’t physically fit on two prep tables, and by 8:30 PM the food quality slips because everything is being made in a rush.

The financial damage is quieter but worse. In a menu this large, 15-20 items typically sell once or twice a week at best. Ingredients for slow-moving dishes sit in the fridge until they expire. Food cost climbs past 40% and parks itself there.

Unlike a dine-in restaurant where a waiter can steer a customer toward a slow-moving dish (“the chef’s special today is excellent, sir”), a cloud kitchen has no such lever. The item either sells on the app or it rots in the fridge. Food cost control in a delivery-only model works differently for exactly this reason.

The fix is boring but it works: launch with 8-12 items in one cuisine. Run it for 45-60 days. Look at what actually sells. Then build the next round of menu items from that data, not from what you personally enjoy cooking.

Why Do Ratings Drop Faster Than Cloud Kitchens Can Recover?

When a dine-in customer has a bad experience, the manager walks over, apologises, maybe sends a free dessert. The relationship gets a second chance. A cloud kitchen doesn’t get that.

For example, imagine the dal arriving cold because the delivery rider spent 10-12 minutes finding the right tower in a housing society. The customer opens the box, sees lukewarm food, taps 2 stars, and moves on. The kitchen owner finds out three hours later when the rating notification pops up. By then there’s nothing to fix.

Aggregator ratings compound downward, and that’s what makes them particularly vicious. Here’s a common pattern: a kitchen’s rating slides from, say, 4.3 to 3.9 over one bad weekend. Swiggy’s algorithm responds by pushing the listing lower in the neighbourhood feed. Fewer people see it, fewer orders come in.

The operator panics, turns on a 30% discount to pull volume back. Orders return, but at near-zero margin. The kitchen is now spending money to get orders that don’t cover costs, and the rating still hasn’t recovered because the underlying quality problem (cold food, late dispatch, leaking boxes) hasn’t been diagnosed.

The diagnosis part is where most operators are blind. Was the rating drop about food quality? Packaging? Rider delays? The Zomato dashboard says “your rating dropped.” It doesn’t say why.

A cloud kitchen POS that tracks KOT-to-dispatch time per order can show, for example, that Thursday 8 PM orders take 22 minutes to prepare versus 14 minutes on Tuesday. Now the operator knows Thursday’s prep line is the bottleneck. Without that data, it’s guesswork dressed up as troubleshooting.

How Does Multi-Brand Complexity Sink Small Operators?

Two brands from one kitchen. Double the listings, double the orders, same rent. Every cloud kitchen owner has run this calculation in their head by week three. Very few have done it successfully by month six.

Adding a second brand doesn’t just mean a new menu on Swiggy. It means a separate ingredient inventory, different packaging stock, a second set of quality standards, and a kitchen that now has to sort 15 incoming orders at 8 PM across two brands without mixing them up.

A common scenario we’ve seen play out: the cook grabs the wrong branded container during rush hour. A burger brand’s packaging goes out with a biryani order inside it. The customer flags it, the review lands on the wrong listing, and both brands take a ratings hit.

The food itself was fine. The problem was the absence of a system that tags each KOT to the correct brand before it reaches the packing station.

Rebel Foods ran this experiment at the largest scale possible: 20+ brands across 450+ kitchens. The result? Only 4-5 brands (Faasos, Behrouz Biryani, Oven Story, Zomoz) generate meaningful revenue. The other 70% are paused, tiny, or shelved (as per the Inc42 analysis referenced earlier).

If the biggest cloud kitchen operator in the world couldn’t make 20 brands work, adding a second brand in month two from a rented kitchen in Hadapsar is probably premature. Get the first brand to 60-80 daily orders. Then consider brand number two.

Why Don’t Operators Know They’re Losing Money Until Month-End?

Here’s a hypothetical that plays out in cloud kitchens daily. 70 orders on a Wednesday. Swiggy dashboard shows Rs 28,000 in gross sales. The owner looks at the number, feels relieved, and goes home thinking the day was good.

Was it? Let’s walk through the maths. Commission at 25%: Rs 7,000 gone. Food cost at 30-35%: another Rs 8,400-9,800.

Packaging: Rs 1,400. Rent, salaries, gas, electricity (divided across 30 days): Rs 6,000-7,000.

Add it up. Net profit from those 70 orders: somewhere between Rs 1,000 and Rs 3,000. On some days that number turns negative, and the owner won’t know until someone sits down with Tally at the end of the month. By then, three weeks of negative-margin days have already drained the operating reserve.

The kitchens that survive past year one share a habit, not a tool. They check their numbers every single day. They know by 6 PM whether the day’s orders covered costs or fell short. Item-level profitability, not just “total sales.” Having a POS that sends a daily P&L summary to WhatsApp (which is what Petpooja POSS does for cloud kitchens) removes the most common excuse we hear: “I’ll sit with the numbers over the weekend.”

Across 1,00,000+ food businesses on Petpooja, the cloud kitchen disadvantages that catch operators off guard almost always involve a delayed awareness of their own unit economics.

Conclusion

The cloud kitchen model itself isn’t the problem. Rs 10-15 lakh entry, no dining hall rent, 15-25% net margins when run well. The problem is a playbook that most operators copy from each other without questioning: 30-item menu on day one, 100% aggregator dependency at month six, no daily cost tracking, a second brand launched before the first one can stand on its own, and discount-driven panic the moment ratings dip.

Operators who last beyond twelve months tend to do none of those things. Small menu, direct ordering from month two, daily P&L on their phone, one brand until it’s doing 60+ orders a day without paid boosts.

Frequently Asked Questions