Skip to content

Prep items

A prep item is a pantry row for something the kitchen produces, not something a supplier delivers. Tomato confit, beef stock, pizza dough, mirepoix, ragù base, lemon curd — they all live in the same inventory list as the tinned tomatoes and the bag of flour that go into them, on the row below. They’re the middle layer of the kitchen: the work the morning crew does to turn raw materials into the half-finished components that the line plates from at service.

This page is for two readers. If you’re the owner, “Why this page exists” is for you — start there. If you’re the head chef, jump to “How to use it”.

Why this page exists

A kitchen that doesn’t track its preps tracks half its food cost. Two kilos of beef, a tin of tomatoes, an onion and ninety minutes of stove time turn into a pot of ragù — and the pot of ragù turns into thirty plates of pasta. If the ragù isn’t a row in the pantry, every plate of pasta points at raw tomatoes and raw beef in the cost calculation, which is the wrong math, in the wrong unit, on the wrong day. The plate’s food cost ends up a guess; the dashboard ends up a fiction.

Prep items fix that by giving every in-house production a row of its own. The ragù has a name, a unit, a current stock level, a target stock level, and — most importantly — a cost-per-unit that rolls up from its recipe. Every dish downstream points at the prep, not at the raw materials. When the price of tinned tomatoes moves, the ragù cost moves; when the ragù cost moves, every pasta on the menu reconciles. One change at the source, the rest of the system follows.

The rule

A prep item is always the output of exactly one recipe. The recipe is the how; the prep item is the what. You don’t create a prep item directly — you write the recipe, mark it as batched, save, and the prep item appears for you. From that point on, the row carries the cost the recipe rolls up, and the rest of the system points at the row.

What makes something a prep item

The system tags every pantry row with a small chip — L1, L2, or L3 — to tell you which layer of the kitchen it sits in.

L1 is the raw layer — the things you buy from a supplier. Tinned tomatoes, beef shoulder, flour, olive oil, salt. These are deliveries; they arrive at the back door with a price on them.

L2 is the prep layer — the things you produce in-house and store. Ragù, dough, stock, sauces, fillings, brines, infusions. This is where prep items live. The cost on every L2 row is the sum of its ingredients, divided by what the batch actually yielded. No supplier on the row; the cost comes from the recipe.

L3 is the finished layer — the things the till sells. A bottle of wine the kitchen stocks for retail is an L3 the kitchen never transforms. A plated Cacio e Pepe is also L3, but it’s an L3 the kitchen makes to order from L1 and L2 — and the system hides those rows from the pantry list because they have no shelf life and no count.

A prep item is the L2 case. Always produced by a recipe, always stocked on a shelf, always carrying a cost the rest of the system reads downstream. Some L3 rows are also produced by a recipe (a batched tiramisu the pastry chef makes ahead) — those behave like prep items in every respect except the layer chip, and the same editor opens them.

What distinguishes a prep item from a finished menu item is the answer to one question: does the kitchen plate this directly from a container to a customer’s plate, or does it go into another recipe first? Tomato confit goes into another recipe — it tops the burrata, it folds into the focaccia dough, it garnishes the bruschetta — so it’s a prep item, an L2. Tiramisu goes onto a plate and out the door — so it’s a finished item, an L3, even though it was made in advance like a prep.

Editing a prep item

Open Cucina e Magazzino → Preparazioni in the sidebar and the list of every prep the kitchen makes opens at /admin/prep-items. Tap a row to land on the prep item’s detail page. The header reads the prep’s name, its current stock and par level, a chip that says OK or Below Par. Two tabs follow — Recipe & Cost (the recipe that produces this prep, broken out by ingredient cost) and Production History (every batch the kitchen has logged for this prep, with date, yield, cook, and frozen cost).

The detail page is read-only. To change something, tap the small edit icon at the top right of the header and the Edit prep item drawer slides in. The drawer walks you through the fields in five short steps, with a help pane on the right that explains why each one exists and a language picker in the header for non-English-speaking kitchen staff.

Step 1 — Name. The label every other screen refers to. Tomato confit, House stock, Pizza dough.

Step 2 — Unit of measurement. Kg, g, L, ml, or unit. The unit downstream recipes will consume from. Pick the unit you’ll use most often when the prep is an ingredient in another dish — a sauce by the millilitre, a dough by the ball, a stock by the litre. The unit shows up beside the stock figure on the list (“Tomato confit · 2.4 kg”) and drives every conversion the system does when a recipe pulls from this row.

Step 3 — Shelf life (hours). How long a batch keeps after it’s logged to stock. This field lives on the recipe, not on the prep item — the drawer surfaces it here so you can edit it in one place, but the save writes back to the producing recipe. If no recipe is linked yet, the field is disabled.

Step 4 — Current stock and par level. Current stock is normally moved by the system: a logged batch raises it, a sold dish lowers it. You edit it by hand only when reality and the row drift apart and you’re correcting the row. Par level is the target the chef wants always on hand; rows below par appear on the daily reorder shortlist and trigger the morning prep checklist.

Step 5 — Linked recipe. The recipe that produces this prep. On a prep that was auto-created by the recipe editor, this is set already; on an older row imported from before recipes existed, you can pick from the list of batched recipes the kitchen has written. Changing the link is bidirectional — the recipe’s output item field updates to match, and the cost roll-up fires immediately so the row’s cost-per-unit reflects the new recipe’s ingredients within seconds.

A Notes field at the bottom is free-text — anything the chef wants the team to read when they open this prep. (“Reduce by 30% over a low flame. Don’t stir.”)

The drawer also exposes the row’s separation rules when relevant — the configuration that splits one ingredient into its parts (a whole egg into yolk and white, a whole leg of veal into shank and shoulder). Most prep items don’t have one; the section only appears on the rows where the kitchen has set one up. See the inventory separations page for the full mechanic.

How to use it

The day-to-day rhythm with prep items is mostly the system’s job, not yours. The kitchen writes the recipe, the prep item appears, the daily prep board produces batches, every batch logs to stock and the row’s number climbs. The till sells dishes and the row’s number drops. You touch the prep item itself in three situations.

Setting up a new prep. The chef writes the recipe in Recipes, marks it as batched, picks an output unit, saves. The prep item appears in the pantry inside a few seconds, in the Kitchen production category, at L2. The chef opens the prep item, sets a sensible par level, adjusts the unit if the default isn’t right, saves.

Correcting a number. Stock count finds 2.6 kg of ragù in the walk-in, the row reads 3.1 kg. The chef opens the prep item, edits Current stock, saves. Use the proper stock-count flow for full audits; the editor is for spot-fixes.

Reviewing what something costs. The owner opens the prep item to ask why is the food cost on the cacio e pepe higher than it was last week? The Recipe & Cost tab breaks out every ingredient with its current price and quantity per recipe-unit, so the number that moved is visible at a glance. The Production History tab is the other half of the same question: each batch is recorded with its frozen cost, so you can see whether the recipe target and reality have drifted apart.

What happens behind the scenes

Editing a prep item writes only the fields you changed. Most fields stop at the row itself — name, par level, notes, current stock.

Two fields cascade. Unit of measurement patches the row’s recipe-unit; if downstream recipes consume from this prep in a different unit (a kg-yielding ragù pulled at 80g per plate, fine; a kg-yielding ragù referenced as “1 portion”, impossible), the system can no longer convert and the affected lines fall to zero cost until you align the units. The save lets you through, but a warning flag appears on every downstream recipe that broke. Linked recipe patches both sides of the link — the recipe’s output-item field and the prep item’s recipe field — and immediately recomputes the cost-per-unit from the new recipe’s ingredients.

A change to Shelf life is delegated to the producing recipe; the editor saves it back to the recipe so future batches inherit the correct expiry. Existing batches in the walk-in keep their original expiry until they clear.

The producing recipe link is the load-bearing relationship. As long as it points at a live recipe, the prep item’s cost stays current — every ingredient price move ripples through, the row’s cost-per-unit refreshes, every dish that consumes the prep reconciles. Unlink the recipe and the row freezes at its last computed cost; from that moment, the prep is a manual row that no longer tracks the price of its ingredients. Don’t unlink unless you know what you’re trading away.

Worked example

Sara, the chef at your venue, is adding a new prep to the menu prep board: Tomato confit. She wants to top the burrata starter with it (30 g per plate), and she’s considering using it in the focaccia recipe and as a bruschetta garnish later in the week.

She starts where the system makes her start — in Recipes, tapping + New recipe. Name: Tomato confit. Category: Sauces & condiments. Ingredients: 1 kg cherry tomatoes (€4/kg), 200 ml olive oil (€8/L → €1.60), 4 garlic cloves (negligible), thyme and salt. Process notes in the Steps section: Confit pomodorino at 90°C for 2h. Cool. Store in oil. Yield: 0.85 kg (the recipe loses 15% in water evaporation). Unit: kg. Batched: on. Shelf life: 120 hours (five days in oil). She saves.

Within seconds, a new row appears in the pantry: Tomato confit, L2, Kitchen production category, 0 kg in stock, cost €6.59 per recipe — about €7.75/kg. Sara opens the prep item from the inventory list, taps the edit icon, opens the drawer. She sets a Par level of 3 kg (enough for fifty starters), leaves the unit as kg, leaves the recipe link as-is (the editor already pointed it at the recipe she just wrote), saves.

The next morning the prep board offers Tomato confit, 3 kg on the recipe-task list. The morning cook logs the first batch at 2.9 kg actual yield (a touch under target — the tomatoes were small). The row goes from 0 to 2.9 kg of stock, and the cost frozen onto the batch is €6.45 against 2.9 kg of yield — so the live cost-per-kilogram on the row settles to €2.22/kg. The burrata starter consumes 30 g per plate; the share of tomato confit on each plate costs €0.067 (0.030 kg × €2.22). At a sell price of €14 on the starter that’s a sliver of the food cost, exactly the kind of small number the chef can now see on the dashboard for the first time. Before the prep existed, the cost of those tomatoes that went onto that plate was unknowable. Now it’s a line item.

Three weeks later, the cherry tomato price moves from €4 to €5.20 a kilo. Sara doesn’t open the recipe, doesn’t open the prep item — she just records the new delivery price on the tomato row. The system does the rest: the Tomato confit recipe recomputes, the prep item’s cost-per-kg ticks up from €2.22 to €2.63, and the burrata starter’s share of tomato confit climbs from €0.067 to €0.079 — a fraction of a cent on the plate, but visible on the dashboard. One number moved at the source; the chain followed.