"How long does an MVP take" is one of the questions we get asked most often, and the honest answer is "8–12 weeks if you do it right". This is the timeline we run at Schedars, week by week, with what happens in each phase and what slows projects down.

TL;DR

Realistic MVP timeline: 8–12 weeks from kickoff to first user. Discovery 1–2 weeks, Sprint 0 (foundations) 1 week, Build 4–8 weeks in 2-week sprints, Launch 1 week. Anyone selling you "MVP in 4 weeks" is either selling a prototype or hiding scope debt.

Week 0–1: Discovery

Discovery is where you save money. We spend 1–2 weeks before any code is written interviewing stakeholders, mapping user journeys, and producing a written scope document. The deliverable is a fixed-bid estimate that everyone signs.

  • 3–5 stakeholder interviews (60–90 min each)
  • User journey + key flows for top-3 user personas
  • Technical scope: data model, integrations, infrastructure, third-party services
  • Risk register: what could blow up the timeline (App Store Review, payment integration edge cases, etc.)
  • Fixed-bid estimate with phases and milestones

Why it matters: every week of Discovery saves 2–3 weeks of mid-project rework. Skipping Discovery is the #1 cause of MVP timeline overruns we’ve seen at clients who came to us mid-rescue.

Week 1–2: Sprint 0

Sprint 0 is the foundation everything is built on. Design system, repo, CI/CD, infra — locked in a week before the first feature ships. This isn’t "we’ll set up later" work; it’s the rails the whole project runs on.

  • Design system: brand tokens, base components, key screens in Figma
  • Repository setup: TypeScript config, ESLint, Prettier, Husky pre-commit
  • CI/CD: GitHub Actions or Vercel preview deployments per PR
  • Infrastructure: Vercel or AWS account, environments (dev / staging / prod), DNS
  • Auth + billing scaffolding (rails for SaaS), or design-system polish (consumer apps)
  • First clickable prototype that renders the home screen

Week 2–10: Build

Build runs in 2-week sprints. Monday is planning, Friday is demo + retro, daily updates are async in Slack. Each sprint ships one or two complete features end-to-end (UI, API, DB, tests, deployed to staging) — not five half-features in parallel.

Sprint 1: Core feature, end-to-end

Pick the most important feature — the one that defines whether the product works. Ship it fully: empty state, happy path, error handling, edge cases, tests, deployed to staging. By Friday demo it should be usable end-to-end on a phone.

Sprint 2: Auth + onboarding

Sign-up, login, password reset, email verification, basic onboarding tour, profile management. Ideally most of this is wired in Sprint 0 with a hosted auth service (Clerk, Auth0); Sprint 2 is about polishing the UX around it.

Sprints 3–4: Second feature + billing

Second core feature shipped end-to-end. Billing rails (Stripe Subscriptions, plan upgrade/downgrade, webhook handling). At end of Sprint 4 you should have a closed-beta-ready product: 2 features working, auth working, billing working.

Sprint 5–6 (if mid-tier scope): polish + secondary features

Empty states, loading states, error states. Edge cases the demo missed. Performance audit. Accessibility review. One or two secondary features that round out the experience but aren’t critical-path.

Week N+1: Launch

Launch week is final QA, security review, performance audit, production deploy + monitoring, handover. We don’t ship to public on Friday — Tuesday morning, with the team available for the next 72 hours to fix anything that breaks.

  • Final regression testing on real devices (iOS + Android + 3 desktop browsers)
  • Security audit: OWASP top 10, headers, CSP, dependency scan
  • Performance audit: Lighthouse 90+ Mobile, Web Vitals real-user reporting wired
  • Production deploy + DNS cutover
  • Monitoring: Sentry for errors, PostHog for analytics, uptime alerts
  • Onboarding documentation for the client team + 2-hour handover call

What slows projects down

Projects that ship in 16+ weeks instead of 8–12 share a small set of failure modes. Knowing them lets you avoid them.

  • Scope creep without change requests — "just one more feature" mid-sprint
  • Skipping Discovery and figuring out scope as you go
  • Underestimating third-party integrations (Stripe edge cases, OAuth redirect URLs, email deliverability)
  • No staging environment — first real-data testing happens in production
  • Skipping closed beta — public launch reveals 50 bugs you’d have caught with 20 users
  • Pixel-perfect design before functional flow is locked — designing in vacuum
  • Custom infrastructure decisions (Kubernetes for an MVP, custom auth, custom billing) that consume sprints

What we ship at Schedars

Our average across the last 12 months: 8.4 weeks from kickoff to first paying customer or first TestFlight build for iOS. Range across 8 client projects: 6.5 weeks (simplest scope) to 13 weeks (mid-tier with custom integrations). The 13-week one had two integrations we underestimated; we fixed our Discovery checklist after that to catch similar risks earlier.

Bottom line

A realistic MVP timeline in 2026 is 8–12 weeks for most product scopes, with discipline around scope-locking, sprint cadence, and closed beta. The teams that consistently hit this aren’t faster — they cut earlier, demo weekly, and refuse to ship features that aren’t end-to-end.

Planning an MVP and want a sanity check on the timeline? Send us the scope — we’ll send back a week-by-week plan within a day.