Should I vibe code
Long-form writing environment for manuscripts, research, and compilation
Your novel is 340 fragments and a manifest. Lose the manifest and you still have 340 fragments.
?
Their verdict, the Standard Licence (macOS or Windows) 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
A manuscript is the one document where the only stakeholder is you and the only unacceptable outcome is losing it, which is why this is green and why the whole entry is about one design decision. Scrivener's actual idea is not the editor — it is chopping a book into hundreds of small documents you can reorder, and then Compile, the pipeline that reassembles them into a DOCX an editor will accept. Copy the first half and you have written yourself a delightful tool in an afternoon. But notice what you have created: three hundred and forty fragments plus a manifest that says what order they go in. The fragments are safe; the manifest is the whole book. Put it in SQLite, sync the folder through Dropbox, open the project on a second machine, and the day those two disagree you are holding a shoebox of scenes with no sequence. Scrivener's answer is that every fragment is a real file with an identity encoded in its name, plus automatic backups on close and a warning before it lets you open a project it thinks is mid-sync. That is a lot of paranoia you would not think to write on a Saturday, and it is the only part worth copying carefully.
What actually breaks
not "if". the specific failures.
- The manifest, which is the ordering of your book and the one file that cannot be reconstructed from the others
- Two devices and a sync folder, where the fragments merge fine and the index does not, because an index is a single file and single files are what sync services pick a winner for
- Compile, which is where the actual work lives: chapter numbering, scene separators, front matter, italics survival, and a DOCX a publisher will open without complaining
- Autosave during a crash, if a save is a truncate-then-write rather than write-temp-then-rename — the failure mode is a zero-byte scene
- Snapshots, which are the feature writers rely on most and the one people leave until version two
- Search across hundreds of fragments, which is instant at 340 documents and is not the reason you would rewrite it later
- Word-count targets, which sound trivial and are the reason people open the app at all
- Import and export of RTF, because formatting is where a writing tool either respects a decade of habits or quietly eats someone's italics
Is that you?
the verdict is a default, not a law
- Every fragment is a real file on disk with a human-readable name, in a folder you could open in Finder and understand
- The order lives somewhere rebuildable — a numeric prefix, a plain-text manifest under version control, anything but a single opaque index
- You write on one machine, or you have thought hard about what happens when two of them disagree
- Compile means concatenate to Markdown and hand it to Pandoc, and you are happy with that
- The only copy of a scene lives inside a database file
- The document order lives only in a table and there is no way to reconstruct it from the folder
- You are writing your own sync rather than putting a folder in something that already solved it
- Your export has to satisfy a publisher's submission format and you were going to hand-roll DOCX
If you build it anyway
the checklist, then the prompt that enforces it
- One scene, one file, plain text, human-readable name. Everything else in the application is an index over that folder and must be deletable and rebuildable without losing a word.
- Encode order in the filesystem where you can — a numeric prefix or a folder hierarchy — so the sequence survives losing every piece of metadata you ever wrote.
- Save atomically: write to a temporary file, fsync, rename. Demonstrate the crash-mid-save case before you build any interface at all.
- Snapshot before features. A timed copy of the folder, or a git commit on a schedule, with a way to browse and restore one scene. Writers change their minds and want yesterday's paragraph back.
- Do not write a sync engine. Assume the folder lives in iCloud Drive, Dropbox or Syncthing, and when you find a conflict file, keep both copies and say so. Never silently pick a winner.
- Detect the mid-sync open. If the index is newer than the fragments, or file sizes look like placeholders, refuse to open and explain why — that single check is the difference between a scare and a loss.
- Send compile through Pandoc. Hand-rolling DOCX or EPUB is weeks of work whose bugs only appear in somebody else's word processor.
- Keep research material as files beside the text rather than blobs inside the index, so a corrupt database costs you an index rather than a folder of PDFs.
I am building a long-form writing app: a binder of small documents, an outline,
a corkboard, word-count targets and a compile step. It is local and single-user.
The only unacceptable outcome is losing text, so build in that order and push
back if I try to skip ahead.
1. The source of truth is a folder of plain-text files with human-readable
names, one per scene. Any database is a derived index that can be deleted
and rebuilt. Refuse a design where a scene exists only inside SQLite.
2. Encode document order in the filenames or the directory structure, not only
in the index. I want the sequence to survive losing all metadata.
3. Saving is atomic — temp file, fsync, rename. Show me the crash-mid-save case
working before any UI exists.
4. Add snapshots before features: a timed copy or a scheduled git commit of the
folder, plus a way to browse and restore a single scene.
5. Do not build sync. Assume the folder lives in iCloud Drive, Dropbox or
Syncthing; on finding conflict files, keep every copy and say which is which.
6. Add an integrity check on open: if the index disagrees with the folder, or
files look like sync placeholders, refuse to open and explain what you saw.
7. Rebuild the index from the folder on demand, and make that a visible menu
command rather than a recovery script I have to find later.
8. Compile goes through Pandoc. Do not hand-roll DOCX, EPUB or PDF writers, and
warn me that formatted output is where the real time goes.
9. Research files, images and notes live next to the text in the same folder
with relative links, so moving the folder moves everything.
10. Word-count targets, labels and collections are advisory. Every document
stays reachable by filename, never only through a smart filter.
11. Out of scope unless I ask: collaboration, accounts, cloud storage and
anything needing a server. This should work with the wifi off.
12. When it runs, tell me what I have not replicated — Compile's formatting
rules and the iOS sync — so I can decide whether $59.99 once 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
Buy if you are going to Compile for real — a publisher's submission format, an EPUB, chapter numbering and front matter that behave — or if you write across a Mac, a PC and an iPad and expect the project to follow you. Sixty dollars once, not per month, is a rounding error against the weeks that formatted export and cross-device sync would take you. Build your own if what you want is a binder, a corkboard and a concatenate-to-Markdown button on one machine, because that version is genuinely competitive, considerably more fun, and shaped exactly like your own head.
There is nothing to exit if you build it right, and that is the whole argument for the file-based design. Scenes as Markdown in a folder open in every editor on earth, the order is legible from the filenames, and deleting your app leaves the book exactly where it was. The failure to avoid is the opposite shape: a proprietary project file referencing documents by internal id, which turns quitting into an archaeology project. If you have already built that, write the exporter now rather than on the day you stop caring about the app.
Open-source writing tool built directly on the Scrivener model — outline, index cards, character and plot tracking.
Plain-text novel editor that keeps every scene as its own file on disk and builds the manuscript from the folder.
Questions
Is there really no risk here?
Only one, and it is the one that matters to the person building it. There is no money, no regulator, no stranger's data and nothing on the internet — the worst possible outcome is that you lose your own manuscript. That is a survivable engineering problem with well-known answers, and it is why this entry is green and why every guardrail on it is about durability rather than security.
How is this different from the Ulysses entry?
Ulysses is about keeping the text as files rather than as rows, and that advice applies here too. Scrivener adds a second thing to lose: the order. A Ulysses library is a pile of sheets you can read in any sequence and still recognise; a Scrivener project is a book that only exists when three hundred fragments are in the right sequence. Which is why the practical fix here is to put the sequence in the filenames rather than only in an index.
What is Compile actually doing that is hard?
Turning a hierarchy of fragments into a formatted document under rules that differ per output. Chapter numbering that skips the prologue, scene separators that become a centred glyph in print and a blank line in ePub, front matter included in one target and not another, italics and small caps surviving the trip into a word processor. Every one of those is easy alone and the combination is the reason the feature has its own manual. Pandoc will do most of it if you let it.
What will an agent get wrong?
It will store the documents in SQLite. That is the natural implementation for a binder with metadata, ordering, labels and search, it demos beautifully, and it puts the only copy of your manuscript inside a file format you cannot read with your eyes. It will also treat the ordering as a column rather than as something derivable from disk, which is the exact failure this entry is about.
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.
The safest writing app is the one your novel survives. Keep the text as files in a folder and it always does.
Nobody is buying a novel editor. They are buying autosave that has never once lost a paragraph.
A novel is a folder of text files. Everything else is a sidebar you could rebuild in an afternoon.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice