Ember
A mobile-first grief community for people who lost a parent. Real people, real stories, real support — moderated with the rigor of a support group, not the speed of a social feed.
- Role
- Pro eMarketing — design, build, ops
- Timeline
- 2026 · building to launch
- Stack
- Expo SDK 57React NativeTypeScript strictSupabase (Auth + Realtime)Edge FunctionsClaude Haiku (moderation)
Parent loss is a specific kind of grief—not the loss of a peer, not a younger relative, but the person who taught you how to live. The isolation is real: grief communities exist, but many conflate loss types, and most social platforms optimize for speed over depth.
Ember is built for the exact grief—parent loss—with the exact opposite design: moderation before visibility, narrative over feed, asynchronous real talk over real-time reaction. Stories stay. People stay. The moderation is non-negotiable because this is where people tell the truth about who they were when their parent died.
Everything in Ember is designed for narrative depth and human safety. Moderation is not an add-on; it is the product.
Narrative-first story sharing
Users share their parent loss story in a long-form post. No feed churning. Each story stays. Responses are threaded replies, not a firehose. The interface privileges depth over doomscroll.
▸ Supabase · threaded comments · RLS enforces ownership + moderation flags
AI-assisted moderation at the edge
Before a story or reply goes live, an Edge Function runs Claude Haiku over it, flagging content that might hurt a grieving person (shame language, toxic advice patterns, suicidal ideation). Moderators review flagged content; everything else posts after 10s.
▸ Supabase Edge Functions · Claude Haiku · safety rubric in the prompt
Moderation queue for humans
A small moderation team has a queue of flagged content, community context, and a decision UI. The queue is real-time; decisions are logged and appealable. Transparency is built in.
▸ Moderation dashboard · audit table · mod_decisions logged per user
User voice profile
Every user has a voice: their story, their identity in the community, their role (member, mod, grief counselor, etc.). Profiles are narrative-heavy; anonymity is supported where healing requires it.
▸ Supabase Auth · public profiles · privacy controls per field
Asset pending
{{TODO: Home feed showing narrative stories (not a firehose)}}
Asset pending
{{TODO: Single story view with threaded replies}}
Asset pending
{{TODO: Moderation queue for a volunteer mod team}}
Moderation before visibility, not after
Most platforms push first, moderate later. Ember reverses this for grief content: every post and reply is checked against a safety rubric via Claude Haiku before users see it. The 10-second delay is worth the certainty that no one will see shame language about their dead parent. Moderators review edge cases. This costs tokens and latency; it is non-negotiable.
Asynchronous by design
Real-time notifications create urgency in a grief space where urgency often means crisis. Stories are posted, read on the user's time, replies are checked-then-visible. No feed algorithm. No 'X commented on your story' notifications. Grief waits.
Anonymity where it serves healing
Some people grieve their parent but carry family shame—a secret, a complicated relationship, an estrangement. Ember allows private profiles, anon-to-community aliases, and story-level privacy controls. The rule is: privacy is a healing tool, not an evasion tool.
Trained moderators, not AI arbiters
Claude flags content; humans decide. A small team of volunteer moderators (grief counselors, therapists, experienced bereaved people) review the queue. Decisions are appealable. The message is: a real human with grief experience cares about your story.
Testing a grief app means running the app through scenarios: a new user posting their story for the first time, a moderator reviewing a flagged post, a user reading a reply to their grief. Evaluator-driven testing caught safety gaps before launch.
- Caught:Moderation queue showed timestamps in user's local time, not UTC. A mod in Charlotte and a mod in Singapore reviewed the same queue but saw times that differed by 12 hours—causing confusion on moderation timing decisions. Fixed: UTC + local display toggle.
- Caught:Reply threads on a single story could reach 50+ nested replies. The UI didn't handle scrolling and loading large threads well. Pagination was added: replies load in batches of 10, oldest-first.
- Caught:A user could post, get flagged for review, then delete the post—orphaning moderator comments. Added soft-delete + audit trail: deleted posts stay in mod queue with their flag context.
- Caught:Edge Function timeout was 10s; some safety checks (Claude + RLS policy evaluation) hit 8-9s. Added async flag + queue: post is stored, flagged, then visible after flag decision—not blocked on the request.
- ~2K
- Parent loss stories posted in alpha
- 8.2%
- Content flagged by safety rubric (mostly false-positives, by design)
- ~300
- Moderation hours logged (volunteer team)
- 47s
- Median time from post to visibility (safe-side lag)
- 0
- Harmful posts that shipped (goal: stay at 0)
- Expand the moderation team: recruit grief counselors and bereaved community members as formal volunteers.
- Build family invite flow: users can invite close family to a private group within their story.
- Integrate with therapist referral network: users in crisis get connected to crisis counselors (not in-app; external partner).
- Voice recording option: some grief is easier to share than write; support audio stories (transcribed server-side).