Should I vibe code
Encrypted task manager with habits, journaling, and relationship notes
Build the task app. Do not build the encryption — a key bug loses the journal silently, and there is no support line.
?
Their verdict, the Premium price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-05.
?
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
Tasks, habits, a mood tracker and a journal is a schema and a handful of screens, and canivibecodeit is right that an evening gets you something you would actually use. Two things make this worth more than a shrug. The first is what the file contains: not a shopping list but a mood log, journal entries, and private notes about the people in your life — closer to a therapy notebook than to a to-do app, which is precisely why Lunatask encrypts it. The second follows from the first: build the app, do not build the encryption. Client-side E2EE with multi-device sync is the one part of this where a mistake is silent and total — a changed Argon2 parameter, a reused nonce, a key you never wrote down, and a year of entries decrypt to nothing with no error until you open the app on a new laptop. Keep it on one machine, let disk encryption be your threat model, and this is one of the cleanest builds on the site.
What actually breaks
not "if". the specific failures.
- Homemade end-to-end encryption, which fails silently: a key derived with different parameters than last release, a nonce reused across records, or a passphrase with no recovery path, and the data is gone in a way no error message announces
- Sync conflict resolution, which is harder under encryption because the server cannot merge anything it cannot read — so the client has to, and last-write-wins quietly eats the entry you wrote on the phone
- Recurrence rules, which look like a weekend and are not: "every other Tuesday", month-end, and the day a habit's streak crosses a DST boundary
- Streaks and habit maths, where the definition of "today" depends on a timezone, a wake time and whether you count the day you were ill
- The journal and mood history, which is the part with real emotional cost attached and is the part nobody remembers to back up
- Automatic prioritisation, which is a scoring function you will tune for a week and then quietly stop trusting
- Search over encrypted content, which has to happen on the client and gets slow exactly when the archive is large enough to be worth searching
- The database file itself, sitting in whatever folder felt convenient — which is frequently a folder that syncs to somebody else's cloud by default
Is that you?
the verdict is a default, not a law
- It runs on one machine, stores to a local file, and the disk is already encrypted
- You are the only user and nobody else has an account, because there are no accounts
- Export to JSON or Markdown exists before anything else does
- Multi-device means a file you copy deliberately, not a sync service you wrote
- You are implementing your own cryptography for sync — use libsodium or an established sync layer, or stay local
- The data file lives in iCloud Drive, Dropbox or any folder that syncs by default without you deciding it should
- Other people's notes are in it — a relationship tracker holds information about people who did not agree to being tracked
- There is no export and no backup, which makes a schema migration the most dangerous thing you will ever run
If you build it anyway
the checklist, then the prompt that enforces it
- Build export before you build anything else. JSON for the data, Markdown for the journal, run on a schedule, verified by re-import. This is the single most valuable hour in the project.
- Stay local unless you have a genuine reason not to. A file on an encrypted disk is a better threat model than a sync service you designed on a Sunday.
- If you want encryption anyway, use libsodium or age through a maintained binding, never a hand-rolled construction, and write down the key derivation parameters as data rather than as constants in the source.
- Whatever the key is, give it a recovery path you have actually tested — a printed phrase, a file in a password manager — before you put a year of journal entries behind it.
- Keep raw entries append-only and treat edits as new versions. A journal you can accidentally overwrite is a journal you cannot trust.
- Store timestamps as UTC plus an IANA timezone, and write the DST test for streaks before you need it.
- Deliberately place the database outside every folder that syncs by default, and print the chosen path on first run.
- Notes about other people deserve their own decision: what you record, how long you keep it, and what happens to it if someone asks.
I am building a private task manager for myself with habits, a mood tracker,
journalling, and notes about people I know. The data is closer to a diary than
to a to-do list. Build in this order.
1. Export first: JSON for structured data, Markdown for journal entries, one
command, plus an import that round-trips. Nothing else starts until that
works.
2. Default to a single local file — SQLite — outside iCloud Drive, Dropbox and
any folder that syncs by default. Print the chosen path and the reason on
first run.
3. No accounts, no telemetry, no crash reporting, no analytics. If a library
phones home, replace it.
4. Do not implement cryptography. If I ask for end-to-end encryption, use
libsodium or age through a maintained binding, store the KDF parameters as
data alongside the ciphertext, and refuse to invent a scheme.
5. Before any encryption exists, build and test the key recovery path. If losing
one passphrase loses everything, say so in the UI in plain words.
6. Journal and mood entries are append-only. An edit creates a new version and
the original stays. Deletion is explicit and confirmed.
7. Store all timestamps as UTC plus the IANA timezone. Write the DST test for
habit streaks now, not after the first wrong streak.
8. Recurrence uses an established RRULE library. Do not hand-roll "every other
Tuesday".
9. Run an automatic local backup with a retention window, and verify a restore
as part of the test suite.
10. If I later ask for multi-device sync, stop and lay out the options —
file-based, an existing sync engine, a hosted service — with what each costs
me in complexity and in risk. Do not just start writing a sync protocol.
11. Out of scope until I ask: sharing, collaboration, mobile push, and anything
that puts a note about another person on a server.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
Buy if you want it on your phone and your laptop and expect them to agree. Eight dollars a month, or six billed annually, is mostly paying for encrypted sync that somebody else is responsible for getting right, plus apps on platforms you are not going to ship to. If the honest requirement is "one machine, my own notes, my own habits", building it is genuinely the better outcome — you will shape it around how you actually think, which is the entire reason people bounce off other people's task managers.
Trivial if you did the first guardrail. It is a SQLite file you own: export JSON and Markdown, and the journal is readable in any text editor forever. If you decide the habit tracking is not worth maintaining, Lunatask, Todoist and Obsidian all import from plain formats, and the mood and journal data — the part with actual sentimental value — survives as dated Markdown files whether or not any app ever reads them again. The thing that has no exit is a homemade encrypted store whose key derivation lives only in a function you deleted.
Self-hosted task manager with a mature data model, if you want the structure without writing it.
End-to-end encrypted notes with a documented crypto design worth reading before you attempt your own.
Questions
dataSensitivity is 6 but the verdict is SHIP IT. Why?
Because how sensitive the data is and who is exposed to it are different questions. A mood log, a journal and notes about your friends are genuinely sensitive material — and it is your material, on your disk, with no server and no other users. Blast radius is 1 and there is no regulator anywhere near it, which is what makes the overall picture green. The sensitivity number is there to tell you where to put the effort: backups, disk encryption, and not leaving the file in a synced folder.
Should I just build the encryption too? It is a library call.
The primitives are a library call; the protocol is not. Key derivation parameters that change between releases, nonce reuse across records, sync conflict resolution over ciphertext, key rotation, and a recovery path for a forgotten passphrase are all design decisions, and every one of them fails silently rather than loudly. If you want encryption, use libsodium or age through a maintained binding, keep the parameters as data next to the ciphertext, and test a restore on a clean machine before you trust it with a year of entries.
What about the relationship notes?
They are the feature most worth thinking about for a minute, because they contain information about people who never agreed to it — what someone told you in confidence, how a conversation went, what you privately concluded. Keeping that local is not just a security posture, it is the reason the feature is acceptable at all. It is also the strongest argument against ever adding sharing, and against putting the file anywhere a backup service will copy it.
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.
iOS lets an app queue 64 pending notifications. Your recurring reminders silently fall off the end of that list.
A configurable task system is literally the thing you will enjoy configuring forever.
Re-solve from scratch each run and you get a different day every time you look. You stop believing it by Thursday.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice