Should I vibe code
Store recipes, drag them onto a calendar, and generate a shopping list
Dragging recipes onto a calendar is an afternoon. Merging ‘1½ cups flour, sifted’ into one shopping list is not.
?
Their verdict, the Plan to Eat price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
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
Nothing in this system belongs to anyone outside your household. No money moves, no stranger has an account, and the worst outcome is a Tuesday where you forgot the tinned tomatoes. Build it. What decides whether you still use it in a year is not the drag-and-drop calendar, which an agent will hand you before dinner — it is the ingredient parser. A shopping list is only useful if it can read '2 (14 oz) cans diced tomatoes, drained' and '500 g plain flour' and '1½ cups flour, sifted' and produce one line per thing you actually buy, and that is a long tail of small linguistic misery no demo exposes. The one genuine risk is banal: four hundred recipes you typed in by hand are the only real asset here, and they will be sitting on a container volume you have never once backed up.
What actually breaks
not "if". the specific failures.
- Ingredient parsing, which is the whole product — quantity, unit, package size, name and preparation all live in one free-text line and the shopping list needs four of the five
- Unit merging: 500 g of flour and 2 cups of flour are either one line on the list or two trips to the shop, and getting that right means owning a density table you did not plan to own
- The recipe clipper, every time a food blog changes its markup. Sites that publish schema.org Recipe JSON-LD are easy; the hand-rolled ones you actually cook from are the ones that break
- Scaling four servings to six, where a third of an egg is the least of your problems
- The only copy of four hundred hand-entered recipes, on a volume you have not backed up since the day you created it
Is that you?
the verdict is a default, not a law
- It runs on your own machine or a box on your own network, for your own household
- You are content to paste a recipe in by hand when the importer fails, rather than debugging somebody else's HTML on a Sunday
- The shopping list is a starting point you edit in the aisle, not an oracle you obey
- Your phone can reach it in a supermarket with one bar of signal
- There is no export and no backup, because a hand-built recipe collection is the one thing here you cannot re-derive from anywhere else
- You are opening it to other households, at which point you have quietly written a small SaaS with logins, invitations and someone else's data in it
- You are crawling recipe sites in bulk rather than clipping the ones you cook — that is a different project with terms of service attached
If you build it anyway
the checklist, then the prompt that enforces it
- Write export before import. A JSON or Markdown dump of every recipe, on a schedule, kept off the machine. This is the only irreplaceable thing in the system.
- Store the raw ingredient line next to the parsed quantity, unit and name. When the parser is wrong you want to see exactly what it was handed.
- Import from schema.org Recipe JSON-LD first, and fall back loudly to a paste-the-text form. A silent half-parse that drops three ingredients is worse than no importer at all.
- Model units by dimension — mass, volume, count — and refuse to merge across dimensions rather than guessing a density. Show the unmerged pile instead of hiding it.
- Never let regenerating the shopping list discard the edits you made in the shop.
- Keep the recipe body as text you can read without the app. If the database is the only way to see your recipes, your side project is now load-bearing for dinner.
I am building a household meal planner: recipe store, drag-to-calendar, generated
shopping list. It is single-household and genuinely low risk, so spend the caution
where it matters. Apply these and push back if I ask you to skip one.
1. Build export before anything else. Before any import path exists, give me a
command that dumps every recipe to Markdown with YAML front matter, and show me
it round-tripping. Hand-typed recipes are the only irreplaceable data here.
2. Store the raw ingredient string on every ingredient row, permanently, next to
whatever you parsed out of it. Parsing is allowed to be wrong; discarding the
original is not.
3. Model units by dimension (mass, volume, count). Refuse to merge grams into cups.
Where two lines cannot be merged, print both on the list rather than picking one.
4. Write the parser against a fixture file of at least fifty real ingredient lines I
will paste in, including '2 (14 oz) cans diced tomatoes, drained', '1½ cups
flour, sifted' and 'salt, to taste'. Show me the failing lines, not a pass rate.
5. Recipe import reads schema.org Recipe JSON-LD. If a page has none, fail visibly
into a paste-the-text form. Never partially import and never invent a field.
6. The shopping list is editable and my edits survive regeneration. Regenerating
merges into the existing list; it never replaces it.
7. Serving-scaling multiplies quantities only. Do not rewrite method text, and mark
scaled amounts so I can see which numbers were derived.
8. No accounts, no invitations, no sharing. If I ask for other households later,
stop and tell me that turns this into multi-tenant software needing real auth.
9. Keep it usable offline on a phone. The shopping list has to render from cache in
a supermarket basement.
10. Out of scope unless I ask, and say so rather than faking it: nutrition data,
pantry inventory, price tracking, and anything that crawls a recipe site.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
Six dollars a month buys two things you would rather not maintain: a clipper that has been taught the quirks of thousands of recipe sites, and a phone app that behaves properly in a shop. If the failure mode you actually fear is 'nobody else in this house will use the thing I built', pay. Otherwise the homemade version is genuinely competitive, and it bends to your kitchen in a way the product will not.
$5.95/mo is cheaper than your weekend.
There is barely an exit problem, and that is the point. Keep recipes as Markdown files with YAML front matter and the raw ingredient lines intact, and the collection outlives the app, the database and your interest in the project. If you move on, Mealie, Tandoor and Paprika all ingest structured recipe text, and the calendar and the shopping list re-derive in an afternoon. The only thing that cannot be reconstructed is a recipe you typed once and never exported.
Actively developed self-hosted recipe manager and meal planner with a URL importer and shopping lists — the whole product, already written.
Self-hosted planner with the most serious ingredient and unit handling in the open-source set, including conversions and food aliases.
Questions
If Mealie and Tandoor exist, why build anything?
Mostly you should not, and self-hosting one of them is the sensible middle. The honest reason to build is that meal planning is extremely personal — your shop, your units, the order of your aisles — and two hundred lines of your own code fits your kitchen better than someone else's model of one. Just read their ingredient handling before you decide yours is a weekend.
Is the recipe importer going to get me in trouble?
Clipping the recipes you personally cook, for your own household, is roughly the shape of printing a web page. Crawling a food site to assemble a recipe database is a different activity with terms of service and copyright attached, and it is not the thing this entry is rating.
What actually goes wrong first?
The shopping list stops being trusted. One week it lists flour twice in incompatible units, the next it drops the tinned tomatoes because the parser choked on a package size, and by the third time you are writing the list on paper again. Nothing broke. It just quietly stopped being worth opening.
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.
Recipes, meal plans, a grocery list. The stakes are dinner.
Port-forwarding your house is a decision, not a feature.
Your family is not a beta cohort. They share your address and they remember the appointment your app dropped.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice