Should I vibe code
Cross-platform journal with photos, maps, reminders, and cloud sync
Cross-platform is the feature and the bill. Nobody hands you sync, so you write key exchange for a diary.
?
Their verdict, the Membership (monthly) 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
Our Diarly entry is a SHIP IT for one reason: it is Apple-only, so the two hard problems in a journal are already solved by somebody else — CloudKit moves the files, the Keychain holds the key, Face ID unlocks it, and what is left for you is a markdown editor with a calendar. Journey is the same product with that reason deleted. Android, Windows, Linux, the web and iOS means no platform will hand you sync, no platform will hand you a key store, and the encryption you promised yourself is now a key-exchange protocol between devices that you are designing personally, for a diary, in a weekend. The browser client is where this gets properly awkward: end-to-end encryption implies the key reaches the page, and holding a long-lived secret in a browser is the least comfortable place in computing to hold one. Add photos and video — Journey allows twenty attachments per entry against 10 GB — and sync stops being text reconciliation and becomes a media pipeline with conflict resolution. Nobody but you is harmed by any of it, which is exactly why this is DEMO ONLY rather than worse. The catch is the asymmetry: a journal is the one database where restoring last week's backup does not fix anything, because the entry you lost was the whole point.
What actually breaks
not "if". the specific failures.
- Sync conflicts, in the direction that hurts: two devices edit the same day, one of them was mid-draft, and last-write-wins quietly promotes the empty version
- The passphrase, because end-to-end encryption you designed has no recovery path unless you designed one, and a decade of entries becomes a folder of ciphertext you own and cannot read
- Device pairing, which is the part people skip. Getting the key onto a second device without sending it through your own server is a protocol, and the shortcut everyone takes is a server-side copy that makes the encryption decorative
- The web client, where the key has to live in browser storage to be useful and is therefore reachable by anything that gets to run script on that origin
- Media attachments, when the entry references a file by absolute path into a photo library you later reorganise, or when a video upload fails halfway and the entry saves with a broken pointer
- Migrations, on a schema that holds every entry you have ever written and gets altered by an app update that shipped on Sunday night
- The enrichment metadata — weather, location, what you were listening to — because those APIs change terms and vanish, leaving five years of entries half-annotated in a way you cannot backfill
- Full-text search over encrypted content, which either means decrypting everything to search or maintaining an index that leaks exactly what you encrypted the entries to protect
- Cross-platform effort, which is not one project: five clients means five release processes, five sets of OS deprecations and five places a bug lives
Is that you?
the verdict is a default, not a law
- Entries are plain markdown files in a folder, and sync is a folder-sync tool you did not write
- You are honestly building for one platform, in which case read our Diarly entry instead and go and enjoy your Saturday
- Encryption comes from the platform or an audited library, with a written, tested recovery path you have used at least once
- There are no attachments beyond images copied into the folder next to the entry
- You would be fine losing the app entirely, because the words are still readable by any text editor
- You are designing the encryption or the key exchange yourself
- The entries live in a proprietary database or a single blob rather than as files
- A browser client needs to decrypt content, which is the hardest place to hold a key and the easiest to lose it from
- You have never restored from your own backup
- Sync is doing conflict resolution and you have not decided, in advance and in writing, which side wins
If you build it anyway
the checklist, then the prompt that enforces it
- Store entries as one plain file per entry, in a normal folder, with the date in the filename. Every failure on this page becomes survivable the moment the words are readable without your code.
- Do not sync it yourself. iCloud Drive, Syncthing, Dropbox or a git repository will move files between platforms better than the layer you would write, and they have already met every conflict you are about to.
- If you encrypt, take an audited library and a documented scheme — age, libsodium, the platform key store — and write the recovery path before the encrypt path. Then test recovery on a machine that has never seen the key.
- Decide the conflict rule up front and make it non-destructive: keep both versions with a suffix rather than merging or overwriting. A journal never wants a silent merge.
- Copy attachments into the entry's own folder instead of referencing a photo library. Absolute paths into someone else's app are a broken link with a delay on it.
- Back up to a second location automatically, and restore from it once, deliberately, before you trust the app with anything you would miss.
- Keep the export continuous rather than a feature: a nightly dump of markdown plus media, so an exit is always one folder away.
- Version the schema and write migrations that copy forward rather than alter in place, keeping the previous version until the new one has opened cleanly.
- Be careful what the search index contains. An index over decrypted text stored beside the ciphertext undoes the encryption for anyone who reads the disk.
I am building a cross-platform journal: entries with photos, on more than one
operating system, synced, and encrypted. Before you write anything, understand
that losing an entry is not recoverable — I cannot re-live the day.
1. First, argue with me about scope. If I only really use one platform, say so
and recommend the single-platform version that borrows the OS for sync and key
storage, because it is a fraction of this work.
2. Storage format first, and it is one plain file per entry in a normal folder
with the date in the filename, media in a subfolder next to it. No proprietary
database, no single blob. Justify any deviation to me explicitly.
3. Then backup and restore, before any editor UI. Automatic copy to a second
location, and a restore I perform once, from scratch, while you watch.
4. Then sync, and default to not writing it: recommend an existing file-sync tool
and explain the tradeoff. If I insist on my own sync, the conflict rule is
non-destructive — keep both versions with a suffix, never merge, never let an
empty draft overwrite a longer entry. Write the conflict tests first.
5. Then encryption, if I want it, using an audited library and a standard scheme.
Write and test the recovery path before the encryption path, and refuse to
invent a key-exchange protocol between my devices. If I ask you to design one,
tell me plainly what happens when I lose the passphrase.
6. If there is a web client, tell me exactly where the key lives in the browser,
what can reach it, and what happens on a shared computer. Recommend against it
for v1.
7. Attachments are copied into the entry folder, never referenced by absolute
path into a photo library.
8. Search: say clearly whether the index stores plaintext, and where it sits
relative to the encrypted entries.
9. Schema changes copy forward into a new version and keep the old one until the
new files open cleanly. Never alter entries in place during an update.
10. Write a continuous export — nightly markdown plus media — before any feature
I would call fun.
11. Out of scope for v1: reminders, maps, weather enrichment, AI prompts, shared
journals. Say so, and mention that $6.99 a month buys five maintained clients
and somebody else's sync.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
As soon as you notice you want the same journal on a phone and a laptop that do not share an ecosystem. That gap is the entire price of the product: $6.99 a month, or $49.99 a year, buys five maintained clients, a sync layer that has already met your conflicts, key management you did not design, and 10 GB for the photos. If you are Apple-only, buy nothing and go and build it — our Diarly entry is a SHIP IT and it is the same weekend without the hard half.
$6.99/mo is cheaper than your weekend.
If you followed the first guardrail there is no exit to plan: the entries are markdown files in a folder and they open in anything, forever, with or without your app. That is the entire argument for the format. If you did not — if the entries are rows in a database, or encrypted blobs keyed to a device — then write the exporter now rather than on the day you get bored, because the exit becomes considerably harder once the app that can decrypt them is also the app you no longer want to maintain. Whatever you build, make one continuous export of markdown plus media the first feature that works, and keep a copy somewhere the project cannot reach.
Actively developed cross-platform notes app with end-to-end encrypted sync across desktop, mobile and several storage backends.
Open-source outliner built around a daily journal page, storing entries as plain markdown files on disk.
Questions
Diarly is a SHIP IT and this is not. What is the actual difference?
One platform versus five. On Apple's platforms, sync and key storage are libraries you call: CloudKit or an iCloud folder, the Keychain, the Data Protection APIs. Cross-platform deletes all of that and hands you the two hardest parts of the product as your own code, plus four more release processes. The journal — editor, calendar, templates, streaks — is identical in both entries, and it was never the difficult bit.
Can't I just put the files in Dropbox and be done?
Yes, and that is the recommendation in the guardrails rather than a cop-out. Plain files plus an existing sync tool gets you most of what the paid product does, on every platform, with conflicts handled by software that has seen millions of them. What you lose is the polish — the media pipeline, the search, the mobile app — and what you gain is that no failure of yours can make the words unreadable.
How bad is rolling my own end-to-end encryption really?
The encryption itself is fine; libraries do that part and you should use one. The failures are at the edges. Getting the key to a second device without your server seeing it is a real protocol, and the shortcut people take makes the encryption cosmetic. Recovery is worse: a scheme with no reset is exactly what the marketing promises and exactly what destroys ten years of entries the day you forget a passphrase. Design recovery first, then decide whether you still want it.
Why is dataSensitivity so high for something only I read?
Because of what is in it. A journal is where people write about their health, their relationships, their work and things they have told nobody, and it is one of the few personal datasets with no upside to a leak and no way to rotate the contents. The blast radius is small — the number of people affected is one — but the sensitivity of what that one person wrote is near the top of the scale, and the two dimensions are deliberately separate.
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 journal is the one database where restoring last week's backup isn't a fix. You can't re-live the entries.
Apple already wrote the hard half: iCloud syncs it, the Keychain holds the key. You are writing a markdown editor.
Local-first object graphs are the correct architecture and also the hardest one to get right.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice