Sprint Plans

This plan turns the PRD's v1 scope — founder-side search/booking/payment/review, mentor-side profile/availability/payout, and platform-side manual vetting/dispute handling — into a sprint-by- sprint build sequence a solo technical founder can execute directly, with an AI coding tool doing much of the line-level implementation. It assumes the recommended stack below, a 2-week sprint length, and a hard 4-month (17-18 week) ceiling to a public v1 launch. Nothing here invents scope beyond the PRD: no mobile app, no Structured Track package, no automated mentor-quality scoring. Where a task depends on a decision the founder hasn't made yet (e.g., which identity-verification vendor to use for mentor vetting), that's called out explicitly rather than silently assumed.

Sprint Overview & Assumptions

Team: one technical co-founder (former hardware PM, writing the code — likely with an AI coding tool such as Claude Code or Cursor doing a meaningful share of implementation) plus one part-time contract designer. No engineering co-founder, no QA hire, no dedicated DevOps. This shapes every sequencing decision below: nothing is scheduled that assumes a second engineer's parallel throughput, and every sprint budgets real founder-only hours, not a two-person team's combined hours.

Sprint length: 2 weeks. At a 4-month (roughly 17-18 week) timeline, that yields 8 sprints of 2 weeks each plus a half-sprint hardening/launch buffer (Sprint 8 is intentionally lighter). A 1-week sprint was considered and rejected: for a solo engineer context-switching between backend, frontend, and a marketplace payments integration, a 1-week cadence produces too much overhead in planning/review relative to actual build time, and a 2-week cadence gives enough room to land a vertical slice (e.g., "founders can complete a real booking") rather than partial horizontal layers.

Recommended tech stack (no strong founder preference stated, so recommended for a 2-person team that needs to move fast and will need marketplace payouts):

• Next.js (App Router) + TypeScript for the web app — one codebase for the founder-side and mentor-side experiences (both are "logged-in web app" surfaces, not fundamentally different products), server components for read-heavy pages (search, profiles), and Vercel or a comparable platform for zero-ops deployment, which matters a great deal when there is no DevOps role.
• PostgreSQL (via a managed provider — Neon, Supabase, or RDS) as the system of record. A marketplace's core entities (bookings, payouts, disputes) are inherently relational and need real transactions; this is not a data shape that benefits from a NoSQL store.
• Prisma as the ORM, for schema-as-code migrations a solo founder can review and roll back confidently, and because its generated types pair well with an AI coding tool inferring correct query shapes from the schema file directly.
• Stripe Connect (Express accounts) for mentor payouts and Stripe Checkout / Payment Intents for founder-side payment collection. This is the single highest-risk piece of technical/compliance surface in the whole build (see Risks & Mitigations) and is treated as its own sprint, not a bolt-on task inside a later sprint.
• Auth.js (NextAuth) with email magic-link plus Google OAuth for both founder and mentor accounts — no custom password storage to build or secure.
• Resend for transactional email (booking confirmations, payout notifications, dispute correspondence), Twilio deferred (SMS reminders are a nice-to-have, explicitly out of v1 scope per the PRD's own scope boundary).
• Cloudinary or Vercel Blob for mentor profile photo/credential-document uploads.
• Vitest + Playwright for automated testing — Playwright specifically because a marketplace's riskiest paths (booking → payment → payout) are end-to-end flows across two user roles, which unit tests alone can't meaningfully cover.

Assumptions made explicit because they shape sequencing:

• The contract designer delivers Figma for a given sprint's screens one full sprint ahead of the engineering work that implements them — e.g., Sprint 3's mentor-search UI is designed during Sprint 2, so engineering never blocks on design mid-sprint. This is the single most important process assumption in this plan; without it, a solo engineer has nothing to build against on day one of a sprint.
• The founder is the only engineer. Every task list below is sized against roughly 30-35 effective coding hours per 2-week sprint (accounting for founder time also spent on mentor recruitment, admin vetting, and general operating work that a solo founder can't delegate away).
• Manual, founder-performed mentor vetting (per the PRD's explicit v1 scope: "manually vet new mentor applications") is treated as an operational process running in parallel with engineering from Sprint 1 onward, not a feature to build — the only engineering work it requires is an admin interface to review and approve/reject applications (Sprint 2) and a status field driving what a pending mentor sees (Sprint 2).
• Stripe Connect's own onboarding review (Know Your Customer checks on mentor payout accounts) has turnaround time outside the founder's control — this plan front-loads Connect integration (Sprint 3) specifically so there's slack before payouts must work end-to-end for launch.
• No automated mentor-quality scoring, no mobile app, and no Structured Track package appear anywhere in this plan, matching the PRD's explicit v1 exclusions. Session video/calling is assumed to be external (Zoom/Google Meet link shared at booking confirmation, not an embedded video product) — building a native video layer inside a 4-month solo-founder timeline would consume a disproportionate share of the budget for a feature that off-the-shelf tools already solve well.

Milestone/Sprint Breakdown

### Sprint 1: Auth & Marketplace Foundations

The skeleton every later sprint depends on: user accounts (both roles), the base data model, and a
deployable app. No booking, search, or payment logic yet — this sprint exists so that Sprint 2
onward has real accounts and a real database to build against instead of mocked data.

- Next.js App Router project scaffolded (TypeScript strict mode), deployed to a staging environment
  from day one (Vercel preview deployments on every PR) so "does it actually deploy" is never a
  surprise late in the project.
- Postgres provisioned (managed, e.g. Neon), Prisma schema v1: `User` (with a `role` enum —
  `FOUNDER` / `MENTOR` / `ADMIN` — a single user table with a role flag, not separate tables per
  role, since a user's core identity fields are identical across roles and this avoids duplicate
  auth logic), `MentorProfile`, `Booking`, `Review`, `Payout`, `DisputeCase` stub tables (empty for
  now, populated by later sprints).
- Auth.js wired: email magic-link (Resend) + Google OAuth, session handling, role-aware route
  protection (`/mentor/*` requires `MENTOR` role, `/admin/*` requires `ADMIN` role).
- Base app shell: top nav (role-aware — a founder sees "Find a mentor," a mentor sees "My
  availability"), responsive layout (mobile-first, since founders will realistically check booking
  status from a phone even though there's no native app), design tokens landed from the designer's
  Sprint 0 exploratory Figma (colors, type scale, spacing) so every later screen inherits a
  consistent look from the start rather than a redesign pass at the end.
- Signup flow: role selection at signup (founder vs. mentor), minimal required fields at this stage
  (email, name) — richer profile fields belong to Sprint 2's mentor-profile work.
- CI: lint + typecheck + unit tests on every PR, blocking merge on failure — set up now, while the
  codebase is small enough that retrofitting CI later would mean fixing a backlog of violations
  instead of never accumulating them.

### Sprint 2: Mentor Profiles & Manual Vetting

Mentors need somewhere to describe their expertise before search can mean anything, and the
platform needs a way to keep unvetted mentors out of the public search index — this sprint builds
both halves of that gate.

- Mentor profile creation flow: company history (structured, repeatable fields — company name,
  years, role, not a single free-text bio blob, since search/filtering in Sprint 3 needs to query
  against structured expertise tags, not parse prose), named expertise tags (a curated, admin-
  maintained taxonomy — e.g. "DFM," "Supply Chain," "EMC/Safety Certification," "Tooling
  Negotiation," "Contract Manufacturer Selection" — picked from a fixed list, not free text, so
  Sprint 3's filtering is exact-match rather than fuzzy), hourly rate, headline, profile photo
  upload, and a short bio.
- Mentor application status field (`PENDING_REVIEW` / `APPROVED` / `REJECTED`) — a mentor profile in
  `PENDING_REVIEW` is fully saved but never appears in public search, and the mentor sees a clear
  "Your application is under review" state instead of their own live profile.
- Admin review queue: a simple internal list view (admin-role-gated) of `PENDING_REVIEW` mentors
  with their full submitted profile, an Approve/Reject action, and an optional rejection-reason note
  emailed to the applicant. This is intentionally the simplest possible interface — a table and two
  buttons — since the PRD scopes vetting as a manual founder process, not a feature requiring
  workflow automation.
- Mentor-side availability groundwork: a calendar data model (`AvailabilitySlot` — day/time-range,
  recurring weekly pattern, timezone stored per mentor) even though the founder-facing booking UI
  that reads it doesn't land until Sprint 4 — building the data model here means Sprint 4 has real
  data to book against rather than needing to retrofit both the schema and a UI simultaneously.
- Designer delivers: mentor profile creation form, admin review queue, and founder-side profile
  *view* screens (the read-only card a founder will eventually see in search results).

### Sprint 3: Payments Foundation — Stripe Connect & Checkout

The highest-risk, most compliance-heavy piece of the entire build, deliberately scheduled as its own
sprint before any booking UI exists, so integration problems surface with weeks of runway left
rather than during launch week.

- Stripe Connect Express account onboarding: mentors are prompted to complete Stripe's own hosted
  onboarding flow (identity verification, bank account linkage) from their profile settings — the
  platform never collects or stores raw bank details itself, Stripe's hosted flow handles that
  entirely, which meaningfully reduces both PCI/KYC surface area and the founder's own compliance
  burden.
- `MentorProfile.stripeConnectAccountId` + `payoutsEnabled` boolean, kept in sync via Stripe Connect
  webhooks (`account.updated`) — a mentor cannot be marked bookable until `payoutsEnabled` is true,
  independent of their admin-vetting status; both gates must pass.
- Stripe Payment Intents integration for founder-side payment collection at booking time, using
  Stripe Connect's **destination charges** model: the founder pays the full session amount, Stripe
  automatically splits it (80% to the mentor's connected account, 20% platform fee retained), which
  means the platform never has to run its own separate payout-calculation job — Stripe's own
  `application_fee_amount` parameter does the split atomically at charge time.
- Webhook handler for `payment_intent.succeeded` / `payment_intent.payment_failed` /
  `charge.refunded`, each updating a `Booking.paymentStatus` field — built now, against test-mode
  bookings created directly in a seed script, since the real booking flow that creates these
  Payment Intents doesn't exist until Sprint 4. This intentionally decouples "does the payment
  plumbing work" from "does the booking UI work," so each can be debugged independently.
- Test-mode end-to-end proof: a seeded mentor with a completed Connect onboarding, a seeded booking,
  a real Stripe test-mode card charge, and a real payout line item visible in the Stripe (test-mode)
  dashboard — the sprint's own concrete bar for "payments actually work," not just "the API calls
  don't throw."
- No designer dependency this sprint (Stripe's own hosted onboarding UI is used as-is) — this is
  deliberate slack, since Sprint 3 is the highest engineering-risk sprint and shouldn't also be
  gated on design availability.

### Sprint 4: Search, Filtering & Booking Flow

The first sprint where a founder can actually do the thing the product exists for: find a specific
mentor and book time with them.

- Mentor search page: expertise-tag filtering (multi-select against the Sprint 2 taxonomy — a
  founder can filter for "DFM" and "Supply Chain" simultaneously), plus filters for hourly rate
  range and general availability window (e.g. "available this week"). Server-rendered for the
  default (unfiltered) view for fast first paint; client-side re-fetch on filter change.
  Explicitly **not** in v1: any ranking/matching algorithm beyond a simple relevance/recency sort —
  the PRD scopes "search/filter," not automated matching.
  - Mentor profile detail page (public, once approved): full bio, expertise tags, rate, aggregate
  review rating (wired once Sprint 6 ships reviews; shows "No reviews yet" until then), and a
  "Book a session" CTA.
- Booking calendar UI: renders a mentor's `AvailabilitySlot` data as bookable time blocks in the
  **founder's own local timezone**, converted from the mentor's stored timezone — this is a real
  correctness risk (see Dependencies & Sequencing and Risks & Mitigations), tested explicitly with
  a mentor in one timezone and a founder in another as a seeded test case, not just "looks right on
  one developer's machine in one timezone."
- Booking creation flow: select a slot → confirm session length/rate → Stripe Payment Intent created
  (Sprint 3's plumbing) → on `payment_intent.succeeded`, `Booking` flips to `CONFIRMED`, the selected
  `AvailabilitySlot` is marked unavailable (preventing a double-book), and both parties get a
  confirmation email (Resend) containing session time in their own timezone and a placeholder for
  the video-call link.
- Manual video-link step (matching the "external video tool" assumption above): the mentor pastes a
  Zoom/Meet link into the confirmed booking, which triggers a follow-up email to the founder — simple,
  explicitly not automated calendar/video API integration, which is out of scope for v1.
- Designer delivers: search results grid/list, mentor detail page, and the booking calendar/
  confirmation flow.

### Sprint 5: Mentor Dashboard, Session Lifecycle & Payouts

Mentor-side operational tools: managing upcoming sessions, marking them complete (which is what
actually releases payment), and a payout history view.

- Mentor dashboard: upcoming confirmed sessions, past sessions, and availability management (add/
  edit/remove recurring `AvailabilitySlot`s from Sprint 2's data model, now with a real UI).
- Session completion flow: after a session's scheduled end time passes, both the founder and mentor
  can mark it "Completed" (either can trigger it — this deliberately doesn't require both parties'
  confirmation, since a mentor waiting on an unresponsive founder to confirm would otherwise never
  get paid). A completed session is what triggers the Stripe Connect payout to actually settle
  (Stripe's own payout schedule handles the mentor's bank transfer timing; the platform's job is
  only correctly marking `Booking.status = COMPLETED` and letting the destination-charge split from
  Sprint 3 do its job).
- No-show handling groundwork: a "Mark as no-show" action available to either party, which does
  **not** auto-refund or auto-pay — it flags the booking `NEEDS_ADMIN_REVIEW` and routes into the
  admin dispute queue (built fully in Sprint 7), since the PRD scopes no-show/dispute resolution as
  a manual admin process, not an automated one.
- Payout history: a mentor-facing read-only list of completed, paid sessions and their net payout
  amount (rate minus 20% fee), sourced directly from Stripe Connect's own transfer records via the
  Stripe API rather than a separately maintained ledger table — avoids a whole class of "our numbers
  don't match Stripe's numbers" reconciliation bugs.
- Founder-side session history: mirrors the mentor dashboard's past-sessions view, from the
  founder's side, as the anchor point for Sprint 6's review flow.
- Designer delivers: mentor dashboard, availability management UI, payout history screen.

### Sprint 6: Reviews & Founder-Side Polish

Reviews close the trust loop the whole marketplace depends on (a founder choosing between two
similarly-tagged mentors needs a signal beyond a self-written bio), and this sprint also absorbs
UI-polish debt intentionally deferred from the faster-moving earlier sprints.

- Review flow: after a session is marked `COMPLETED`, the founder gets a one-time prompt (in-app +
  emailed) to leave a 1-5 star rating plus a short written review, tied to that specific booking (one
  review per completed booking, not a general "rate this mentor" free-for-all that could be
  duplicated or gamed).
- Aggregate rating shown on mentor search results and profile pages (average of all their reviews,
  count shown alongside it — "4.8 (11 reviews)" rather than a bare average, since a bare 5.0 from one
  review reads very differently from a genuine 4.8 across a dozen).
- Mentor-side visibility into their own reviews (read-only — no response/rebuttal feature in v1,
  matching the PRD's scope boundary against building a full reputation-management system).
- Polish pass across Sprints 1-5's shipped screens: empty states (no bookings yet, no reviews yet, no
  availability set), loading states, and form-validation error messaging — deliberately batched here
  rather than gold-plated sprint-by-sprint, so early sprints could move at full speed on core
  mechanics first.
- Email notification audit: confirm every state transition that should send an email actually does
  (booking confirmed, booking cancelled, session completed, review requested, payout sent) — a
  marketplace's trust depends heavily on both sides always knowing what just happened, and it's easy
  for one transition to get missed while iterating quickly through Sprints 3-5.
- Designer delivers: review submission modal, review display components, and the empty/loading/
  error states audited above.

### Sprint 7: Admin Console — Disputes, Cancellations & Platform Health

The platform-side half of the PRD's scope that isn't "manually vet mentors" (already covered,
Sprint 2): dispute/no-show handling and basic operational visibility, so the founder can actually run
the marketplace day-to-day once real users are on it.

- Dispute/no-show admin queue: every booking flagged `NEEDS_ADMIN_REVIEW` (from Sprint 5's no-show
  flow, plus a new founder/mentor-initiated "Report an issue" action on any completed or in-progress
  booking) lands here with the full booking context (both parties, session time, payment status).
- Admin resolution actions: issue a full or partial refund (Stripe refund API, correctly reversing
  the destination-charge split so the mentor's portion is also clawed back when appropriate — tested
  explicitly against Stripe's own documented behavior for refunding a destination charge, not
  assumed), mark resolved with no refund, or manually re-open a booking for rescheduling.
- Cancellation policy enforcement: a founder or mentor can cancel a confirmed booking up to a
  configurable cutoff (e.g. 24 hours before the session) for a full automatic refund with no admin
  involvement; a cancellation inside that window routes to the same admin queue above rather than
  auto-refunding, since that's exactly the judgment call the PRD scopes as manual.
- Basic admin metrics view: total bookings, gross booking value, platform fee revenue, and open
  dispute count — a single dashboard page, not a full analytics product, but enough for the founder
  to sanity-check the marketplace's health without querying the database directly.
- Mentor/founder account suspension: an admin action to disable an account (e.g. a mentor with
  repeated no-shows or a founder attempting chargeback abuse), which immediately removes a mentor
  from search and blocks a founder from booking, without deleting either party's historical data.
- Designer delivers: admin queue table + detail panel, admin metrics dashboard (can be visually
  simple — this is an internal tool, not a customer-facing surface, so it gets proportionally less
  design investment than any founder- or mentor-facing screen in prior sprints).

### Sprint 8: Hardening, Security Review & Launch

A deliberately lighter half-sprint (roughly 1.5-2 weeks of the total 4-month budget) whose entire
purpose is de-risking launch rather than adding features — no new user-facing functionality is
planned here.

- Full Playwright end-to-end suite covering the three riskiest cross-role flows: founder search →
  book → pay → mentor marks complete → payout settles → founder leaves a review; a no-show → admin
  dispute → refund; and a mentor's Stripe Connect onboarding from signup through `payoutsEnabled`.
- Security pass: confirm every `/mentor/*`, `/admin/*`, and API route enforces role checks server-
  side (not just hidden client-side nav — a role check that only hides a link is not a security
  boundary), confirm Stripe webhook signatures are verified on every webhook endpoint, confirm no
  Stripe secret keys or database credentials are exposed to the client bundle, and run a dependency
  vulnerability scan.
- Load/cost sanity check: confirm the hosting and database tier can handle a realistic launch-week
  load (a few hundred concurrent sessions, not thousands) without surprising cost spikes, and confirm
  Stripe is switched from test mode to live mode with a real bank account connected for platform-fee
  settlement.
- Legal/compliance groundwork the PRD assumes exists but doesn't specify as an engineering task:
  Terms of Service and a mentor-facing independent-contractor agreement (drafted with counsel, not by
  the founder alone — flagged here as a hard external dependency, not an engineering deliverable) is
  linked from signup and Stripe Connect onboarding.
- Soft launch: a small, hand-picked cohort of 5-10 real mentors (from whatever sourcing channel the
  founder pursued in parallel with engineering, per the Sprint Overview's assumptions) fully onboarded
  and bookable, and a handful of real founder users invited directly, before any public/marketing
  launch — this is the actual bar for "launched," not a big-bang public opening on day one of Sprint
  8's end.
- No new designer deliverables this sprint — any polish surfaced by the security/hardening pass gets
  triaged as a fast follow, not folded back into the launch-blocking scope.

This synthesis is model-generated analysis, not an independently verified fact.

Task-Level Detail per Sprint

The three highest-risk sprints get expanded task-level detail below; the remaining five sprints' Milestone/Sprint Breakdown descriptions above are already close to task-level granularity and are not repeated here.

Sprint 3 (Stripe Connect & Checkout) — expanded task list:

1. Create a Stripe platform account in test mode; enable Connect; configure Express account settings (capabilities: transfers, card payments).
2. Build POST /api/mentor/connect/onboard — creates a Connect Express account for the current mentor user (if one doesn't exist) and returns a Stripe-hosted Account Link URL; redirect the mentor there from their settings page.
3. Build the Connect return/refresh URL handlers (/mentor/connect/return, /mentor/connect/refresh) per Stripe's documented Account Link flow.
4. Build POST /api/webhooks/stripe-connect — verify signature, handle account.updated, persist payoutsEnabled/detailsSubmitted onto MentorProfile.
5. Build POST /api/bookings/:id/pay — creates a Payment Intent with application_fee_amount set to 20% of the session amount and transfer_data.destination set to the mentor's Connect account id (destination charge).
6. Build POST /api/webhooks/stripe — verify signature, handle payment_intent.succeeded, payment_intent.payment_failed, charge.refunded; update Booking.paymentStatus accordingly.
7. Seed script: create a test mentor, drive them through Connect test-mode onboarding via Stripe's test data helpers, create a manually-inserted test Booking, charge it with a real Stripe test-mode card (4242 4242 4242 4242), and confirm the fee split and payout line item appear correctly in the Stripe test dashboard.
8. Write integration tests against a Stripe test-mode webhook fixture (Stripe's CLI can forward and replay real test-mode webhook events into a local dev server) — not a hand-mocked payload, since a hand-mocked payload can silently drift from Stripe's real event shape.

Sprint 4 (Search, Filtering & Booking) — expanded task list:

1. Build GET /api/mentors/search?tags=&minRate=&maxRate= — server-side filtering against MentorProfile, APPROVED status and payoutsEnabled = true both required for a result to appear (the two independent gates from Sprints 2 and 3 converging here for the first time).
2. Build the search results UI consuming that endpoint, with tag multi-select and rate-range controls as URL query params (so a search is shareable/bookmarkable, and the browser back button behaves correctly).
3. Build GET /api/mentors/:id (public profile) and GET /api/mentors/:id/availability?from=&to= — returns bookable slots within a date range, with server-side timezone conversion applied before the payload is sent to the client (never trust the client to do timezone math against raw stored times).
4. Build the booking calendar component: render available slots grouped by day in the viewer's local timezone (derived from the browser, with an explicit override control in case it's wrong), selecting a slot opens a confirmation step showing session length, total price, and platform fee breakdown before payment.
5. Build POST /api/bookings — creates a PENDING_PAYMENT booking and locks the selected slot (a short-lived lock, e.g. 10 minutes, released if payment isn't completed — prevents two founders from racing to book the same slot).
6. Wire the booking confirmation step to Sprint 3's POST /api/bookings/:id/pay, then to Stripe's client-side payment confirmation (Stripe.js), then poll or webhook-drive the booking to CONFIRMED.
7. Build the two confirmation emails (Resend templates) and the mentor's post-confirmation "add your video link" prompt.
8. Timezone test case: seed a mentor in America/New_York with a fixed availability slot, and a test session in Europe/Berlin, and assert the rendered slot time is correct in both directions — this exact test is what actually catches an off-by-one-DST-hour bug, which a same-timezone development setup would never surface.

Sprint 7 (Admin Console — Disputes) — expanded task list:

1. Build GET /api/admin/disputes — list bookings with status = NEEDS_ADMIN_REVIEW, joined with founder/mentor identity and payment status.
2. Build the "Report an issue" action available on any founder/mentor booking-detail view, which sets status = NEEDS_ADMIN_REVIEW and stores a free-text reason.
3. Build POST /api/admin/disputes/:id/resolve — accepts an action (REFUND_FULL / REFUND_PARTIAL / NO_REFUND / REOPEN), calling stripe.refunds.create() with the correct reverse_transfer: true for the destination-charge case when a refund is issued, so the mentor's payout is correctly clawed back rather than leaving the platform out of pocket.
4. Build the cancellation-cutoff logic: a scheduled check (a cron-style job, run e.g. hourly) or an on-request check at cancellation time comparing "now" to the session start time against the configurable cutoff constant, branching to auto-refund vs. admin queue accordingly.
5. Build the admin metrics query — aggregate SUM/COUNT queries against Booking for gross volume and fee revenue, filtered by date range, plus a live count of open NEEDS_ADMIN_REVIEW rows.
6. Build the account-suspension action (User.status = SUSPENDED), and confirm it's actually enforced at the search-query and booking-creation layers (a suspended mentor must disappear from search immediately, not just show a "suspended" badge while still being bookable).
7. Manual test script: simulate a no-show end to end (book, don't complete, mark no-show, appear in admin queue, issue a partial refund, confirm both the founder's refund and the mentor's clawback show correctly in Stripe test mode).

Dependencies & Sequencing

• Auth and the base data model (Sprint 1) block everything. No other sprint can meaningfully start without real User/role/session infrastructure — this is why it is Sprint 1 with no exceptions.
• Mentor profiles must exist before search/filtering has anything to search (Sprint 2 before Sprint 4). Building search UI against an empty or fake mentor table would produce a search experience that has to be substantially reworked once real profile data and the expertise-tag taxonomy exist — sequenced to avoid that throwaway work.
• Stripe Connect onboarding must land, and be provably working in test mode, before booking/ payment logic can be tested end-to-end (Sprint 3 before Sprint 4). A booking flow that collects payment but has nowhere valid to route the mentor's share is not testable as a real flow, only as a UI mockup — this is the single most important sequencing decision in this plan, and is why Sprint 3 is scheduled as its own dedicated sprint rather than folded into Sprint 4 alongside the booking UI it depends on.
• The admin mentor-vetting gate (Sprint 2) and the Stripe Connect payout gate (Sprint 3) are independent but must both be satisfied before a mentor is publicly bookable (both feed Sprint 4's search query). They can be built in parallel with each other (they touch different systems — internal admin state vs. an external Stripe API) but Sprint 4's search endpoint is the first point where both conditions are checked together, and that combined check needs both pieces to already exist.
• The booking/session lifecycle (Sprint 4-5) must exist before reviews are meaningful (Sprint 6). A review is anchored to a specific completed booking; there is no reviewable unit before a real booking can reach COMPLETED status.
• No-show flagging (Sprint 5) is a prerequisite for the admin dispute queue (Sprint 7) — Sprint 7 builds the resolution UI and refund logic against a NEEDS_ADMIN_REVIEW state that Sprint 5 already introduced; Sprint 7 does not re-invent that state.
• Refund logic (Sprint 7) depends on the destination-charge payment model established in Sprint 3. A refund against a Stripe Connect destination charge must explicitly reverse the transfer to the mentor, a materially different API call than refunding a normal, non-split charge — this is why refund logic is sequenced after, and explicitly tested against, Sprint 3's exact charge model, not designed in the abstract.
• The full Playwright suite (Sprint 8) depends on every cross-role flow it exercises already being individually functional — it is intentionally the last sprint, not run continuously from Sprint 1, because there is no complete flow to test end-to-end until search, booking, payment, session completion, payout, and review all separately exist.
• Design leads engineering by one sprint throughout (per the Sprint Overview's explicit assumption) — e.g., Sprint 4's booking-calendar UI is designed during Sprint 3, Sprint 6's review UI is designed during Sprint 5. Sprint 3 and Sprint 8 are the two exceptions (Sprint 3 uses Stripe's own hosted UI; Sprint 8 has no new UI), which is precisely what gives the designer slack to work ahead again after Sprint 3 rather than falling permanently behind.

Definition of Done

A sprint is done when every item below is true — not when the code merges, and not when it "looks right" in the founder's own local testing:

• Every task-level item listed for that sprint is merged to the main branch and deployed to the staging environment, not sitting in an open, unmerged pull request.
• The sprint's core flow is provably exercised in Stripe test mode where payments are involved — e.g. Sprint 3 is only done once a real Stripe test-mode card charge produces a real, correctly- split payout visible in the Stripe test dashboard; Sprint 4 is only done once a founder can complete a real Stripe test-mode payment end to end, from search through a confirmed, paid booking, in a single unbroken session with no manual database edits in between.
• Automated tests exist and pass for the sprint's new API routes and critical UI flows — at minimum, unit tests for new server logic (e.g., the fee-split calculation, the timezone conversion) and, from Sprint 4 onward, at least one Playwright test per newly-completed end-to-end flow.
• No TODO/placeholder logic remains in a path the Definition of Done above claims is working — e.g., a "mark as no-show" button that doesn't yet route to a real admin queue does not count as Sprint 5 being done; it means the no-show groundwork task is incomplete.
• The designer's screens for that sprint are implemented pixel-reasonably (not pixel-perfect — a solo founder does not have the bandwidth for exhaustive design QA — but no obviously broken layout, no missing responsive behavior at common breakpoints, and no missing empty/loading/error state for anything the sprint's own scope introduces).
• Every webhook consumed in that sprint (Stripe payment, Stripe Connect) has its signature verification tested against a real Stripe-generated test event, not only a hand-constructed mock payload.
• A one-paragraph sprint-close note is written (timeline actually spent vs. planned, anything descoped or deferred, anything discovered that changes a later sprint's plan) — cheap to produce, and the only reliable way a solo founder catches slow scope drift before it compounds across 8 sprints.

Risks & Mitigations

• Scope creep from the founder's own hardware-industry conviction. A technical founder who deeply understands the DFM/certification problem space is at real risk of over-building the mentor-matching or expertise-taxonomy side of the product (e.g., adding a matching algorithm, or a much richer credential-verification flow) beyond what the PRD scopes, because it feels more "real" than plumbing work like Stripe Connect. Mitigation: the PRD's explicit v1 exclusions (no automated mentor-quality scoring, no Structured Track) are treated as hard sprint-boundary constraints in this plan, not aspirational notes — any mid-sprint feature idea outside the Milestone/Sprint Breakdown above goes into a backlog for a fast-follow release, not into the current sprint, full stop.
• Stripe Connect's own onboarding, compliance, and refund-reversal complexity is genuinely hard and only partially within the founder's control. Express account KYC review times, edge cases in destination-charge refund reversal, and jurisdictional differences between US and Germany-based mentors (Stripe Connect's own supported-country and payout-currency rules differ by country) are real risks a solo founder with no prior payments-infrastructure experience can easily underestimate. Mitigation: Sprint 3 is scheduled early and treated as its own dedicated sprint specifically so a Stripe integration surprise (e.g., a mentor's country requiring additional verification steps) surfaces in month 1-2 with runway to resolve it, not in month 4 during launch week; Stripe's own test-mode tooling (test clocks, test bank accounts, the CLI's webhook-replay feature) is used throughout rather than only hand-written mocks, so integration bugs are caught against Stripe's real event shapes early.
• Cold-start mentor supply before the product is ready to demonstrate to them. Retired engineers are, per the PRD's own target-user research, not reliably found through ordinary channels like LinkedIn search, and a marketplace with zero bookable mentors has nothing to show a founder-side user either. Mitigation: mentor sourcing (industry alumni associations, professional engineering societies, direct retiree-network outreach — the actual channel is a business decision outside this plan's engineering scope) runs in parallel with engineering starting in Sprint 1, not after Sprint 8; the manual vetting flow (Sprint 2) is deliberately simple specifically so it doesn't become its own bottleneck once real applications start arriving; and Sprint 8's soft launch is explicitly gated on having 5-10 real, fully onboarded mentors in hand before any public opening, rather than opening publicly on a fixed calendar date regardless of actual supply-side readiness.
• Solo-founder bus-factor and burnout risk across a dense 4-month timeline with no engineering co-founder. Every sprint above assumes the founder personally ships 30-35 hours of coding work every two weeks on top of mentor recruitment, vetting, and general operating work — there is no slack for a multi-week illness, a distracting fundraising process, or simple underestimation compounding across 8 sprints. Mitigation: Sprint 8 is deliberately a lighter half-sprint that functions as schedule slack if any earlier sprint runs long; the sprint-close note required by the Definition of Done exists specifically to surface slippage after Sprint 2 or 3, while there is still enough runway to compress a later sprint's scope, rather than discovering the timeline has slipped only in month 4.
• Legal/liability exposure between founders and mentors is a real gap this plan does not engineer around. Mentor advice on a certification or design decision that turns out to be wrong, or IP exposure during a session, is a genuine open question the PRD inherits from the underlying idea brief, and no engineering task in this plan resolves it. Mitigation: a Terms of Service and mentor independent-contractor agreement, reviewed by actual counsel (not drafted solo by the founder), is called out explicitly in Sprint 8 as a hard external dependency, not an engineering deliverable — and it blocks the soft launch, not just the public launch, since even a 5-10 mentor soft launch involves real paid sessions and real liability exposure.
• Disintermediation risk (a founder and mentor take their second session off-platform to avoid the 20% fee) is a business-model risk, not a pure engineering one, but it does shape what gets built. Mitigation, reflected directly in this plan: reviews (Sprint 6) and payout/session history (Sprint 5) exist partly to make staying on-platform genuinely more valuable than a bare payment-processing relay — a mentor with a growing on-platform review history has a real incentive to keep booking through the platform rather than routing around it, which this plan treats as a reason reviews are scheduled before launch rather than deferred to a post-launch fast-follow.

Open questions

Needs real-world validation

What to do next

Downstream Summary