Solutions
Menu management for meal-plan businesses
A restaurant menu is a list of things a customer may order. A meal-plan menu is a rotating schedule of what will be offered when, and every dish on it carries data that four other parts of the operation depend on.
The menu is an operational document
When a restaurant adds a dish, the consequence is a new line on a card. When a meal-plan kitchen adds one, it changes what customers can select, what the kitchen might have to produce, what ingredients purchasing may need, what appears on a label, and what the portion costs.
That makes menu management less like publishing and more like product management. A dish is a record with a recipe, macros, allergens, a cost and a shelf life — and everything downstream reads those fields rather than the name.
It also means a careless menu change is an operational event. Adding a dish with an incomplete ingredient list produces a cost of zero, an empty allergen set and a purchasing requirement that silently under-orders.
What a dish record has to carry
A complete recipe
Because it drives both purchasing and cost. A partial ingredient list is worse than none, since it produces a confident wrong number.
Macros
Visible at selection time for macro-led plans, and printed on the label.
Allergens
Derived from the ingredients rather than typed separately, so they cannot disagree with what is actually in the dish.
Shelf life
So the use-by date is derived from the production day rather than hand-entered.
Names in both languages
Where the kitchen and the customer read different ones.
Rotation is the part most systems handle badly
Meal-plan menus rotate — often on a two, three or four week cycle — and the rotation interacts with the cut-off. A dish appearing in week three must be selectable before week three opens, and a dish being retired must not disappear from a week customers have already chosen it in.
The failure mode is retiring a dish mid-cycle and discovering it is still on a frozen production day. The rule that avoids it is simple: retirement affects future selectable weeks only, and anything already committed runs to completion.
This is the same immutability principle that governs delivered history, applied one step earlier. What has been committed does not get rewritten because the catalogue changed.
Limits worth knowing
Mealroh does not do menu engineering — there is no popularity-versus-margin quadrant analysis, no suggested pricing, and no automatic rotation optimisation. It holds the menu and its data honestly; deciding what should be on it is a chef and commercial judgement.
It also does not manage supplier catalogues or contract pricing. Ingredient costs are values you maintain, and their accuracy is your responsibility rather than something we source.
And it is not a recipe development tool. There is no versioning of experimental recipes, no scaling calculator for test batches, and no nutritional analysis beyond the macros you enter.
Common questions
- What happens if a dish is retired mid-cycle?
- It should stop being selectable for future weeks while remaining intact on any week already frozen. Removing it from a committed production day is how kitchens end up with a gap nobody notices until service.
- Should allergens be entered separately from ingredients?
- No. Deriving them from the ingredient list means they cannot disagree with what is actually in the dish. A separately maintained allergen field will eventually drift from the recipe, and that is the one field where drift is dangerous.
- Does Mealroh suggest which dishes to keep or drop?
- No. There is no menu engineering or popularity-versus-margin analysis. It holds the data accurately — cost, macros, allergens, selection counts — and the judgement about what belongs on the menu stays with you.
- Can it manage supplier pricing for ingredients?
- It stores an ingredient cost that you maintain. There is no supplier catalogue, contract pricing or automatic price feed, so keeping those figures current is a manual discipline.
See it running against a real kitchen
The product pages show the actual admin loaded with a demonstration kitchen — production, packing, routes and the dashboard, exactly as an operator sees them.
Related reading
- SolutionsMeal plan software for businesses that sell plans, not mealsA plan is a contract with a shape: a number of meals, a set of delivery days, a term, and a set of rules about what the customer may change and when. Software that does not model that shape will be fought with.
- SolutionsRecipe costing for meal-plan businessesMost meal-plan operators can tell you their revenue precisely and their food cost approximately. The gap between those two levels of confidence is where the margin quietly goes.
- SolutionsMeal production planning and ingredient forecastingProduction planning is the join between what customers chose and what the business has to buy. When those two are maintained separately, food cost drifts and nobody can say exactly why.
- SolutionsMeal label software for prep kitchensThe label is the last line of defence in a meal-prep operation and the only artefact the customer actually reads. Everything about how it is produced matters more than it appears to.
- GuidesGetting useful feedback from meal-plan customersMeal-plan businesses run surveys and get low response rates and polite answers, while the most reliable feedback they will ever receive sits unread in their own selection data.