I built the wrong front door

I spent nearly a year building a product around a single idea: help people write a final message. A letter to a spouse, instructions for a sibling, passwords for the family. The user writes it, the system holds it, and if they stop checking in, it gets delivered.

The concept was solid. The execution worked. The infrastructure was reliable. And the thing I got wrong was the very first screen.

The Blank Page Problem

One Final Message launched in January 2026. The onboarding flow walked new users through 18 categories of things they might want to include in a message. Account credentials, legal documents, financial context, personal notes. We had 144 options across those categories, each generating a fill-in-the-blank template. The idea was to lower the bar. Make it easy. Give people a starting point so they weren't staring at a blank page.

But the output was still a message. A single document addressed to someone. And no matter how many templates you offer, asking someone to sit down and compose a letter that begins with the implicit premise "when I'm gone" is a heavy ask.

I didn't get a flood of user complaints about this. It was subtler than that. I could see it in the design itself, in how the onboarding tapered off, in the gap between signup and the first completed message. The product was asking for an emotional commitment before it had demonstrated practical value. It was like handing someone a blank journal labeled "Last Words" and expecting them to feel motivated.

The message-first model made sense to me as the builder. I'd been thinking about this problem for a long time. I'd already processed the emotional weight. But I was designing for a version of the user who had already decided this was important, not the version who was still deciding.

What I Was Protecting

Here's the thing about building something for nearly a year: the architecture becomes part of your identity. The Envelope was the core data object. Everything hung off it. Messages, attachments, recipients, scheduling, delivery status. The entire backend, from the Durable Objects to the workflow engine to the API layer, was organized around this one concept.

Letting go of it wasn't a technical problem. I could see the better architecture. It was an ego problem. I'd spent months getting the confirmation cycle right, the retry logic, the grace periods, the rapid response mode for high-risk users. That work was good. Throwing away the container it lived in felt like throwing away the work.

Writers talk about "kill your darlings." The phrase gets used so often it's lost its edge, but the reason it persists is that the advice is genuinely hard to follow. The darling isn't the bad code or the ugly feature. It's the thing you're most proud of. The thing that works well and represents real craft. Killing it isn't about quality. It's about fit. The Envelope worked. It just wasn't the right front door.

The Shift

The realization was that most of the information people need to protect isn't emotional. It's practical. Your spouse doesn't need a heartfelt letter to find out who your insurance agent is. Your brother doesn't need three paragraphs of context to locate the car title. A personal message is one kind of thing you might want to leave behind. But it's one item on a list that includes policy numbers, account credentials, document locations, contact information, and a hundred other mundane details that become urgent the moment someone can't ask you about them.

The old model forced all of that through a letter-writing paradigm. Want to make sure your wife knows the life insurance policy number? Write her a message about it. Want your brother to know where the deed is? Write him a message. Every piece of practical information got wrapped in an emotional container that most people weren't ready to fill.

The new model flips it. We call the new primary object a Vital. A Vital is a structured record of a specific piece of critical information. Life insurance? There's a Vital for that, with fields for carrier, policy number, beneficiary, agent contact, and document location. Bank account? Fields for institution, account type, holder, branch. Vehicle title? Make, model, year, VIN, title location, lienholder.

The user doesn't write a message. They fill in fields. The emotional weight drops by an order of magnitude. And the personal message, the letter to a loved one, is still there. It's just one type of Vital among many instead of the entire product.

The other thing this unlocked was a readiness score. It tracks how many of your Vitals have their required fields completed and how many have recipients assigned. It gives users a concrete sense of progress without requiring them to finish everything in one sitting. Start with the essentials, get to 60%, come back next week and add more. The score creates a re-engagement loop that the old model never had, because "finish writing your message" is a much harder prompt than "your readiness is at 72%, your homeowner's insurance is missing a few details."

What I'd Tell Another Builder

If your product has an engagement problem and you've been tuning the onboarding, adjusting the copy, simplifying the flow, and it's still not clicking, consider the possibility that the problem isn't in the execution. It might be in the premise.

I spent months refining the message builder. Better templates. More categories. Simpler language. A wizard that broke the process into smaller steps. All of it made the experience of writing a final message marginally better while leaving the core friction untouched. The friction was the act itself.

The fix wasn't to make the hard thing easier. It was to change what I was asking people to do. Filling in a policy number is not emotionally loaded. Noting where you keep the car title is a two-minute task. Writing a letter to your wife about what happens when you die is something people will defer for years.

The uncomfortable part, for me, was admitting that the thing I'd centered the product around was the wrong entry point. Not wrong conceptually. People do want to leave personal messages. But making it the first and primary action created a barrier that no amount of UX polish could remove.

I'm not the first person to learn this. There's a pattern in product development where the founder's vision for what the product should be, the version that exists in your head, doesn't match what users actually need the product to do first. The gap between those two things is where a lot of good products stall.

Kill the darling. Keep the mission. The mission for One Final Message hasn't changed: make sure the people you care about have what they need when you can't be there. The darling was insisting that a letter was the right way to do it.

Brian is the founder of One Final Message (onefinalmessage.com), a platform for organizing and automatically delivering your critical information to the people who need it.