How to scope an MVP: what to test and build first

Start with one user and one task

Start with a person in a real situation: a client requesting a service, a coordinator assigning a job, or a customer choosing a booking. Write down what triggers the task and what a successful finish looks like.

For a service portal, the first journey could begin when a client sends a request and end when they approve a proposal and see the project status. A general-purpose CRM, billing system and document editor are separate ambitions.

Name the actors and decisions. Who prepares the proposal? Who may approve it? What happens when it is rejected? A written journey makes missing responsibilities easier to spot than a list of screens.

Test the journey before you build it

A clickable prototype is most useful when it answers a specific question. Use realistic examples rather than placeholder text: a proposal needs a scope to read, an approval needs a consequence, a status needs to say what happens next.

Give a potential user a task rather than a tour. Ask them to find the proposal, explain what they are approving and show where they would check progress. Record where they hesitate and what they expect to happen. ‘Could not find the delivery date’ is evidence; ‘add another dashboard’ is one possible response.

Know what a prototype cannot prove

A smooth prototype does not establish demand, willingness to pay, security, integration reliability or production performance. Those need different evidence: conversations with buyers, real-world trials and engineering checks.

Watching a few people use it tells you whether the journey makes sense. Whether enough people will pay is a separate question, answered by buyers, not by testers.

Sort every feature into three lists

Put each proposed capability into one of three groups: needed for the first outcome, required to run safely in production, or deferred. The second group matters: backups, permissions and a recovery process are invisible to users but necessary.

• Core journey: request, proposal, approval and status.
• Production needs: access control, validation, monitoring and agreed recovery procedures.
• Later: advanced reporting, additional roles and integrations that do not block the first outcome.

Decide what can stay manual

A first release can leave occasional work with a person if the responsibility is explicit. A team member might prepare proposals while the product handles review and status. Manual work should have an owner and a visible queue.

Be explicit about integrations that are not built yet. If the first version uses sample or imported data, record which connections still need API access, technical investigation or a commercial agreement.

Write acceptance criteria in plain language

‘The portal is finished’ is hard to verify. ‘A client can approve the latest proposal, the team can see that approval, and an older proposal cannot replace it’ names an observable result.

Add the important failure cases. If a submission fails, does the user keep their text? If someone repeats an action, can it create duplicate work? The expected behaviour belongs in the fixed-price scope.

Keep changes tied to the outcome

When a new idea appears, ask whether the first user can still finish the agreed task without it. If yes, it goes into a later stage. If no, revisit the scope, price and acceptance criteria together.

• Write the main question before anyone tries the prototype.
• Observe the complete journey, not only the attractive screens.
• Keep untested assumptions visible in the plan.
• Start the build only when its scope and acceptance criteria are written down.