Should I vibe code
Manage shared grocery lists, recipes, and meal plans with a simple household sync server
A shared grocery list is the friendliest possible excuse to learn real-time sync.
?
Their verdict, the Complete 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
Small, shared with people who love you, and the worst outcome is buying milk twice. Ideal territory for building the thing rather than renting it.
What actually breaks
not "if". the specific failures.
- Offline in a supermarket, which is where the list is actually used and where signal is worst
- Two people editing the same list at once, which is the normal case — one at home, one in the aisle
- Ticking an item that someone else already removed, so the list disagrees with itself between two phones
- Item identity, where 'milk' added twice by two people should probably be one line and sometimes should not
- Household adoption, because a shared list only works if everyone uses it and one holdout defeats it
The realistic failure is a Saturday, in a shop, with one bar of signal. You tick things off as you go and the app looks fine, because it is optimistically updating locally. At the checkout your partner texts to ask why you did not get the bread — they added it twenty minutes ago and it never arrived on your phone, and the three items you ticked have not propagated either. The list is not broken. It is just two lists now, and the reconciliation happens in the car park.
Is that you?
the verdict is a default, not a law
- It works fully offline and syncs when it can
- Concurrent edits merge rather than overwrite
- The household actually agreed to use it
- It requires a connection to show the list
- Sync is last-write-wins on the whole list
- Only you will use it, in which case it is a text file
- Ticking an item is not idempotent
If you build it anyway
the checklist, then the prompt that enforces it
- Offline first. The list must be fully readable and editable with no signal, because the shop is where it is used.
- Merge at item level, never at list level. Two people editing different items must both succeed without either noticing.
- Make ticking idempotent and tolerant — removing an already-removed item is a normal event, not a conflict.
- Use a CRDT or a simple per-item last-writer-wins with a tombstone for removals, and never resurrect a deleted item.
- Deduplicate on add by normalised name, with an easy override for when two really are wanted.
- Keep it fast to add an item — one field, one tap. A shared list competes with shouting down the hall.
Before you build a shared grocery list, apply these and push back if I ask you to break them. 1. Build offline-first. The list must be fully usable with no connection, because the place it is used is a supermarket and that is where signal is worst. Test in airplane mode before adding any feature. 2. Merge changes at item level, never by syncing the whole list. Two people editing different items must both succeed silently. Explain that list-level last-write-wins is what makes shared lists lose items. 3. Make every operation idempotent: ticking an already-ticked item, or removing an already-removed one, is normal rather than a conflict. 4. Use tombstones for removals so a stale device cannot resurrect an item that was already bought. 5. Deduplicate on add by normalised name, and make the override obvious for when two entries are genuinely wanted. 6. Keep adding an item to one field and one tap. This competes with a text message, and friction loses. 7. Show sync state honestly — when the list last synced, and whether there are unsent changes. Never imply everything is up to date when it is not. 8. Out of scope unless I ask: recipes, meal planning, price tracking, store layouts, barcode scanning. 9. Tell me that the hardest part of this project is household adoption, not code.
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
At $0.83 a month this is nearly free and works everywhere. Build it because real-time sync on something genuinely low-stakes is the friendliest way to learn the problem — the hot take is right that this is a good excuse rather than a saving.
There is very little to keep — a grocery list is worthless a week later, which is part of why this is such a comfortable project. Keep recipes, if you add them, as plain files; the list itself is meant to be thrown away.
Active open-source recipe manager and meal planner for households.
Questions
Why is a grocery list a good project for learning sync?
Because it has every interesting property and no consequences. Two writers, frequent concurrent edits, terrible connectivity, and a genuine need for offline — but if it goes wrong you buy the wrong bread. That combination is rare; most systems with real sync difficulty also have real stakes.
Why tombstones instead of just deleting?
Because a device that was offline still has the item and will happily sync it back. Without a record that it was deliberately removed, the sync sees an item on one side and absence on the other, and adding it is the safer-looking choice — so bought items reappear. A tombstone makes the removal a fact rather than an absence.
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