Community Cold-Start — PRD
Status: ✅ Shipped (v1.16, 2026-04-??) Proposed by: Penny (2026-05-11) Phase fit: Pre-launch — target for v1.13 or bolt-on to Phase 4 engagement work Source exploration: OBJ-220
Problem
At launch, Objectuve will have zero existing users and zero existing communities. The community surface — which is already live and is the strongest long-term retention predictor (Habitica data, cited in streak-science.md) — risks making the product feel like a ghost town before organic critical mass develops.
Two bad solutions were considered and rejected:
- Hard feature gate: removes accountability from early adopters exactly when they'd use it most; delays the north star (goals completed)
- Ally invite gate: "invite N friends to unlock" is a dark pattern — off-brand and asymmetric to timing
This PRD defines the right solution: four small engineering changes that make the cold-start period feel alive rather than empty, plus one non-engineering action (founder-led community seeding).
North Star Alignment
Communities drive accountability → accountability drives consistency → consistency drives goal completion. Every item here directly supports cumulative goals completed.
PBC Check
- Free tier impact: None. All community features remain fully free.
- Engagement vs. goals: Accountability partners and ally-seeded communities drive goal completion, not time-on-app.
- Dark-pattern check: No invite gates, no FOMO mechanics, no manufactured urgency. Founding Member badge celebrates early users; it doesn't pressure them.
Scope
Engineering — 4 items
1. Founding Member badge
What: A new badge awarded automatically when a user joins any community within 30 days of that community's created_at.
Why: "You're one of 3 people here" reads as failure. "You're a Founding Member" reads as achievement. Scarcity becomes cachet. Early adopters who build a community from the ground up deserve a durable marker of that — and will wear it proudly when the community has 200 members six months later.
Design:
- Badge name:
founding_member(scoped to a community, not global — or global for the first wave, TBD with Desi) - Rarity: Rare or Epic (founding a community is a real contribution)
- Trigger:
UserCommunitycreation event whencommunity.created_at > 30.days.ago - One-time per community; users who join multiple founding communities earn multiple
Acceptance criteria:
- Badge awarded within 1 minute of joining a qualifying community
- Badge appears on user profile with community name attribution
- Celebratory toast/modal on earn ("You're a Founding Member of [Community Name]")
- Badge has correct rarity glow and particle effect
2. Community private formation phase
What: Newly created communities are not shown in public discovery until they reach 5 members. During this formation period they are visible only to current members and accessible via direct link or ally invite.
Why: Prevents empty communities from surfacing in discovery and creating a "dead product" impression. Communities that graduate to public discovery will feel alive because they started from real ally relationships.
Design:
- Add
discoverablecomputed field (or persisted boolean) toCommunitymodel discoverable = members_count >= 5- Discovery queries filter to
discoverable = true - Community creation flow: creator invited to share the community with specific allies first ("Invite your allies to get started — once you have 5 members, your community will appear in discovery")
- "Founding" label on community card in discovery for first 30 days after crossing the threshold
- Direct invite links always work regardless of
discoverablestatus
Acceptance criteria:
- Communities with < 5 members do not appear in discovery tab or search results
- Communities with ≥ 5 members appear in discovery with "Founding" label if < 30 days old
- Community creation flow shows threshold progress ("3 of 5 members — 2 more to go live in discovery")
- Existing direct links and ally invites work at any member count
3. Ally invite prominence in onboarding
What: Strengthen the post-onboarding or onboarding step 4 (Check-In Rhythm) to surface "invite an accountability ally" as a clearly rewarding, optional next step — not a gate.
Why: The onboarding already surfaces the "Ally" persona (slide 1). But the payoff — inviting a real person — doesn't happen in the onboarding flow. Getting even one ally invite sent per new user materially changes the product's cold-start dynamics. Two users = full accountability value.
Design:
- After goal creation (post-wizard), add a "Better together" screen before the main feed
- Copy: "Goals are easier with someone in your corner. Invite one person who's working on something similar." [Invite an ally] [Skip for now]
- Skip is always available, always above the fold
- If user has contact permissions, suggest contacts who might be relevant (based on nothing other than existing in contacts)
- Incentive: show that having an accountability ally unlocks the shared streak mechanic ("You and your ally maintain a shared streak when you both check in on the same day")
Acceptance criteria:
- Prompt appears after first goal creation, before main feed
- Skip is always available without friction
- Invite sends a deep-linked invite to Objectuve
- Shared streak mechanic is clearly explained and not misleading
- PostHog event:
ally_invite_prompted,ally_invite_sent,ally_invite_skipped
4. Community creation guided toward ally path
What: When a user taps "Create Community," the creation flow prompts them to select existing allies to invite — before the community goes live.
Why: Ally-seeded communities are more active than cold-open communities. If we guide the behavior without forcing it, we get better communities naturally.
Design:
- After naming a community and setting its description, show an "Invite your allies" step before confirming creation
- List the user's existing allies with one-tap invite
- Copy: "Communities that start with people you know are twice as active. Invite some allies to join before you go live."
- Can skip the ally invite step and create anyway
- Ally invites send push notification + in-app alert to the ally
Acceptance criteria:
- Ally invite step appears as part of community creation flow (between description and create button)
- Step is skippable with no friction
- Invited allies receive push + in-app notification
- If no allies exist, step shows "You don't have any allies yet — you can invite them after creating" and proceeds
Non-engineering — 1 founder action
5. Seed 3 founder communities pre-launch (Josh)
What: Before the public store listing goes live, create 3 thematic communities and populate each with at least 20 genuine posts from the founder, beta users, and early community members recruited through organic seeding channels (Reddit, ProductHunt, Discord).
Suggested themes:
- "Morning Routines" — broad, evergreen, maps to common onboarding goals
- "Fitness & Movement" — largest goal category in most habit apps
- "Creative Practice" — differentiates from fitness-only competitors, maps to creative goals (writing, music, art)
Why 20 posts is the threshold: Qualitative research on community perception consistently finds that spaces with < 10 posts feel inactive; spaces with 20+ feel like ongoing conversations. This is the difference between a new user thinking "this is fresh" vs. "this is dead."
Timeline: Complete before iOS/Android store listing goes live. Owner: Josh (this is content + community work, not engineering)
Delivery recommendation
These are all small to medium changes that fit naturally alongside the Phase 4 accountability partners and community challenges work. Recommend rolling them into v1.13 or a dedicated "community cold-start" milestone rather than treating them as a separate phase, since items 1-4 are:
- No new infrastructure (badge system, community model, onboarding wizard, and community creation flow all exist)
- Additive, not disruptive
- Completable in 1-2 sprints
Items 1 and 2 (Founding Member badge + private formation phase) are the highest-leverage pair and could ship as a single sprint if needed.
Success metrics (6 weeks post-launch)
| Metric | Target |
|---|---|
| % of new users who send ≥ 1 ally invite | > 25% |
| % of new communities that reach 5 members within 14 days | > 50% |
| Community join rate in first session | > 30% |
| Founding Member badges earned in first 30 days | > 100 |
| Avg posts in each seeded founder community at launch | ≥ 20 |
Open questions for human triage
- Should the Founding Member badge be community-scoped (one badge per qualifying community joined) or a single global badge for joining any community in its founding period?
- Is 5 members the right public discovery threshold, or should it be 3 (more achievable for solo creators) or 10 (higher quality bar)?
- Should the ally invite onboarding step be part of the 5-slide wizard or a post-wizard interstitial? (Current wizard has a sidebar-zero contract — adding a slide may conflict.)
Related Documentation
- Communities — feature doc for the shipped implementation
Last updated: 2026-07-16 — Phase 100 audit. PRD for shipped feature (v1.16, Phases 73–74) archived from active to completed/.
Objectuve Softworks — community-cold-start-prd.md — Penny-proposed 2026-05-11