Phoenix
Phoenix was a web app for writing final messages that would be sent to loved ones after the user died.
View original storyProduct snapshot
What it was
Phoenix let users write last messages, choose recipients, and rely on a yearly check-in mechanism to trigger delivery after death.
Who it was for
Problem / value
Help people preserve final thoughts and messages for loved ones.
Core workflow
- Write final messages like emails
- Add recipients for future delivery
- Use yearly check-ins to prevent premature sending
Product form
Pricing model
The founder described the product as about $30 per year; total revenue was $0.
What happened
Summary
Phoenix was a first-time founder project that spent months building a full app before proving audience fit, trust, or willingness to pay.
Outcome
Shut down. The case is best read as a founder-reported warning about overbuilding a first product before validating audience, trust, and payment intent.
Demand signal
The source shows visitors and signups, but not paid demand. Phoenix reached thousands of visits and 45 signups, yet produced $0 revenue and had no early customers.
Distribution issue
Distribution was limited to Product Hunt and Hacker News launches, with no proper audience or repeatable channel validated before the build.
Timeline
- The founder built Phoenix as a first online project: a SaaS app for sending last messages after death.
- The app used a yearly check-in mechanism to decide whether messages should be sent.
- The founder spent about half a year building the Rails app and also paid for setup details such as legal work, SSL, email, icons, and infrastructure.
- The only stated growth activity was launching on Product Hunt and Hacker News.
- After launch, the founder reported thousands of visits, 45 signups, about $30 monthly expenses, and $0 total revenue.
Before you build
Why it matters
First-time builders often spend months on polish, infrastructure, and edge cases before learning whether anyone wants the product. Phoenix shows how costly that can be for a sensitive, low-frequency idea.
Primary check
Test the audience, payment intent, and smallest useful version before spending months on a sensitive low-frequency product.
Relevant if
- You are building your first product.
- Your idea depends on trust, sensitive personal data, or an infrequent life event.
- Your launch plan is mainly Product Hunt, Hacker News, or one-time attention.
Less relevant if
- You already have paying users for a manual version.
- Your product solves a frequent operational pain with clear budget and urgency.
Pre-build tests
- Launch a landing page that asks users to write the first message or join a waitlist.
- Interview the exact audience about trust, timing, and who would pay.
- Manually deliver a simple version for a few users before building the automated check-in system.
Transferable lessons
- Collect emails and test the message before building the system.
- Use a tiny MVP to prove trust and intent before adding infrastructure.
- Treat launch traffic as attention, not demand, unless it converts into activation or payment.
If you build this today
Start with a landing page, email capture, and manual promise test; only build the full check-in and message system after people show real intent to use or pay.