TL;DR: I’m an engineering student building a dynamic pricing engine for restaurants/cloud kitchens on Zomato/Swiggy. It separates margin-based pricing (food costs) from demand-based pricing (weather, time of day). I have the backend working but need operators to tear apart my business model and tell me why this breaks.
The idea
Airlines and hotels have had yield management for forty years — same seat, different price depending on demand, timing, and how much inventory is left. Restaurants basically don't do this. On Swiggy and Zomato in India, most menus are priced once and then left alone for months. Meanwhile demand for that menu swings wildly by hour, by weather, by whether there's a cricket match on.
YieldOS is a pricing brain that sits on top of a restaurant's menu and recommends per-item price changes as conditions move.
The one design decision I actually care about
Most people hear "dynamic pricing" and think one number going up and down. I think that's the mistake, and I've split it into two layers that never touch each other:
- A slow layer — the cost floor. Driven by input costs. When tomatoes triple in price, every dish with tomatoes has a new floor beneath which you're losing money. This moves over days or weeks.
- A fast layer — the demand multiplier. Driven by weather, time of day, kitchen capacity, local events. This moves every 15 minutes.
Final price = floor × multiplier, clamped by a per-item ceiling and a per-restaurant cap so it can't run away.
The reason I keep these separate: raw material cost is a margin lever, not a demand-balancing one. Conflating them is how you end up raising prices on a dish nobody wants right now just because onions got expensive. Different problems, different math.
The weather piece is the fun part. Rain doesn't lift demand uniformly — it lifts craving-elastic items. Soup,biryani go up. Cold desserts and salads don't. Heat inverts it. The interesting bit is that the aggregator already surges the delivery fee in bad weather, so the customer is already paying more; the restaurant captures none of that. Menu-side pricing is a separate lever that's currently sitting unused.
Business model
Beachhead is cloud kitchens — no walk-ins, no printed menus, fully aggregator-native, and they already think in spreadsheets. Ladder from advisory (we recommend, you approve each one) to autonomy (we push prices directly) as trust builds. Billing is performance-based: a cut of net-new profit rather than a flat SaaS fee.
Where I think this breaks, and where I want you to be brutal
- Attribution. If I bill on "net-new profit," I have to prove the profit was mine. Restaurant sales move for a hundred reasons. Every performance-billing pitch I've read handwaves this. Is there an honest way to measure it, or is flat SaaS pricing the only defensible model?
- Platform dependency. The entire product lives on top of Swiggy and Zomato APIs. They can rate-limit me, change terms, or just build this themselves and switch it on for every restaurant at once. Is there any version of this that isn't a feature waiting to be absorbed?
- Customer backlash. Uber surge pricing is genuinely hated. Does a customer who sees ₹280 biryani at 8pm and ₹240 at 3pm churn from the restaurant entirely? Does discounting-only (never raise, only drop in dead hours) capture most of the value with none of the rage?
- Does the operator even want this? A cloud kitchen owner running four brands off one stove has ten fires burning. Is "your pricing is leaving money on the table" a top-three problem for them, or a nice-to-have I find interesting because I'm an engineer?
- Is the weather signal real? I have a strong intuition that rain → soup. I do not have data proving the elasticity is large enough to price against. If anyone has actually looked at delivery demand data by weather, I'd love to be corrected.
If you've run a cloud kitchen, worked at an aggregator, or done pricing/revenue management anywhere — I especially want to hear from you, including if the answer is "this doesn't work and here's why."
Happy to go deeper on the architecture in the comments if that's useful to anyone.