You have a date: an investor meeting, a pilot customer, a conference. And you have a feature list that would take a year. The gap between them is where most MVPs fail, not because the team is slow, but because the scope was never really decided.
Find the one thing it must prove
An MVP is an experiment. Before listing features, write one sentence: "We believe that [these users] will [do this] because [reason]." Everything in the first version should help prove or disprove that sentence. Everything else waits.
Cut with three questions
- Would a user notice if this was missing on day one? If not, cut it.
- Can we do this by hand behind the scenes for the first 50 users? If yes, don't build it yet.
- Does this help prove the sentence above? If not, move it to the list for later.
Things that are usually safe to postpone: admin dashboards, complex permissions, multiple payment options, deep analytics, and anything described as "nice for later".
Design the risky parts first
Every MVP has one or two parts nobody is sure about, like a tricky integration, an unusual interaction, or an AI step. Prototype those in the first two weeks, while changes are cheap. Leave the familiar parts, like sign-up and settings, for later.
A realistic eight-week shape
- Weeks 1–2: agree the sentence, the scope and the success measure; prototype the risky parts; set up the repository, hosting and deployment pipeline.
- Weeks 3–6: build in weekly loops, with a working demo on a real URL every week and the scope re-checked at every demo.
- Week 7: test with real users, fix what they trip over, and add monitoring.
- Week 8: launch to your first group of users, measure, and plan the next loop.
Decide what success looks like before you launch
Pick one or two numbers you'll check after launch, like how many invited users complete the core action, or how many come back in the second week. Without them, it's impossible to know whether the MVP worked or what to build next.
What we'd tell a friend: Ask any team you hire to show you working software in the first two weeks, and make sure the code lives in your own repository from day one. Those two habits prevent most MVP disasters.