A Week Is Not Seven Recipes

Every meal plan I have ever made was correct on Sunday and wrong by Tuesday.

Not wrong in an interesting way. Wrong in the most ordinary way possible: I cooked a big pot of chili on Monday, there was half of it left, and Tuesday’s plan said to cook something else. So I ate the chili, ignored the plan, and by Thursday I had stopped opening the app at all.

For a long time I assumed this was a discipline problem. It isn’t. It’s a modelling problem, and it’s worth being precise about what the model gets wrong.

What most planners actually model

Almost every meal planner represents a week the same way: N slots, each holding a recipe. Pick seven dinners, and the tool merges their ingredients into one shopping list. That’s the whole data model, and it’s elegant — which is part of why it’s so common.

It also quietly asserts something false: that every meal in a week is a thing you cook from a recipe. Think about your last seven dinners honestly. Mine had four answers in them, not one:

• Cooking something. The case every tool handles.
• Going out, or ordering in. Handled by some.
• Eating what we already made. Handled by almost none.
• Whatever’s around — toast, cereal, a plate of cheese and crackers, everyone foraging separately. Handled by none at all.

Two of those four are not edge cases. Leftovers are the single most common thing a household eats that it did not cook that day. And "nothing in particular tonight" is most people’s Sunday.

A rigid plan doesn’t degrade. It gets abandoned.

Here is the part that took me longest to see. When a plan can’t express what actually happened, it doesn’t become slightly less accurate. It becomes fiction, and it does so silently.

Because when Tuesday turns out to be leftovers, you have exactly two options. You can lie to the tool — mark the meal "cooked" when you didn’t cook it, or "skipped" when you ate perfectly well. Or you can stop using it. Nobody opens an app to record that they grazed.

Most people take the second option, and they blame themselves for it. But a plan you have to lie to is not a plan you were going to keep.

A tool that can’t represent what happened doesn’t get a little bit wrong. It gets abandoned, and the person blames themselves.

The leftovers problem is really a shopping problem

This is where the missing kind stops being a cosmetic complaint and starts costing something real.

"Cook once, eat twice" is the most reliable trick a household has. It cuts cooking time roughly in half for those two meals, and it’s one of the few habits that reduces food waste without anyone having to think about waste. Cook a double batch of chili on Monday; Wednesday is already done.

But a planner that models a week as seven recipes shops for single batches. It looks at Monday’s chili, sees four servings, and buys enough for four. If you want the double batch, you have to notice, do the arithmetic, and override the list yourself — every time.

Which means the tool isn’t neutral about leftovers. It’s working against them. Every week it hands you a shopping list sized for cooking seven separate times, and cooking once and eating twice becomes something you do in spite of the app rather than with it. A tool whose stated purpose is less effort and less waste has a data model that produces more of both.

Unrepresentable states don’t vanish. They get misfiled.

When I went looking at how people were working around this in our own app, the answer was uncomfortable — and it’s the most concrete argument I can make for taking the modelling seriously.

There was no way to say "leftovers", so people used the two things that were there. Some tagged the meal with a free-text label. Others marked it skipped.

The tag does nothing at all, which is fine — it’s a note. But "skipped" is worse than nothing, because skipping a meal keeps its recipe attached and keeps shopping for it. Someone recording an honest week — "we didn’t cook Tuesday, we ate Monday’s leftovers" — ended up with a grocery list that bought Tuesday’s ingredients anyway. The workaround didn’t just fail to help. It produced a quietly wrong answer, in the one part of the app where wrong answers cost money.

That’s what happens to a state a system can’t express. It doesn’t disappear. It gets pushed into whatever field is closest, and that field already meant something else.

The difference is in the grocery list

It would be easy to add "leftovers" as a label and call it done. That’s the version that changes nothing: the meal shows a nicer word and the shopping list stays exactly as wrong as before.

The test of whether a meal kind is real is what it does to the list. Each of the four has a different answer, and that’s precisely why they need to be different kinds rather than one field with four values:

• Cooking — buy the ingredients, scaled to the people eating.
• Eating out or takeout — buy nothing.
• Leftovers — buy more of an earlier meal. Nothing new goes on the list; one line on it gets bigger.
• Whatever’s around — buy nothing, unless you’re making a salad alongside, in which case buy the salad.

Leftovers are the interesting one. It’s the only kind whose effect lands on a different meal than the one you edited. Saying "Wednesday is leftovers of Monday" has to reach back and change what Monday is cooked for — and if it doesn’t, you’ve built the label and skipped the feature.

Why most tools don’t do this

I want to be fair about the tradeoff, because it’s a real one and it explains the state of the world.

Every kind of meal you add is a branch in every part of the system that walks a week. The grocery aggregator. The week’s summary line. The calendar view. The drag-to-reorder logic. The row on screen and its expanded panel. The API. Four kinds is not twice the work of two — it’s a new case in a dozen places, each of which has to be right.

Seven recipe slots is a genuinely cheaper product, and for a while it looks like the same product. That’s the trap. The cost doesn’t show up as a bug report. It shows up as people quietly stopping.

What I’d ask of a meal planner now

Not "are the recipes good". Not "does it generate a sensible week". Both are table stakes, and both are things a generated week can be on Sunday while being useless by Wednesday.

The question I’d ask is narrower and much harder: can it describe the week I actually had? Can it hold a Monday I cooked, a Tuesday we went out, a Wednesday of leftovers that Monday was sized for, and a Sunday where nobody made anything? If it can’t, the plan and the week will drift apart, and the plan is the one that loses.

The measure of a meal planner isn’t whether the week it generates is good on Sunday. It’s whether the week is still true on Thursday.