I started building Read After I Die on a Sunday in early May.
No company. No co-founder. No roadmap. Just a problem I couldn't stop thinking about — and a laptop.
Here's every decision I made in the first week, and why.
Why this exists
I lost someone I loved for 16 years. She passed in her early 40s.
I've spent years in crypto circles. I've watched people lose everything — not because they were careless, but because they had no plan. The family finds out about the wallet after the funeral. The hardware wallet is in a drawer nobody knows about. The seed phrase is written on a piece of paper that got thrown out.
I carry crypto my family doesn't know about. I've put it off for years. After losing her, I stopped putting it off.
But this isn't just about crypto. The product is for everything you're carrying that you haven't figured out how to hand over — wallet seeds, account details, letters you never sent, things you couldn't say out loud. Everything you don't want to take to your grave.
The positioning decision
I started with "crypto dead man's switch." It's accurate. It's also a terrible way to talk about what this actually is.
The decision: don't lead with crypto. Don't lead with death. Lead with the secret.
Crypto is the entry point — urgent, quantifiable, credible to the early audience. But the real product serves anyone carrying something privately they want to leave behind. I'm building for that broader problem from day one.
Tagline: Keep it private until it matters.
The architecture
Zero-knowledge encryption. Everything encrypted on your device before it ever reaches the server. I never see the contents. Nobody does — until your heir uses their key shard to unlock it.
Key management: Shamir's Secret Sharing — a 2-of-3 threshold split. Your key is divided into 3 shards. Any 2 unlock it. Mathematically impossible to reconstruct from a single shard. Already quantum-proof by design, because the security comes from the polynomial math, not from computational hardness assumptions.
Post-quantum ready from day one: This vault is designed for 10+ year post-death maintenance. "Harvest now, decrypt later" attacks are real — adversaries capturing encrypted data today to decrypt once quantum computers are viable. I'm using a hybrid approach — X25519 + ML-KEM768 (NIST FIPS 203) for key encapsulation. Same method Cloudflare and Chrome use in production TLS today.
Trigger system: Heir-initiated pull, not a timer. They request access. I get notified. If I'm alive, I block it. No missed check-ins causing false alarms. No service going dark after my death because I missed a ping.
The open source decision
AGPL + commercial dual license — the open core model.
Open: client-side encryption, Shamir key management, trigger logic.
Closed: server infrastructure, AI synthesis features, billing, the 10-year post-death maintenance SLA.
In a product that lives or dies on trust, "audit the code yourself" hits differently than "trust our security whitepaper." Open sourcing the crypto core is a trust signal, not a business risk. You can't fake the math.
The stack
- AWS, serverless-first — Lambda + API Gateway + DynamoDB + SES. No servers to maintain. I'm in Singapore, so
ap-southeast-1for everything. - Marketing site: Next.js static export on Cloudflare Pages. Zero infrastructure to manage.
- Waitlist backend: My own Lambda + DynamoDB. Decided against Loops (third-party) — I own the data from day one.
- API security: Cloudflare Worker proxy between the frontend and API Gateway. The AWS URL never appears in the frontend bundle. The Worker holds the internal secret.
- DNS + delivery: Cloudflare. DKIM verified on
readafteridie.com.
What's live as of this writing
readafteridie.com— marketing site with waitlist- Double opt-in email confirmation — name + email → PENDING → confirmation email via SES → CONFIRMED
- Dev and prod environments fully isolated under
readafteridie-*naming - 35 unit tests covering the Lambda handlers
The one thing pending: AWS SES production access (sandbox only sends to verified addresses right now). Requested, waiting for approval.
What I learned
Audience before product. The build path is: tell the story → collect the waitlist → then build. Shipping ugly code to zero users is just wasted time.
Own your data from day one. The instinct to reach for a third-party waitlist tool is strong. Resist it. The waitlist is your early audience. Own the relationship.
Trust is the product. Every technical decision — ZK encryption, open source crypto, client-side everything — exists to make "you can verify this yourself" a true statement. In a product that holds your most private things, trust isn't a feature. It's the whole game.
I'm building this in public. Every decision will be documented here.
If you're carrying something you haven't figured out how to hand over — join the waitlist.