The 30% food-cost rule is the most-quoted KPI in hospitality. It’s also the most misunderstood. A “healthy” 30% blended food cost can disguise dishes losing money + dishes that should be priced higher than they are.
This post walks through the better way to think about it — with the basics of menu engineering and what to do about it.
Why 30% is a starting point, not an answer
The 30% target comes from a generic margin model: 30% food cost + 30% labour + 30% rent/overhead + 10% net profit. That assumption is rough; it doesn’t survive a closer look at the modern P&L. Labour, rent, energy + insurance have all moved. Card fees + delivery commission stack on top.
But the more interesting problem is that an average is hiding the truth. If half your menu runs at 22% and half runs at 38%, you have a 30% average — and a serious problem. The 38% dishes are subsidising the 22% dishes, which means you’re both leaving money on the table on the 22%-ers (price them up) and slowly losing on the 38%-ers (re-engineer or drop them).
The four-box menu engineering model
Plot every dish on two axes: popularity (units sold) and contribution margin (sell price minus food cost, in €). You get four quadrants:
- Stars (high popularity, high margin). Push them. Front-of-menu placement. Specials. Don’t change the recipe.
- Plowhorses (high popularity, low margin). Re-engineer. Smaller portions? Switch a costly garnish? Replace with a cheaper substitute that customers won’t notice?
- Puzzles (low popularity, high margin). Push them harder. Better photo? Better menu placement? Server recommendation script?
- Dogs (low popularity, low margin). Drop them.
This isn’t new — it’s been the basis of menu engineering for decades. The new bit is the friction of doing it.
What kills menu engineering in practice
- Food cost is a guess. Recipes were costed in January; suppliers have changed; nobody re-costs unless there’s a project.
- Sales mix is in the POS; recipes are in Excel. Joining them is a weekend’s work.
- The chef + the owner disagree on which dishes are dogs. Nobody has the data.
What changes with a live recipe engine
The recipe engine (live food cost, sales mix, allergen matrix) plus the POS (units sold by service, by day, by cover) joined together is the menu-engineering analysis on tap. Every dish on the menu, weekly:
- Live food cost (recalculated as supplier prices move).
- Sell price; theoretical GP; actual GP after variance.
- Quadrant assignment (star / plowhorse / puzzle / dog).
- Recommendation: push, re-engineer, promote, or retire.
The decisions are still the chef’s and the owner’s. The point of the platform is to make the data trivial to see.
An illustrative example
Say a 60-cover restaurant runs a 30% blended food cost. Menu engineering reveals 22 plowhorses subsidising 8 stars. Re-pricing 6 plowhorses up by €1.20 each (with portion or garnish adjustments) and dropping 4 dogs adds roughly 2–4 percentage points of GP across the menu. On €1.4M annual revenue, that’s €28–56K to the bottom line — from changes that didn’t need a single new customer.
(Illustrative scenarios based on industry benchmarks for Irish independent restaurants. Named case studies available under NDA on request.)
What to do this week
- Pick your top-10 most-sold dishes. Cost them properly against current supplier prices.
- Plot them on the four-box. Be honest.
- Take action on three: push one star, re-engineer one plowhorse, promote one puzzle.
- Measure the impact in 30 days.
Read next
- Recipe Management product page — how live food cost is wired up.
- Recipe costing that actually works — the supplier-price loop.
- Analytics — menu engineering on a dashboard.
“Illustrative scenarios based on industry benchmarks. Named case studies available under NDA on request.”