Food
Things you make from ingredients: recipes, sizes that use more, waste, modifiers and build-your-own, allergens, and the kitchen workflow. Also covers light manufacturing.
Food is the "made from ingredients" block. Raw stock becomes a finished item through a recipe, with some waste, and usually it's made fresh to order. The crucial difference from retail: what you sell ("Large Latte") is not what you count ("coffee, milk, cups"), so there has to be a bridge between them. You model a food item as a product whose inventory is made from a recipe (composition).
The same machinery covers anything assembled from parts: a café, a kitchen, a bakery, a juice bar, and even light manufacturing (a longer recipe, no rush to serve).
The recipe bridge
A recipe lists, for one item, every stock ingredient it uses, how much, and the waste:
Product: "Latte" (made from a recipe)
uses Coffee beans 18 g waste 2%
uses Whole milk 200 ml waste 1%
uses 12oz cup 1 waste 0%When a Latte sells, inventory automatically draws amount × (1 + waste) of each ingredient. Waste is the spillage, trimming, and cooking loss you expect — set it honestly and your stock forecasts stay accurate. A few percent for liquids; more for items with heavy prep loss.
For agents: set inventory_type = Composition and define product components (ingredient stock, base quantity, waste percentage). Retail is the same mechanism with one component, quantity 1, waste 0 — which is why a business can mix both freely.
One ingredient can feed many recipes. A "house sauce" used in ten dishes is one stock item referenced by ten recipes; selling any dish draws down the shared sauce. That's the bridge working as intended.
Sizes that use more: multipliers
A food size ("Small / Medium / Large") usually changes how much of the recipe is used, not the recipe itself. You express that with a multiplier on each size:
Latte sizes: Small ×0.8 Medium ×1.0 Large ×1.5
Large Latte → coffee = 18 g × 1.5 × 1.02 (waste) = 27.5 gThe catch: a multiplier should only apply to axes that actually scale the recipe. A Size axis does; a Temperature: Hot/Iced axis usually doesn't. So you mark each axis as affecting the recipe or not. Mark Size yes, Temperature no, and the right dimension scales consumption while the wrong one leaves it alone.
The multiplier scales stock used, never price. Price comes from the size variant's price difference. A Large both costs more and uses more — two separate settings doing two separate jobs. See pricing.
Modifiers: tweaks vs. build-your-own
Two different customer experiences, two different tools. Choosing right keeps menus clean.
Add-ons — small tweaks to a set item. "Extra shot", "oat milk", "no onions", "make it a meal". The base item is the star; the choices adjust it. Model these as add-on groups on the product, with rules like "pick exactly one milk" or "up to five toppings". Each option can cost extra and can consume its own stock.
Build-your-own — the customer assembles the item. A salad, a custom pizza from scratch, a poke bowl, a cocktail. The selection is the product. Model it as a build-your-own product with groups (Base, Protein, Toppings), each with its own min/max and pricing rules (first three toppings free, etc.). Components can pull straight from raw stock so ingredients deduct as the customer builds.
Rule of thumb: if the customer is customising a thing, use add-ons. If the customer is building the thing, use build-your-own.
The kitchen
Prepared items route to the kitchen, where each order ticket moves through Pending → Preparing → Ready → Served / Picked up → Completed. You can route items to specific stations (grill, bar), flag rush orders, and number courses for dine-in. There's nothing to configure per product beyond it being a prepared item — the kitchen surface runs the workflow. This is separate from a service booking: a kitchen ticket is a make-it job, not a calendar reservation.
Allergens, calories, and consent
Food carries safety information, and Cimplify treats it as first-class, not an afterthought:
- Calories and allergens on the product (and on each build-your-own component) show on the storefront and on the order.
- A custom input field marked as an allergen or dietary preference turns the customer's answer into a visible signal on the order/booking (a pill the kitchen sees) rather than buried free text. A field marked as consent can require a signed acknowledgement (an allergy waiver) before the order is fulfilled.
Light manufacturing
Manufacturing is food's transformation shape stretched out: a longer recipe, multiple stages, and no need to serve immediately. If a merchant assembles or produces goods from tracked components, model the finished good as a composition product with a recipe of its parts. Sizes/grades that consume more use multipliers exactly as food sizes do.
Worked examples
A drink with size and milk. Size is an axis that affects the recipe (scales the pour) with multipliers. Milk is either (a) an axis that affects the recipe if it swaps one stock ingredient for another at no/known cost, or (b) an add-on group if it's an optional upcharge. Choose by whether the milk is intrinsic to the variant or an optional change.
A pizzeria. Menu pizzas are composition products with a Size axis (affects recipe). "Build your own" is a build-your-own product with Base/Sauce/Cheese/Toppings groups pulling from raw stock. "First three toppings free" is a group pricing rule.
A combo meal. Burger + fries + drink at one set price is a bundle (fixed contents), not build-your-own.
A bottled sauce on the shelf. Already made and counted as a unit → that's retail, not food. Only use a recipe when you make it to order from tracked ingredients.
Mistakes to avoid
- Marking every axis as affecting the recipe. Only sizes (and ingredient-swapping axes) should. A wrong mark corrupts stock forecasts.
- Modelling build-your-own as twenty add-on groups. Use a build-your-own product; it has the group rules you need.
- Tracking a packaged, pre-made item as a recipe. If it's already a countable unit, it's retail.
- Zero waste everywhere. Some loss is real; leaving waste at 0 slowly drifts your stock counts.
Common questions
Do I have to set up recipes? Only if you want ingredient-level stock tracking and accurate costs. If you just sell finished items and don't track ingredients, you can model them as retail. Recipes are what make food food, though — they're how stock and cost stay right.
How do add-ons that use stock work? An add-on option can carry its own ingredient, so choosing "extra shot" deducts an extra shot's worth of coffee. Set the option's stock reference.
Can one ingredient be sold on its own and used in recipes? Yes — track it once as stock, sell it as a retail product (1:1) and reference it in recipes. One stock item, two uses.
I'm an agent. How do I tell food from retail? Ask whether selling the item should deduct tracked ingredients (food) or just one finished unit (retail). Made-to-order with ingredient tracking → composition; finished goods → one-to-one.
Next: Services for time-based offerings, or Bundles & build-your-own for combos and customisers.
Retail
Things you sell and hand over: products, variants and axes, sizes and colours, stock, conditions, and the rules for when something is a variant and when it's a separate product.
Services
Time you sell over a calendar: appointments vs multi-day stays, duration, capacity, availability, staff, deposits, cancellation and reschedule policy, and multi-day check-in/out.