From Idea to MVP in Six Weeks: What I've Learned

Six weeks from idea to production: it's the constraint I get called in on most often. And the one that teaches you the most about what actually matters in a product — because it forces you to choose.

This isn't a universal playbook. It's what works on B2B SaaS projects with one to three people. If your context is different, adjust — but the principles hold.

Week 1 — Deciding What Not to Build

The first week produces zero code. Eighty percent of the time goes to cutting scope. A backlog of 40 items becomes a scope of 8. The selection rule is simple: if a feature doesn't directly address the core problem, it's out.

Write the problem in one sentence: "[user type] loses [time or money] because of [specific problem]." If you can't write that sentence without ambiguity, scoping isn't done. Uncomfortable? Yes. Necessary? Always.

Weeks 2–3 — Stack Choices and Setup

For a B2B SaaS in 2026, the stack that minimizes time-to-production without accumulating early technical debt:

• Next.js App Router — native SSR, API routes, zero-config deployment on Vercel or Netlify.
• Supabase — managed Postgres, authentication in half a day, row-level security from the start.
• Stripe — payment integration in a day, well-documented webhooks.
• Resend or Postmark — reliable transactional email without SMTP server configuration.

These aren't the only good choices — they're the fastest to assemble coherently. Initial setup — CI/CD, staging and production environments, basic Sentry monitoring — takes two days. Looks unproductive. In practice, it prevents a week of firefighting at the midpoint.

Weeks 4–5 — Build

Two one-week sprints with a demo at the end of each. No daily standups — an async message every evening: what shipped, what's blocked, what's planned tomorrow. Short, factual, traceable.

Arbitration rule: if a feature takes more than two days, cut it or simplify it. Estimates at this stage are rarely accurate — the rule protects the timeline without needing to debate every slip.

An MVP is a question, not a finished product. The question: is this problem worth solving, with this solution, for this user?

Week 6 — Shipping and Early Feedback

Shipping isn't the end — it's when the real learning starts. Deploy, run a guided session with the first users, identify the three most common friction points. Those friction points become the 1.1 backlog.

What I look for at this stage: do users come back without being nudged? If yes, the problem is real and the solution is good enough. If not, week 7 is a diagnosis week, not a development week.

What I'd Do Differently

Document architecture decisions from the start. Not a formal doc — five lines per structural decision, with context and discarded alternatives. Three months later, when someone asks why you chose X, the answer doesn't depend on whoever happened to be in the room.

And start integration tests on critical paths in week 3, not at the end. An MVP shipped with tests on the payment and authentication flows is infinitely more solid than one with 90% unit test coverage on utility functions.