Every catering operation runs on the same arithmetic. One booking — guest count, menu, service type — decides how much to prep, what to buy, what to quote, and what deposit to collect. In most small operations I have seen described, that arithmetic still happens in spreadsheets and in someone's head.
I wanted to see how far Zoho Creator alone can take it, so I built a sample app end-to-end on my own account: give it a confirmed booking, and it produces the numbers.
The design: one recipe table drives everything
The core of the model is a Recipes table — menu item × ingredient × quantity per guest. Once that table exists, everything else is derivation:
- Prep quantities: guests × servings per guest, plus a configurable buffer rate (I used 10%)
- Ingredient requirements: aggregated across all selected menu items from the recipes
- Shopping quantities: required amounts rounded up to whole purchase units — tortillas come in packs of 50, so needing 220 means buying 250
- Money: subtotal, service fee, tax, total, deposit and balance, written back onto the booking
The calculation lives in a single Deluge function, calculateBooking. A form workflow calls it whenever a booking line is added, so the booking totals are always in sync with its lines. Re-running it first clears the previous results in bulk, so re-calculation never leaves duplicates or stale rows.
The generated packing checklist for the test booking, grouped by category.
The same booking's figures: revenue, ingredient cost and gross profit, calculated by the sample itself.
Verified numbers, not screenshots of promises
I tested it with a 50-guest booking (two taco items). The app produced a subtotal of $1,300.00, tax of $114.40, a total of $1,544.40 and a deposit of $772.20 — exactly the hand-computed values. The shopping list split perishable from non-perishable and rounded every item up to its purchase unit: chicken 8.25 kg → 10 kg, limes 27.5 → 40.
See it run
I also recorded a short walkthrough on the live app: a new 80-guest booking is entered with the money fields left blank, two menu lines are added, and the app calculates the quote (subtotal $2,080.00, total $2,471.04, deposit $1,235.52), the prep quantities and the shopping list on its own. Those numbers were checked against hand calculations too.
Two lessons worth sharing
- SubForms are plan-dependent. On the Creator plan I used, a form containing a SubForm could not be submitted at all — the plan treats SubForms as demo-only. I moved booking lines into a standalone form with a Lookup to the booking. Honestly, that pattern scales better for reporting anyway, but I would not have discovered the limit without building the real thing.
- Never delete rows one by one inside a
for eachover the same collection in Deluge. It fails at runtime as soon as more than one row matches. Bulk delete by criteria is the correct shape.
What this sample is — and is not
To be transparent: this is a self-built sample on my own Zoho account with dummy data, based on the requirements of a real catering-operations job posting. It is not client work. The code is on GitHub (MIT, reuse freely): https://github.com/kotarosan-dev/zoho-creator-catering-ops-sample.
Update (Phase 2, built and verified): the packing checklist and the per-booking profit summary are now implemented. Packing lists are generated from a rules table (fixed / per guest / per 25-guest block / per prep unit), and regeneration is blocked once any item is checked, so field progress is never wiped by a recalculation. Profit is an estimate per booking: revenue excluding tax, minus ingredient purchase cost (purchase quantity × unit cost), minus recorded expenses. On the same 50-guest test booking: revenue $1,430.00, ingredient cost $142.00, gross profit $1,288.00 (90.1%). Two failure behaviours are deliberate: a missing ingredient cost fails the calculation instead of silently counting as zero, and a failed run never overwrites the last good numbers. Still designed but not built: deposit/final invoices and the Zoho CRM / Sign / Books and Square integrations.
The same pattern — derive quantities and money from a headcount and a recipe-like master — transfers directly to bento and meal-prep services, event rentals, and class-based businesses. If your team still does this arithmetic in spreadsheets, I am happy to walk through the design, in writing or in a recorded demo.