Menu Costing and Stock Variance Intelligence
A restaurant that knows its total food spend and its total sales, prices dishes by feel and by what competitors charge, and counts stock when something runs out.
The problem
The restaurant does not know which dishes make money. Menu decisions — what to promote, what to reprice, what to remove — are made on popularity, which is not the same thing as profit.
In scope
- Recipe definition
- Ingredient cost tracking
- Per-item cost and margin by channel
- Theoretical versus actual usage
- Variance reporting
- Menu engineering analysis
Out of scope
- Replacing the point of sale.
- Automated repricing.
- Supplier ordering.
- This reads from what exists and tells the owner what it means.
What this would cover
Grouped by module — open the ones you want to read.
Recipes
- Ingredients and quantities per menu item, including the ones people forget: oil, seasoning, packaging, the sachet of pepper that goes in the bag
Ingredient cost
- Purchase price history per ingredient per supplier, with unit conversion between purchase unit and recipe unit handled explicitly
Item cost
- Computed from current ingredient prices and refreshed as prices move, which in this market is constantly
Channel margin
- Margin per item at dine-in, takeaway and each aggregator price, net of commission, because an item profitable in the dining room can lose money on an aggregator
Theoretical usage
- What should have been consumed given what was sold
Variance
- Theoretical against counted, per ingredient, trended over time
Menu engineering
- Items plotted by popularity against margin, producing four groups: promote, reprice, rework, remove
Price sensitivity
- What happens to margin if an ingredient rises by a given percentage, which matters when a single input moves sharply
Data model
- Read-mostly.
- MenuItem → RecipeLine → Ingredient
- PurchasePrice → PriceHistory
- Sale (read)
- StockCount → CountLine
- VarianceRecord
- ChannelPrice
- MetricDefinition
Invariants
- Item cost is computed from dated ingredient prices, and a historical margin figure uses the prices that were current at the time — recalculating history with today's prices makes trend analysis meaningless.
- Variance is always expressed with the period and the count dates that produced it.
Offline behavior
Not applicable. Stock counting should work on a phone offline.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Theoretical usage will never match counted usage, and an owner who reads variance as theft will destroy the tool.
Portioning varies between cooks, spillage is real, recipes are approximations, and a cook who is measured on variance will start under-portioning, which costs more in customer perception than the variance was worth. The value is in the size and direction of variance over time, and in one ingredient moving differently from the rest. This has to be explained before the first report, not after the first argument.
Recipe accuracy is the foundation and it decays.
Cooks change, portions drift, a dish is tweaked without anyone updating the recipe. Recipes need a review cadence, and without one the output degrades quietly over about six months — which is worse than obviously breaking, because nobody notices.
End state
What would be true about their day once this is running.
- Every dish has a cost computed from what its ingredients actually cost today, and a margin at each channel's price net of commission.
- The owner can see which items are popular and unprofitable.
- Variance is tracked as a trend rather than discovered as a shock, and one ingredient moving against the others is visible.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review