Should I vibe code
Write in a focused Markdown library, organize sheets, set goals, and export polished documents
The safest writing app is the one your novel survives. Keep the text as files in a folder and it always does.
?
Their verdict, the Personal 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
Nobody else is on the other end of a writing app. It is your prose, your machine, your problem, and that is the whole reason this one is green: the worst outcome is a bad afternoon and a git checkout. Build it. There is exactly one decision that turns it from harmless into regrettable, and it is the one Ulysses itself made — a library rather than a folder. The moment your sheets live in a database with your own schema instead of as .md files on disk, your manuscript is only as durable as your storage layer, and you will be debugging that storage layer on the evening you most want to be writing. Keep the text as plain files, delegate sync to something that already solved it, and the two genuinely hard parts of Ulysses — three-device conflict resolution and an export that produces a DOCX an editor will accept without swearing — become someone else's problem rather than the reason you stopped writing.
What actually breaks
not "if". the specific failures.
- Sync, the second there are two devices — the same sheet edited on a laptop and a phone, and something has to lose
- A proprietary library format, which is the one decision that makes your text hostage to your own bug
- Export, because Markdown to DOCX is a library call and DOCX-with-styles-a-publisher-accepts is a week
- Word count and goals, which will disagree with your editor's count forever, because footnotes and headers are a judgement call
- The undo stack across a crash, which is where the last forty minutes live
- Full-text search, once the library is a few thousand sheets and you implemented it with LIKE
- Attachments and images, which are the thing that quietly stops being included in the backup
Is that you?
the verdict is a default, not a law
- The text lives as plain Markdown files in a folder you could open with anything else tomorrow
- It is you, on your own machines, with no server in the middle
- Sync is delegated to something that already solved it — iCloud Drive, Dropbox, Syncthing or a git repo
- You would enjoy an editor that is exactly yours, which is a legitimate reason on its own
- You invent a database-backed library instead of files, because the migration out is then a script you write while upset
- Two devices write the same file and nothing decides the winner except whichever save landed last
- The manuscript is the only copy and the backup is the same app that wrote it
- You are actually trying to rebuild the export pipeline, which is the expensive half and the least fun
If you build it anyway
the checklist, then the prompt that enforces it
- Store sheets as .md files in a normal directory. Any index or database you build is a cache you can delete and rebuild, never the source of truth.
- Never write a file in place. Write to a temp file, fsync, rename — the crash-during-save is the one that costs you a chapter.
- Put the writing folder in git, or run a snapshot on a timer. Version history is the feature you will be most grateful for and the cheapest to add.
- Let iCloud, Dropbox or Syncthing own sync. If you must do it yourself, decide the conflict rule first and make it 'keep both', never 'last write wins'.
- Use Pandoc for export rather than hand-rolling DOCX and EPUB. The formats are worse than they look and the styles are the whole point.
- Make search rebuildable from the files. An index that can drift from the text is a bug that reads as lost work.
I am building a personal Markdown writing app — a sheet library, goals, focus
mode, export. It is single-user and local. The only thing I cannot afford to
lose is the text, so build in that order and argue with me if I go off it.
1. The source of truth is a directory of .md files with human-readable names.
Any database is a derived index that can be deleted and rebuilt. Refuse a
design where the only copy of a sheet lives in SQLite.
2. Saving is atomic: temp file, fsync, rename. Show me the crash-mid-save case
working before you build any UI.
3. Add snapshots before you add features — a timed copy or a git commit of the
folder, with a way to browse and restore an old version of a sheet.
4. Do not write a sync engine. Assume the folder is in iCloud Drive, Dropbox or
Syncthing, and handle the conflict files those produce by keeping both
copies and telling me. Never silently pick a winner.
5. Search is an index rebuilt from the files on demand. If the index and the
files disagree, the files win, always.
6. Export goes through Pandoc. Do not hand-roll DOCX, EPUB or PDF writers, and
tell me up front that styled output is the part that takes real work.
7. Images and attachments live next to the text in the same folder, with
relative links, so moving the folder moves everything.
8. Word-count goals are advisory. Never let a goal, a filter or a smart folder
be the only path to a sheet — every sheet stays reachable by file name.
9. Out of scope unless I ask: collaboration, publishing integrations, cloud
accounts, and anything that needs a server. This app should work with the
wifi off.
10. When it works, tell me which parts of the real product I have not
replicated — three-device conflict handling and publisher-grade export —
so I can decide whether $6 a month buys them back.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 write across a Mac, an iPad and a phone and expect to pick up mid-sentence, buy it. $6 a month is buying conflict-free sync across three devices and an export pipeline that produces documents an editor will accept — the two parts you would spend months on and still not match. If you write on one machine, the homemade version is genuinely competitive and quite a lot more fun.
There is nothing to exit. The files are Markdown in a folder; every other Markdown app on earth opens them, and deleting your app leaves the writing exactly where it was. That property is the entire argument for the file-based design, and it is worth more than any feature you would trade it for.
Open-source Markdown writing workbench with project organisation, citations and Pandoc-backed export — the closest full analogue to Ulysses.
The universal document converter that does the export half properly, including DOCX and EPUB with real templates.
Mature open-source grammar and style checker with desktop and server components.
Questions
Files or a database for the library?
Files. A database is faster to query and easier to build features on, and both of those are true right up until the migration that half-succeeds. With files, the worst bug you can ship is a bad UI over intact text; with a library format, the worst bug you can ship is text you cannot get out. Build the index over the files if you need speed — just make it disposable.
Is export really that hard? It is Markdown to Word.
Markdown to Word is one Pandoc invocation. Markdown to a Word file with the right heading styles, correct footnote numbering, a title page and a stylesheet that survives Track Changes is the thing Ulysses spent years on, and it is why people who submit manuscripts pay for it. Use Pandoc with a reference document and you get most of the way; expect the last 10% to cost you more than the editor did.
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.
Tagged Markdown notes in a folder. The format outlives every app that has ever held it.
A capture app is judged on one number: milliseconds to first keystroke. Everything after that is a text field.
A grammar checker you run locally never has to be trusted with what you wrote.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice