Should I vibe code
Password manager with autofill, passkeys, sharing, and security alerts
Encryption is a library call. Not losing the only copy of your keys is a business.
?
Their verdict, the Premium price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Every password manager clone dies the same way: it works fine until the day you actually need recovery, and there is nobody to escalate to because you are the vendor.
What actually breaks
not "if". the specific failures.
- Sync between two devices, resolved last-write-wins, quietly discarding the eleven logins you added on the other one
- The breach alerts, which are a curated data pipeline someone else maintains, not a feature you can write
- The password reset flow every user expects and you structurally cannot offer
- A schema migration on version 3 that fails halfway through an encrypted blob you cannot inspect
- You, as the support desk, on a day you are on a plane
You added logins on your phone all week. Tonight your laptop syncs, wins the conflict because its clock is two minutes ahead, and writes its version over the top. You do not notice for a month, because you do not visit those eleven sites for a month. When you do, there is no version history, because history was going to be v2. The encrypted blob is intact and perfectly consistent. It is consistent with the wrong week.
Is that you?
the verdict is a default, not a law
- It is single-device by construction, with sync explicitly unimplemented
- The secrets in it are all recoverable by an email reset you control
- You are building it to learn, and you already use a real manager for real credentials
- It syncs between devices
- You would be the only support channel for anyone, including yourself
- It holds credentials for email, banking, or infrastructure
- There is no independently readable second copy of the data
If you build it anyway
the checklist, then the prompt that enforces it
- Pick single-device or bust. Sync is a distributed-systems problem wearing a convenience feature's clothes, and last-write-wins loses data silently.
- If you sync anyway, sync an append-only log of changes, never the whole blob. Conflicts must be visible, not resolved.
- Version the on-disk format from the first commit, and write the migration test before the migration.
- Use the platform keychain, age, or libsodium. Argon2id for derivation, parameters justified in the README.
- Breach monitoring is out of scope — say so. Point users at Have I Been Pwned rather than implementing an alerts pipeline.
- Export first, atomic writes, verified restore. Every entry must survive the loss of your binary.
Before you write any code for a password manager, apply these and push back if I ask you to break them. 1. Ask me one question first: does this sync between devices? If yes, tell me to build the single-device version instead, and explain that last-write-wins sync destroys data quietly and without an error message. 2. If I still want sync, do not sync the vault file. Sync an append-only log of individual changes and replay it. A conflict must surface to the user as a conflict, never be auto-resolved by timestamp. 3. Version the on-disk format in byte one of the file. Write the v1-to-v2 migration test before there is a v2, and make every migration copy to a new file rather than editing in place. 4. Refuse to implement cryptographic primitives. Use the OS keychain, filippo.io/age or libsodium exactly as documented. Argon2id for key derivation, with the parameters and their justification in the README. 5. Build 'export' before 'add', in a format documented well enough that someone could write a reader from the spec alone. 6. Every write is atomic: temp file, fsync, rename. On each write, also write a timestamped encrypted backup, and give me a 'verify' command that decrypts the newest backup and confirms it parses. 7. Do not build breach or dark-web monitoring. It is a maintained data feed, not an algorithm. If I ask, point me at Have I Been Pwned's API and stop. 8. Never write a secret to stdout, a log, or an error message. 9. Write in the README, in the first paragraph: there is no password reset, there is no support, and I am the vendor. Then tell me to consider paying the $4.99 a month instead.
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
If you want the alerts, the sync and someone to escalate to, buy it — that is the whole product and it is $4.99 a month. If what you actually wanted was to stop paying a subscription, Bitwarden is $1.65 and KeePassXC is free, both audited, both with real import paths.
$4.99/mo is cheaper than your weekend.
Export to KeePass XML or CSV on day one and import it into KeePassXC or Bitwarden before storing anything real. Re-run that round trip after every format change — a migration you cannot export from is a migration that has already trapped your data.
Open-source local password manager prior art; not a Dashlane clone but covers the core vau
Questions
Sync is just a file in Dropbox though, isn't it?
That is exactly the assumption that loses data. Two devices editing one encrypted blob and syncing it through a file-sync service produces conflicted copies at best, and a silent overwrite at worst — and because the blob is encrypted, neither you nor Dropbox can merge them or even tell you what was lost.
Could I use Have I Been Pwned for the breach alerts?
For checking a password against known breaches, yes, and the k-anonymity API means you never send the full hash. What you cannot rebuild is the monitored, continuous version — watching an address across new dumps over time and telling you within days. That is an operations job, not an endpoint.
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice