See a real IdeaClarify report.

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.