Resources · tool
The full back office for a catering business in one system: recipe costing through nested sub-recipes, a tagged dish catalogue, an eight-stage booking pipeline, and a finance screen where every total opens into its rows.
A catering business runs on numbers that move. Supplier prices change, a dish is built from sub-recipes that are themselves built from sub-recipes, and an event quote is usually last year's spreadsheet times head count. By the time anyone notices the margin was wrong, the food has been served.
A dish is not a flat ingredient list. It is a tree: a sauce inside a component inside a plate. The engine walks that tree and computes cost to the penny.
Sample output: Elevated Chicken Paprikas · 30 lines · 5 sub-recipes · $39.39/batch · $9.85/plate · 0 blocked lines.
If one line in that tree cannot be priced, the dish shows no cost at all — a blank you investigate, never a guess you quote.
136 dishes, tagged by cuisine, meal and course, filterable across all three at once. The point is not the count. The point is that menu building starts from what exists and what it costs, instead of from memory.
The booking pipeline has eight stages. What makes it trustworthy is what it refuses to store: there is no "paid" checkbox. Money recorded is the record, and deposit and balance state are derived from it.
A status field somebody forgot to update is the most common lie in small-business software. This system does not have one to forget.
The finance screen shows totals, and every total drills into the rows behind it. That is the honesty rule made structural: if a number cannot be traced to rows, it does not get shown.
The industry is catering because that is the business I own. The mechanics are not: a costed tree, a derived stage, a total you can open. Swap plates for jobs, tickets, units or matters and the same three moves apply.