A meal planner has more state than its calendar suggests

Dingoygl — Tue, 03 Nov 2026 06:30:16 +0000

Moving a dinner from Tuesday to Thursday looks like a small UI action. The interesting question is what moves with it: the serving count, ingredient choices, recipe instructions and shopping quantities.

I looked through MealMuse, a free dinner-planning web app, with that question in mind. These are observations about the visible workflow, not its source code.

MealMuse brings dinner planning and the grocery list into one workflow.

A recipe is not the same thing as a planned dinner

A recipe describes a dish. A planned dinner also needs a date, a serving count and any supported ingredient choices. MealMuse offers household portions of one, two, four or six, along with per-dinner controls. Moving the dinner should preserve those choices rather than quietly reset them.

That distinction is a useful starting point for a data model. The calendar item is an instance of a recipe, not just a recipe ID in a date column.

The ready-made two-person plan is a starting point, not a locked schedule.

A substitution reaches beyond the ingredients panel

The site supports selected ingredient alternatives. Its homepage gives paneer-to-tofu as an example: the method and grocery list follow the chosen alternative. That is more meaningful than replacing one word in an ingredient label.

This creates an interesting interaction chain: ingredient choices, portions and the calendar all contribute to the same dinner. Keeping those choices connected makes the resulting grocery list easier to follow.

Grocery totals are not supermarket pack sizes

The two-person plan explicitly says its list contains recipe quantities, not automatically rounded shopping packages. That is an important boundary. A recipe requiring part of a package does not mean the shop sells that exact amount.

Keeping this visible is better than letting a precise-looking list imply a promise about waste or cost that it cannot keep.

No account changes the persistence contract

MealMuse keeps plans in the current browser. It does not currently sync them between devices. Clearing browser data can remove access to a plan, so copying the list or downloading a PDF matters.

For a browser-local tool, I would treat exports and clear storage explanations as part of the main workflow. “No signup” is useful only if people also understand where their work lives.

You can explore the workflow at usemealmuse.com: choose a few dinners, adjust the portions and bring the ingredients together in one grocery list.

A small calculator UX problem: whose numbers are you showing?

Dingoygl — Tue, 03 Nov 2026 05:52:29 +0000

A calculator can get every multiplication right and still give someone a misleading answer. The awkward part is often the meaning of the inputs.

A residential cleaning estimate is a useful example. There are at least three things on the screen that look like “the price”: the business’s costs, the selling price, and the profit left after costs. Mixing them up makes a tidy interface much less useful.

Hours need a unit

Imagine two cleaners spending two hours at a property. A field labelled Hours could mean two hours or four. Both answers sound reasonable until you ask what the calculation expects.

Total labor hours is clearer. A short example next to the field is even better: 2 cleaners × 2 hours = 4 labor hours. You should not need a help article to discover the unit.

Room counts have a similar problem. If someone adds three bedrooms, does the app estimate the cleaning time, or just record the scope? Either approach can work. The interface needs to say which one it uses.

Margin is not markup

For a cost C and target margin m, expressed as a decimal, the selling price is:

price = C / (1 - m)

That is different from multiplying costs by 1 + m, which calculates a markup. With $100 in costs and a 20% target margin, the selling price is $125. A $120 selling price leaves a margin of about 16.7%. These are example inputs, not recommended service prices.

A field called Profit % makes the user guess which calculation is happening. A precise label and a visible explanation are more useful than an extra decimal place.

The PDF has a different audience

The person preparing the estimate needs cost and margin details. Their customer needs the agreed services, exclusions and selling price. Exporting the whole workspace gives both audiences the wrong document.

Quotewise is the concrete example I’m sharing here: a free house-cleaning estimate tool with PDF export and no signup. It uses entered labor hours, costs and a target margin, and keeps internal costs and private notes out of customer exports.

For anyone working on a small business calculator, these are useful review questions:

Does each quantity say what it measures?
Can users tell an assumption from a value they entered?
Are margin and markup named correctly?
Does the export contain only what its reader needs?

None of this requires a complicated interface. It does require deciding what each number means before polishing how it looks.

DEV Community: Dingoygl