Should I vibe code
Draft long-form fiction with chapters, boards, templates, and story-element tracking
A novel is a folder of text files. Everything else is a sidebar you could rebuild in an afternoon.
?
Their verdict, the LivingWriter 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
Strip the marketing away and a novel-writing app is a tree of text files, a word counter and a sidebar that remembers your characters' names. All of that is genuinely yours to build, it is pleasant to build, and the version you make will fit your process better than any product can, because your process is the requirement nobody else has. There is exactly one condition and it is not negotiable: the manuscript has to live as plain files in a folder you control, under version control, syncing through something boring. Every horror story in this category is the same story — the app was the only place the book existed. Get that right and the worst outcome is an ugly editor you stop using with the words intact; get it wrong and you have built the most expensive possible way to lose two years of work. The one thing worth buying rather than building is the export: a manuscript that has to arrive at an agent as correctly-formatted DOCX, or at a store as valid EPUB, is a standards problem, and Pandoc has already solved it better than you will.
What actually breaks
not "if". the specific failures.
- Sync, in the only way that matters: two devices, one chapter, last-write-wins, and Tuesday's three thousand words replaced by Monday's version of the same file
- The autosave-during-crash window, which is where a scene disappears and where nobody has a backup because the app was the backup
- Export, on contact with reality — an agent wants double-spaced Times New Roman DOCX with specific scene breaks, and a store wants EPUB that actually validates
- The story-element sidebar, once a character is renamed and half the references are stale text rather than links
- Word-count history, which writers care about more than any feature you would predict, and which is trivially easy to lose in a schema change
- Search across a 120,000-word manuscript, when the editor was built around one chapter in memory at a time
Is that you?
the verdict is a default, not a law
- The manuscript is Markdown or plain text in a folder, one file per scene or chapter
- That folder is in git, or in a sync service you already trust with things you cannot lose
- It is for you alone, and nobody else's book is in it
- You can open and finish the book in any text editor on any machine with your app uninstalled
- The chapters live only inside a database, or only inside browser storage
- Two devices write to the same document and you have not thought about conflicts
- Other writers are trusting it with their manuscripts
- Your export path is code you wrote rather than a tool that produces valid DOCX and EPUB
If you build it anyway
the checklist, then the prompt that enforces it
- Files first, always. One Markdown file per scene, in a folder you chose, named so they sort correctly. Any index or database is a cache you can delete and rebuild.
- Put the folder in git and commit automatically on a timer. Version history is the single feature that makes a writing tool trustworthy, and you get it free.
- Never resolve a sync conflict silently. Write both versions to disk with distinct names and tell the writer. Losing a session's work quietly is the only unforgivable bug here.
- Use Pandoc for export rather than generating DOCX or EPUB yourself, and validate the EPUB with epubcheck before believing it.
- Make story elements references to a canonical record, not copied strings, so renaming a character updates every mention.
- Snapshot the word-count log separately from the manuscript. It is small, it is precious to the writer, and it is the first casualty of a schema change.
I want a novel-writing app: chapter tree, corkboard, character and location
tracking, word-count goals. The manuscript is the only thing that matters —
build as though I will lose interest in your UI but not in the book.
1. Decide storage before anything else and make me approve it: one Markdown
file per scene, in a folder I pick, with sortable filenames and YAML front
matter for metadata. No database holds the prose. If I ask for a database,
say no once and explain why.
2. Initialise git in that folder and commit on a timer with a generated message.
Do this in the first commit of the project, not later.
3. Build open, save and export before the editor is pretty. Autosave to disk on
a debounce, and never hold unsaved text only in memory across a navigation.
4. Sync conflicts are never resolved silently. If two versions of a file differ,
write both to disk with distinct names and surface it loudly. Write the test
for the two-devices-one-chapter case.
5. Export goes through Pandoc: DOCX for submission, EPUB for stores, PDF for
proofs. Validate the EPUB with epubcheck. Do not hand-generate either format.
6. Story elements — characters, locations, items — are records with IDs, and
mentions are references to those IDs. Renaming a character must update every
mention. Copied strings are how the sidebar goes stale.
7. Keep the word-count log in its own append-only file, separate from the
manuscript and separate from any schema you might change.
8. Make search work across the whole manuscript at 150,000 words before adding
a second view. Tell me where the performance ceiling is.
9. Anything AI is opt-in, per invocation, writes into a separate draft pane, and
never edits the manuscript in place. Losing my own sentence to a suggestion
is the failure I will not forgive.
10. Out of scope, and say so rather than faking it: collaborative editing,
mobile apps, and cloud accounts. If I want to write on a phone, the answer
is a sync service on the folder, not a backend you build.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 the sidebar is the point rather than the writing, or if the book has a deadline and you would be building instead of drafting. Around fifteen dollars a month is a small price for not thinking about any of this, and Scrivener sells the same shape as a one-off purchase. But this is the rare category where the homemade version is genuinely competitive, because the requirement is your own habits and nobody else can specify those for you.
$14.99/mo is cheaper than your weekend.
There is nothing to exit if you followed the one rule: the book is Markdown files in a folder in git, so uninstalling your app leaves you with the entire manuscript and its full history. That is the whole design, and it is worth stating as the goal rather than the fallback. If you have already put chapters into a database, export every one to a file today and check the result opens in a text editor — that is a twenty-minute job now and an archaeology project the week your schema migration goes wrong.
Plain-text novel editor with a project tree, story elements and Markdown files on disk — close to the recommended shape, already finished.
Open-source writing tool with outlining, character sheets, a corkboard and distraction-free drafting.
Questions
canivibecodeit says KINDA. Why are you more relaxed than they are?
Because our question is about consequences, and here they are unusually small. Their KINDA is a fair read of the work: chapter tree, corkboard, story elements and a clean editor is a real build. Our answer is that if the words are files in a folder in git, the worst outcome is an editor you abandon, with the manuscript untouched. Downside that small is what SHIP IT is for.
What is the single thing that turns this from SHIP IT into a disaster?
Storing the prose only inside the app. Everything else on this page is recoverable. A database schema you outgrow, a browser storage quota, a sync conflict resolved silently in favour of the older device — each of those is how people lose a book, and all of them are avoided by the same decision made on day one.
Should I build the export myself?
No. Submission DOCX and valid EPUB are standards problems with fiddly requirements and a validator that will disagree with you. Pandoc plus epubcheck gets you there in an afternoon and keeps working. Spend the time you saved on the outline view, which is the part that actually differs between writers.
Is adding AI drafting a problem?
Only in how you wire it. A suggestion that appears in a side pane for you to accept is a feature. A model that rewrites a paragraph in place, in the only copy of the manuscript, without a commit behind it, is the one way an AI feature can cost you something you cannot get back. Keep generation out of the document until a human moves it there.
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.
Your novel is the asset, not the app. Keep it as files you can read without it and the AI part is just a menu.
Nobody is buying a novel editor. They are buying autosave that has never once lost a paragraph.
A fiction brainstorming tool is prompts with a nice wrapper. Make it yours.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice