5thSocial Beta Plan & Rollout
A controlled systems validation of a multi-application ecosystem
Beta is not a launch.
It is a controlled systems validation of a multi-application ecosystem built on a separated social graph, tenant architecture, workflow engine, and agent layer. The stack spans frontend navigation (PilotNav), backend services, MongoDB Atlas, media storage, monitoring, and orchestration logic. Architecture, behavior, economics, and operational discipline are tested simultaneously under real conditions.
Phase 0 — Define Beta or Don’t Start
Overview:
Before anyone is invited, we define what “working” actually means. If we can’t measure it, we don’t scale it. Expansion is earned, not assumed.
Success Targets
500 DAU sustained without instability
70% onboarding completion
40% create structured output
<1% critical system errors
Business entities operate without schema refactor
If these thresholds are not met, we refine — not expand.
Phase 1 — Infrastructure Lock
Overview:
No humans enter until the system is hardened. This phase eliminates avoidable instability and validates tenant isolation, media durability, and monitoring coverage. The system must behave predictably under load.
Required Before Invite
Boot-time environment validation (fail fast)
Tenant enforcement verified
Media 3-step flow hardened (intent → upload → finalize)
Basic CSP enabled
Structured logs in place
Sentry (frontend + backend) active
Atlas alerts configured
Render health checks enabled
Load test to 1,000 concurrent sessions
If it breaks under synthetic load, it will break under humans.
Phase 2 — Controlled Cohort (Regional Structure Enforced)
Overview:
We introduce a curated cohort distributed evenly across the four canonical regions. This phase validates cross-region interaction, tenant integrity, and behavioral symmetry. Access is controlled. Exposure is structured.
Canonical Regional Model (Permanent Structure)
Region 1 — Northeast: ME, VT, NH, MA, CT, RI, NY, PA, NJ, DE, MD, DC, VA, WV, KY, OH
Region 2 — South: NC, SC, GA, FL, TN, AL, MS, LA, AR, OK, TX
Region 3 — Midwest: ND, SD, NE, KS, MN, IA, MO, WI, IL, IN, MI
Region 4 — West: WA, OR, CA, ID, MT, WY, NV, UT, CO, AZ, NM, AK, HI
Numbering always begins with Region 1 = Northeast.
Phase 2A — Stability Gate (200 Users)
Total: 200 users
50 per region
Region 1 — Northeast: 50
Region 2 — South: 50
Region 3 — Midwest: 50
Region 4 — West: 50
Objective
Validate infrastructure under balanced regional load
Observe cross-region workflow interaction
Confirm graph separation discipline across geography
Validate media + feed stability at sustained usage
No regional imbalance. No expansion until thresholds are met.
Stability Checkpoint (Before Expansion)
Expansion is blocked unless:
≥60% 14-day retention
No required schema refactor
No unresolved production-level incidents
Agent workflows usable without engineering intervention
Regional participation reasonably balanced
If not met → hold. Fix. Retest.
Phase 2B — Expansion Gate (300 Users)
Total: 300 users
75 per region
Add 25 per region simultaneously.
No region scales independently.
14-Day Discipline (All Regions)
Days 1–3: Account setup, profile completion, first structured post
Days 4–7: Workflow creation, feed interaction, invite testing
Days 8–14: Build and publish something tangible
If users only scroll, positioning or training is wrong.
Phase 3 — Behavioral & Product Validation
Overview:
This phase answers one question: does the system make sense to real people? We validate graph separation, workflow clarity, and agent usability. Friction is surfaced and corrected before scale.
Signals We Track
Creation rate
14-day retention
Graph discipline accuracy
Agent workflow completion without hand-holding
Confusion here means UX or training failure — not user failure.
Phase 4 — Business Entity Activation
Overview:
Mid-beta, we introduce organization profiles. This tests the tenant model under real-world relationships: person to business, membership roles, and shared workflows.
Validation Areas
Person → Org association integrity
Org profile creation flow
Membership roles & permissions
Org workflow publishing
Tenant isolation stability
No schema rewrites allowed at this stage.
Phase 5 — Verification Gate (eBay Purchase Model)
Overview:
Verification is executed through a $2.50 eBay purchase of a designated verification item. The purchase acts as an external identity + commitment signal and creates a traceable transaction record. Payment is not for platform features; it is for verified entry into the system.
Signals
Waitlist → eBay purchase conversion rate
Purchase → onboarding completion rate
Drop-off between purchase and platform activation
Regional balance of verified participants
Engagement quality of verified accounts
If the eBay verification flow creates excessive friction or distorts regional distribution, the flow must be optimized — not removed.
Phase 6 — Earned Income Validation (30% Nonprofit Allocation)
Overview:
This phase validates the economic engine under real participation. We activate earned income flows and enforce the 30% allocation model for nonprofits, testing distribution accuracy, reporting transparency, and operational clarity.
The objective is to confirm that revenue generation, allocation logic, and regional distribution function cleanly before scale.
Validation Areas
Revenue attribution accuracy
Nonprofit account payout logic
Regional distribution symmetry
Reporting clarity (participants can see where value flows)
No schema modifications required to support allocation logic
Checkpoint Requirement
If allocation logic requires structural redesign, scale is paused.
If payout tracking is unclear to participants, UX is revised before expansion.
Architecture Reference
Insert: 5thSocial Earned Income Architecture Diagram (People → PilotNav → Graph Layer → Apps → BFF → AI Execution → Earned Income Engine).
This diagram defines the economic execution path and must remain aligned with the canonical 4‑region model.
Infrastructure Stress Simulation
Overview:
We simulate early growth to confirm headroom. Database, media, workflows, and agents must remain stable under pressure.
Simulated Load
1,000 concurrent feed pulls
300 media uploads/hour
100 workflow executions/hour
50 agent executions/hour
Atlas CPU should not sustain above 60%. If it does, we optimize before growth.
Operational Readiness
Overview:
Clear ownership between development and infrastructure is mandatory. Monitoring, rollback paths, and issue triage must be operational — not theoretical.
Development
Structured logging only
Feature flags ready
Rollback capability verified
Clean production builds (no debug residue)
Infrastructure
Backup verification completed
R2 lifecycle policies defined
Rate limits configured
Alert routing tested
Process
Bug intake channel defined
Severity classification model
24-hour SLA for blockers
Beta Exit Gate
Overview:
We scale only if the system proves stable, understandable, and economically viable. Growth without discipline compounds problems.
Scale Criteria
≥60% 14-day retention
No required schema refactor
Stable feed under 1k concurrency
Non-technical users complete agent workflows independently
If these conditions are met, we expand deliberately.
If not, we iterate.