How to Build a Restaurant Management System That Runs Your Floor

The problem

• Food cost drifts silently: inventory is counted on paper (or not at all), so you discover you were running 38% only after the month-end P&L closes — far too late to fix that period.
• Prep sheets and temperature logs live on clipboards that get coffee-stained and lost, right up until a health inspector asks to see the last 90 days.
• The 86 list, the day's specials, and allergen details live in the chef's head and a group chat, so servers confidently give guests answers that are wrong.
• Every supplier invoice is a different PDF, and nobody reconciles the case price you were quoted against what you were actually billed — the profit leak nobody is watching.

A day in the system

1. Open: the manager pulls the prep sheet — recipe_lines plus yesterday's sales tell the line exactly how much mise to make, so nobody over-preps the soup that sells six bowls a day.
2. Delivery: the receiving screen checks each case against the supplier's expected case_cost, flags short or over deliveries, and bumps on_hand_qty for every ingredient in the drop.
3. Cooler check: every four hours a cook taps the temp_logs screen and records the walk-in reading; if it is above 41°F the app blocks the save until a corrective action is entered.
4. Service: a server marks the salmon 86'd — menu_items.is_86 flips and the dish greys out on every station screen and the guest-facing specials board at once.
5. Cooling: after the braise comes off the stove a cook starts a cooling timer; the system prompts for the 135->70°F check at two hours and the 70->41°F check four hours after that.
6. Close: waste, comps, and the POS sales totals are logged, and tomorrow's prep quantities recompute against the updated on-hand counts.
7. Weekly count: the manager walks each storage area counting on a phone; the app diffs counted_qty against par_level and builds a purchase order per supplier.
8. Month-end: food-cost % rolls up per dish and overall, surfacing which items are underpriced or over-portioned before the accountant ever opens the books.

Where AI trips up

• Units are the number-one trap. You buy chicken by the case, portion it by the ounce, and count the walk-in by the each. A naive build stores one "quantity" field and your food-cost math silently breaks — every ingredient needs a purchase unit, a recipe unit, and a conversion between them.
• A temperature log is not just a number. The FDA Food Code that most states adopt expects a reading, a timestamp, who took it, and a corrective action whenever it is out of range — and it expects roughly the last 90 days to be retrievable. Never let an out-of-range reading save without the follow-up.
• Cooling is two-stage, not one checkbox: 135°F to 70°F within 2 hours, then 70°F to 41°F within 4 more. A single "is it cold yet" toggle fails inspection — model both checkpoints, each with its own clock and its own pass/fail.
• Allergens cannot be a free-text note. Sesame became the ninth major allergen in the 2022 Food Code; store allergens as tagged fields on each item so a server can filter and answer instantly, not as a sentence someone forgets to update.
• Never hard-delete a menu item or ingredient. Drop last month's "Fish Special" and its sales and food-cost history vanish from your reports. Soft-delete with is_active so recipe_lines and past counts stay intact and the numbers stay honest.

FAQ

Does this replace my POS?

No — keep your POS for taking payments at the table. This system sits alongside it: you drop the daily sales totals in (by hand or a simple import) so food cost and inventory reconcile against what actually sold. Rebuilding card processing is not a fight worth having in v1.

How does it calculate food-cost percentage?

Each menu item links to recipe_lines, and each line points to an ingredient with a case cost and pack size. The app converts to the recipe unit, sums the plate cost, and divides by menu price. Change one case cost and every dish that uses that ingredient reprices. Most full-service restaurants target roughly 28-35%.

Will the temperature logs actually satisfy a health inspector?

The logs capture the reading, equipment, timestamp, staff initials, and a required corrective action for out-of-range values, and keep at least 90 days retrievable — which is what jurisdictions following the FDA Food Code look for. Always confirm the exact format your local health department wants, since states adapt the model code.

Can I run more than one location on it?

Yes. Inventory counts, par levels, and temperature logs are scoped per location while the menu and recipes are shared, so a price change rolls out everywhere at once. Start with one location, prove the loop, then clone it.

Is it usable on the line without training?

The count and temp screens are built for a phone held with wet hands — big buttons, one reading at a time, no menus to hunt through. Because the whole system is hosted on ybuild at your own domain, staff just open a bookmarked URL on any phone; there is nothing to install or update.