Should I vibe code
Fast personal notes with backlinks, calendar context, and AI assistance
E2EE and an AI that reads your notes pull opposite ways. The homemade version resolves it by keeping your key.
?
Their verdict, the Reflect (single plan) 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
An outliner with backlinks and a daily note is genuinely an evening, and the local-only version of this is a fine thing to own — canivibecodeit is right about the build. Reflect's actual promise is narrower and much harder: the same graph on the laptop and the phone, encrypted so that nobody upstream can read it, with a model summarising it on request. Those three commitments fight each other. End-to-end encryption means the server holds ciphertext, so it cannot merge, cannot index and cannot search, which makes sync a conflict-resolution problem you now own and makes search something that happens on a device after downloading everything. Then the AI features need plaintext, and the shortest path from there is to keep a copy of the key — at which point you have built an ordinary cloud notes app with an encryption-shaped README. Build the graph. Think properly before you build the sync, and be honest about which of the two promises you quietly dropped.
What actually breaks
not "if". the specific failures.
- Sync, the way sync always breaks: the laptop was offline for a day, the phone edited the same block, and something has to choose which paragraph survives. Last-write-wins is the default answer and it is a silent deletion with a timestamp on it
- Search, which you will miss within a week. Ciphertext is not indexable on the server, so search runs on the device over the whole graph, and it stops feeling instant right around the point the graph becomes worth searching
- The encryption you wrote: key derivation, key rotation, and the recovery path for a forgotten passphrase. There is no reset link for a key only you held, and adding one is exactly how the guarantee ends
- The AI features, which need plaintext by definition. Whether decryption happens on the device or on your server is not an implementation detail — it is the difference between the two products
- The backlink index on rename. The graph is the point, and renaming a page that 300 blocks reference is a bulk edit with no undo unless you wrote one
- Imports as a standing tax: a calendar OAuth grant that reads every meeting you have and who was in it, plus a Kindle highlights format that changes when Amazon feels like changing it
- The mobile half, where "fast" is actually judged, and where a hand-rolled sync engine meets its first tunnel
Is that you?
the verdict is a default, not a law
- It is markdown files on your disk and the sync is a folder your OS already syncs
- One user, one device, or a git repo you push by hand
- You want the graph and the daily note rather than the encrypted multi-device product
- The AI runs against a local model, or you have decided exactly which passages leave the machine
- You are writing the encryption yourself and the notes are the only copy
- You have promised anyone else end-to-end encryption, because it is now a claim rather than a preference
- There is an export you have never restored from
- Sync is last-write-wins over whole documents, which loses edits quietly and often
If you build it anyway
the checklist, then the prompt that enforces it
- Plain files first. Markdown on disk, one file per note, links as ordinary text. Everything else — the graph, the index, the search — is derived state you can rebuild from those files.
- Do not design a crypto scheme. Use age or libsodium primitives at the level they were meant to be used, and write down in the README what the threat model actually is and who holds the key.
- Borrow someone else's sync before writing a merge algorithm: git, Syncthing, an OS-synced folder, or a CRDT library like Yjs or Automerge. Merging rich text correctly is a research topic, not a ticket.
- Version every note append-only on disk. It costs a few megabytes and buys back every accidental deletion, which is the failure that actually happens.
- Back up before each schema migration and restore from that backup once, deliberately, before you need it in anger.
- Decide where plaintext goes for the AI features, put the answer in the README, and make the app show which note it is about to send anywhere.
- Test the rename path against a copy of the graph, with a note that is referenced from a hundred places. That is the operation that rewrites the most files at once.
I am building a networked notes app: backlinks, daily notes, sync across my
devices, optional AI summarising. The failure I care about is silent data loss,
and the second is a privacy claim I cannot actually keep. Work in this order.
1. Storage first, and it is plain files. One markdown file per note in a folder
I choose, links as plain text, no proprietary container. Prove I can open my
notes in any editor before you build a single screen.
2. The graph, the search index and the backlink map are derived state. Anything
that cannot be rebuilt from the files is a bug — say so where it is written.
3. Version history before editing features: every save appends the previous
content somewhere recoverable. Show me the restore path working.
4. Do not write encryption primitives. Use an established library, and before
any code state who holds the key, what happens when I forget the passphrase,
and what the server can still see. If I then ask for a password reset,
refuse: a reset means you kept the key.
5. Do not write a merge algorithm. Sync goes through git, Syncthing, an
OS-synced folder, or an existing CRDT library. If I ask for custom sync,
push back once and describe the offline-laptop-versus-phone case concretely.
6. Last-write-wins is banned as a default. On conflict, keep both versions as
separate files and tell me. A visible duplicate beats an invisible deletion.
7. Search runs locally over the files. If encryption is on, say out loud that
server-side search is now impossible and what that costs at ten thousand
notes.
8. For AI features: show me exactly which text is about to be sent to which
provider, per request, and never send the whole graph. Support a local model
as a first-class option rather than an afterthought.
9. Rename and delete are the dangerous operations. Make both dry-runnable and
test rename against a note that a hundred others link to.
10. Out of scope until I ask: sharing, multiplayer editing and publishing. Those
move the risk from mine to somebody else's, and Reflect is $10 a month if I
want that part maintained by people who do it full time.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 you want it on your phone. Ten dollars a month, billed annually, buys multi-device sync you do not maintain, an iOS app you do not build, and an encryption design more than one person has looked at. The graph, the daily note and the backlinks — the part you were actually excited about — is a weekend and yours forever. It is specifically the sync engine that is worth renting.
$10/mo is cheaper than your weekend.
This is the category where a good exit is nearly free, provided the files stayed the truth. If notes are markdown on disk, quitting means stopping the app: the folder still opens in Obsidian, Logseq, a text editor or grep, and the links still read as links. What does not survive is anything that lived only in your database — block-level metadata, the ordering of an outline, saved AI prompts, whatever you invented on top. Mirror those into the files as you create them, keep a copy of the encryption key somewhere one fire cannot reach both copies, and remember that an export you have never restored from is a hypothesis rather than a plan.
Local-first open-source workspace with documents and databases.
Open-source local knowledge graph and outliner built over plain markdown files on disk.
Questions
Isn't end-to-end encryption basically a library call?
Encrypting a blob is. The product is everything around the blob: where the key comes from, how it reaches a second device without a server ever seeing it, what happens on a forgotten passphrase, and how you rotate after you leak one. Each of those is a design decision with a wrong answer that still compiles. The library call is the part you should absolutely not write yourself; the key handling is the part that decides whether the claim is true.
Can I have both encryption and AI features?
Yes, if you decrypt on the device and send only the passage you asked about — that is what a careful implementation does, and it is worth being clear that those words still go to a model provider. The version to avoid is the one that keeps the key server-side so a background job can summarise the whole graph overnight. It is the easiest thing to build and it quietly cancels the entire promise.
Is local-first enough on its own?
For one person on one machine, yes, and that is the version this entry recommends. The trap is the second device. That is where a folder of files becomes a distributed system, and where "it works on my laptop" stops being a joke and starts being a description of your sync guarantees.
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.
Markdown export gives you the cards back. The arrangement — which was the entire point — is not in the file.
Semantic search over fifty notes is magic. Over five thousand it's a ranking problem you have no way to measure.
Typed objects and backlinks is a schema decision, and you have opinions about schemas.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice