Most founders who end up disappointed by an MVP build can trace it back to a single moment: the proposal. That is where scope gets set, timelines get promised, and the shape of the next six months gets decided. The questions below are the ones worth asking before that moment, not after.
How much scope is too much for a first build?
This matters because scope is the quiet driver of everything that follows. A long feature list feels like value for money. In practice it stretches the build, and by the time the thing goes live, the assumptions it was built on have aged. A market moves, a competitor ships, an investor's interest cools. The window you were building for has already narrowed.
A good answer depends on being honest about what the launch is actually for. Proving one hypothesis and demoing to investors are different jobs with different minimums. The useful conversation is about which features earn their place in the first version and which can wait, and that conversation is uncomfortable precisely because it is the one that protects the timeline.
What is the difference between a demo and a product?
Plenty of MVPs look convincing in a meeting room and fall apart the moment real users touch them. No error handling, no thought about edge cases, no plan for what happens when traffic arrives. It works in the pitch and breaks in the wild.
The distinction matters because it decides whether you spend the next six months iterating or rebuilding. A demo proves a point once. A product survives contact with users and gives you something to grow from. What a good result looks like is a live URL that holds up under real conditions, not a prototype dressed as one.
Who owns the code, and why does it matter later?
This question gets skipped more often than it should. Founders discover months in that they cannot hand the codebase to a new developer, or that the history is a single tangled commit, or that nobody wrote down why anything was built the way it was.
Ownership and documentation are boring until your first technical hire or your first investor's due diligence. A good answer depends on clean source control, architecture notes someone else can follow, and clarity on who holds what. Those things cost little at the start and a great deal to reconstruct later.
What should happen in the weeks after launch?
Launch is a beginning, not a finish line. The period right after is when bugs surface, edge cases appear, and questions pile up. If the engagement ends at handover, you inherit all of that alone.
What a good result looks like here is a defined window of support and a team that answers rather than disappears. It also means analytics you can actually read from the first session, so the next decision is informed rather than guessed.
The full guide, including the week-by-week breakdown and how MVP development in London is scoped to ship in four weeks, covers the specifics this piece deliberately left out.
Top comments (0)