Should I vibe code
Organize recipes, meal plans, timers, and a grocery list locally
Recipe import is not a feature. It is an unpaid subscription to other people's HTML.
?
Their verdict, the Discover (monthly) 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
Recipes are the friendliest data in software: yours, boring to everyone else, worth nothing on a market, and legally invisible. Nothing about a homemade recipe box can hurt a stranger, and the worst realistic outcome is that you cook something at the wrong scale. So build it — and know in advance which bit will actually cost you the weekend. It is not the storage, the timers or the shopping list; it is the import. Crouton's headline trick is pasting a URL and getting a clean recipe, and that works because a good chunk of the web publishes schema.org Recipe JSON-LD, while the rest is a food blog with eleven hundred words about a holiday in Puglia and the ingredients inside a table with no class names. Parse the structured half, paste the rest by hand, and you have something genuinely better than a subscription because it is exactly your kitchen.
What actually breaks
not "if". the specific failures.
- URL import, on any site without schema.org JSON-LD — which is most of the interesting ones, and every one of them differently
- Scaling, the moment an ingredient is "1 can of chopped tomatoes" and the app confidently asks for 1.5 cans
- Unit conversion, because grams to cups depends on what is in the cup, and flour and honey are not interchangeable at any density
- Timers, when the phone locks — running a countdown in the background is a platform permission problem rather than a code one
- Sync, if you add it, since two people editing one shopping list mid-supermarket is the smallest distributed system that still bites
- The library, on the day you change the schema and run the migration once, on a laptop, at midnight, with no backup
- Photo import of a handwritten card, which is OCR against stains and cursive and is a separate project wearing a friendly icon
Is that you?
the verdict is a default, not a law
- It is your kitchen, your recipes, your phone
- Recipes are stored as plain files you could read in a text editor if the app vanished
- You are happy to paste awkward recipes in by hand rather than writing a parser per food blog
- The shopping list syncs through something that already exists — Reminders, a shared note, a git repo — rather than a sync layer you wrote
- You are rebuilding it for a household and there is no backup anyone else knows how to restore
- The plan starts with "first, a scraper that handles any recipe site", because that is the whole project and it never finishes
- It would hold the only digital copy of family recipes that exist nowhere else
If you build it anyway
the checklist, then the prompt that enforces it
- Store recipes as human-readable files — markdown with front matter, or one JSON per recipe — in a folder you can back up, so the app is a viewer rather than a vault.
- Parse schema.org Recipe JSON-LD and stop there. Fall back to a paste box for everything else instead of writing site-specific scrapers you will maintain forever.
- Keep the original source URL and the raw imported text alongside the parsed recipe, so a bad parse is fixable later rather than lost.
- Model quantities as a number, a unit and a note, and refuse to scale anything the unit does not support. "1.5 cans" is worse than "1 can, scaled x1.5 — check this".
- Back up before every schema change, automatically, and keep the last few copies. This is the only genuine loss risk in the whole project.
- Use the platform's own timer and notification APIs rather than a foreground loop, or your pasta finishes when you next unlock the phone.
I am building a personal recipe manager: recipes, meal plans, a shopping list and cooking timers. Keep me out of the two holes this project has.
1. Start with the storage format, not the UI. One human-readable file per recipe — markdown
with YAML front matter, or plain JSON — in a folder I choose. The app reads and writes
that folder and owns nothing else.
2. Write the export and the re-import before any editing screen, and include a test that
round-trips a recipe folder back into an identical library. If the app dies, my recipes
must still open in a text editor.
3. Back up the whole folder automatically before any schema or format change, keeping the
last five copies. Say clearly that this is the only real way to lose anything here.
4. For URL import, parse schema.org Recipe JSON-LD only. If a page does not have it, show a
paste box and let me clean it up by hand. If I ask for per-site scrapers, refuse and
explain that I would be signing up to maintain a parser for every food blog that
redesigns.
5. Keep the source URL and the raw imported text next to the parsed result, so a bad parse
can be corrected later instead of silently becoming the recipe.
6. Model quantities as {amount, unit, note}. Scale only units that can be scaled, and when
an ingredient is "1 can" or "a handful", show the multiplier as a note rather than
inventing 1.5 cans.
7. Do not convert between weight and volume. Flour and honey do not share a density and a
confidently wrong conversion ruins the thing I am cooking.
8. Timers use the platform notification and background APIs, not a foreground interval. Show
me the locked-screen behaviour before you show me the timer UI.
9. Sync is out of scope. If I want the shopping list on another device, write it into a file
in a synced folder or push it to the OS reminders app. Do not build a sync server.
10. Also out of scope on purpose: nutrition calculation, OCR from photos, recipe discovery
feeds, multi-user households. Put them in the README.
11. Finish by telling me which parts of the import are best-effort, so I never assume a
silently mangled recipe is what the site actually said.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
You want the import to just work, on any site, today — that is the feature you would be paying for and the one you cannot realistically reproduce. Crouton is also a rare shape in this category: Plus is a one-time $24.99 unlock rather than rent, which makes "buy it and stop thinking about it" genuinely cheap. If you are on Android or the web, self-hosted Mealie or Tandoor already does everything described here and is a much better use of the weekend than starting from an empty repo.
$1.99/mo is cheaper than your weekend.
There is nothing to escape from if the recipes were never trapped: a folder of markdown or JSON files, backed up wherever the rest of your documents live, readable with or without the app. Keep the original URL and raw text in each file and even a bad parse stays fixable. The failure worth avoiding is the one where the library lives in an app-private database with no export, in which case leaving means writing a migration for a schema you invented and forgot.
Active self-hosted recipe manager and meal planner with URL import, shopping lists and multi-user households.
Self-hosted recipe and meal-plan manager with strong ingredient parsing, scaling and shopping-list generation.
Questions
Why is import the hard part when every recipe site looks the same?
Because they only look the same to a human. The reliable path is schema.org Recipe metadata embedded in the page, which many sites publish and many do not, and once it is missing you are reverse-engineering someone's HTML — which they will change. That is why paid apps advertise import quality as a feature: it is a maintenance commitment, renewed every time a site redesigns, and it is the only part of this project that never finishes.
Is a recipe app really a data-loss risk?
Only in the mundane way, and that is exactly why it catches people. Nobody backs up a hobby app's database, the schema changes three times in the first month, and one of those migrations runs badly at midnight. The recipes are not sensitive, but the handwritten one from your grandmother exists in precisely one place. Files in a synced folder solve this completely, which is why the guardrails start there rather than with the UI.
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.
A shared grocery list is the friendliest possible excuse to learn real-time sync.
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