Should I vibe code
Write visually polished documents, link them, and export a portable personal library
Beautiful documents are a typography problem, and typography does not respond to prompting.
?
Their verdict, the Plus price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
The editor and export are reachable. The reason people pay is that everything already looks right, which is a thousand small decisions rather than a feature.
What actually breaks
not "if". the specific failures.
- The editor, because rich text editing in a browser is one of the genuinely hard problems and it is the entire surface of this app
- Paste, which arrives as somebody else's HTML from Word, a webpage, or another editor, and has to become your document model
- Nested lists, where backspace at the start of an indented item has about four plausible behaviours and users expect the one you did not pick
- Undo, once collaborative or asynchronous edits enter — a naive undo stack starts reverting other things
- The visual polish itself, which is the product and is measured against a team of designers
Someone pastes three paragraphs from a Word document. What arrives is nested spans with inline styles, mso- attributes, a table wrapping the whole thing and a font declaration on every run. Your sanitiser keeps some of it, drops some, and produces a document that renders almost right — until they hit enter in the middle, and the split leaves half the styling behind. They will not report this as a paste bug. They will say your editor is buggy, and they will be right.
Is that you?
the verdict is a default, not a law
- You build on an established editor framework rather than on contenteditable directly
- It is Markdown-based, where the document model is text and paste is trivial
- It is personal and you are prepared to live with the rough edges you create
- You are implementing rich text on raw contenteditable
- Paste from Word and the web is not handled deliberately
- The appeal is visual polish and you have not budgeted most of the project for it
- There is no export to a format that outlives the app
If you build it anyway
the checklist, then the prompt that enforces it
- Never build on raw contenteditable. Use an established editor framework — the document model, selection handling and undo are years of work you do not need to repeat.
- Consider Markdown seriously. If the document model is text, paste, export and diffing all become easy, and you lose less than you expect.
- Sanitise paste through an explicit allowlist into your own model, and test with real Word and webpage content rather than typed samples.
- Define nested list behaviour explicitly — enter, backspace at start, tab, shift-tab, at every depth — and test each one.
- Build export early and keep it lossless. A notes app people trust is one they can leave.
- Budget most of the schedule for interaction detail. In this category the polish is the product, not the finish.
Before you build a rich text document editor, apply these and push back if I ask you to break them. 1. Do not implement rich text editing directly on contenteditable. Use an established editor framework with its own document model. Tell me that selection handling, undo and paste normalisation are multi-year problems that browsers do not solve for me. 2. Ask me whether Markdown would do. If the answer is anything but a firm no, recommend it — a text document model makes paste, export, diffing and version control nearly free, and removes most of this entry. 3. Handle paste explicitly: sanitise incoming HTML through an allowlist into my document model, and test with content copied from Word, Google Docs and a news site rather than with markup I typed by hand. 4. Define nested list behaviour for enter, backspace at start, tab and shift-tab at every depth, and write a test for each. These are the interactions users hit within minutes. 5. Implement export to a portable format early and keep it lossless. Tell me that a notes tool people trust is one they can leave. 6. Store documents as a structured model, not as an HTML blob, so rendering and export are separate from storage. 7. Add autosave with a local buffer that survives a crash or a lost connection. 8. If collaboration is ever in scope, choose the approach before the document model, because retrofitting it means replacing the model. 9. Out of scope unless I ask: real-time collaboration, comments, version history UI, mobile, publishing.
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 want the polish, $10 a month is buying a design team's output and an editor that has absorbed every paste anyone has thrown at it. A personal Markdown notes app is a genuinely good build; a polished rich text editor is a different and much larger project.
$10/mo is cheaper than your weekend.
Build the exporter in the first week and run it on a schedule to Markdown or HTML files in a folder. Notes accumulate for years and the value is entirely in being able to read them later — an editor with no export is a format nobody else can open.
Active open-source workspace with local-first documents and databases.
Questions
Why is contenteditable considered so difficult?
Because it gives you a mutable DOM rather than a document model, and every browser has its own opinions about what typing, pasting and deleting do to it. Editor frameworks exist because the only workable approach is to intercept everything, maintain your own model, and render from it — which is a large amount of machinery before you have written a feature.
Is Markdown really an acceptable substitute?
For most personal notes, yes, and it removes the majority of this entry's difficulty. What you lose is layout, images placed precisely, and the visual feel that is Craft's actual selling point. If that feel is why you wanted the tool, Markdown will disappoint — which is itself a useful thing to learn before starting.
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.
Sync is the hardest problem you will ever underestimate, and the loser is your notes.
Block references are the fun part. Block references at 50,000 blocks are the part that ends projects.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice