SaaS MVP timeline: a realistic week-by-week build plan

A SaaS MVP that includes auth, Stripe billing, six user flows, a custom design system, an admin panel, analytics, and a production deploy takes six weeks of focused engineering. Below that, you're either cutting scope, skipping design, or running on a starter kit. Above that, the timeline isn't a build problem. It's a scope-discipline problem. This piece walks through the realistic week-by-week plan we ship every engagement against.

#The shape of a six-week build

Before the day-by-day, the high-level shape: weeks 1–2 are foundation (auth, schema, deploy pipeline, design system). Weeks 3–4 are the core flows (the six user journeys that define the product). Week 5 is admin + analytics + billing wiring. Week 6 is cleanup, polish, security pass, and ship. Every week ends with a working software demo; nothing is "two weeks from working" at any check-in.

This is the same plan every engagement runs against. Different products, same plan. The discipline is what makes the timeline real.

#Week 1. Foundation

Day 1: Kickoff Slack channel goes live. GitHub repo created in your org with the team invited. Vercel project linked. Staging URL deployed (just a placeholder, but live). Postgres provisioned (Supabase or Neon, depending on your geography and compliance posture). Schema v0 designed in Figma's database tool or just on paper, then committed as Drizzle migrations.

Day 2: Auth works. Real auth. Email + password, OAuth via Google, magic links if your audience expects them. Forgot-password works. Email verification works. Session management works. The "log in" demo at the end of day 2 is a real test of an underestimated scope item.

Day 3: Stripe sandbox connected. Webhook handler stubbed and tested. Customer creation on signup, subscription on checkout, cancellation flow, plan switching. Not the full UI yet. Just the wiring tested via the Stripe CLI.

Day 4: First end-of-week demo. What you see: a working signup → log in → Stripe checkout → log out flow against your staging URL. No design system yet. It's all default Tailwind. The demo is functional, not pretty. The point is to prove the foundation works before the polish goes on.

Day 5: Sentry installed. PostHog installed. CI pipeline set up. Branch protection rules. Code formatter, linter, type-checker all wired. Pre-commit hooks. Boring infrastructure that makes weeks 2–6 not painful.

#Week 2. Design system

This is the week founders most often underestimate. A custom design system is not "use shadcn." It's the typographic scale, the color tokens, the spacing rhythm, the component variants, the form patterns, the empty states, the loading states, the error states, the responsive breakpoints, the dark mode (or not). For a B2B SaaS that wants to look serious, this is the difference between "looks like a Bubble app" and "looks like Linear."

Days 6–8: Design exploration in Figma. We bring two or three directional references, usually Linear, Resend, or Plain (the calibration bar for 2026 B2B SaaS aesthetics), and decide which the product takes. Type scale, color tokens, accent system, base components defined.

Days 9–10: Component library implemented in code. Buttons, inputs, selects, cards, modals, tables, navigation, tabs, breadcrumbs, toasts, empty states. Not pretty mockups. Actual TSX files in src/components/ui/.

Day 10 demo: a static page showing every component variant in dark + light. The product itself doesn't look any further along than week 1, but the foundation for it does.

#Weeks 3–4. Core flows

Six flows. Each takes roughly a day and a half to build end-to-end (API + UI + edge cases + states). That's 9 working days for 6 flows; the spare half-day per flow absorbs the surprises.

Each flow gets the same treatment: API route designed, types generated, UI built, loading state, error state, empty state, success state, optimistic updates where appropriate, and a manual end-to-end test against the staging URL. End of each day: commit, push, narrate a 3-minute Loom on what shipped.

End of week 4 demo: the product is functional. A user can sign up, hit the core path, and accomplish what they came to do. Design is in. Billing is wired. The friendly-user demo happens here. Real founders pulling in real friendly users (their first three customers, an advisor, a co-founder) and watching them try.

#Week 5. Admin, billing, analytics

The week that turns the demo into a real product.

Days 21–22: Admin panel. The list of users, their plan, their billing state, their last login, the search field across them, the action buttons (impersonate, refund, cancel, escalate). Not a CRM. Just the operations you'll need on day one when something breaks and you need to fix it without a database client.

Days 23–24: Stripe live mode. Real cards. Real webhooks. Real plan switching. Dunning emails wired. Payment-failed flow. Refund flow. Tax handling at minimum (Stripe Tax if available, otherwise the manual jurisdiction rules for your launch markets).

Day 25: Analytics + monitoring pass. PostHog event mapping for the six core flows. Funnel analysis pre-built. Sentry pages set up. Uptime monitoring (Better Uptime or equivalent) on. Dashboards bookmarked.

End of week 5 demo: you can now run the business. Not just demo it. run it.

#Week 6. Polish + ship

The week where most builds slip. The discipline of saying no kicks in here harder than anywhere else.

Days 26–27: Security pass. Rate limits on every public endpoint. RLS or equivalent on the database. Input sanitization everywhere user content lands in HTML. CSP and other relevant security headers. SSL hygiene. Secrets rotation check. The pen-test-but-light pass. Not a SOC2 audit, just the obvious stuff.

Day 28: Performance pass. Lighthouse 90+ on the marketing pages. Database query plans on the heavy reads. Image optimization on user uploads. CDN cache configuration. Lazy loading where appropriate.

Day 29: Content pass. Every empty state has copy. Every error message is human-readable. Email templates look like they were sent from a real product, not Stripe defaults. Onboarding flow is dialed in.

Day 30: Production deploy. Domain wired. SSL live. Monitoring on. Status page set up if your buyers expect one. Repo handoff documentation written. Final demo. Champagne if appropriate.

#What changes the timeline

A few common deviations from the six-week plan and what they actually mean:

"We need an AI feature". That's MVP Plus territory, eight weeks not six, because LLM features have nontrivial integration, rate limiting, prompt-iteration, and cost-control work that doesn't fit alongside the other six flows.

"We need native mobile". That's a separate engagement. We ship responsive web for MVPs; native is a v2 conversation.

"We're regulated (HIPAA, SOC2, PCI)". Compliance work runs alongside the build but adds 2–4 weeks of audit prep and design review. Quote separately.

"We need internationalization on day one". Adds about 1 week of i18n scaffolding. Most founders skip and add later; the scaffold cost is ~80% of the eventual cost so the “skip and add later” advice depends on how confident you are in your launch markets.

#What "done" looks like at week 6

Working product on a real domain. Real auth, real billing, real admin. Six core flows that take a real user from sign-up to their first useful action and beyond. Custom design system that doesn't look like a starter kit. Analytics + monitoring + error tracking wired. Repo transferred to your GitHub org. Docs written. Runbook for the first production incident written. Thirty-day post-launch fix coverage active.

That's the realistic timeline. Anything faster is one of: scope cut, pre-built starter kit, or a bill that arrives later.