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. The common industry observation is that the monetary value of staff hours spent on claim handling adds another 1–2 points on top of commission. That rarely appears in the margin calculation at all.
When your job stops being cooking and becomes working out what eight different systems want at the same moment, the problem to solve is not in the kitchen — it's in the software.
