Should I vibe code
Manage a local-first object graph with pages, collections, relations, and peer sync
Local-first object graphs are the correct architecture and also the hardest one to get right.
?
Their verdict, the Builder 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
The philosophy is excellent and the sync layer is where local-first projects go to die. Build it if the journey is the point.
What actually breaks
not "if". the specific failures.
- Local-first sync, which means merging divergent histories without a server to arbitrate — a genuinely hard distributed systems problem
- Naive merge, which produces duplicates rather than conflicts: two objects where there should be one, silently
- Relations between objects, where one side of a link merges and the other does not, leaving dangling references
- Storage growth, because CRDT history accumulates and pruning it safely is its own project
- Encryption plus sync plus key rotation across devices, each reasonable alone and unpleasant together
Your laptop is offline for a week while your phone is not. You edit the same project object on both — rename it on one, add a relation on the other. When they meet, your merge takes the union and you end up with two projects: one with the new name, one with the new relation, both claiming to be the same thing. Nothing errored. The next sync propagates both to your tablet, and now the duplicate looks like history rather than a bug, and you cannot tell which one the other objects are pointing at.
Is that you?
the verdict is a default, not a law
- It is single-device with no sync at all, which removes essentially every hard part
- Sync is a file in a folder that something else replicates, and you accept last-write-wins on whole files
- You are building it to learn CRDTs and shipping is not the goal
- You are writing your own merge algorithm
- Objects have relations and there is no defined behaviour for a dangling reference
- There is no export that works without your sync layer
- It holds notes you would be upset to lose and there is no second copy
If you build it anyway
the checklist, then the prompt that enforces it
- Use an established CRDT library. Do not write a merge algorithm — this is the specific place where 'it seems to work' and 'it is correct' differ invisibly.
- Prefer single-device or file-based sync unless multi-device really matters. Most of the difficulty here is optional.
- Define referential integrity explicitly: what a relation means when its target has not arrived yet, or has been deleted on another device.
- Test by deliberately diverging two clients offline and merging. Include renames, deletions and relation changes to the same object.
- Plan history pruning before storage becomes a problem, and never prune in a way that can resurrect deleted objects.
- Export to plain files continuously, so the notes survive independently of the sync engine that is the risky part.
Before you build a local-first note graph, apply these and push back if I ask you to break them. 1. Ask me whether this genuinely needs multi-device sync. If not, build single-device and tell me that removes the hardest part of the project by a wide margin. 2. If sync is required, use an established CRDT library. Refuse to write a merge algorithm and explain that a homemade merge appears to work while silently producing duplicates rather than surfacing conflicts. 3. Define what happens to a relation whose target object has not synced yet, or was deleted on another device. Dangling references are the normal case in a distributed graph, not an error case. 4. Build a test harness that diverges two clients offline and merges them. Include: rename on one and edit on the other, delete on one and relate on the other, and the same field edited on both. Show me the results. 5. Export every object to plain files continuously, so my notes are readable without the sync engine. Do this before building sync, not after. 6. Plan for history growth from the start — say how large a document's history gets after a year of daily edits, and how pruning will work without resurrecting deleted objects. 7. If encryption is in scope, design key rotation across devices before the first release, not as a follow-up. 8. Out of scope unless I ask: collaboration with other people, publishing, mobile, plugins. 9. Tell me honestly how long the sync layer alone will take.
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
If you want local-first multi-device sync, that is the expensive engineering and $8.25 a month buys it. Building a single-device object graph for yourself is a genuinely rewarding project; adding sync turns a weekend into a research problem.
$8.25/mo is cheaper than your weekend.
Export to plain files on a schedule from the very beginning — this is the category where the sync layer is both the interesting part and the most likely thing to lose data. If the export works, an unrecoverable merge bug costs you a tool rather than a decade of notes.
Active open-source workspace with local-first documents and databases.
Questions
Why do homemade merges produce duplicates rather than errors?
Because the safest-looking fallback is to keep everything. Faced with two versions it cannot reconcile, a naive merge takes the union — and a union of two edits to the same object is two objects. It never throws, so it passes testing, and the damage looks like something you did rather than something the code did.
Is single-device really that much easier?
Dramatically. Without sync there is no divergence, no merge, no dangling relations across devices, no history growth from operation logs, and no key distribution. Most of what makes local-first hard is the 'multi-device' part rather than the 'local' part, and a single-device object graph is an ordinary application.
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.
Beautiful documents are a typography problem, and typography does not respond to prompting.
Sync is the hardest problem you will ever underestimate, and the loser is your notes.
Block references are the fun part. Block references at 50,000 blocks are the part that ends projects.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice