Implementation Roadmap
Guiding principle: The frontend never hardcodes stage types, field configs, tool toggles, or question bank types. Every piece of UI behavior that differs between stage types is driven by data from GET /v1/stage-types. All phases follow this contract from day one.
Delivery Sequence
Phase 0 Foundation (schema + seeds + /stage-types API + no hardcoding) ✅ Complete
↓
Phase 1A Automated Screening (invite → session → AI report → recruiter view) ✅ Complete
↓
Phase 1B Live 1-on-1 Interview (schedule → WebRTC → feedback gate) ✅ Complete
↓
Phase 2 Candidate Dashboard (Firebase login → pipeline history → privacy projection) Planned
↓
Phase 3 Technical DSA Round (IDE + code execution + expiry cron) Planned
↓
Phase 4 AI-Assisted Rounds (conversational AI + technical scenario interviewer) Planned
↓
Phase 5 Org Management + Subscription Gating (multi-user, Stripe, hard limits) Planned
↓
Phase 6 Advanced Analytics + Platform Hardening (reporting, branding, queues) PlannedWhat "No Hardcoding" Means at Every Phase
| What you might be tempted to hardcode | Where it comes from instead |
|---|---|
| Stage type names and keys | GET /v1/stage-types → key, displayName |
| Which fields show for each stage type | StageTypeConfig.schedulingConfig.* |
| Which tools are enabled | StageTypeConfig.toolsConfig.* |
| Min/max question counts | StageTypeConfig.questionBankConfig.minQuestions/maxQuestions |
| Whether questions are interviewer-only | StageTypeConfig.questionBankConfig.questionsVisibleTo |
| Whether to show send-link toggle | StageTypeConfig.automationConfig.hasSendLinkToggle |
| Whether feedback is required | StageTypeConfig.feedbackConfig.feedbackRequired |
| Feedback rating criteria and labels | StageTypeConfig.feedbackConfig.ratingCriteria[] |
| Plan names and features | GET /v1/plans |
| Which stage types are available | GET /v1/stage-types — all types, all plans (no filtering) |
| Usage limits per plan | Organization.featureSnapshot.* |