Should I vibe code
Write tagged Markdown notes with backlinks and sync them across Apple devices
Tagged Markdown notes in a folder. The format outlives every app that has ever held it.
?
Their verdict, the Pro 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
Writing and tagging is easy; the reason to build it is that plain Markdown on disk means you never have to migrate again. Sync is the only part to treat carefully.
What actually breaks
not "if". the specific failures.
- Sync, which is the only genuinely hard part and the reason the paid tier exists
- A file-sync service resolving a conflict by keeping both, so you accumulate 'note (conflicted copy)' files nobody merges
- Search across thousands of notes, which is instant at a hundred and needs an index at ten thousand
- Tags parsed from the text, where renaming a tag means rewriting every file that mentions it
- Backlinks, which have to be indexed on write or recomputed on read, and neither is free at size
The honest failure is small and slow. You write on your laptop and your phone, syncing through a folder, and one afternoon both devices have an unsynced edit to the same note. The sync service does the sensible thing and keeps both, leaving a conflicted copy beside the original. You do not notice, because you were not looking at that note. Three months later there are nine of these, each holding a paragraph that exists nowhere else, and merging them is an evening of reading your own writing twice.
Is that you?
the verdict is a default, not a law
- Notes are Markdown files in a folder and the app is a view over them
- Sync is a service you already trust, and conflicts are surfaced rather than hidden
- It is yours, and the worst case is re-reading a duplicate
- Notes live only in a database with no file representation
- Conflicted copies are created silently and never surfaced
- You are writing your own sync engine for this
- Search is unindexed and the collection will grow past a few thousand
If you build it anyway
the checklist, then the prompt that enforces it
- Markdown files in a folder, one note per file. The format outliving the app is the entire reason this verdict is SHIP IT.
- Use an existing sync service rather than writing one, and actively detect conflicted copies so they surface instead of accumulating.
- Index for search on write. Scanning files works until it does not, and the transition is abrupt.
- Store tags in front matter rather than parsing them from prose, so renaming is a metadata change rather than a rewrite.
- Keep an append-only history or rely on version control, since a notes app is the only copy of thinking you cannot reconstruct.
- Make the app a view over the files, never the owner of them — anything you can only do in the app is a thing you lose with it.
Before you build a Markdown notes app, apply these and push back if I ask you to break them. 1. Store one note per Markdown file in a plain folder, with metadata in front matter. Tell me this is why the project is safe: the format outlives the application, and the app is a view rather than an owner. 2. Do not write a sync engine. Use a file sync service I already have, and actively scan for conflicted copies — files matching the service's conflict naming pattern — and surface them prominently. Explain that these accumulate silently and each one holds writing that exists nowhere else. 3. Build a search index updated on write. Scanning files directly works for a few hundred notes and degrades sharply after that. 4. Put tags in front matter rather than parsing them from the body, so renaming a tag does not mean rewriting prose across many files. 5. Index backlinks on write, and define what happens when a link target is renamed or deleted. 6. Rely on git or an append-only history for versions. A notes collection is the one dataset I cannot reconstruct from anywhere else. 7. Never store anything in the database that is not also in the file. If a feature requires state the file cannot hold, tell me what I would lose by abandoning the app. 8. Out of scope unless I ask: real-time collaboration, publishing, encryption, mobile app, WYSIWYG editing.
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
$2.99 a month is essentially buying sync across Apple devices, which is the one hard part. If you have a sync service you already trust, building the editor over a folder of Markdown is one of the most durable projects on this list.
There is barely an exit to plan, which is the point — the notes are already Markdown files in a folder. Keep it that way and abandoning the app costs nothing but the view. Put the folder in version control and the history comes free.
Active open-source workspace with local-first documents and databases.
Questions
Why are conflicted copies worse than a sync error?
Because they are silent and they look like success. The sync service did the safe thing — it kept both versions rather than choosing — but it filed the second one as a new file you have no reason to open. Errors get investigated; a spare file in a folder of hundreds does not, and the divergent paragraph sits there until you go looking.
Is one file per note really better than a database?
For notes specifically, yes, and it is why this entry is SHIP IT rather than DEMO ONLY. Plain files mean any editor opens them, version control works, sync services handle them, and abandoning your app costs nothing. A database gives you faster queries and takes the notes hostage — a poor trade for something you intend to keep for a decade.
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