Should I vibe code
Private journal with media, location, prompts, and cross-device sync
A journal is the one database where restoring last week's backup isn't a fix. You can't re-live the entries.
?
Their verdict, the Silver 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
The journal is a text box and a date, and you can have that tonight. Day One is not selling the text box. It is selling a promise that the entry you write this evening is still openable in 2041, on hardware nobody has designed yet, with the photo, the voice memo, the GPS point and the weather still attached, encrypted end to end while it moves between three devices. Every one of those is somewhere a home build loses data without saying so: media stored as absolute paths into a photo library you will reorganise, a sync conflict that resolves in favour of the empty draft, an enrichment API that shuts off and leaves a decade of entries half-annotated, and the classic — an encryption scheme you designed yourself, which works flawlessly until the day you lose the passphrase and discover you never wrote a recovery path. Nobody but you pays for any of it. But a journal is the one database where restoring last week's backup is not a fix, because you cannot go back and re-live 2027.
What actually breaks
not "if". the specific failures.
- Photos referenced by absolute path, then a library reorganisation turns eight years of entries into broken thumbnails
- A sync conflict on an entry open on two devices, resolved last-write-wins in favour of the one you had not typed into yet
- Home-rolled encryption with no key escrow and no recovery path: one forgotten passphrase and the archive is mathematically gone
- The export you wrote but never ran, discovered to be broken on the single day you needed it
- Location and weather enrichment through an API that changes tiers or disappears, leaving years of entries with half their metadata and no way to backfill
- Background upload on iOS, which is governed by rules that change every September and fail silently when they do
- Storage growth nobody modelled — thirty photos and a video per entry, times ten years, on a phone with 128GB
Is that you?
the verdict is a default, not a law
- Entries are markdown files with their attachments beside them in dated folders, referenced relatively
- Sync is a boring file-sync product you already trust rather than a protocol you wrote
- Encryption comes from the operating system — FileVault, device encryption, the Keychain — not from a design of your own
- You have restored the entire archive onto a second machine at least once, on purpose, before relying on it
- You are designing your own encrypted sync protocol, which is the specific mistake this category is famous for
- The only copy of the archive lives inside an app database whose exporter is still on the todo list
- You want it on iOS, Android and the web, because that is three apps and a server, not one project
- You are migrating an existing Day One archive and the import is the hard part — get the export out first and confirm it is complete before deleting anything
If you build it anyway
the checklist, then the prompt that enforces it
- One markdown file per entry in a YYYY/MM folder, attachments in a sibling folder, referenced by relative path. Everything else is derived and rebuildable.
- Write the exporter and the importer before the editor, and run the round-trip in CI. An archive you cannot get out of your app is not an archive, it is a hostage.
- Do not invent encryption. Rely on full-disk encryption plus a synced store you already trust, or use an audited library with a documented, tested key-recovery path.
- Copy attachments into the archive at import time, never link into a photo library. The photo library will be reorganised; your folder will not.
- Store enrichment — weather, location, step count — as literal values at write time, never as an API call resolved at read time.
- Back up somewhere that is not your sync service, and schedule a calendar reminder to restore it onto a second machine once a year.
- Keep the search index disposable. If it can be deleted and rebuilt from the files, it can never be the reason an entry disappears.
I am building a private journal to replace Day One: text, photos, audio,
location, cross-device. Assume the archive will outlive the app by twenty
years and design for that. Argue with me if I ask for anything that risks it.
1. Storage format before features. One entry per markdown file with YAML front
matter, in YYYY/MM folders, attachments in a sibling media folder referenced
by relative path. No opaque database holding the only copy of the text.
2. Build export and import first, and make the round-trip a test that runs on
every commit. If the exporter is not the first working feature it will never
be finished.
3. Then the crash and conflict paths. Atomic writes only — temp file, fsync,
rename. On a sync conflict, keep both versions side by side and tell me.
Never resolve last-write-wins silently.
4. Do not write your own encryption. If I ask for end-to-end encrypted sync,
stop and explain that a lost key means the archive is unrecoverable, then
offer: full-disk encryption plus an existing sync product, or an audited
library with a written, tested recovery procedure. Make me choose out loud.
5. Media is copied into the archive at import, never linked into a system photo
library, and never stored as an absolute path.
6. Location, weather and health data are resolved once at write time and stored
as literal values. Never a read-time API call — that API outlives nothing.
7. Backups: a scheduled export somewhere that is not the sync service, plus a
restore script I can run against an empty machine. Prove it works first.
8. The search index must be deletable and rebuildable from the files alone.
9. No analytics, no crash reporting that includes entry text, no AI feature
that sends an entry anywhere unless I approve that specific request.
10. Out of scope: a second platform, sharing and collaborative journals. Each
changes the threat model completely.
11. When it works, tell me what Day One Silver costs a year and ask whether I
want to be maintaining this in 2036.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
You want the whole product — phone, tablet, laptop, watch, media, encrypted sync, and an archive somebody else is contractually motivated to keep readable. Fifty dollars a year is about four dollars a month for a company whose core competence is not losing your entries, and Day One's export is genuinely good, which means buying it does not lock you in. The build worth doing yourself is the small, local, text-only one. The build not worth doing is the one that tries to match the media and sync story.
$4.17/mo is cheaper than your weekend.
The exit plan and the architecture are the same decision. A folder of dated markdown files with media beside them is already importable into Day One, Obsidian, Journey or nothing at all, and readable by a person with no software at all. Keep it that way and leaving costs nothing. If you instead store entries in a proprietary local database, the exit becomes writing an exporter for an app you have already lost interest in, at the exact moment you have lost interest in it — which is how personal archives quietly become unreadable.
Actively maintained command-line journal that stores everything as plain text, which is the storage model this entry recommends.
Self-hosted, markdown-native capture tool with attachments and a REST API, and a good reference for the dated-entry-plus-media shape.
Questions
How is this different from the Diarly verdict, which is a ship it?
Scope. Diarly is Apple-only, so CloudKit does the sync and the platform does the encryption, and what remains is a markdown editor with a calendar. Day One is iOS, Android, Mac and web with its own sync service, media and transcription — you are not building a different app, you are building four of them plus a backend. Same category, completely different amount of work, which is why one is a Saturday and the other is a multi-year commitment.
What is genuinely worth building here?
The small one. A dated markdown file per day, a template, a reminder, a calendar view and full-text search over the folder is a lovely weekend project and better than any subscription for a text journal. Add photos and it is still fine, as long as you copy them into the folder. The line is sync and encryption: at that point you are writing infrastructure, and the data you are practising on is the one dataset you cannot recreate.
Should I roll my own encryption if only I use it?
No, and being the only user makes it worse rather than better. A bug in a multi-user product gets reported by someone else; a bug in yours gets discovered by you, alone, on the day you need an old entry. Use disk-level encryption or an audited library with a recovery path you have actually tested — and test it by pretending you forgot the passphrase, not by decrypting a file you just encrypted.
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.
Cross-platform is the feature and the bill. Nobody hands you sync, so you write key exchange for a diary.
Apple already wrote the hard half: iCloud syncs it, the Keychain holds the key. You are writing a markdown editor.
A capture app is judged on one number: milliseconds to first keystroke. Everything after that is a text field.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice