Inventory App Starter · Industry version
Kitchen-grade stock control — recipe depletion, expiry-aware batches, waste logging — in code your restaurant owns.
A kitchen doesn't sell what it buys: it buys kilograms of ingredients and sells plates of dishes. This starter models that translation directly — recipes deplete ingredient stock, batches carry expiry dates, waste gets a reason — and generates it all as code you own.
01 · The problem
The core mismatch is the unit of sale. Generic inventory decrements one SKU per sale, but a restaurant sale is a dish that consumes 180 grams of one ingredient, 40 of another, and a splash of a third. Without recipe-level depletion, theoretical stock is fiction by Friday and food-cost percentage is a monthly guess instead of a daily number.
Then there's time. Produce, dairy, and proteins expire on different clocks, and first-expired-first-out isn't a preference — it's the difference between service and a health inspector's citation. Inventory that tracks quantity without batch dates can tell you that you have twelve kilos of chicken, but not that four of them die tonight.
And kitchens lose stock in ways warehouses don't: trim, spoilage, comped plates, staff meals, the dropped tray. A system with no waste vocabulary lumps all of it into one shrinking number, which is precisely how a two-point food-cost problem hides for a quarter.
02 · Data model
Everything in the base Inventory starter —
itemswarehousesstock_movementssupplierspurchase_ordersreorder_rules— plus the entities this industry actually runs on:
| table | what it holds |
|---|---|
recipes | Dish-to-ingredient mappings with quantities and yield — the bill of materials that turns sales into depletion. |
batches | Received lots with expiry dates, so on-hand splits into fresh, use-first, and about-to-die. |
waste_logs | Every discarded item with a quantity, reason, and shift — trim, spoilage, error, comp — feeding the variance report. |
03 · Screens
Each sold dish posts ingredient-level depletion movements from its recipe, so theoretical on-hand stays live through service. The gap between theoretical and counted stock becomes your variance report — the number a food-cost conversation should start from.
Reorder suggestions weigh batch expiry, not just quantity: twelve kilos on hand with eight expiring tomorrow is a shortage, and the alert says so. Par levels per prep area replace the walk-in squint before the supplier cutoff.
Deliveries are received against the order with weight checks, price verification against the quoted list, and an expiry date per batch. Short weights and substitutions are recorded at the door — where they're arguable — not discovered at count.
04 · In practice
Count sheets ordered by shelf location, entered by section as each station finishes. Variance against theoretical posts immediately, so the chef sees which five ingredients drove the week's food-cost drift before the Monday order goes in.
The day starts with the expiry queue: what dies today, what dies tomorrow. Prep pulls from the oldest batches, the specials board absorbs what the par sheet can't, and tonight's waste log stays short.
Before a new dish goes live, its recipe prices itself from current supplier costs — margin per plate, sensitivity to the volatile ingredients. When the seafood price spikes, every affected dish surfaces in one query on your own data.
Both, linked by recipes: you purchase and count ingredients, you sell dishes, and each sale depletes ingredient stock through the recipe's quantities. That link is what makes daily food-cost and variance reporting possible at all.
Stock is received in batches that carry expiry dates, so every ingredient's on-hand splits by freshness and the morning use-first list writes itself. Expired batches are written off as dated waste events, not silently absorbed.
Yes — each kitchen, prep site, or commissary is a location with its own stock, pars, and counts, and transfers between them are paired ledger movements. A central-production model is a data shape here, not an enterprise tier.
That's the intended integration: sales flow in from your POS and post recipe-based depletion automatically. Because the codebase is yours, the mapping between POS items and recipes lives in your tables where you can audit and fix it.
Dual7 App Starters
Kitchen-grade stock control — recipe depletion, expiry-aware batches, waste logging — in code your restaurant owns. Describe your version to start — the output is a project you own.