How to scope an MVP: plan your first app release

Turn an industry method into one complete transaction

Imagine a consultant who reviews supplier risk for small manufacturers. Today, the customer fills out a spreadsheet, emails it back, and waits for the consultant to produce a report. The proposed software business would let other consultants sell the same assessment to their clients. This is an illustrative product, not a past engagement.

The first release could serve one consultancy and one assessment type. A client receives an invitation, answers the questions, saves a draft, submits it, and returns to read the approved report. A reviewer sees submissions and publishes a result. That sequence exposes work a feature list can miss: invitations, draft recovery, review status, and permission to read the report.

Write the release boundary in those terms before adding a score builder or a marketplace for consultants. You can evaluate whether a customer completed an assessment. You cannot evaluate whether an undefined platform is complete.

Choose what waits by naming the consequence

For each requested feature, ask what happens to the first customer if it is absent. If the answer is that the founder performs a manageable task, document that task. If the customer cannot receive the promised result, either include the work or change the release promise.

For the assessment example, the following choices keep the first transaction complete. The decisions would change for a self-service product sold to hundreds of firms, or for a customer whose procurement process requires organization-wide sign-in.

Calculate the capacity behind a manual step

Suppose each report needs 20 minutes of founder review. With 12 submissions a week, that is four hours of review before customer questions or corrections. At 60 submissions, the same task takes 20 hours. Those are scenario assumptions, not measured customer demand.

The first scenario may fit your available time; the second may not. Record a trigger such as reviewing automation when the weekly queue exceeds your review capacity for two consecutive weeks. Choose the threshold from your actual availability and service promise.

Manual work also needs an owner and an absence plan. If you are away for a week, can another reviewer deliver the result, or must customers wait? Put the answer in the operating plan and avoid selling a turnaround the first release cannot support.

Replace a feature label with checks you can witness

An acceptance check describes a starting condition, an action, and an observable result. Use ordinary business language first; the developer can translate it into technical tests. Include the awkward path as well as the successful one.

For the assessment workflow, confirm that a client can save and return to an unfinished form, that submission places it in the correct review queue, and that publishing a result makes it visible only to the intended client. Decide whether a submitted answer can be edited and what happens to a result already under review.

This prevents a late disagreement over what the word assessment included. It also gives you a way to review a milestone without inspecting code. A demo with prepared records should be followed by your own attempt using the agreed starting conditions.

Given a client has an unfinished assessment
When they sign out and return
Then their saved answers remain available

Given client A has a published result
When client B tries to open its address
Then client B cannot read the result

Keep a change from quietly becoming a second product

If a pilot customer asks for multi-office reporting, record the need behind it. They may need a comparison once a month, which could initially be supplied manually. They may instead require daily access for several regional managers, which changes permissions and reporting scope.

Ask the builder for the effect on the current release before agreeing to the request. A scope swap should compare effort, dependencies, and risk. Removing a simple settings screen does not automatically pay for organization-wide reporting. Preserve the original release boundary until both sides agree to a replacement.