Should I vibe code
Plan chapters, draft a manuscript, track plot threads, and sync a structured writing project
Nobody is buying a novel editor. They are buying autosave that has never once lost a paragraph.
?
Their verdict, the Writer 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 novel is ninety thousand words arranged in a tree of scenes, and an agent will hand you that tree — chapters, drag to reorder, word-count goal, focus mode, a dark theme you like better than Dabble's — before dinner. What it will not hand you is the eighteen months afterwards. What Dabble is actually charging for is autosave that has never dropped a paragraph, versioning you have never had to think about, and sync that survives a laptop closing mid-sentence on a train. Those three are the hardest things in the app and precisely what a weekend build stubs out. The way it ends is not dramatic: a last-write-wins merge quietly keeps the older copy of chapter nine, you notice in month seven, and there is no second copy to check against. Build it if the tool is the fun part. If the novel is the fun part, a folder of markdown files under git will outlive Dabble, your app, and probably the laptop.
What actually breaks
not "if". the specific failures.
- Two devices, one manuscript, one flight: the merge that resolves to the older copy without telling anyone
- Autosave on a timer instead of on change, so the four minutes you lose are always the four you liked
- A schema migration against a proprietary local database holding ninety thousand words, with the exporter still unwritten
- Word counts kept as a maintained counter rather than computed, drifting away from the compiled manuscript over months
- DOCX export, where the formatting an editor actually expects — italics, scene breaks, smart quotes, first-line indents — turns out to be its own project
- A single binary project file synced through Dropbox or iCloud, which is the classic way to lose everything to one conflicted copy
- The machine you replace in 2029, holding a file format only your code has ever understood
Is that you?
the verdict is a default, not a law
- Scenes are plain files on disk in a format any other editor can open
- The project folder lives in git or a synced drive and you have restored from it once on purpose
- You are the only writer, on one machine at a time
- You would enjoy the tool-building evening even if you never wrote another chapter
- You are co-authoring, which turns a text editor into a concurrent editing problem
- The manuscript will exist only inside your app's own database
- There is a real deadline and your appetite for a debugging evening in month seven is zero
- You want it on a phone too, because that is a second app plus the sync layer you were avoiding
If you build it anyway
the checklist, then the prompt that enforces it
- Plain text on disk, one file per scene, folders as the outline. Everything else — plot grid, counts, search index — is derived and can be rebuilt from the files.
- Write export before you write the editor. If the first working feature is 'produce a DOCX and a full markdown dump', the project can never trap the manuscript.
- Never sync a single binary project file through a consumer file-sync product. Sync per-scene text files, or use git, or do not sync.
- Snapshot on every save into an append-only history — timed git commits are fine — and make restoring an old version a button rather than an archaeology exercise.
- Test the crash path deliberately: kill the process mid-sentence and confirm what survives. That is the test that matters and nobody runs it.
- Compute word counts and progress from the files at read time. A stored counter will disagree with reality eventually, and you will trust the wrong one.
- Keep an offsite backup that is not the sync service, and restore it onto a second machine once before you rely on it.
I am building a novel-writing app to replace Dabble: scene tree, plot grid,
character notes, word goals. The manuscript is the only thing here that
matters. Refuse the designs that put it at risk, even when I ask for them.
1. Storage first, features second. Every scene is a plain UTF-8 markdown file
in a folder that mirrors the outline, with metadata in front matter or a
sidecar. No proprietary binary container, no single database file that holds
the prose.
2. Build export before the editor. The first working command dumps the whole
project to markdown and to a DOCX with italics, scene breaks and smart
quotes intact. Nothing else ships until that round-trips cleanly.
3. Then the crash path. Save on change with an atomic write — temp file, fsync,
rename — never truncate-and-rewrite. Then write me a test that kills the
process mid-write and asserts the previous version is still readable.
4. Then versioning: commit the folder to git on a timer and on close, with a
restore view that shows a diff. This is the feature I am really paying for.
5. Only after all of that, the outline UI, the plot grid and the stats.
6. If I ask for multi-device sync, stop and tell me it is a merge problem, not
a copy problem. Implement it as per-file sync that keeps conflicts side by
side. Never last-write-wins across a whole project. Never a binary blob in
a sync folder.
7. Word counts, streaks and progress are computed from the files on read. Do
not maintain a counter.
8. Search is an index I can delete and rebuild from the files at any time.
9. No telemetry, no cloud account, and no AI feature that sends the manuscript
anywhere without me typing yes for that specific request.
10. Deliberately out of scope: co-authoring, comments, track changes and
beta-reader sharing. Each is a permissions and merge system, not a UI
addition.
11. Finish by telling me how long this took and that Dabble Writer is $19 a
month, then ask whether I meant to write the book or the app.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
You are drafting to a deadline, or you have lost work before and remember how it felt. Nineteen dollars a month buys autosave and version history that thousands of writers have already stress-tested, sync you never have to reason about, and — quietly the biggest one — no temptation to spend Saturday on the outliner instead of on chapter twelve.
$19/mo is cheaper than your weekend.
Built the way this entry recommends, the exit plan is the storage format: a folder of markdown files with front matter is already readable by Obsidian, by novelWriter, by Scrivener's importer, or by a text editor on a machine that has never heard of your project. Keep it in git and the history comes along too. The version with no exit is the one where prose lives inside your own database, because leaving then means writing an exporter for an app you have already stopped maintaining — exactly when you have least patience for it.
Actively developed plain-text novel editor that stores each scene as its own file, which is the storage model this entry argues for.
Open-source outliner and manuscript organiser with character sheets, plot lines and a distraction-free editor.
Questions
Isn't a folder of markdown files just the answer, then?
For most writers, yes — and it is a better answer than either the subscription or the weekend build. What a folder does not give you is the plot grid, the per-scene metadata view and the sense of a project rather than a pile. If those matter, build a thin viewer over the folder rather than an app that owns the files. The moment the app owns the files you have taken on the one risk this entry is about.
Where exactly does the weekend build fall short?
Three places, in order: atomic saves, version history and sync. Everything visible in Dabble is easy and an agent will nail it. Everything invisible is a distributed-systems problem in a trenchcoat, and it fails in ways you only discover weeks later, which is the worst possible feedback loop for a manuscript.
Why is this demo-only rather than a flat ship it?
Because the failure mode is silent and the data is irreplaceable, which is an unusual pairing for something that only affects you. A broken feature announces itself. A merge that quietly keeps the wrong version of chapter nine does not, and by the time you notice you have written past it.
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.
A fiction brainstorming tool is prompts with a nice wrapper. Make it yours.
Twenty-five reports, and most of them are counting things. The one you can’t write is the grammar engine.
A grammar checker you run locally never has to be trusted with what you wrote.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice