Solutions
Meal plan software for businesses that sell plans, not meals
A 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.
A plan is not a big order
The most common modelling mistake is treating a plan as a repeating order. It behaves like one until the first exception, and meal plans are almost entirely exceptions: a customer travels, gets ill, changes goals, develops an intolerance, or simply wants the salmon instead of the chicken this week.
Modelled properly, a plan is a durable record with its own lifecycle — scheduled, active, paused, expired — and each week is a set of slots generated from it that the customer may fill until a cut-off passes.
What a plan definition has to carry
Meals per week
The count that drives how many slots are generated, and therefore how many portions the kitchen owes.
Delivery days
Which weekdays this customer receives on, which is not the same as which days the kitchen cooks.
Term and end date
When the commitment runs out. Without an authoritative end date, kitchens keep cooking for customers who have stopped paying.
Dietary constraints
Allergens and preferences that must follow the customer into every week they are ever assigned a meal.
Change rules
What may be altered after a cut-off, and what rolls to the following week instead.
How a week is built from a plan
The order matters: each step consumes the previous one, which is what stops the outputs disagreeing.
Generate the slots
The plan’s meals-per-week and delivery days produce a set of dated slots for the coming cycle, skipping non-delivery days.
Collect selections
The customer picks meals for those slots, or defaults are assigned so the kitchen is never left guessing.
Close the cut-off
At a fixed point the week freezes for purchasing and production. Later changes move to the next open week.
Derive everything else
Production counts, ingredient requirements, labels and delivery stops are all computed from those selections rather than entered again.
Where plans quietly leak money
Two leaks are almost universal. The first is a term that nobody enforces, so boxes keep going out after the paid period ends — the kitchen is paying for food, labour and fuel with no revenue behind it. The second is a pause that reduces the customer’s obligations but never reduces purchasing, so ingredients are bought for meals that will not be cooked.
Both are propagation failures rather than pricing failures, which is why they are invisible in a profit-and-loss report until they are large.
Common questions
- What is the difference between meal plan software and a subscription billing tool?
- A billing tool knows how to charge a card on a schedule. It knows nothing about how many portions of a recipe the kitchen owes on Tuesday, which is the harder half of the problem and the part that determines food cost.
- Should customers pick every meal, or should defaults be assigned?
- Both, in that order. Let customers choose, but assign a sensible default when the cut-off arrives and slots are still empty. A kitchen cannot cook an unanswered question, and chasing selections by message does not scale.
- How should a plan upgrade mid-cycle be handled?
- As one atomic change: the subscription record, the current or next week’s slots, the production counts, the ingredient forecast, the labels and the billing record should all move together, so no downstream sheet is left on the old plan.
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
- SolutionsManaging mid-cycle subscription changes without re-typing themSelling the subscription is the easy part. The work is everything that happens after, when a customer changes something and five downstream systems need to hear about it before Tuesday.
- SolutionsMeal delivery scheduling, cut-offs and the calendar problemScheduling looks like the simplest part of a meal-plan operation and is quietly one of the hardest, because the calendar a Gulf kitchen runs on is not the one most software assumes.
- SolutionsMeal delivery software for subscription kitchensMost software sold to food businesses is built for one-off orders. A meal-plan kitchen sells a commitment that runs for weeks, and almost every operational problem it has comes from that difference.
- 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.
- GuidesSetting up meal plans properly the first timePlan definitions are cheap to get right at the start and expensive to change once customers are on them, because every alteration is a conversation with everyone affected.
- SolutionsMenu management for meal-plan businessesA 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.