Cloud kitchen profitability analytics in India

Many cloud kitchens in India do not fail because of bad food. They fail because nobody measured unit economics at the SKU level until cash was already tight. Set up the data from day one.

Why do cloud kitchens struggle after the first year?

The model looks easy. Launch a brand, list on Swiggy and Zomato, hire a small crew and start cooking. Capital needs are a fraction of a dine-in restaurant, and revenue starts fast.

The trouble comes as order volume grows and costs become clear. Operators who survive measure more than revenue and order count. They know the economics of every SKU, every channel and every kitchen. That tells them whether growth will add profit or only add losses.

What is the difference between COGS and contribution margin?

Many operators use cost of goods sold (COGS) as their main profit number. COGS is only the ingredient cost of a dish, so on its own it gives a rosier picture than the business deserves.

Here is an example with assumed numbers. A biryani costs ₹80 in ingredients and sells for ₹280 on Zomato, which looks like a 71 percent gross margin. Now take off the platform commission (assume 22 percent, which is ₹61.60), packaging of ₹15 to ₹25, a promotional discount share of ₹20 to ₹40 and a share of kitchen overhead. What remains may be ₹40 to ₹60, a contribution rate of roughly 15 to 21 percent.

What does contribution margin measure?

Contribution margin is the revenue left after all variable costs: food, packaging, aggregator commission, delivery-related costs and any discounts you fund. It shows how much each order adds towards fixed costs such as rent, salaries and utilities. The business makes a profit only when total contribution exceeds those fixed costs.

Most operators track COGS and revenue. Few track contribution margin per SKU, per channel and per period. That gap lets a kitchen look busy for a year while it spends its starting capital on orders that never covered their variable costs.

How does per-SKU profitability change decisions?

Assign food, packaging, commission and discount cost to each menu item and the pattern is usually clear. A part of the menu earns nothing or loses money on every sale.

This is often not a pricing mistake. The items may sell mostly during promotions. Ingredient prices may swing, as chicken does in the monsoon. Or the dish may need premium packaging that the price never covered.

What should a per-SKU framework track?

Update these for every menu item at least weekly:

• standard recipe cost at current ingredient prices, updated when supplier invoices are recorded
• packaging cost for that item, not an average across the menu
• average selling price after platform-funded and restaurant-funded discounts
• average commission rate for that item
• order frequency and share of total orders, since high-frequency, low-margin items hurt most
• ratings per item, where the aggregator API allows it

With this in place, menu decisions become numbers. You can see what to promote, reprice or remove, and which dishes deserve a place at the top.

Why is aggregator dependency a trap for cloud kitchens?

A cloud kitchen has no walk-in customers. Every order arrives through a digital channel, and in India that mostly means Swiggy or Zomato. A change to their ranking, commission or search can hit the whole business at once, and there is no dine-in revenue to cushion it.

If almost all your revenue comes from two platforms and you have no direct ordering channel, you are running a kitchen on their behalf. Operators with several brands and cities reduce this risk with direct ordering, WhatsApp Business and corporate catering. These take time to build, and they give resilience that platform-only kitchens lack. See our delivery and quick commerce work for how we think about channels.

Why is monthly reporting too slow?

Many kitchens compile numbers at month end, see a loss, and learn about it weeks late. By then the menu was promoted, the ingredients were ordered and the staff were rostered.

What does daily reporting give you?

A dashboard updated every morning with yesterday’s sales, cost and margin lets you stop a promotion that drives volume but not margin. You catch an ingredient price spike before it distorts the month. You can answer a competitor’s new listing with an offer of your own.

This does not need heavy technology. It needs your POS or order system to feed an analytics layer that works out the main figures for you.

What should you set up from day one?

Operators who ask “how do I set this up correctly?” build sustainable kitchens. Those who ask “how do I fix this?” are usually already in distress. A new cloud kitchen should have:

• a POS that records every order with item detail, discounts and channel
• a recipe costing system with a standard cost for every item, updated as prices change
• aggregator API connections that pull commission, payout and order data automatically
• a daily dashboard of revenue, COGS, contribution margin and order count by brand and channel
• a weekly per-SKU report that flags items below their target margin

Why use alerts and thresholds?

Set alerts for when a metric crosses a line you chose. If food cost for a brand goes above your target in a week, someone should investigate at once. If a popular SKU falls below its minimum contribution margin, it should reach the menu team as an action item. Each kitchen’s thresholds depend on its own costs, so define them at launch instead of after the first crisis.

What changes when you scale to many kitchens?

With several locations or brands, you need to know which brand is profitable, which kitchen has the best economics, and whether a new brand in an existing kitchen helps or only adds complexity. That needs brand-level P&L, overhead allocation per kitchen and handling of shared ingredients, such as the same dal going into three branded dishes.

Our restaurant analytics platform is built for this level of detail, including per-SKU visibility and channel-level margins. If you want to see how it would look for your kitchens, contact us.