Carlos

## Execution Plan: TutorLink (v0.9)

This document outlines the strategic plan to design, build, and launch the Minimum Viable Product (MVP) for TutorLink as defined in the PRD v0.9.

### 1. Executive Summary

This plan details a phased, sprint-based approach to deliver the TutorLink MVP within an ambitious 14-week timeline. It covers team structure, a detailed sprint-by-sprint breakdown, technology strategy, risk management, and a plan for the beta and public launch phases. The primary goal is to de-risk the project by building foundational components first and iterating toward the full MVP feature set required for a successful market entry.

Key Assumption: The proposed 14-week timeline is highly aggressive and assumes a dedicated, senior-level team with minimal unforeseen blockers.

### 2. Project Governance & Team (Assumed)

A cross-functional team is required. The following structure is assumed:

Product Lead (1): Owns the PRD, backlog, and makes priority calls.
Design Lead (1): Owns UX/UI, from wireframes to high-fidelity mockups.
Engineering Lead (1): Owns technical architecture, code quality, and delivery.
Backend Engineers (2): Focus on API, database, payments, and business logic.
Frontend Engineers (3):
2x React Native (iOS/Android mobile apps for Students/Tutors).
1x Next.js (Web app for Students/Tutors/Admin).
DevOps/Infrastructure Engineer (1): Manages AWS, CI/CD, and scaling.
QA Engineer (1): Responsible for test planning, automated/manual testing.

Tools:

Project Management: Jira or Linear
Communication: Slack
Design: Figma
Code Repository: GitHub
CI/CD: GitHub Actions

### 3. Phased Delivery Plan & Timeline

This plan follows the high-level milestones from the PRD, breaking them down into detailed sprints. Each sprint is 2 weeks long.

| :--- | :--- | :--- | :--- |

| Total Estimated Timeline: | ~15-17 Weeks | | (Note: Expanded from PRD's 12-14 weeks to account for design & realistic beta phase) |

---

### 4. Detailed Sprint Breakdown (MVP Build)

#### Sprint 0: Project Kickoff & Infrastructure Setup (1 Week)

Goal: Prepare the environment for development.
Tasks:
[DevOps] Set up Git repositories (Frontend, Backend).
[DevOps] Configure AWS infrastructure (EKS, RDS, S3).
[DevOps] Establish CI/CD pipelines for automated testing and deployment to a staging environment.
[Eng Lead] Finalize tech stack choices (e.g., confirm Twilio vs. 100ms).
[All Eng] Set up local development environments.
[Product] Create Jira project, populate backlog with epics and user stories from PRD.

#### Sprint 1: User Identity & Core Models

Goal: Users can sign up, log in, and basic profiles exist.
Tasks:
[Backend] Design database schema (Users, Tutors, Students).
[Backend] Implement user registration & login API (Email/Pass, Google/Apple OAuth). (FR-1)
[Backend] Implement basic Tutor & Student profile models.
[Frontend] Build registration/login screens (Web & Mobile).
[Frontend] Set up state management (e.g., Redux, Zustand) and authenticated routes.
[QA] Write test plan for authentication flows.

#### Sprint 2: Tutor Onboarding & Profile Management

Goal: Tutors can complete their profiles and become "listable."
Tasks:
[Backend] Integrate Stripe Connect for tutor account creation.
[Backend] Integrate Stripe Identity for KYC workflow. (FR-2)
[Backend] Build API endpoints for tutor profile creation/update (bio, expertise, etc.). (FR-4)
[Backend] Build API for setting availability calendar and rates. (FR-5, FR-6)
[Frontend] Develop the multi-step tutor onboarding flow.
[Frontend] Build the "Edit Profile," "Set Availability," and "Pricing" pages for tutors.
[Design/Product] Finalize cancellation policy logic.

#### Sprint 3: Marketplace Search & Discovery

Goal: Students can find and view relevant tutors.
Tasks:
[Backend] Implement search endpoint with keyword and filtering logic (subject, price, etc.). (FR-7, FR-9)
[Backend] Optimize database queries for performant search.
[Frontend] Build the marketplace search page with filters and sorting controls.
[Frontend] Create the Tutor Listing Card component. (FR-8)
[Frontend] Create the public-facing Tutor Profile Detail page.
[QA] Begin performance testing on the search API.

#### Sprint 4: Booking & Payment Flow

Goal: A student can select a time slot and successfully book a session.
Tasks:
[Backend] Implement booking logic: check for conflicts, create session record.
[Backend] Integrate Stripe Payments to pre-authorize student's credit card. (FR-10)
[Backend] Integrate Twilio (or chosen provider) to generate a unique video room link upon booking confirmation. (FR-11)
[Backend] Implement notification service for booking confirmations. (FR-18)
[Frontend] Build the booking modal/page on the tutor's profile.
[Frontend] Implement the Stripe checkout flow.
[Frontend] Create a "My Sessions" page for students to view upcoming bookings.

#### Sprint 5: The Live Session & Post-Session Flow

Goal: Both parties can join the video call, and the student can leave a review afterward.
Tasks:
[Backend] Create API endpoint to capture payment at lesson start. (FR-12)
[Backend] Implement API for submitting ratings and reviews. (FR-16)
[Frontend] Integrate the Video SDK into a dedicated "Session" view. (FR-14)
[Frontend] Implement core video features: screen share, chat, timer, "End Session" button. (FR-15)
[Frontend] Build the post-session rating/review modal/page. (FR-19)
[QA] Conduct end-to-end testing of the "book-to-rate" happy path.

#### Sprint 6: Tutor Payouts & Admin Dashboard (v1)

Goal: Tutors can see their earnings, and Admins have basic oversight.
Tasks:
[Backend] Implement logic to move funds from platform to tutor wallet (minus commission). (FR-13)
[Backend] Build APIs for the tutor's earnings dashboard and payout history. (FR-20, FR-21, FR-22)
[Backend] Build basic admin APIs for user management (CRUD) and session viewing. (FR-23)
[Frontend] Develop the Tutor Wallet/Earnings dashboard.
[Frontend-Web] Build the initial Admin Portal: User list, search, view user details.
[DevOps] Secure the admin portal with separate auth/IP whitelisting.

#### Sprint 7: Beta Prep & Polish

Goal: Harden the application for a closed beta release.
Tasks:
[All Eng] Intensive bug fixing and performance optimization (<3s page loads).
[QA] Full regression testing across all platforms (iOS, Android, Web).
[Frontend] Implement remaining notifications (reminders). (FR-18)
[Backend] Implement admin functions for refunds and user suspension. (FR-24)
[Product/Design] Accessibility audit (WCAG 2.1 AA).
[DevOps] Prepare app store listings (screenshots, descriptions).

#### Sprint 8: Beta Launch & Monitoring

Goal: Onboard initial users, gather feedback, and monitor system health.
Tasks:
[DevOps] Deploy production environment. Submit apps to Apple App Store and Google Play Store.
[Product] Onboard the 50 invited tutors and 200 students.
[Eng Lead] Set up production monitoring and alerting (Mixpanel, Looker, AWS CloudWatch).
[All Eng] Triage and fix critical bugs reported by beta users.
[Product] Collect qualitative feedback via surveys and interviews (target NPS ≥ 50).

### 5. Risk Management & Mitigation (Execution Focus)

| Risk (from PRD + Technical) | Mitigation Plan | Owner |

| :--- | :--- | :--- |

| Low liquidity at launch | Pre-Launch: Engineering will build a simple invite/onboarding tool for the Product team. Launch: Product/Marketing to execute the targeted outreach plan to 3 universities. | Product |

| Poor video quality | Tech: Choose a robust SDK (Twilio/100ms) with strong QoS monitoring. Implement adaptive bitrate streaming. Product: Define minimum device specs and display a warning for users on poor connections. | Eng Lead |

| Aggressive Timeline Slip | Ruthlessly prioritize the MVP scope. Defer non-critical polish (e.g., complex animations, optional profile fields). Be prepared to simplify a feature (e.g., basic chat instead of full whiteboard for v1) if a sprint is falling behind. | Product/Eng Lead |

| 3rd Party API Dependency | Stripe/Twilio: Create abstracted service layers in the backend to isolate their APIs. This makes future replacement easier and simplifies testing with mock servers. | Backend Lead |

| Mobile App Store Rejection | Submit a preliminary, feature-incomplete build early in the process (Sprint 5/6) to vet the core concept and in-app payment model with reviewers. Address any feedback long before the final launch deadline. | Eng Lead |

### 6. Addressing Open Questions (from PRD)

This plan proceeds with the following decisions to unblock development:

Background Checks: For MVP, make background checks (Checkr) optional and US-only. Display a clear badge on profiles of tutors who complete it. This balances safety with reducing onboarding friction globally.
Group Lessons: Explicitly out-of-scope for v1, per the PRD. The entire data model and video architecture will be designed for one-to-one sessions.
Promotional Coupons: For MVP, all promotional discounts will be absorbed by the platform (TutorLink). This simplifies the payout logic and is a cost of customer acquisition. We will not pass the cost to tutors initially.
Minimum Device Specs: To be defined during Sprint 5 (Live Session build). QA will test on a range of low-end but popular Android devices (e.g., Samsung A-series) and older iPhones (e.g., iPhone 8) to establish a baseline for acceptable performance.
Video Cost Contingency: The Engineering Lead will set up billing alerts in the Twilio/100ms dashboard at 50%, 75%, and 90% of the forecasted monthly budget. If costs spike, the contingency plan is to (a) analyze usage for abuse, and (b) temporarily lower the default video resolution from HD to SD to control costs while investigating.