DRAG
SCROLL
00%
Back to blog
§ MVP

MVP in 8 weeks: what's in and what's cut?

An MVP isn't a cheap product. It's a small, charming product built to learn what users actually need. Wrong cuts destroy learning; right cuts accelerate everything.

Weeks 1–2: clarification, not code

Most MVPs jump straight into dev. Wrong. The first two weeks go to: defining the business hypothesis, identifying the 3–5 real users who will test it, sketching the simplest flows (signup, main action, feedback), and setting success metrics. If we don't know what we're measuring, we don't know what we're building.

Weeks 3–5: main flow, end-to-end

One working flow beats three half-flows. We start with the most critical path (e.g. "user logs in, does X, receives Y") and take it all the way — real auth, DB persistence, emails, everything the flow needs. The rest stays a stub.

Weeks 6–7: second flow + polish

We add the second critical flow (dashboard, history, simple admin) and polish UX — clear errors, loading states, decent mobile. No time for a settings page, i18n, or dark mode. We say "no" a lot.

Week 8: test with the first real users

We give access to the 3–5 users identified at the start. Monitor, collect feedback, track success metrics. Here's where the learning begins. Everything up to this point is infrastructure for this week.

What does NOT go into an 8-week MVP

  • Complex permissions or multi-tenancy.
  • Internationalization (pick one language).
  • Subscription billing (add after you've validated value).
  • Integrations with 5 tools; pick one, the most critical.
  • Full admin dashboard; a CSV export is enough initially.

Conclusion

8 weeks is possible when scope is disciplined and decisions happen fast. Projects that pass 3 months at MVP aren't MVPs — they're products. Both are valid, but budgets and expectations differ significantly.

Have a similar project in mind? Let's talk.

Start a project