Should I vibe code
Store recipes, plan meals, create grocery lists, and keep data in a portable local database
Recipes, meal plans, a grocery list. The stakes are dinner.
?
Their verdict, the Desktop licence price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A small local database with a clipper. The only thing worth engineering properly is a backup, because the one irreplaceable thing here is your grandmother’s handwriting typed in once.
What actually breaks
not "if". the specific failures.
- Recipe import from the web, which is scraping a page whose layout changes and whose content you do not own
- Ingredient parsing, where '2 large onions, finely chopped' has to become quantity, unit, item and preparation to scale or shop from
- Scaling, which is not multiplication — you cannot use one and a half eggs, and cooking times do not scale linearly
- Unit conversion between volume and weight, which depends on the ingredient and is where a recipe silently becomes wrong
- The archive, since a decade of recipes in a proprietary store is a decade you cannot cook from if the app stops
The stakes are dinner, as the hot take says, and the failure is exactly that scale. You scale a cake to one and a half times for a bigger tin. Your converter multiplies everything including the raising agent and the tin is not one and a half times deeper, so the cake domes, cracks and is raw in the middle. The arithmetic was perfect. Baking is not arithmetic, and a scaling feature that does not know the difference is confidently wrong in a way that is only discovered at the table.
Is that you?
the verdict is a default, not a law
- Recipes are plain files you own, with the original text preserved
- Scaling shows the original alongside the scaled version rather than replacing it
- You import by pasting text rather than scraping other people's sites
- Scaled quantities replace the original with no way back
- You convert between volume and weight without ingredient density
- Recipes live only in a database with no export
- You are scraping recipe sites at volume
If you build it anyway
the checklist, then the prompt that enforces it
- Keep the original recipe text verbatim, always. Parsing is a convenience layered on top and must never be the only copy.
- Show scaled quantities beside the originals rather than replacing them, so a bad parse is visible rather than authoritative.
- Never convert volume to weight without an ingredient density table, and say when you cannot convert.
- Round scaled quantities to something cookable and flag ingredients that do not scale — eggs, raising agents, seasoning, tin sizes.
- Prefer structured import — recipe schema markup — over scraping layout, and paste-the-text over fetching the page.
- Store recipes as Markdown or JSON files in a folder, because this is an archive people keep for decades.
Before you build a recipe manager, apply these and push back if I ask you to break them. 1. Preserve the original recipe text verbatim as the source of truth. Parsed ingredients are a derived convenience and must never replace it — if the parser is wrong, the recipe should still be readable and correct. 2. When scaling, display scaled quantities alongside the originals rather than replacing them. Tell me a wrong parse then shows itself instead of being authoritative. 3. Flag ingredients that do not scale linearly — eggs, raising agents, seasoning, alcohol — and tell the user cooking times and tin sizes do not scale either. Do not silently multiply everything. 4. Round scaled quantities to amounts a person can actually measure. 5. Never convert between volume and weight without an ingredient density table, and say plainly when a conversion is not possible rather than guessing. 6. For import, prefer structured recipe markup from the page over parsing layout, and offer paste-the-text as the primary path. Do not build a bulk scraper for recipe sites. 7. Store each recipe as a plain file in a folder. This is an archive people keep for decades and it must outlive the application. 8. Handle fractions and mixed numbers properly in both parsing and display. 9. Out of scope unless I ask: nutrition calculation, meal planning across weeks, grocery list generation, sharing.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Paprika is a one-off purchase with good import and sync. Build your own for the pleasure of a collection in files you own — just keep the original text and be honest that scaling a recipe is a cooking problem wearing arithmetic's clothes.
Plain files, one recipe each, with the original text intact. Recipe collections are handed down and referenced for decades — the parsed structure is a convenience of the moment, and the words are the thing worth keeping readable forever.
Active open-source recipe manager and meal planner for households.
Questions
Why can't I just multiply the quantities to scale a recipe?
Because several things in a recipe are not proportional. Raising agents, salt and strongly flavoured aromatics scale sublinearly; eggs come in whole units; and the physical constraints — tin size, pan surface area, cooking time — do not scale at all. Multiplying everything produces a mathematically correct recipe that cooks badly, which is worse than not offering scaling.
Why keep the original text if I've parsed it?
Because ingredient parsing is heuristic and will be wrong occasionally, usually on the interesting entries — a range, a preparation instruction inside the quantity, an ingredient with a comma in its name. With the original preserved, a bad parse is a cosmetic annoyance. Without it, the parse becomes the recipe and the error is permanent.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice