A menu cost calculator on AWS for a few dollars a month
A dish is costed once, when the menu is written, using the prices from that week and the weights from the recipe. Eighteen months later beef has moved, the portion has crept, and nobody has recosted anything because recosting forty dishes by hand is a day’s work. The gross profit has fallen four points and the reason is invisible.

Key takeaways
- Yield turns purchase price into usable price, and it is often a large adjustment.
- Every costing is stamped with the date and the exact prices used.
- Portion variance usually moves food cost more than ingredient prices do.
- Report cash margin alongside gross profit percentage, always.
- Designed on AWS for about $2 a month.
The whole system on one page
Before any code, here is the shape of what we are designing.
- Compute
- Analytics
- Front-end & mobile
- People
Three adjustments
Between the invoice and the plate there are three things that move the number, and hand-written costings typically include one of them.
- Yield. A whole beef fillet loses weight to trim; potatoes lose weight to peeling; a lettuce loses its outer leaves. The usable kilo costs more than the purchased kilo.
- Cooking loss. Meat loses weight in the pan, sauces reduce. A hundred and eighty grams on the plate is more than a hundred and eighty grams raw.
- Waste and trim value. Some trim becomes stock or staff food and has value; most is a cost. The treatment should be stated rather than assumed.
What runs (the inside)
- Usable cost. Applies measured yields to purchase prices, per ingredient. Part 2.
- Plate cost. Assembles a dish from its recipe at a point in time, stamped. Part 3.
- The report. Dish-level profitability, with the two numbers that have to appear together. Parts 4 and 5.
One dish, end to end
- Compute
- Analytics
- Front-end & mobile
In plain words
Beef comes in at eleven pounds a kilo. The kitchen weighed a delivery, trimmed it, and weighed what was usable: sixty-eight per cent. So the usable cost is eleven divided by nought point six eight, which is sixteen pounds eighteen a kilo.
A hundred and eighty grams on the plate costs two pounds ninety-one at that rate, against one pound ninety-eight if you use the purchase price. Add the potatoes, the sauce, the garnish and their own yields and the dish costs four pounds sixty-two.
At nineteen fifty it makes fourteen pounds eighty-eight and runs at seventy-six per cent gross profit. Both of those numbers matter and the last post is about why reporting only one of them leads to bad menu decisions.
Design rules that shaped every decision
- Yields are measured in the kitchen, not taken from a book.
- Every costing stores the exact prices used and the date.
- Recipes are versioned; changing a recipe does not rewrite history.
- Report cash margin and percentage together, always.
- Never automatically change a menu price.
- Say when a costing is stale, rather than quietly using old prices.
Why this shape
Recipe costing is done once and then not again, because doing it by hand is slow and the result goes out of date within a month. The consequence is that most kitchens are operating on costings that were correct at some point in the past and have drifted by an unknown amount.
Automating the arithmetic is not the hard part. The parts that matter are getting yields measured once properly, keeping the price history so a change can be attributed, and presenting the result in a way that does not encourage the two classic errors: chasing gross profit percentage, and removing dishes that look unprofitable.
The next four posts walk through each piece: how yield turns purchase price into plate cost, why prices need a date stamped on them, why portion size moves more than price does, and how to read a dish profitability report without getting it wrong. One diagram per post, a cost breakdown, and an engineering reference at the end.
All posts