The Brief

A founder needed a marketplace connecting teachers with schools. Two-sided platform. Video interviews. Payment processing. User authentication for both roles. Launch needed to happen fast — investor deadline, market validation required.

The constraint: 3 weeks. The reality: we said yes because scope was clear and decisions could happen fast.

Week 1: Discovery & Architecture Lock

Days 1–2: What we're actually building

First meetings with the founder mapped the core flow:

• Teachers: Create profile → Upload video intro → Browse school postings → Apply
• Schools: Create job posting → Review applications → Schedule interviews → Hire
• Platform: Facilitate interviews, process payments, manage contracts

We explicitly didn't build: advanced matching algorithms, AI-powered recommendations, reporting dashboards, contract templates (version 2). These wait. MVP means: does the transaction work?

Days 3–5: Stack & architecture

• Frontend: Next.js + Tailwind (fast to iterate, component reuse)
• Backend: Node.js + Express (familiar to our team, fast API development)
• Database: PostgreSQL (relational data, user roles, clear schema)
• Video: Daily.co (WebRTC, one-line integration, no custom streaming)
• Payments: Stripe (payment platform takes commission, escrow handled)
• Auth: NextAuth.js (JWT, no custom OAuth implementation)
• Hosting: Vercel (frontend) + Railway (backend)

Every choice was: "What's production-ready in 2 days, not 2 weeks?" We didn't build custom anything. We integrated proven services.

The AI part: Our team used Claude Code to scaffold the API layer, database migrations, and form components. We designed the flows. AI executed the boilerplate. Saved about 3–4 days of setup.

Week 2: Core Build & Integration

Days 6–8: API & database structure

User models (teacher, school, admin). Job posting schema. Application workflow. Interview session tracking. Payment transaction log.

Using Claude Code, we generated the API endpoints, database migrations, and validation layer. Engineers reviewed every output. Nothing shipped unreviewed. This phase compressed what would typically be 1 week into 2 days.

Days 9–12: Teacher & School flows

Teachers can: Sign up with email/password, upload profile info, record 30-second intro video, browse open positions, apply with a message.

Schools can: Sign up, create a job posting, see applications, click "invite to interview", send calendar link (Daily.co video room auto-generated), accept hire.

WebRTC integration (Daily.co) took 1 day. Payment flow took 2 days (test mode before launch). User authentication and role-based views took 2 days. By end of week 2, the full loop worked end-to-end.

Week 3: Testing & Launch

Days 15–18: QA & edge cases

What happens if a teacher applies to the same job twice? What if a school forgets to accept payment before interview? What if the video fails mid-call?

We ran through real user scenarios. Caught 12 edge cases. Fixed all of them. Set up error tracking (Sentry) and performance monitoring (Vercel analytics). Monitoring was live before users were.

Days 19–21: Soft launch & real users

We onboarded 5 schools and ~30 teachers to test. Real money moved through Stripe (test mode). Real video interviews happened. Real applications submitted.

We caught 3 bugs in production that didn't show in testing. Fixed all of them same-day. Day 21: public launch. Traffic was low but the system held up.

What Actually Shipped

• Two-sided authentication (teacher & school roles)
• Profile creation with file uploads
• Job posting creation & browsing
• Application workflow
• WebRTC video interviews (Daily.co)
• Payment processing (Stripe, escrow)
• Email notifications for key events
• Error tracking & monitoring
• Responsive design (mobile-friendly)

No custom optimizations. No fancy algorithms. No analytics dashboard. No admin reporting. Just a working marketplace where teachers and schools could connect, interview, and hire.

What Waited for v1.1

• AI matching: Suggested teachers for schools based on job requirements
• Contract templates: Auto-generate offer letters with salary/start date
• Analytics: Schools could see applications trends, time-to-hire metrics
• Background checks: Integration with verification services
• Mobile app: Came 3 months later, after we saw which features were actually used

This wasn't laziness. It was discipline. We shipped what mattered (the transaction) and iterated on what users actually asked for.

Why This Timeline Actually Works

1. Scope was locked before code started

The founder had one job: say "yes" or "no" to features. No scope creep. No "while you're at it, can you also..." We said "version 2" for everything that wasn't core transaction.

2. We didn't build infrastructure

We rented infrastructure (Stripe, Daily.co, Vercel, Railway). We didn't write custom payment processing, custom video server, custom hosting. We integrated proven APIs.

3. AI accelerated repetitive work, not decisions

Humans decided: what to build, how data flows, what users see. AI generated: form components, API boilerplate, test scaffolding, documentation. We reviewed everything.

4. Every person had one job

One engineer owned frontend. One owned backend. One handled DevOps. One did QA. No hand-offs, no waiting. Senior people only (no junior developers burning time).

5. Risk accepted early

We knew we wouldn't polish everything. Animations could wait. Advanced filtering could wait. We accepted technical debt in areas users wouldn't hit in week 1.

The Honest Take

Three weeks is aggressive. It works because:

• Scope is crystal clear (or you're lying about timeline)
• Stakeholder can make fast decisions (no 10-person committee)
• Your team is senior (not learning on the job)
• You're comfortable with v1.0 being rough

If any of those are false, your timeline will slip. We've seen it. The first week of discovery is where most three-week projects actually die — because scope explodes, or decisions take too long, or architecture debates happen in week 2 instead of week 1.

EduHire shipped in 3 weeks because the founder came in with a clear vision, made calls fast, and was okay with MVP meaning "minimum viable," not "fully polished."