Should I vibe code
Long-running note app for capture, search, tasks, and cross-device notes
Sync is not a feature you add in week two. It is the product, and it is a distributed systems problem in a notes app.
?
Their verdict, the Starter 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
You will have a beautiful notes app by Sunday evening. Editor, tags, a sidebar, keyboard shortcuts — all of it, and it will feel better than Evernote because it does exactly what you want and nothing else. Then you buy a second device, and you discover that the product was never the editor. It was sync: two offline edits to the same note, merged correctly, forever, on a corpus that has become the only copy of your last decade. That is a distributed systems problem wearing a text editor, and it is where every version of this project quietly stops.
What actually breaks
not "if". the specific failures.
- Sync, in the specific case you will never test: two devices offline, both editing the same note, and whichever reconnects second silently wins
- Search, at around note four hundred, because `LIKE '%term%'` is not a search engine and retrofitting a real index onto twenty thousand notes is a rewrite
- The web clipper, which is a browser extension aimed at a moving target and breaks with every manifest revision and every site that changes its DOM
- Attachments, which are the actual bytes of your life and are not inside the database dump you have been calling a backup
- A schema migration in month five, run against the only copy, at 23:00, on the laptop
- Your interest, in month seven — at which point you are the sole maintainer of the only place your last decade is written down
Is that you?
the verdict is a default, not a law
- The notes are markdown files in a folder and your app is a nicer way to look at them
- It is a reader and a capture front end over something that already syncs and already backs up
- You would be genuinely fine losing the entire thing tomorrow
- There is exactly one device, and you have made peace with that
- The only copy of anything you would grieve lives inside it
- You are writing your own sync protocol, which is the moment this stops being a notes app project and becomes a database project
- It has to work offline on a phone while a laptop edits the same note
- Attachments matter and your backup only covers the database
If you build it anyway
the checklist, then the prompt that enforces it
- Store notes as files on disk in a format any other program can read. The database is an index you can rebuild; it is never the source of truth.
- Do not write sync. Use a filesystem that already does it, or a CRDT library someone else maintains, or accept a single device.
- Back up automatically before every schema migration, and restore from that backup once, on purpose, before you trust it. The migration that eats notes is this category’s signature failure.
- Adopt SQLite FTS5 in the first commit. Search bolted on later is a rewrite, and you will hit the wall long before you expect to.
- Keep attachments beside their notes on disk rather than in a blob column, so a backup that copies files copies everything.
- Write the export before the import. If you cannot get all of it out as a folder of markdown and files today, you have already locked yourself in.
I am building a personal notes app. Apply these constraints and push back when I ask for the thing that eats notes.
1. Export before anything else. Day one, before the editor: dump every note
as markdown with front matter, plus its attachments, into a folder. Write
the test that round-trips a note through export and import.
2. Notes are files on disk in a folder I choose. Any database is a rebuildable
index over those files, never the source of truth. If I ask you to move the
canonical content into SQLite, refuse and explain what a corrupt index
costs versus a corrupt corpus.
3. Do not implement a sync protocol. If I ask for multi-device, offer three
options — a synced filesystem, a maintained CRDT library, or one device —
and explain that last-writer-wins on an offline edit silently destroys
text with no error anywhere.
4. Full-text search with SQLite FTS5 from the first commit, over note bodies
and attachment text. Tell me now that `LIKE` breaks down in the hundreds,
not the thousands.
5. Automatic backup before every schema migration, written to a separate
directory, with a restore command I can run. Make me actually run the
restore once and confirm.
6. Attachments live next to their notes as ordinary files. No blob columns.
7. Deletion is soft, into a visible trash directory, for at least 30 days.
8. Do not build a web clipper. If I insist, keep it in its own repo — it is a
separate maintenance treadmill against browsers and other people’s markup.
9. Out of scope on purpose: sharing, collaboration, accounts, OCR, encryption
at rest, mobile apps. Put that list in the README so I have to argue with
myself before adding one.
10. Then say the quiet part: I am volunteering to maintain the storage layer
for my own memory, forever, and $15 a month buys a company that has
already recovered other people’s notes from worse mistakes than mine.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 it is going to hold your actual life rather than a demo, rent it. Around $15 a month buys sync that has been fought over for fifteen years, search that works at fifty thousand notes, and — the part that really matters — a company whose support team has recovered other people’s notes from exactly the mistake you are about to make in month five.
$14.99/mo is cheaper than your weekend.
The exit plan is the architecture: markdown files with front matter in a folder, attachments beside them, an index you can throw away. Do that and leaving for Obsidian, Joplin, Evernote or a directory of text costs you a copy command. Skip it and the exit is a scraping project against your own app, written by a version of you who has already lost interest — which is the same as no exit at all.
Mature open-source note app with sync, markdown notes, clipping, and end-to-end encryption.
Self-hosted personal knowledge base with local-first storage and its own sync; a working reference for the part that is hard.
Questions
Why is this DEMO ONLY rather than SHIP IT? Nobody else is affected.
Nobody else is, which is exactly why it is not ABSOLUTELY NOT. It lands on DEMO ONLY for the ordinary reason: you will reach an impressive v0 in a weekend and never reach the product, because the product is sync and search over a corpus that grows for a decade. The gap is not danger, it is that the last 10% never arrives and the notes accumulate anyway.
What if I just use markdown files and skip the database entirely?
Then you have found the SHIP IT version and it is a genuinely good project. Files in a synced folder, an app that reads and writes them, FTS5 as a disposable index. You give up OCR, clipping and cross-device conflict handling, and you get an exit plan for free, which is the better trade for something that has to outlive your enthusiasm.
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.
Sync is the hardest problem you will ever underestimate, and the loser is your notes.
Saving is the weekend. Finding the thing you saved six years ago is the product you will not finish.
Save a URL, tag it, search it. This has been a solved weekend since 2004.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice