Most restaurants think they need a central production kitchen/unit (CPU) far earlier than they actually do. A few need one on day one. The trick is knowing which you are.
Our own numbers show why it's worth asking the question properly. Of the brands running a central production unit with us, 62% operate three or more sites, and 38% run from a single location. There's no middle: no one takes a CPU at two sites. It's two clear groups, and they arrive for completely different reasons.
Nearly two-thirds centralise because they're scaling. But well over a third do it from a single restaurant, which is far too many to treat as an exception. Whether you need a CPU has surprisingly little to do with how many sites you have, and everything to do with which of these two you are. Work that out before anything else, because almost every other decision follows from it.
Reason one: the specialist single-site operator
For a small number of brands, a CPU makes sense immediately, before a second site is even on the table.
It's almost always the same situation: a signature product that's labour-intensive, equipment-heavy or made at high volume, and a Central London kitchen that simply can't house the making of it. The restaurant kitchen was designed to cook and serve, not to produce at scale, and the signature product has outgrown it. We see this most with bakeries, Chinese concepts and pizza brands.
Bun House is a good example. Although they now have multiple sites, they came to us with a single restaurant. Their cult-followed Cantonese buns needed dedicated space to produce at scale: room for specialist equipment, loading and deliveries. For them a CPU wasn't a growth decision at all. It was essential to the product itself.
The tell, if you're wondering whether you're in this category: it's not about how many sites you have or plan to have. It's about whether the thing you're known for has become too big or too specialist to keep making where you serve it. If your kitchen is fighting your product for space, you may need a CPU at one site, and waiting for a second won't change that.
Reason two: the group hitting three or four sites
For most operators, though, the CPU conversation starts later, at three or four locations. And the driver is different. It's not capacity. It's consistency.
This is worth understanding properly, because most operators misread it when it first happens, and reach for the wrong fix.
Somewhere around the third or fourth site, the food stops being quite the same everywhere. Not dramatically. The signature dish is slightly better at the original site than the newest one. A sauce tastes marginally different depending on which kitchen made it. Nobody can point to a single failure, because there isn't one. It's drift, and the instinct is to fix it by tightening the recipes: writing them down more precisely, training harder against them.
That rarely works, because the recipe was almost never the problem. Ask any chef to make the same dish in two kitchens and you'll get two subtly different results, even from an identical recipe. The variables that move the outcome mostly aren't in the recipe. They're in the environment: an oven that runs hotter, a supplier substitution at one site, a slightly different technique, produce at a different point of ripeness, a busy Saturday that forces a shortcut. Multiply those across several kitchens and a dozen dishes, and drift isn't a risk. It's arithmetic.
Centralising fixes it because it collapses the number of times each thing is made. Produce a signature component once, in one place, by one specialist team, and every site receives the identical thing. There's no second version, because there's no second kitchen making it. The variance has nowhere to enter.
Kricket and Din Tai Fung run this beautifully. Skilled chefs produce the specialist components centrally, the broths beneath every Din Tai Fung dish, Kricket's signature curry pastes, so each restaurant delivers the same experience, and does it more efficiently. The knock-on effects are the part operators underestimate: with core production centralised, purchasing consolidates, waste drops, staffing simplifies, and new site openings get faster, because a new location doesn't need to recreate your whole production capability, just finish and serve what the central kitchen sends.
What to centralise
Whichever reason brought you here, the same question decides whether centralising works: what moves to the central kitchen, and what stays on site?
Get it wrong in one direction, by centralising too little, and you keep drifting. Get it wrong in the other, by centralising too much, and you strip out the character customers came for. The principle that runs through the operators who get it right: keep in view what the customer values, and centralise everything behind it.
Din Tai Fung fold the dumplings in front of the customer, because that's the theatre people come for, but the stock and dough behind them are made centrally. Kricket serves in the room, but the curry pastes that define the food are produced once, centrally. The visible, valued, finishing step stays on site. The specialist, invisible, consistency-critical production moves central.
The one-line version
So: centralise when your product is too specialist to fit in a restaurant, or too important to leave inconsistent across several of them.
The first is a small group who need a CPU from day one. The second is most operators, who reach it around their third or fourth site. Knowing which you are is the whole decision, and it's worth working out before the food starts drifting, not after.
Wondering which you are? Talk to us about your production →, or see how multi-site operators work with us →.
