Should I vibe code
Visual whiteboards and cards for research and sense-making
Markdown export gives you the cards back. The arrangement — which was the entire point — is not in the file.
?
Their verdict, the Pro 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 canvas with draggable cards, arrows between them and a markdown editor inside each one is a genuinely good evening, and it will look like Heptabase by bedtime. What it will not have is the two things that make a whiteboard worth trusting with a year of research. The first is that the layout is the content: where a card sits, what it sits next to, how big it is and which group it belongs to is the thinking, and every export format you will reach for stores the text and throws that away — so "I can always get my notes out" turns out to be true of the words and false of the map. The second is sync. The moment there is a laptop and a phone, an offline canvas needs a merge strategy, and the naive one silently resolves an hour of rearranging into whichever device wrote last. Nobody but you is harmed by any of this, which is why the numbers stay low. But a knowledge base whose value compounds for two years and whose failure mode is quiet is a bad thing to have built on a Tuesday.
What actually breaks
not "if". the specific failures.
- Sync, on the day a second device appears — an offline canvas edited in two places needs a real merge, and last-writer-wins turns an afternoon of rearranging into a diff nobody can read
- Export, in the specific way that matters: markdown round-trips the words, and the coordinates, sizes, groupings and connections that carried the argument are not in it
- Canvas performance somewhere between one and two thousand cards, when re-rendering on every pan turns the thing you built for thinking into the thing you avoid opening
- Undo, once a single gesture moves forty cards — a naive stack either restores one of them or all of the wrong ones, and both feel like data loss
- PDF highlight anchoring, which points at character offsets in a document you may re-upload, re-OCR or replace
- Backlinks and orphan cards after a rename, because a graph you maintain by hand quietly stops being a graph
- Your own appetite for maintaining it, roughly six weeks in, at which point the notes are still real and the app is not
Is that you?
the verdict is a default, not a law
- One machine, one canvas, files on local disk, and no sync story at all
- The source of truth is a folder of markdown you already keep, and the whiteboard is a view over it rather than the place the text lives
- You want one specific map — a literature review, a system diagram, a course — and you expect to throw the tool away when that project ends
- You are building it to learn how canvas rendering and spatial layout actually work, which is a perfectly good reason
- There is a phone as well as a laptop, and you have not chosen a conflict-resolution strategy on purpose
- This is where your research will live for the next two years
- You have never tested the export by importing it back into an empty copy of the app
- Somebody else is going to put their notes in it, because now the sync bug lands on them
If you build it anyway
the checklist, then the prompt that enforces it
- Write the export before the editor, and make it lossless: one file per card plus a sidecar recording position, size, colour, group and every connection. If the map is not in the export, you do not have an export.
- Prove the round trip on day one. Export, wipe the store, import, and diff the canvas visually as well as textually. Repeat after every schema change, because that is the change that silently drops a field.
- Pick a sync model deliberately and write down what happens on conflict. Either single-device with a file sync you understand, or a CRDT library you did not write. Ad-hoc last-writer-wins over a whole canvas document is the option that eats work.
- Snapshot the store on a schedule and keep versions rather than one file. The failure here is not a crash, it is a bad merge you notice a week later, and only history gets that back.
- Keep card text as plain markdown on disk, never as rows only your app can read. That is the difference between switching tools and doing archaeology.
- Cap what one canvas holds and virtualise rendering early. Discovering the ceiling at eight hundred cards costs you a rewrite of the part you thought was finished.
- Anchor PDF highlights to quoted text plus a page number rather than byte offsets, so a re-uploaded file degrades to a fuzzy match instead of to nothing.
I am building a visual note app: an infinite canvas of markdown cards with connections between them. The canvas is the easy part. Protect the two things that actually fail — losing the arrangement, and losing work to a bad sync. 1. Before any canvas code, define the on-disk format. One markdown file per card, plus a sidecar recording x, y, width, height, colour, group and every edge. Human-readable, diffable, and readable without my app. 2. Build export and import next, in that order, and write a test that exports a populated canvas, imports it into an empty store and asserts the layout is identical. Tell me plainly if any field cannot survive the round trip. 3. Ask me whether this will ever run on two devices. If yes, stop and make me choose a sync model. Do not invent one. Use an established CRDT library or keep it single-device — never document-level last-writer-wins, which silently discards an hour of rearranging. 4. Snapshot the whole store on a schedule and keep the last thirty. The realistic failure is a merge I notice a week later, not a crash. 5. Undo must be transactional across multi-select. Moving forty cards is one entry on the stack, not forty, and not one. 6. Virtualise rendering from the start and load off-screen card bodies lazily. Show me the frame time at 2,000 cards before adding a second feature. 7. Anchor PDF and web highlights to quoted text plus a locator, never to raw character offsets in a file I might replace. 8. No accounts, no server, no sharing. If I ask for collaboration, say that it changes the data model and should be a separate decision. 9. Out of scope, and say so: mobile apps, real-time multiplayer, and AI over my notes. If I want all three, tell me Heptabase is $11.99 a month and that the sync is most of what I would be paying for.
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
Once there is a second device, or once the notes matter more than the tinkering does. Twelve dollars a month buys offline-first sync, a mobile client and whiteboard-scale rendering, which is essentially all of the work and none of the fun. If you build anyway, build the folder-of-markdown version and let the canvas be a view, not a vault.
$11.99/mo is cheaper than your weekend.
Keep the cards as markdown files in a folder you sync yourself, with the layout in a sidecar next to them, and the whole thing snapshotted on a schedule. Then the exit is a copy command rather than a migration: any editor opens the notes, and the sidecar is the only thing anyone needs to write an importer for if you move to a real canvas tool later. Test that exit once, early, by rebuilding your canvas from the export — the version you never test is the version that turns out to have been dropping edges since March.
Local-first workspace that puts documents and an infinite whiteboard on one data model, which is the specific hard part here.
Infinite canvas SDK with shapes, selection and undo already solved.
Local knowledge graph over plain files, if what you want is the linking rather than the map.
Questions
canivibecodeit says YES and one sitting. Why are you harsher?
Because they are answering whether an agent can build it, and it can — a pannable canvas with markdown cards and arrows really is one sitting. We are answering whether you should keep it. The evening version has no sync, no export that preserves the layout and no history, and none of those absences announce themselves until the notes are worth something.
Isn't markdown export enough of an escape hatch?
For a notes app, mostly yes. For a whiteboard, no. The reason you drew the map is that proximity, grouping and connection carried meaning the sentences do not. Export the words and you have a folder of paragraphs with the argument removed. Put the coordinates in a sidecar and the escape hatch becomes real again, which is why the guardrails put it first.
How is this different from the mem.ai verdict?
Mem is a retrieval problem: semantic search quietly gets worse as the corpus grows and you have no way to measure it. Heptabase is a state problem: the arrangement is the value, it lives in a format only your app understands, and a sync you did not design can clobber it. Different failure, same low blast radius — it is only ever your own work.
What about the AI features?
Skip them in v0. An AI tutor over your own cards is retrieval plus a prompt, it is well-trodden, and it bolts on any time without touching the data model. The data model is the part you cannot change later without a migration, which is why every guardrail above is about the file format.
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.
Semantic search over fifty notes is magic. Over five thousand it's a ranking problem you have no way to measure.
The AI that connects your ideas is an embedding and a cosine. What you're paying for is two taps to capture.
E2EE and an AI that reads your notes pull opposite ways. The homemade version resolves it by keeping your key.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice