Introducing Multiple Notes and Recipients
We've moved from a one-note model to many for more targeted delivery.
Hey folks!
DeathNote now supports multiple notes! This is a feature we’ve been planning for a long time, almost since the very beginning, but didn’t want to build until the model was perfectly proven.
And, we didn’t want to invest too much time into these advanced features until we knew that the core experience was working and that we had the interest to boot.
Well, things have been working really well with happy customers. And the interest in our platform and technology has been growing, very steadily.
It’s all be super-positive — here’s a look at our organic growth on the web:
In the last 6 months we’ve just gone up and up and up with more registrations and new community members every single day. The growth has been slow and steady, just like we wanted it to be. Nothing crazy. Just repeatedly showing up, every single day and providing meaningful value.
So, it was about time to move on from a one note per account type system, which kept the product simple, but was too limiting for our users and not quite realistic for what people want to do and delivery when they pass.
You see, real relationships are not all the same. A note for a spouse is not the same note you would write for a parent. A message for a sibling is not the same as something practical for a co-founder, a business partner, or the person who needs the passwords and documents.
Your accountant and your lawyer should get different notes, right?
Consequently, one shared note forced people into compromise. Either the message got watered down until it sort of fit for everyone on your list or important things got left out entirely.
So we changed it.
Why This Matters
DeathNote is supposed to help people be precise. Not louder. Not more complicated. Just more precise.
If the writing context is different, the note should be different. If the recipient list is different, the delivery logic should be different too. That sounds obvious, but the product did not fully reflect that before.
Multiple notes fixes that. One account can now hold more than one note, each note can have its own recipient mapping, and the editor can tell you exactly what you are working on instead of pretending one message covers every relationship equally well.
What Changed
Here is what shipped:
You can create and manage multiple notes from the editor instead of being locked to one account-wide message.
Each note can be renamed, switched, archived, restored, and deleted without breaking the active-note flow.
Recipient assignment is now explicit per note, not implied by one shared selection state.
The editor shows the delivery context for the active note, including who it applies to and whether delivery is actually active.
Preview email now follows the active note you selected, instead of risking the wrong note content.
The dashboard reflects note assignments directly, so it is clearer who is attached to what.
We also tightened the gating so the product behaves predictably across plans:
Free accounts keep one active note and one active recipient.
Paid plans unlock multiple active notes.
Premium unlocks more than one active recipient at a time.
And importantly, downgrade behavior is non-destructive. Extra notes and assignments are stored, not deleted. If you downgrade, they become inactive. If you upgrade again, they reactivate.
The Hard Part
This was not a surface-level feature.
Multiple notes touched note loading, active-note pointers, recipient assignment state, previews, delivery seeding, retries, webhook reconciliation, downgrade rules, and migration safety.
That matters because the failure mode here is not a button looking weird. The failure mode is silent behavior drift:
The wrong note getting previewed
The wrong note getting retried
Recipient state becoming ambiguous
Downgrade flows deleting or mutating data people expected to keep
That is why this took a staged rollout instead of one big switch.
What We Hardened Under The Hood
The product change is visible. The more important work is what changed underneath it. Here’s a look at what we built:
Delivery jobs now carry note snapshots. If a delivery job is seeded and the note changes later, retries stay tied to the original job snapshot instead of drifting to whatever the current note happens to be.
Recipient assignment is many-to-many now. We stopped pretending a contact could be represented by one flat delivery flag. The system now tracks note-to-recipient assignment directly, which is the only model that makes sense once multiple notes exist.
Webhook failures map back to the exact delivery path. If an email provider reports a failure, the system can reconcile that failure to the correct job and assignment instead of mutating generic contact state.
Downgrades preserve data. Stored notes and stored assignments do not disappear just because a plan changes. They become inactive until the plan supports them again.
Editor and dashboard loading got cleaned up too. Some of the old singleton assumptions caused redundant reads and fragile UI states. Those paths are now more consistent because the app has a real note model instead of a hidden one-note assumption everywhere.
What This Means For People Using DeathNote
The simple version:
You can now write more honestly.
In other words:
You do not have to force one note to serve every person in your life.
You can separate emotional context from operational context.
You can write something intimate for one person and something much more practical for another.
You can be specific without making the note generalized or confusing.
We also think the system is easier to trust now, because it is more explicit about what will be delivered, to whom, and from which note.
You see, this is entirely deliberate. Intentional. A digital legacy product should not treat delivery behavior like a casual feature release. Every note is made-to-order.
Just as it should have been.
— 8
TL;DR:
DeathNote now supports multiple notes. One shared message was too limiting for real relationships, so we changed the product to allow note-specific writing context, explicit note-to-recipient assignment, and clearer delivery behavior.
The visible feature is simple, but we also hardened previews, retries, webhooks, downgrade handling, and delivery jobs underneath it so the system stays precise when it matters.
Oh! And thanks to my business partner who suggested this even before we wrote a single line of code! They saw the future and it just took time for us to build it.
Thank you.