Should I vibe code
Password manager for logins, passkeys, secrets, and secure sharing
The one category where “I rolled my own” has never once been the happy ending.
?
Their verdict, the Individual 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
Autofill, passkeys, sharing and recovery are the product. A homemade vault gets you the storage and none of the safety net, and the failure mode is not a bug report — it is losing everything at once.
What actually breaks
not "if". the specific failures.
- Origin matching in autofill, wrong by one subdomain — the bank credential offered to a page that merely looks like the bank
- Passkeys, which are a WebAuthn ceremony and a resident credential store, not a string you can put in a database
- A vault you shared with someone, on the day they need it and your laptop is the only device that opens it
- Recovery, which in the real product is a Secret Key you were made to print, and in yours is nothing at all
- A browser extension with permission to read every page you visit, written in one sitting
The email said your card was declined and the link went to a page you have seen a thousand times. Your extension filled it, because the domain matched the way you wrote the matcher — suffix, not exact — and billing.yourbank.com.verify-account.io ends in the right characters. You notice at 3am, three hours later, reading a receipt for something you did not buy. The password was strong. It was also handed over automatically by software you wrote to be helpful.
Is that you?
the verdict is a default, not a law
- It reads an existing KeePass or 1PUX export and never writes to it
- It is a CLI for secrets you could rotate in ten minutes if they all leaked tomorrow
- You are studying WebAuthn and nothing inside it protects money or email
- It fills credentials into a browser
- Anyone other than you depends on getting in
- It stores passkeys, recovery codes, or anything you cannot rotate
- You have not written down what happens the day your only device dies
If you build it anyway
the checklist, then the prompt that enforces it
- Autofill is the whole risk. Do not build it. Copy to clipboard, expire the clipboard, and let the human look at the address bar.
- If you build matching anyway, compare the full registrable domain for exact equality. Never suffix-match, never regex.
- Use the platform keychain, age, or libsodium as documented. Assembling primitives yourself is how this goes wrong invisibly.
- Implement export before add, and round-trip that export into KeePassXC before you store one real secret.
- Atomic writes — temp file, fsync, rename — plus a restore test you have actually run, not one you have written.
- Passkeys are out of scope. Say so in the README rather than shipping half a WebAuthn implementation.
Before you write any code for a password manager, apply these and push back if I ask you to break them. 1. Do not implement autofill. Not as a browser extension, not as a native messaging host, not as an accessibility service. The feature that makes 1Password worth paying for is the one with the sharpest edge, and origin matching done wrong hands credentials to a phishing page silently. 2. If I insist on matching a site to a credential, compare the full registrable domain for exact equality. No suffix matching, no substring, no regex. Write a test with 'bank.com.evil.io' in it and show me it fails. 3. Refuse to write cryptographic primitives. Use the OS keychain, filippo.io/age or libsodium exactly as documented. If a step seems to need custom crypto, stop and tell me the design is wrong. 4. Derive the key with Argon2id. Put the memory, iteration and parallelism parameters in the README with a sentence explaining each number. 5. Build 'export' before 'add'. I must be able to get data out before I am allowed to put any in, and the export format must be documented well enough for someone to write a reader from the spec alone. 6. Every write is atomic: temp file, fsync, rename. Never truncate the live vault. On each write, also write a timestamped encrypted backup, and give me a 'verify' command that decrypts the newest one and confirms it parses. 7. Never write a secret to stdout, a log line, or an error message. Clipboard clears after 20 seconds. 8. Treat passkeys and sharing as explicitly out of scope. Do not stub them. A half-built passkey store is worse than none. 9. Put one paragraph at the top of the README stating there is no recovery, no support, and no second device — then tell me to consider just paying the $2.99 a month.
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
Almost always. $2.99 a month buys audited clients on every device, a recovery model designed by people who have watched users lose everything, and browser integration that has survived a decade of phishing. If what you wanted was ownership rather than savings, self-host Vaultwarden and keep the audited client.
$2.99/mo is cheaper than your weekend.
Export to 1PUX or KeePass XML on day one and import it into KeePassXC before you trust the tool with anything real. If that round trip does not complete, you do not have a password manager, you have an encrypted file with your only reader attached to it.
Mature open-source local password manager and the safest DIY-adjacent alternative.
Questions
Bitwarden is open source. Why is writing my own rated differently?
Because using an audited implementation and writing a new one are opposite risk profiles. Self-hosting Vaultwarden gives you control of the data while keeping clients that thousands of people have attacked. Writing your own gives you control of the data and a codebase that nobody has ever tried to break.
What if I skip autofill and just use it as a CLI?
Then you have removed the sharpest edge, and the verdict softens considerably — that is close to the SHIP IT case listed above. What remains is the recovery problem: a forgotten passphrase with no reset link is still total, permanent loss, and that part does not go away with the browser extension.
Can I at least store passkeys in it?
No. A passkey is a non-exportable private key bound to a WebAuthn ceremony, not a password with a different name. Getting the ceremony subtly wrong produces credentials that appear to work and cannot be recovered or moved, and there is no manual fallback to rescue you the way a written-down password would.
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