Should I vibe code
Capture small linked cards, tag them, and review or share focused collections
Offline editing plus realtime sharing is a merge problem. Last-write-wins resolves it by eating your paragraph.
?
Their verdict, the Unlimited 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
Cards, links between them, tags and a review mode is a weekend, and the result will feel good by Sunday evening — which is exactly how this category gets you. Supernotes' distinguishing decision is that the card, not the notebook, is the unit of sharing: any single card can be handed to another person, edited by both of you at the same time, and published to a public URL, while still sitting inside both of your graphs. Take that seriously and you have signed up for three genuinely hard problems in one app — a permission list on every object, realtime collaborative editing, and full offline editing — and they interact badly. The one that will actually bite is the third. Two devices, both offline, both edited the same card, and a naive sync takes whichever timestamp is newer. Nothing errors. Nothing is flagged. A paragraph you wrote on a train is simply not there any more, and you will not notice for six weeks, in the one application whose entire purpose is remembering the things you will not. Build the graph. Do not build the sync until you have written down, on paper, what happens to a conflicting edit.
What actually breaks
not "if". the specific failures.
- Sync, silently: two offline edits to one card, last write wins, and a paragraph disappears with no error, no conflict marker and no way to tell which device won
- Per-card permissions, which is an access list on every object rather than a flag on a workspace — and the first bug in that logic shares more than you meant with more people than you meant
- Published cards, because "anyone with the link" is one boolean and a URL that will outlive your interest in the note by several years
- Search, once there are twenty thousand cards and the naive LIKE query starts taking two seconds on a phone with a cold cache
- The backlink index, cheap to maintain on write and miserable to rebuild the day you change the link syntax
- Mobile, which is where notes are actually captured and where your desktop build is not
- Migration, the afternoon you rename a field and the only copy of nine years of thinking is in a database you are about to ALTER without a backup
Is that you?
the verdict is a default, not a law
- It is a single-user graph on one machine and sharing is an export rather than a feature
- You build on an existing local-first sync engine with real conflict resolution instead of writing one
- Every card is a Markdown file on disk, so the worst database bug you can write is still recoverable with a text editor
- Two people are going to edit the same card, offline, on different devices — that is a CRDT problem and it does not have a shortcut
- You are planning to publish cards to public URLs without deciding first what happens when a card that got published is later edited to contain something private
- This is where nine years of notes are going to live and there is no export running on a schedule
If you build it anyway
the checklist, then the prompt that enforces it
- Write the export before the editor. One command, every card, as Markdown files with frontmatter, runnable on a cron. If you never build anything else in this list, build this.
- Decide the conflict rule on paper before writing any sync code, then implement whichever you chose visibly: keep both versions as siblings, or refuse the write and show a diff. Silent last-write-wins is the one option that loses data without telling anyone.
- Keep per-card revision history from the first commit. It is cheap when the schema is new, it is the only way to recover from a bad merge, and it is impossible to backfill.
- If cards can be published, treat the public URL as permanent: unguessable identifiers, an explicit unpublish that actually revokes, and a list somewhere of everything currently public. A published card that gets edited six months later is the sharp edge here.
- Model permissions on the card and test the negative case — that a card shared with one person does not become reachable through a backlink from a card shared with another. Graphs leak sideways.
- Use SQLite with FTS from the start rather than adding search later. Retrofitting an index over twenty thousand rows of Markdown is a weekend you did not budget for.
I am building a networked note-taking app: small linked cards, tags, search, and
sharing at the level of an individual card. Take these as constraints and argue with me
where I break them.
1. Build the export first, before the editor. One command dumps every card as a
Markdown file with YAML frontmatter into a directory. Make it idempotent and make it
runnable from cron. Nothing else in this project matters if that does not exist.
2. Then revision history. Every card keeps its previous versions with timestamps and a
device identifier. Do not defer this — it cannot be backfilled and it is the only
recovery path from a bad merge.
3. Only then sync. Before writing any of it, ask me one question and wait: when the
same card is edited offline on two devices, what should happen? Do not implement
last-write-wins. If I ask for it, refuse and explain that it deletes text with no
error and no trace.
4. Prefer an existing local-first sync engine or a CRDT library over hand-rolled merge
logic, and name which one you used and what its conflict semantics are.
5. Store cards as files or as rows that map one-to-one to files. Never let the only
representation of a note be a blob inside an ORM.
6. Use SQLite with full-text search from the beginning, and seed the database with
twenty thousand synthetic cards before building the search UI so I find out how it
feels at real scale.
7. Permissions belong on the card, not the workspace. Write the negative tests first:
a card shared with A must not become reachable to B through a backlink.
8. If cards can be published publicly, use unguessable identifiers, implement unpublish
as genuine revocation, and give me one screen listing everything currently public.
9. Deletion is real deletion, and it reaches the card, its revisions, its backlinks,
its search index entries and any published URL. Prove it by re-querying each store.
10. Out of scope unless I ask: AI features, a public API, mobile apps and a plugin
system. Then tell me honestly what a sync engine costs to maintain.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
Two people are ever going to edit the same card, or you want this on a phone. Supernotes Unlimited is £6 a month billed annually — £72 a year, priced in pounds by a two-person team in London — and what that buys is the sync engine, the offline handling and the apps on iOS, Android, Mac, Windows and Linux. That is the part of this that is not a weekend, and it is the part that quietly loses your text if you get it wrong. The free tier gives you 100 cards, which is enough to find out whether the card-shaped model suits you before either of you writes any code.
A directory of Markdown files with frontmatter, one per card, written on a schedule rather than on demand. Cards are small, which makes this format unusually honest for Supernotes-shaped data — a card is roughly a paragraph and a paragraph is a file. Keep the links as plain wiki-style references so they survive being read by something that is not your app, and export the revision history alongside, because the version you want back is rarely the current one.
Active open-source workspace with local-first documents and databases.
Local-first knowledge base with realtime collaborative editing already solved on a CRDT.
Self-hosted, Markdown-native quick capture — the closest open thing to a card-shaped note.
Questions
There are already several note apps on this site. What is different here?
The unit. Reflect's entry is about end-to-end encryption fighting an AI that needs plaintext; Heptabase is about the canvas; Napkin is about capture. Supernotes' distinguishing choice is that a single card is the thing you share, publish and collaborate on, which means access control lives on every object and two people can be inside the same card at once. That combination — per-object permissions plus realtime plus offline — is what turns an evening project into a sync engine.
Is last-write-wins really that bad for personal notes?
It is worse for personal notes than for anything else, because there is no second person to notice. In a team document someone says "where did my paragraph go" the same afternoon. In your own notes the sentence just is not there, and you find out in eight months when you go looking for the thing you are certain you wrote down. The whole promise of the category is that the app remembers better than you do, and silent merge loss breaks precisely that promise.
Do I need a CRDT, or is that overkill for one person?
For one device, no — you need a text editor and a backup. The moment there are two devices that can both be edited while offline, you need either a real merge strategy or an honest conflict UI, and a CRDT library is much cheaper than inventing one. The middle option, and the one most weekend builds should take, is to make conflicts visible: keep both versions as sibling cards and let the human decide. Ugly, but nothing disappears.
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.
Beautiful documents are a typography problem, and typography does not respond to prompting.
A search box says "here are three pages". An answer box says "this is true". Only one of those can be wrong.
Last-write-wins is not an error you will ever see. It is a paragraph a colleague typed that quietly never existed.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice