Cloud kitchens are a software problem dressed up as real estate
Six brands, one prep line, eight aggregators. Cloud kitchen economics only work when the system can keep up with the chaos — and that is exactly where most platforms stop.
Cloud kitchens are usually pitched as a real-estate story: cheap square metres, no dining room, no service staff. The reality on the ground is different — what eats the cost advantage isn't rent, it's coordination overhead.
Why complexity doesn't grow linearly
Running one brand on one platform gives you one connection point. Six brands across eight platforms gives you 48. Each arrives with its own menu format, its own promotion logic and its own cancellation rules.
The prep-line reality
Six brands' orders land on one prep line, and kitchen staff care about which station does what, not which brand it belongs to. A brand-based KDS screen is therefore the wrong abstraction in the field — it needs to be station-based.
- Orders should be split by station, not by brand.
- The packing point should be the only place brand identity is visible.
- Prep-time estimates should be computed from line load, not per brand.
- Stock should be held at ingredient level, not brand level — six brands use the same chicken.
The invisible part of aggregator commission
The commission rate is in the contract; the cost of cancellations and claims is not. Across the operations we studied, the monetary value of staff hours spent on claim handling added an average of 1.8 points on top of commission. That rarely appears in the margin calculation at all.
Our job had stopped being cooking and become working out what eight different systems wanted at the same moment. That was exactly the problem the software needed to solve.
