Last week, a fellow builder working on a zero-knowledge financial tracker left a thoughtful comment on the Metamorphic Product Hunt page. He hit his first 100% streak, said he liked the product, and then — because he's deep in the same architectural decisions I've been living with — asked me three questions.
They're the same three questions I get asked everywhere: in DMs, in calls with potential customers, in conversations with other founders. So I'm pulling my reply out of the thread and putting it here, because if you're building anything zero-knowledge, you'll get asked all three eventually.
The questions:
- Is end-to-end encryption worth keeping in the core, or should it be optional?
- Aren't you worried about users losing their data, with no way for you to help?
- Don't you feel like the odd one out for not bolting on AI?
Here was my reply:
1. Is E2EE worth keeping in the core?
Yes — and I'd encourage you to hold the line on financial data especially. Financial behavior is one of the most sensitive datasets imo. If you've already done the architectural work to support it, that's compounding value you don't want to throw away. Every time you re-litigate the decision, you pay the migration tax twice (I’ve been there too). Build it in, document the tradeoffs honestly, and move on to features. The customers who care will be the ones worth keeping. Also, the more we build with zero-knowledge, privacy-first architectures in mind — the more we’ll start to innovate there too.
2. Worried about users losing their data because we can't recover it?
Yes, but it doesn’t keep me up at night, and I built around that constraint. A few things that I think help:
- Password reset flows preserve data. When users reset their password, their data stays accessible — we use password-derived keys with a recovery mechanism that doesn't give us access to the cleartext.
- Data export, always. Users can export everything at any time. The strongest user protection isn't us holding their data hostage — it's making sure they can walk out the door with it whenever they want.
- Human readable recovery keys so people can be proactive to have a second layer of protection against accidental data loss due to forgotten passwords. All while remaining zero-knowledge.
- Clear UX around the tradeoff. We're explicit during signup: this is zero-knowledge, which means you hold the key. The customers who choose us choose us partly because of that constraint, not despite it.
The worry never fully goes away, but I try to reframe it because what's the alternative? Being able to recover data because we hold the keys — that seems worse in terms of failure for the people who actually need privacy.
In your case, I would think failure is even higher-risk than a service like Metamorphic. Or take our other product, Mosslet (a social network), you could have journalists, abuse survivors, people with controlling family members, people in regulated industries.
The "we can recover anything" architecture is the architecture that gets subpoenaed, breached, or sold. Maybe you can protect it for a while, but it’s a hard thing to do the longer you stay in business. Being able to say, “Okay we got breached, but all they got was encrypted blobs that they can’t do anything with” — that seems better to me than “Okay — it happened to us too".
3. Feeling like the odd one out for not bolting on AI?
Sometimes it does seem like only AI-heavy products are getting attention. But, honestly? No. The opposite. And DuckDuckGo just saw huge adoption numbers after Google started force-feeding people AI, showing customers might still prefer choice and considerate design.
And in terms of privacy, AI-in-the-product almost always means "your data goes to a third-party model provider," which collapses zero-knowledge the moment you ship it. There are emerging patterns for on-device / WASM-resident inference that could preserve E2EE, and I'm watching that space — but I'm trying not to ship AI features that quietly undo all the wins for people from our privacy-first zk architecture — so I have to be slower perhaps than others in that space.
Although, I have started to use some WASM/on-device AI on Mosslet to get some of the automation benefits while preserving people’s privacy. I think that’s an area you may want to explore because there is some real value to the speed and automation you could achieve with AI models and financial data, you’d just want to ensure they’re running locally on the client-side with no exposure of people’s decrypted data.
I’ve heard people say the market will split to be either AI products or privacy products, but not both — I tend to push back a bit there. I think the more we develop privacy-first products then the more we will start to think about how we can make AI fit that model — and then we’ll have some real innovation. And hopefully also innovation around the production of AI (as it’s not a bright spot in my opinion).
Why this matters
The three questions above all share a shape. They're all variants of the same underlying anxiety: am I making the product harder, slower, or less competitive by holding the line on privacy?
My honest answer, after building two zero-knowledge products and shipping a post-quantum migration to production: no. The constraint makes the product better. It forces clearer UX. It forces honest tradeoffs. It attracts the customers who actually care, and those customers stay.
And to me, most importantly, it makes the product safer.
Software products (therefore developers) have become so integral to our modern life that it becomes borderline negligent to ship a service that isn’t built to protect its customers. It would be like a doctor or surgeon or nurse treating a patient with no regard for the harm their position makes possible.
Software is being used to decide whether your future self-driving car stops for a pedestrian or traffic light. It’s also being proposed to determine whether you should be arrested for a crime you didn’t commit. And currently being used to find, identify, and track you. These systems carry an immense amount of power and wield an immense potential to harm people — privacy and thoughtful, considerate design of software systems have never been more important.
The world doesn't need fewer zero-knowledge builders. It needs more of us — building in public, comparing notes, and refusing to treat privacy as a feature flag.
If any of this is useful in your own build, here are the tools we've open-sourced along the way:
- metamorphic-crypto — our Rust encryption library, also packaged for WASM on npm. Hybrid ML-KEM-1024 + X25519 post-quantum KEM, XSalsa20-Poly1305, Argon2id. Dual MIT/Apache-2.0.
- metamorphic_crypto — the Elixir NIF wrapper. Honest scoping: this is server-side, not zero-knowledge itself, but it's a useful drop-in enacl replacement for teams migrating toward a ZK architecture. There's a zero-knowledge guide in the repo.
If you want the deeper technical story of how we got Mosslet to post-quantum zero-knowledge in production, I wrote that up here earlier this week.
And if you'd ever like direct help thinking through a zero-knowledge architecture, my company Moss Piglet does consulting. 🦦
Top comments (0)