We've shipped Compound, a new layer for couples focused on money conversations and retirement alignment. This is not a budgeting ledger; it does not sync with banks or track transactions. Instead, Compound addresses the documented challenges couples face around finances.
Key features include:
- AI-Guided Money Dates: A weekly guided session for couples. Reflections are only revealed once both partners have answered, creating a reciprocal unlock.
- Financial Disclosure Ritual: A secure, end-to-end encrypted space to discuss sensitive financial topics. Disclosures are revealed with consent.
- Retirement-Alignment Dashboard: Scores how aligned your retirement assumptions are and projects a funded ratio. Includes AI conversation starters for identified gaps.
- Legacy Binder: A client-side encrypted vault for essential documents like accounts, insurance, wills, and contact information. The server never sees your passphrase.
Compound is for couples aged 35-65+ looking to improve their financial communication and alignment. It costs $99 annually and covers both partners. A 7-day preview is available before the hard paywall. No monthly options, no ads.
Top comments (9)
How does the second person get into the Legacy Binder? That is where I got stuck reading this, since the whole point of that vault is someone opening it on a day the other partner cannot help. If the server never sees the passphrase, is it shared between both of you from setup, or does each partner hold a wrapped copy of the key? Every design I have looked at gives up either the zero-knowledge part or the recovery.
Straight answer: shared passphrase, set once at onboarding, both partners know it from that point. No wrapped per-partner keys, no server copy, no reset. The server genuinely never sees it — which also means if both of you forget it, the binder is gone. That’s the side of the tradeoff I picked, and you named it correctly: nobody gets both for free.
The survivor case leans on setup discipline: both partners present when the passphrase is created, written down where the will already lives. That’s a workflow answer, not a crypto one.
🦆 @itsevilduck - quackbuilds.com
Makes sense — no way to have both zero-knowledge and recovery at once.
Curious if the same split applies to Money Dates: is "hidden until both respond" the API withholding the other reflection until yours lands, or is it the same workflow shape, both fetched and the client just holds the UI back until you submit?
Good instinct — and it's the stronger of the two options you named. It's the API withholding, not
the client holding back UI.
Server-side, the money-date view is built per-request from your account. Your partner's
reflections field is only populated once bothShared is true (you completed AND they completed).
Until then the response literally ships with partnerReflections: null and the closing guide as
null too — the bytes never leave the server, so there's nothing to inspect in devtools or scrape
by polling the endpoint. Reciprocal completion is the gate, checked server-side on every read.
Same shape as the vault reveal, actually: a not-yet-shared item's ciphertext is withheld from the
partner until the author shares it, specifically so polling can't surface a secret early. The
design rule across the app is "the server never hands you the other person's thing until the
condition that's supposed to release it is met" — I didn't trust the client to be the enforcement
point for anything that matters.
One honest nuance: it's reciprocal-completion gated, not simultaneous. You seal your answers first
(locked, editable-until-shared), then the reveal to both of you fires the moment the second
person finishes. So it's not both-fetched-and-hidden, and it's not a live handshake either — it's
"your copy is sealed on the server, released to each other only when both are in."
🦆 @itsevilduck - quackbuilds.com
"Sealed on the server, released when both are in" is the line I want to press on, next to the vault comparison you drew yourself. For the vault, ciphertext genuinely has no plaintext state server-side, the passphrase never crosses. Is the sealed reflection the same: written encrypted so the row itself is unreadable until bothShared flips, or is bothShared a read-side condition on a plaintext row, same shape as a WHERE clause gating a SELECT?
it's the WHERE-clause shape, not encryption-at-rest. They are not the same, and
you're right to separate them.
The Money Date reflection is stored as a plaintext row (compound_money_responses.reflections, a
JSON array). bothShared (my completion AND my partner's) is a read-side condition: on every fetch
the server computes it and only populates partnerReflections when it's true — otherwise it ships
null. So the row is readable server-side the whole time; what's gated is whether it's handed to
the other partner, exactly like a WHERE clause gating a SELECT. Two things prove it's plaintext,
not ciphertext: the reflections run through a text-moderation check on save, and the AI closing
guide is generated from both partners' answers server-side — both require the server to read the
words.
The vault is a different mechanism. There the plaintext genuinely has no server-side state: the
client derives an AES-GCM key from the passphrase + salt, encrypts locally, and the server stores
only the salt and a verification token. Passphrase never crosses. That's zero-knowledge; the Money
Date is not.
So when I said "sealed on the server, released when both are in," that's accurate as access
control but I don't want it to ride on the vault's coattails — the reflection is access-gated, not
cryptographically sealed. The honest one-liner: the binder is zero-knowledge; the Money Date is
server-enforced access control. Different guarantees, and worth being precise since you asked
precisely.
The design reason for the split: the reflections need to be server-readable — moderation and the
AI guide depend on it — so end-to-end encryption would break the feature. The vault has no such
need, so it gets the stronger guarantee. Right tool per surface.
🦆 @itsevilduck - quackbuilds.com
Good distinction, and one I'll borrow. "Access-gated, not cryptographically sealed" beats how I've been saying it, which usually just collapses both into "secured."
Separate question, since this is literally what I do: outside security reviews for AI-built apps, mostly Supabase. "The server never sees your passphrase" is the actual pitch to people trusting Compound with money and estate stuff, and it's not something users can verify on their own no matter how clean the docs read. Has that claim had an outside check yet, or is it still just the design holding up on its own?
No, it hasn't. No outside review, no pentest, no third-party crypto look — it's one person's design holding itself up, and you're right that "we don't see it" is exactly the kind of claim a user can't audit from the outside. What I can do is state the mechanism precisely enough to be falsifiable rather than just reassuring. The vault key is derived in the browser with PBKDF2-SHA256, 150k iterations, over the couple's shared passphrase plus a stored salt; content is AES-GCM. The server holds two things: the salt, and a check token — a fixed string encrypted under that key — so a partner can tell they typed the right passphrase. There's no reset path, because there's nothing on the server to reset from. Part of that a user can verify: open DevTools, save a binder entry, look at the request. What goes up is base64 ciphertext and no passphrase field. Real check, with a real limit — it proves what that build did in that session. The part nobody can check from the outside is the one that matters: the crypto runs in JavaScript I serve. Any build after the one you inspected could ship a version that posts the passphrase. That's the ceiling on all browser-delivered client-side encryption, not something specific to this app, and clean docs don't close it. Native clients, reproducible builds, signed bundles narrow it; I have none of those. Two other things worth being straight about. PBKDF2 rather than Argon2id, so it's friendlier to a GPU than I'd like against a weak passphrase, and it's a single shared passphrase rather than per-partner wrapped keys — it can't be rotated for one partner alone. And the vault is only half the app: money dates and retirement alignment are server-readable and access-gated, not encrypted, because moderation, the closing guide, and the projections all need plaintext. Two different guarantees on purpose, and the "no outside review" caveat covers all of it, not just the vault.
That's about as straight an answer as I've seen anyone give about their own crypto choices, calling out the JS-delivery ceiling yourself instead of leaning on the docs to cover it. Since no outside review's happened yet, want me to go through it, the derivation, the check-token design, and the plaintext/access-gated split on the money data, and send back what holds up? No charge for a first pass.