Shipping an MVP in six weeks: what to build, what to cut

Six weeks is enough time to build something real, if you're ruthless about what 'real' means. Most MVPs fail not because they were built too fast, but because they tried to be a full product on a prototype's budget.

Build the one thing that proves the idea

Every product has a single risky assumption, the one thing that, if it's wrong, means nothing else matters. Your MVP exists to test that assumption and nothing else. Everything that doesn't serve it is a candidate for the cut list.

What to cut (almost always)

• Settings pages nobody has asked for yet.
• Admin dashboards you can replace with a database query for now.
• Onboarding flows before you know where users get stuck.
• Every 'nice to have' that starts with 'wouldn't it be cool if'.

What not to cut

Speed to real users, basic analytics, and an architecture that won't need a rewrite when it works. Cutting corners on the foundation is the one shortcut you pay for later, which is why we build MVPs on foundations that extend, not throwaway prototypes.

Six weeks, roughly

Week one is scope and design. Weeks two to five are build, in demoable slices. Week six is launch, instrumentation, and the first round of real feedback. If your content and decisions are ready up front, that timeline holds.

An MVP isn't a smaller product. It's a sharper question.