Scoping an MVP in a week: five questions we ask first

Most MVPs do not miss their deadline because the code was hard. They miss it because nobody wrote down what "done" meant. Before we estimate any project, we spend the first week answering five questions with the client. The output is a written scope, an estimate and a plan.

1. Who is the first user, exactly?

Not "small businesses" but "a school office in a town of 100,000 that currently uses paper registers". One concrete user makes every later decision easier, because you can ask what that person would do on a Monday morning.

2. What is the one job the product must do well?

Write it as a sentence a user would say: "I can take attendance in under a minute." If you need the word "and" three times, you are describing a roadmap, not a first release. Everything else goes on a list for later.

3. What is the riskiest assumption?

Every idea rests on something that might be false. Maybe users will pay, maybe they will type their data in, maybe an outside service will allow the integration you need. Name the riskiest one and plan the first release to test it as early as possible, before the polish.

4. What do we have to integrate with?

Payments, messaging, government or bank systems, an existing database. Integrations hide most of the surprises, because someone else controls their timeline and rules. Find them in week one, read their documentation, and check what an account and approval will take.

5. How will we know it is working?

Agree on two or three numbers before launch: sign-ups, completed tasks, repeat use. It keeps the team honest and makes the next decision, to continue, change or stop, a calm conversation instead of an argument.

What you should have at the end of the week

• A one-page scope listing what is in and what is out
• Clickable screens for the main journeys
• A list of integrations and what each needs
• An estimate with the assumptions behind it written next to it
• A weekly plan with something working to see every week

None of this needs special tools. A shared document and a few honest conversations are enough. What matters is that the scope is written down before the first line of code, so that changes become visible decisions rather than silent drift.

If you have an idea and want it turned into a plan you can hold us to, tell us about it. We will reply within one working day.