Challenge
A commercial kitchen producing hundreds of portions a day was still being run from memory. The plan for a cook day lived in a notebook, the order of who prepped what lived in habit, and yield loss lived nowhere at all.
Two things made this hard to systematise. First, recipes are recursive: a dish is assembled from sub-recipes that are themselves assembled from sub-recipes, so a single service order has to explode several levels deep before anyone knows what to pull from the cold room. Second, nothing weighs what it should. Every wash, peel, trim and reduction loses mass, so planning against recipe quantities quietly under-buys and costing against them quietly under-prices. Modelling that honestly means carrying gross against net and expected against actual at every level of the tree, not only at the top.
Sitting on top of the data problem was an interface problem. Six stations work in parallel through a service and all of them need the same live plan. Whatever they were given had to be drivable on a tablet, mid-service, with wet hands, in more than one language.
A commercial kitchen producing hundreds of portions a day was still being run from memory. The plan for a cook day lived in a notebook, the order of who prepped what lived in habit, and yield loss lived nowhere at all.
Two things made this hard to systematise. First, recipes are recursive: a dish is assembled from sub-recipes that are themselves assembled from sub-recipes, so a single service order has to explode several levels deep before anyone knows what to pull from the cold room. Second, nothing weighs what it should. Every wash, peel, trim and reduction loses mass, so planning against recipe quantities quietly under-buys and costing against them quietly under-prices. Modelling that honestly means carrying gross against net and expected against actual at every level of the tree, not only at the top.
Sitting on top of the data problem was an interface problem. Six stations work in parallel through a service and all of them need the same live plan. Whatever they were given had to be drivable on a tablet, mid-service, with wet hands, in more than one language.
Solution
CODT built a tablet-based production system that turns a day's menu into a tracked manufacturing run.
A chef opens the cook-day configurator, schedules prep day, cook day and plan day together, then walks from cooking date to plan date to dishes and quantities. The system explodes that plan into every sub-recipe, preparation step and ingredient it implies, and the chef reviews the full ingredient list before submitting.
The work then moves through six connected stages — Configurator, Bulk Prep, Preparation, Cooking, Dish Chef and Jar Filling — each visible to the whole kitchen in real time. Every ingredient carries its supplier reference and both gross and net quantity, so yield loss is measured rather than guessed. Sub-recipes are assigned by category and cooking zone (oven, cold room) and capture expected versus actual quantity and elapsed time per batch. Stations filter by pending, in progress and completed, switch between list and grid views, filter by date range, and see per-dish assignment showing who is on it and how long it has taken. Traceability runs both ways: open an ingredient to see every dish and sub-recipe it feeds, or open a dish and trace back to every input.
It is built as a multilingual web application for kitchen tablets on Node.js and NestJS, with MySQL, Redis and ElasticSearch behind it.
CODT built a tablet-based production system that turns a day's menu into a tracked manufacturing run.
A chef opens the cook-day configurator, schedules prep day, cook day and plan day together, then walks from cooking date to plan date to dishes and quantities. The system explodes that plan into every sub-recipe, preparation step and ingredient it implies, and the chef reviews the full ingredient list before submitting.
The work then moves through six connected stages — Configurator, Bulk Prep, Preparation, Cooking, Dish Chef and Jar Filling — each visible to the whole kitchen in real time. Every ingredient carries its supplier reference and both gross and net quantity, so yield loss is measured rather than guessed. Sub-recipes are assigned by category and cooking zone (oven, cold room) and capture expected versus actual quantity and elapsed time per batch. Stations filter by pending, in progress and completed, switch between list and grid views, filter by date range, and see per-dish assignment showing who is on it and how long it has taken. Traceability runs both ways: open an ingredient to see every dish and sub-recipe it feeds, or open a dish and trace back to every input.
It is built as a multilingual web application for kitchen tablets on Node.js and NestJS, with MySQL, Redis and ElasticSearch behind it.
Results
The choreography that used to live in chefs' heads is now written down, running and measurable — batch by batch, gram by gram.
A cook day is planned once, exploded automatically, and executed against one shared live view instead of six separate mental models. Yield loss is a number rather than an estimate, which makes purchasing and portion costing defensible. Batch times and expected-versus-actual quantities accumulate into a record the head chef can review, so bottlenecks and preparations that consistently over-run surface on their own rather than being noticed by accident. Because traceability runs in both directions, an ingredient question — a supplier change, a substitution, a recall — resolves to a list of affected dishes and sub-recipes immediately.
The kitchen ends up behaving like the production system it always was.
The choreography that used to live in chefs' heads is now written down, running and measurable — batch by batch, gram by gram.
A cook day is planned once, exploded automatically, and executed against one shared live view instead of six separate mental models. Yield loss is a number rather than an estimate, which makes purchasing and portion costing defensible. Batch times and expected-versus-actual quantities accumulate into a record the head chef can review, so bottlenecks and preparations that consistently over-run surface on their own rather than being noticed by accident. Because traceability runs in both directions, an ingredient question — a supplier change, a substitution, a recall — resolves to a list of affected dishes and sub-recipes immediately.
The kitchen ends up behaving like the production system it always was.
