Should I vibe code
Doc platform that combines writing, tables, automations, and small apps
You'll have a block editor by Sunday and be maintaining a formula language by Christmas.
?
Their verdict, the Pro Doc Maker 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
This is one of the most flattering demos an agent can produce and one of the most misleading. Coda is three products wearing one coat — a rich-text editor, a spreadsheet with a formula language, and an automation runtime — and the second and third are where the years go. What you get this weekend is a contenteditable div and a table component, and it will look astonishingly close. What Coda has is undo across a nested block tree, two cursors in the same paragraph, paste from Word that does not explode into forty divs, and a formula engine that recalculates without redrawing the document. The gap is not danger. It is that your team will start keeping things in it before you have written an export.
What actually breaks
not "if". the specific failures.
- Concurrent editing, which is not a feature added later — either the document model supports two cursors from the start or the schema is already wrong
- Undo across a nested block tree, where every naive implementation handles the simple case and loses a table on the third ctrl-Z
- The formula language, which begins as three functions and becomes a dependency graph, a type system and a recalculation strategy nobody asked for
- Paste from anywhere else, which is where a hand-rolled editor turns a copied table into a nest of divs and a copied doc into forty empty paragraphs
- Sharing, because the public-link feature always ships before the permission model and a "read-only" link exposes the API that backs the page
- Migration, since the team's operating documentation now lives in a block schema only your application can read
- Whatever ends up in the docs — a table of salaries, a customer list, credentials somebody pasted "temporarily" — because a wiki collects whatever people have to hand
Is that you?
the verdict is a default, not a law
- The document structure is fixed and known — a runbook, a dashboard, a form — rather than an editor where anything can nest inside anything
- One writer at a time, and you would genuinely rather have a bad merge than a CRDT
- Content is stored as markdown or another format something else can already open
- It replaces a spreadsheet rather than becoming where the team writes things down
- Two people will edit the same document, ever
- It becomes the team wiki, which happens quietly and without anyone deciding
- There is no export another tool can read
- You are building a formula language "just for now"
- Losing it would mean losing the only written copy of how anything works
If you build it anyway
the checklist, then the prompt that enforces it
- Decide the storage format before the editor. Markdown, or a documented block JSON with a written spec — this is the exit plan and it has to exist first, because it cannot be retrofitted.
- Use an existing editor framework — ProseMirror, Lexical, Tiptap. A document model is a multi-year project and the hand-rolled one will lose data on paste.
- Build export before the second feature: every document, as files, on demand, without the application running.
- Version documents on every save with a retention window. A block tree with no history means one bad migration is the only copy gone.
- Check permissions on the server, per document, on every API call. Not by rendering only the links a user is allowed to follow.
- If a formula language appears, cap it hard — named functions over a fixed set, no arbitrary evaluation, no recursion, no fetching. "Just eval the expression" is remote code execution in a wiki.
- Write down, on the day you invite the second person, what this is not for: credentials, customer data, anything under retention rules.
I am building a docs-plus-tables workspace. Assume it quietly becomes
where my team writes everything down, and constrain accordingly. Push back if I
ask you to start with the editor.
1. Decide and document the storage format before any editor code — markdown with
front matter, or block JSON with a written spec. Tell me it becomes my only
exit and cannot be changed later without migrating live documents.
2. Build export second, before any authoring feature: every document as files,
on demand, runnable without the app. Until that exists, nothing written in
this tool is safe to rely on.
3. Use an established editor framework rather than contenteditable directly. If
I ask you to hand-roll one, refuse once: paste, undo and selection across
nested blocks are where hand-rolled editors lose content.
4. Version every save with a retention window and a restore path I can use
without a database client. A block tree with no history has no undo.
5. Ask me now whether two people will ever edit one document. If yes, say that
collaboration is a document-model decision and not a later feature, then
either adopt a CRDT library or design explicit locking. Never last-write-wins.
6. Authorise per document on the server on every request, including the API
behind a public share link. Write the test that fetches a forbidden document
id and expects a 404.
7. Public sharing is opt-in per document, revocable, and never inherited by
children. Show me what a shared link exposes beyond the rendered page.
8. If I ask for formulas or automations: a fixed set of named functions, a
parser, no evaluation of arbitrary expressions, no recursion, no network, and
a log of every run. Say "this is remote code execution in a wiki" if I ask
for eval.
9. Sanitise everything rendered from a document, including pasted HTML. A wiki
that renders raw markup is stored XSS aimed at my own team.
10. Out of scope, and say so: live cursors, a formula language worth the name,
and mobile. If I want those, tell me Coda is $12 a seat and that this is
three products, not one.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 moment more than one person writes in it. $12 per Doc Maker buys collaborative editing, version history and an export that works — three things which each cost more than a year of the subscription to build once, badly. Build your own when the doc structure is fixed and narrow and you are really building an internal app that happens to have text in it.
$12/mo is cheaper than your weekend.
Decided in week one or not at all. If content is markdown plus a documented sidecar for the table data, leaving is a directory of files any other tool imports. If it is a block tree in a database, leaving is a migration script you write during the fortnight your team has nowhere to write anything down. The tell is simple: can you produce every document as a file today, with the app switched off? If not, that is the first thing to build.
Open-source workspace with docs, whiteboard and knowledge-base features; a partial Coda-like alternative you can self-host.
Questions
The demo looked genuinely good. What am I missing?
The first ninety percent of a block editor is a weekend and looks indistinguishable from the real thing in a screenshot. The remaining ten percent is paste, undo, selection across nested blocks, and two people typing at once — and that ten percent is what people notice within a day of actually using it. It is the highest ratio of demo quality to product distance on this whole index.
Can I get away with it if only I use it?
Largely yes, and that is a reasonable personal project. The failure mode is social rather than technical: single-user wikis become team wikis without a decision being made, usually by someone else sharing a link. If you build it for yourself, build the export on the same day, so the transition happens with an escape route already in place.
Why is a formula language such a trap?
Because the version that ships is `eval` over user input, which is remote code execution in your own wiki, and the version that is safe is a parser, an evaluator, a type system and a dependency graph for recalculation. There is very little in between, and the in-between version is what an agent will hand you by default.
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 form is easy. A form that receives strangers’ data and does not get spammed is less easy.
One question at a time means storing answers from people who thought about it and decided not to submit.
Jotform will sign a BAA. You will not. That one sentence is the whole verdict.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice