The hardest design decision in DB.Life was not the information architecture. It was working out what happens to an archive when its author dies.
The default — delete — felt wrong. Health knowledge is inheritable in a way that most user data is not. A grandmother's coffee pattern might be medically useful for a grandchild she never meets. And yet: archives can contain things one never intended to pass on.
We settled on three locks.
One: a death certificate, formally submitted. Two: ninety days of account inactivity. Three: explicit confirmation from a designated next-of-host — someone you chose while alive. Only when all three align do your legacy rules activate.
The default is "keep private forever." You can change this per-pattern. You can change it at any time. Your next-of-host can override shares you'd permitted and keep everything sealed, if that's their call.
This is, in short, a product that takes mortality seriously. If it feels like a lot for a health-tracking app — that's because it is. But if the product works the way we want, these decisions matter more than step counts ever did.