Internal Plan · R-Link Studio

14-Day MVP Plan

Locking the real-time pipeline at 80-100 concurrent participants, finishing the admin to 80%, and putting Kim plus a 5-10 user beta cohort on staging by Day 14. Production cutover follows in week 3.

14
Calendar Days
80-100
Participants Target
5-10
Beta Users on Day 14
80%
Admin Functional

14-Day Timeline

Week 1 Week 2 Buffer Milestone
Week 1 · Real-Time Stability
Week 2 · Admin + Beta Prep
Day 1
Wed 5/13
Audit + bug list
Day 2
Thu 5/14
Load test harness (25 → 100)
Day 3
Fri 5/15
Fix top bugs from audit + load test
Day 4
Sat 5/16
Webinar flow + public landing
Day 5
Sun 5/17
Livestream + chat hardening
Day 6
Mon 5/18
Screen share + recording
Day 7
Tue 5/19
Week 1 load test repeat + Kim status
Day 8
Wed 5/20
Admin: Users + roles
Day 9
Thu 5/21
Admin: Recordings + transcripts
Day 10
Fri 5/22
Admin: System settings + analytics shell
Day 11
Sat 5/23
Admin: Affiliates + Rewards parity
Day 12
Sun 5/24
Beta cohort prep
Day 13
Mon 5/25
Buffer + internal dry run (Memorial Day)
Day 14
Tue 5/26
Beta dry run + Go/No-Go
Day 1: Wed May 13● Day 14: Tue May 26● Memorial Day = Day 13 (buffer)● QA tests this week = live ground truth● Go / No-Go meeting Day 14● Day 1: Wed May 13● Day 14: Tue May 26● Memorial Day = Day 13 (buffer)● QA tests this week = live ground truth● Go / No-Go meeting Day 14●
🎯 Day-14 Bar

Staging proven to hold 80-100 concurrent participants across meeting, webinar, and livestream flows, with chat, screen share, Deepgram captions, and recording all working end-to-end. Admin panel 80% functional. Kim plus 5-10 beta users live on staging. Production cutover follows in week 3.

📋 Visibility Ground Rule · Monday is the Source of Truth

Every bug, PR, assignment, and milestone in this plan mirrors to a Monday board so the team can see what's moving without DMing each other. Triage dashboard, deploy events, CS notifications, and the team's PR pipeline all push status into Monday automatically. Track D covers the wiring.

⚡ Pre-Day-1 Input · QA Tests This Week

QA testers are running two large simulated-participant tests this week (15-25 participants each). Their findings are the real-world ground truth that synthetic load can't fake. Both test outputs feed directly into Day 1's audit and Day 3's fix queue.

  • Every bug gets logged on the triage board AND mirrored to Monday the moment it's seen, and is fixed immediately
  • Performance metrics (CPU, RAM, dropouts, latencies) get captured during the runs, not after
📅 Calendar Notes

Day 13 (Mon 5/25) is Memorial Day. Use it as a buffer and run an internal-team-only dry run, not beta-user-facing.

Week 1 Real-Time Stability

The single biggest risk to the 80-100 number is real-time pipeline drift, not feature gaps. Week 1 locks the pipeline. Days 1-7 = Wed 5/13 through Tue 5/19.

Day 1Wed 5/13
Audit + bug list
  • Run the full meeting / webinar / livestream flow end-to-end in staging. Record screen.
  • Pull open GitHub issues + QA triage board. Pull every bug from this week's QA 15-25 participant tests. Dedupe and rank by impact on 80-100 person sessions.
  • Verify Agora subscription tier and concurrent-stream limits in writing.
  • Confirm Doppler r-link-studio-redux dev and prod configs are intact post-team-exit.
Day 2Thu 5/14
Load test harness (bridge QA 25 → target 100)
  • Wire up synthetic-participant tool (Agora Cloud Player SDK or k6 + headless Chrome via Playwright pool).
  • Step-load: 25 first (match QA baseline → validate harness), then 50, then 100. See where it breaks, not just whether.
  • At target 100: half publishing audio, 10 publishing video, 1 screen sharing.
  • Capture: connect time, audio dropouts, video freezes, Socket.IO latency, server CPU/RAM, Mongo pool saturation.
Day 3Fri 5/15
Fix top bugs from audit + load test
  • Fix top issues from Day 1 audit + Day 2 load test. Prioritize anything that breaks > 1% of joins or fails > 10 participants.
  • Compare metrics from QA's recorded runs against Day 2's synthetic numbers at the same participant count.
  • If real 25 diverges from synthetic 25, the harness is lying — fix that before trusting the 100 number.
Day 4Sat 5/16
Webinar flow + public landing
  • Validate: scheduled webinar create → public landing → registration → join → broadcast → end → replay → recording surface.
  • Fix dashboard webinar end fallback edge cases.
Day 5Sun 5/17
Livestream + chat hardening
  • Validate livestream path. Confirm RTM chat works at 100-person scale without Presence add-on (we are NOT enabling withPresence).
  • Stress chat: 100 participants posting once every 5 seconds for 5 minutes. Measure Socket.IO + RTM behavior.
Day 6Mon 5/18
Screen share + recording
  • Validate screen share with viewer layout retention (commit d57b384 fix).
  • Validate recording → S3 → playback. Confirm Deepgram Nova-3 transcripts land in JSONL.
Day 7Tue 5/19
Week 1 load test repeat + Kim status
  • Re-run the Day 2 load test. Compare deltas. Capture metric baseline.
  • 5-bullet status to Kim: what's locked, what's flaky, what's deferred.

Week 2 Admin + Beta Prep

Days 8-14 = Wed 5/20 through Tue 5/26. Build the admin to 80% across the high-value surfaces, prep the beta cohort, and run a real 80-100 person dry run.

Day 8Wed 5/20
Admin: Users + roles
  • Lock down Admin.jsx: create, edit, suspend, reset password, assign roles.
  • Verify per-user tenant scoping holds (SHARED_ACCOUNT_MODELS cutover from 2026-04-24).
Day 9Thu 5/21
Admin: Recordings + transcripts
  • Lock down AdminRecording.jsx: list, search, play, share-link, delete, transcript export.
  • Confirm S3 lifecycle / retention rules are explicit.
Day 10Fri 5/22
Admin: System settings + analytics shell
  • Branding, defaults, feature toggles UI.
  • Read-only analytics page (DAU, meetings, minutes used) backed by Mongo aggregation. Accurate over pretty.
Day 11Sat 5/23
Admin: Affiliates + Rewards parity
  • AdminAffiliates.jsx + RewardsAdmin.jsx: parity with Kim's current expectations.
  • If anything is broken, mark it Phase 2 in writing rather than rebuilding.
Day 12Sun 5/24
Beta cohort prep
  • Sign 5-10 beta users (Kim's choice). Onboarding doc. Bug-report path = QA triage board.
  • Production-equivalent staging URL: studio.staging.stonelabs.app. Confirm Cloudflare DNS.
Day 13Mon 5/25 · Memorial Day
Buffer + internal dry run
  • Light day. No beta-user-facing work (holiday).
  • Internal team-only 80-person dry run on staging using synthetic load + a few stakeholders. Capture issues.
  • Spot fixes only. No new feature work.
Day 14Tue 5/26 · Go/No-Go
Beta dry run + go/no-go meeting
  • Real 80-100 person webinar on staging with Kim + beta cohort + dummy attendees. Record. Score against Week 1 baseline.
  • Same-day go/no-go meeting with Kim: cut over to production in week 3, or extend staging beta by another sprint.

Parallel Tracks Run Alongside the 14 Days

These don't compete with the MVP — they multiply it. Tracks owned by Matt multiply the throughput of the core 14-day work. Track C reflects Kim's role as project owner and creative-technical co-builder.

Track ADays 1-7 · ~1.5 work days
AI Infra Buildout
  • Day 1: Auto-fix bot wired to the rebuild repo + QA triage (add r-link-studio client, "Submit bug" link in admin nav).
  • Day 2: Sentry client + server projects, Doppler DSNs, source maps, alert rules → #r-link-studio-alerts.
  • Day 3: Deploy automation + /studio-redeploy slash command, smoke-test GitHub Action on every deploy.
  • Day 4-5: Rivendell status pill polling /health, /api/studio/redeploy endpoint, Hall quick-action card.
  • Day 6-7: CS email automation — extend cs-ticket-resolved to auto-notify beta users when their reported bug ships.
  • Detail: r-link-studio-infra-integration-plan.md.
Track BBoth weeks
Hire 2-3 AI-first Developers
  • Week 1 — Sourcing. Post in AI dev communities. Filter: ships code with AI tools daily, comfortable with PR-based workflows. Skip anyone who needs hand-holding through Doppler.
  • Week 1 — Screening. 60-90 min paid pair session on a real Studio ticket in Claude Code. Watch how they think.
  • Week 2 — Paid trial. Top 2-3 candidates start 2-week trials on scoped verticals: one owns admin, one owns webinar/livestream, one owns API + mobile parity bridge.
  • Onboarding system. Per-repo CLAUDE.md, auto-fix bot, QA triage, Doppler, worktree slash commands — all already exist. Productive Day 1.
  • Goal by Day 14: at least one trial hire shipping merged PRs, freeing Matt for architecture + deeper pairing time with Kim.
Track DDays 1-4
Monday.com as System-of-Record
  • Day 1 — Board structure. Stand up "R-Link Studio Development" board. Groups: Live Bugs, In Fixing, Ready for QA, Done This Sprint, Roadmap, Hires + Trials. Team gets access at right permission level.
  • Day 2 — QA triage ↔ Monday sync. New triage ticket auto-creates a Monday item. Status changes sync both directions. Comments mirror as Monday updates.
  • Day 3 — Deploys + Sentry → Monday. Every Vercel/Railway deploy posts a Monday update on relevant items. Sentry new-issue alerts open Monday items in Live Bugs automatically.
  • Day 4 — Kim's work + hiring pipelines on Monday. Kim's PRs and pairing sessions live in the same Monday groups as everyone else's work. Trial-hire applicants + screens (Track B) tracked in a Hires group.
  • Beyond Day 4: every new automation drops events into Monday as part of its definition of done.
Track CBoth weeks
Kim — Project Owner & Creative-Technical Co-Builder
  • Kim is the project owner and the creative-technical lead on Studio. Product vision, user experience, and Phase 2 cut decisions are hers. She is also actively building inside the sprint — keeping the fusion of creative direction and code that built Studio originally.
  • What Kim ships: UI components and user-facing flows in her zone, admin panel work, onboarding and beta experience, creative direction translated directly into code where she can build it solo.
  • What Kim pairs with Matt on: work requiring senior architectural judgment, patterns she hasn't internalized yet (with the explicit goal of internalizing them), production hardening of features she's built.
  • What Kim owns as project lead: Phase 2 cut line (Day 10), all product and UX direction, final approval on beta launch readiness, customer-facing communication and rollout.
  • Working cadence: Kim's PRs flow through the same Monday structure as anyone else's. Product input on Matt's work happens inline in PRs and Slack — no formal review sync. Pairing sessions scheduled as work demands.
  • Goal by Day 14: Studio ships with Kim materially in the build — project owner who is also shipping code in her zone alongside Matt.

Daily Rhythm

  • 9:00 ET: 10-minute standup with self (Rivendell Council). Top 3 for the day.
  • 16:00 ET: status bullet to Kim (Slack DM) — what shipped, what's blocked, tomorrow's top 3.
  • Friday: 30-min sync with James to align on Flutter parity items + share the change log bot output.
  • Monday: 15-min sync with Kim — review the week ahead, identify pairing sessions needed, align on what Kim is building solo vs. with Matt.

Risks + Mitigations

  1. Agora limits at 100. Confirm tier in writing Day 1. If we're capped below 100, escalate to Kim same day.
  2. Mongo at scale. DigitalOcean managed Mongo 8 should handle this load, but verify Railway connection pool size. Bump if needed.
  3. Recording S3 costs. Validate retention policy before the beta dry run or fees spike.
  4. Edge cases that need real engineering. Phase 2 backlog gets a clear definition by Day 10 so Kim sees what's deferred and why.
  5. Real-time bugs surface only at scale. Day 2, Day 7, Day 13 dedicated load tests catch what real users would find on Day 15.
  6. Weekend pace. 14 calendar days includes Sat 5/16, Sun 5/17, Sat 5/23, Sun 5/24 as real work days. Build in a 1-day slip buffer mentally — if Day 7 or 13 slips, Day 14's dry run still has to happen.

Phase 2 (post-Day 14, week 3+)

  • Production cutover + legacy retirement plan
  • Stripe billing UI in admin
  • Integration UI (Slack, Zapier, etc.)
  • Mobile (James's Flutter) parity catch-up
  • Public API doc + key management UI for /external/v1/*