F&B Cost Control: Recipe Cards, Portions & Menu Engineering
The menu is a price list for recipes nobody costed — recipe cards, portion discipline, waste as a transaction, and menu engineering: the four habits that hold food cost where the budget says.
Most Kenyan restaurants price by market: the burger costs what the competitor's burger costs, plus or minus ambition. What almost nobody knows is what the burger costs to make — this week, at this supplier's prices, at the portions the kitchen actually serves. Without that number, "food cost control" is a monthly autopsy. With it, every dish on the menu is a small business whose profit you can read.
Habit 1: recipe cards with live costs
- Every menu item gets a recipe card: ingredients, exact quantities, yield — the BOM discipline, plated.
- Ingredient costs update from purchasing automatically — when tomatoes double in the rains, every recipe using them re-costs itself the same day.
- The output is a live margin per dish: recipe cost vs menu price, ranked. The ranking is where every pricing and menu decision starts.
- Prep items (stocks, sauces, marinades) are sub-recipes — costed once, consumed by the dishes that use them.
Habit 2: portion discipline
The recipe card says 180g of beef; the ladle says whatever the cook's mood says. Portion drift of 10–15% is invisible on the plate and lethal on the month:
- Portioning tools where they matter — scoops, ladles, scales at the protein station — cost a few thousand shillings and repay weekly.
- Spot-weigh plated dishes against cards twice a week, publicly and blamelessly; measurement itself corrects most drift.
- Pre-portion the expensive proteins at prep time (butchered, weighed, bagged) so service-time speed never fights portion accuracy.
- Track yield on butchering and prep: the whole chicken → portions math is a yield reconciliation the kitchen should win, not wonder about.
Habit 3: waste is a transaction
| Waste type | Hides as | Record it as |
|---|---|---|
| Spoilage (produce, dairy) | General food cost | Waste entry with item, quantity, reason — trends expose ordering errors |
| Prep waste beyond yield | The kitchen's secret | Yield variance per prep batch |
| Returned plates & comps | Lost revenue nobody logs | Void/comp reasons on the POS, reviewed weekly |
| Staff meals | A perk that eats 2–3 points | A defined staff-meal allowance, issued and costed like any outlet |
The cost of "it's just a little"
A restaurant doing KES 3M monthly at 32% food cost spends ~KES 960,000 on food. Two points of drift — portions, waste, staff meals — is KES 60,000 a month, quietly. That is a salary, disappearing into generous ladles and unlogged spoilage.
Habit 4: menu engineering
With live recipe costs and POS sales data, every item lands in one of four boxes — high margin/high volume (stars: protect them), high margin/low volume (puzzles: promote or reposition), low margin/high volume (workhorses: re-cost, re-portion, or re-price), low margin/low volume (dogs: cut them). Reviewing the grid quarterly is how menus earn more without a single price increase the customer notices — portion architecture, plate composition, and placement do the work.
All four habits assume the plumbing underneath: store-to-kitchen issues, daily counts, a POS that consumes recipes, and purchasing that tracks ingredient prices. The bar runs the same play with tighter tolerances.
What AWRA OpsHub does today
- Waste and spoilage recorded as adjustments with a reason drawn from a configured catalogue and a named user.
- Live ingredient costs — weighted average cost per item, updated as goods are received, with landed cost included.
- Stock counted per location with blind entry, so kitchen and store variance is measurable at the item level.
- Purchase price history per supplier, so ingredient cost movement is visible.
More we can add to your workspace
- Recipe cards. A recipe, dish and bill-of-materials entity, so a plate cost assembles itself from ingredients.
- A theoretical usage and therefore no portion variance. Without a recipe there is nothing to compare actual consumption against.
- A menu-engineering grid. Popularity-versus-margin analysis is not produced, and could not be without plate costs.
- A yield or trim factors on raw ingredients.
Most of what this article teaches needs a recipe layer, and we do not have one. What we give you is the honest input side: accurate ingredient costs, counted stock per location, and waste captured with a reason. Plate costing itself is a spreadsheet exercise today — and worth doing, because the ingredient costs feeding it will at least be real.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsCost the burger, then the menu
Live ingredient costs with [landed cost](/glossary/landed-cost) included, waste captured with a reason, and stock counted per outlet — the accurate inputs a plate cost needs.
See F&B cost control in AWRAFrequently asked questions
How many recipe cards do we need before this works?
Start with the twenty items that drive 80% of sales — costing them takes a few kitchen afternoons and covers most of the money. The long tail follows at a card or two a week. What fails is trying to cost 200 items before turning anything on. Note that the cards themselves live in your spreadsheet, not in the product: nothing here has to be configured before you can start, and nothing you build is locked into us.
Ingredient prices change weekly at the market. How do cards stay current?
Half of that is automatic and half is not, so be clear which. Purchase prices do flow from receiving into ingredient costs, so the per-kilo and per-litre figures you cost from are always current without anyone retyping them. The re-costing of the dish is not automatic, because the system holds no recipe to re-cost — you rebuild the card from the current ingredient costs, which for twenty core dishes is a short monthly job rather than a research project. The volatility is still the argument for the system; it is just an argument about the input prices, not the cards.
Is cutting staff meals really worth the morale cost?
Don't cut them — define them. A costed staff-meal allowance (what, when, budgeted value) is a benefit everyone understands; an undefined "kitchen eats" policy is 2–3 food-cost points with no owner and endless suspicion. Definition is the win, not deprivation.
What margin should individual dishes make?
Think in shillings and mix, not just percentages: a 60%-margin soup earning KES 180 matters less than a 45%-margin platter earning KES 520. The menu-engineering grid weighs both — margin per plate and plates per week — which is why it beats a single food-cost target applied to everything.
