Should I vibe code
Browser-based writing studio with goals, analytics, and cloud backup
Novlr's edge is a promise: no AI, writer-owned. You can vibe code an editor. You cannot vibe code a promise.
?
Their verdict, the Studio 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
Three novel-writing tools on this site come out at or near SHIP IT, and the reasoning is always the same — a manuscript is a tree of text files and the app around it is a sidebar you can rebuild in an afternoon. Novlr is where that reasoning runs out, for two reasons that have nothing to do with code. The editor is already free: the no-cost tier gives you projects, focus mode, sprints, streaks and notes, so a weekend spent rebuilding it buys you something you could have had for nothing. And what the subscription actually covers is not features but commitments — unlimited version history, backups somebody else is accountable for, an Academy full of courses, a community of other writers, a stated promise that no generative AI will ever be built into the writing surface, and part-ownership of the company by its writers since 2023. The streak is the tell. A streak works because breaking it costs you something, and a streak in a database whose password you chose costs you nothing at all.
What actually breaks
not "if". the specific failures.
- The motivation, immediately and permanently — goals, streaks and analytics are social pressure wearing a progress bar, and they do not survive being the database administrator
- Version history, which is the feature Novlr charges for and the one a weekend build always stubs to 'we autosave'
- Sync, the first time you draft on a phone on a train and finish on a laptop at home and the merge picks a winner without telling you
- Session auth, because unlike its local-first competitors Novlr is a website, so your rebuild needs accounts, password reset and session expiry before it needs a chapter list
- The backup, which exists right up until the week you need it and discover it has been writing zero-byte files since a dependency bump
- The Academy and the community, which are not software and cannot be built at all
- The word count, eventually, when a schema change silently drops the pre-migration history and the analytics page starts a new life
Is that you?
the verdict is a default, not a law
- The prose lives in plain files in a folder under version control, and the app is a view over them
- You have restored the whole manuscript from a backup at least once, on purpose, before writing chapter two
- The point is enjoying the tool-building, and the novel is not on a deadline
- You are replacing a Google Doc, not replacing a habit
- The database you configured on a Sunday is the only place the book exists
- You are writing your own login, password reset and session handling to get multi-device access
- You expected the streak counter to do to you what Novlr's does
- The manuscript is under contract and a lost week is a conversation with an agent
If you build it anyway
the checklist, then the prompt that enforces it
- Write to plain files first and treat any database as an index over them. Every disaster story in this category is the same sentence: the app was the only place the book existed.
- Put the folder under version control on day one and push it somewhere else. That single decision replaces version history, backup and undo, and it is free.
- Restore before you rely. Wipe the local copy and rebuild the manuscript from the backup once, deliberately, while it is three chapters long rather than thirty.
- If you want it on two devices, prefer a boring sync service over your own auth. A folder in Dropbox with git behind it beats a login screen you wrote in an evening.
- Decide the conflict rule and show it. If two copies diverge, refuse the write and show both versions — silently keeping one is how a rewritten chapter nine disappears.
- Export to DOCX and EPUB through Pandoc rather than by hand. Manuscript formatting is a standards problem that is already solved, and badly-generated DOCX is how a submission gets rejected unread.
- Do not build streaks and goal analytics expecting them to work on you. If accountability is what you need, the cheaper fix is another human being who asks on Fridays.
I am building a browser-based writing app for a novel. Constraints first, and tell me when I am asking for the thing this page warns about. 1. Storage before interface. The manuscript is plain markdown files in a folder, one per scene, with a manifest for order. Any database is an index that can be rebuilt from the files, never the source of truth. 2. Build export and restore before the editor. I want a command that writes the whole book out and a command that reconstructs it from that output, and I want you to tell me to run both before I write chapter two. 3. Initialise a git repository over the manuscript folder and commit on every save. That is my version history; do not implement a bespoke one. 4. Autosave is a write to disk plus a commit, not a debounce into memory. If a save fails, say so loudly in the interface rather than retrying quietly. 5. Do not write my own authentication. If I ask for multi-device access, propose file sync or a managed auth provider first, and only build sessions if I insist — in which case do password reset, session expiry and logout before anything else. 6. Never resolve a sync conflict by picking a winner. Refuse the write, keep both copies, and show me a diff. 7. Deletion is soft with a tombstone, including deleting a scene, a chapter or a project. In a manuscript, delete is nearly always a mistake. 8. Use Pandoc for DOCX and EPUB export rather than generating either by hand. 9. Out of scope: goal streaks, writing analytics, community features and courses. Say plainly that these are the parts of Novlr that do not work when there is only one user and I control the numbers, and that the free tier of Novlr already covers the editor.
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
The novel matters more than the software does. Sixteen dollars a month buys version history you never have to think about, backups that are somebody's job, and a set of promises — no generative AI in the editor, a company partly owned by the people using it — that no amount of code on your machine can reproduce. And if the budget is the issue, note that Novlr's free tier is the editor; the honest alternative to building your own is not paying, it is signing up.
$16/mo is cheaper than your weekend.
If you followed the first guardrail there is no exit to plan, which is the whole point: the book is a folder of markdown under git and every tool in this category imports markdown. If you did not, the exit is whatever your export endpoint produces, so write that endpoint now and open the file it makes — a JSON blob of scene rows is technically an export and practically a hostage note.
Plain-text novel editor that stores the manuscript as files on disk, which is the architecture this page keeps recommending.
Open-source writing tool with outlining, character sheets and a distraction-free mode.
Questions
Why is Novlr rated below Novelcrafter and LivingWriter?
Because those two have a local-files escape hatch and Novlr does not. The advice on their pages is 'build it, but keep the prose as files you can read without the app', and that advice makes the whole risk profile collapse. Novlr is a website by design — there is no desktop app and no local copy — so a faithful rebuild is a hosted application with accounts, sessions and sync, which is a materially larger thing than a text editor. One notch, not three.
Is the no-AI promise really a differentiator?
For a chunk of this market, yes, and it is worth being clear that it is a governance commitment rather than a feature. Novlr states there is no AI writing or co-writing in the product and never will be, and it has been part-owned by writers since 2023. You can absolutely build an editor that contains no AI — that is the default — but you cannot build the assurance, because the assurance is about what happens next year when the roadmap gets tempting.
So what is actually worth building here?
The specific thing your process needs that no product ships. A scene tagger for your own plot structure, a research pane wired to your reference manager, a compile step that produces exactly the format your publisher wants. Build that against markdown files on disk and it is an evening well spent. Rebuilding the editor, the streak and the login is the part that ends with a folder called novel-app-v2 and no novel.
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.
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.
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.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice