Most health apps assume you will use them forever. They optimize for daily active usage, for streaks, for engagement. They measure success in sessions per week. None of them have a plan for what happens when you stop using the app — not because you churned, but because you died.
DB.Life had to think about death from the first commit. The product's core promise — a health archive that outlives you — makes mortality a design constraint, not an edge case. We needed to answer questions that no onboarding flow prepares you for: Who gets your health data when you die? What if you change your mind but cannot tell us? What if your family disagrees about what should be shared?
We spent four months on the legacy transfer system before writing a single line of product code for it. We interviewed grief counselors, estate attorneys, and families who had lost someone and wished they had access to health information that died with them. We also interviewed families who had lost someone and were grateful that certain health information remained private.
The result is the three-lock system. No posthumous sharing happens until three conditions align: a death certificate is submitted, the account has been inactive for ninety days, and the designated next-of-host confirms they want to proceed. Each lock exists for a specific reason. The death certificate prevents premature activation. The inactivity window prevents mistakes. The next-of-host confirmation gives a human being — someone the user chose while alive — the final say.
The default is "keep private forever." This was the most debated decision on the team. Some of us felt the default should be "share with family," because the whole point of the family graph is cross-generational knowledge. But we kept coming back to a principle: the user's privacy should not weaken after they lose the ability to manage it. If anything, it should strengthen.
Designing for death also changed how we think about everyday features. Empty states say "nothing here yet" instead of "get started!" because the former works whether the reader is the account owner or a bereaved family member viewing a legacy archive. Date formats are absolute, not relative, because "3 months ago" becomes meaningless when the person who wrote it has been dead for a year. We avoid gamification entirely — no streaks, no badges, no scores — because none of those mechanics age well across a lifetime, let alone beyond it.