Shipping an MVP in six weeks: scope, sequence, and what we cut
Most six-week MVPs fail because the team tries to build a three-month product in six weeks. The trick isn't working faster — it's building less. Here's the sequencing we use.
Priya Sharma
Product & Design Lead
A six-week build sounds arbitrary until you've tried to ship one. The shape of the constraint does real work: it forces decisions that endless timelines postpone. Every time we've extended past eight weeks, the quality of the decisions went down, not up.
Week 1: Decide what you're not building
Most of week one is a scoping conversation with the founder. We write down every feature they've imagined, then cross out every one that isn't in the critical path for the MVP's single job. The list of things we're not building is longer than the list of things we are.
Week 2–3: The skeleton
- Auth, user model, and the single happy path (nothing else)
- Database schema for the two or three core entities
- The first real screen the user sees after signup
Week 4–5: The product
Everything that makes the product feel like a product — empty states, error messages, the loading states, the onboarding nudge. This is the phase that teams skip and that users feel the most.
Week 6: Polish, launch, watch
The final week is not for new features. It's for fixing the three bugs that shipped in week five, writing the onboarding email, and preparing for the launch — including turning on analytics and error tracking. Then we watch.
Enjoying the read?
Get notes like this in your inbox every month. No spam, unsubscribe anytime.