How to Scope an MVP

Who This Guide Is For

Founders, product owners, and business leaders planning the first version of a custom software product or internal tool. This guide helps you decide what goes into v1 and — equally important — what does not.

Before You Start

• An MVP is not a bad product. It is the smallest version that delivers real value. “Minimum” refers to scope, not quality. The features you include should be well-built.
• Know your core problem. If you cannot articulate the single most important problem your software solves in one sentence, you are not ready to scope an MVP.
• Accept that you will be wrong about some things. The purpose of an MVP is to learn from real usage. If you knew exactly what to build, you would not need an MVP.

Step 1: Define the Core Value Proposition

Write one sentence: “This software allows [who] to [do what] so that .” Everything in the MVP must directly support this sentence. Anything that does not is a candidate for later.

For example: “This software allows our operations team to generate client reports from three data sources in five minutes so that weekly reporting no longer takes twelve hours.” That sentence tells you the MVP needs data integration, report generation, and a basic interface. It does not need user management, client self-service, or custom branding — those come later.

Step 2: List Everything, Then Cut

Write down every feature you can think of. Do not filter yet — get it all on paper. Then categorise each feature:

• Critical: The MVP does not work without this. It directly enables the core value proposition.
• Important: Adds significant value but the MVP still functions without it. This goes in v2.
• Nice-to-have: Would be great eventually. This goes in the backlog.

Be aggressive with cutting. Most teams put 60-70% of their initial list into “Critical” on the first pass. The target is closer to 20-30%. For each “Critical” feature, ask: “If we launched without this, would anyone use the software?” If yes, it is not critical.

Step 3: Define User Journeys, Not Features

Instead of listing features, describe the journeys your users will take through the system. “A team member logs in, selects a client, chooses a date range, clicks ‘Generate Report,’ and downloads a PDF.” That journey implies specific features (authentication, client selection, date filtering, report generation, PDF export) but keeps the focus on what the user actually does.

This approach naturally eliminates features that are not part of any core journey. If a feature does not appear in a user journey, it probably does not belong in the MVP.

Step 4: Set Boundaries Explicitly

Document what the MVP will not do. This is as important as documenting what it will do. Explicit exclusions prevent scope creep during development:

• “v1 will not include client-facing access — only internal team use.”
• “v1 will not support custom report templates — all reports use a standard format.”
• “v1 will not integrate with Xero — data will be exported manually.”

These boundaries are not permanent decisions. They are conscious choices to defer complexity until the core is validated.

Step 5: Validate With Users Before Building

Before committing to development, test your scope with the people who will use the software. Show them the planned user journeys. Walk them through what v1 will and will not do. Ask: “Would you use this? What is missing that would prevent you from using it?”

If multiple users identify the same gap, it may need to move into the MVP scope. If they identify gaps you had not considered, you have saved yourself from building something incomplete. This validation step costs days and saves months.

Common Mistakes

• Scope creep through “small additions.” Each individual addition seems harmless. Collectively, they double the project timeline. Be disciplined about the boundary between v1 and v2.
• Building for scale before validating demand. An MVP does not need to handle a million users. Build for the first ten. Scale when you have evidence it is needed.
• Confusing MVP with prototype. A prototype demonstrates a concept. An MVP delivers real value to real users. An MVP must be production-quality within its scope.
• Not planning for what comes after. The MVP is step one, not the final product. Have a rough roadmap for v2 and v3 so that MVP architectural decisions do not create dead ends.
• Including admin features that nobody needs yet. User management, settings panels, and audit logs are important — eventually. For an MVP with five users, they are overhead.

What Good Looks Like

A well-scoped MVP has three to five core user journeys, a clear list of explicit exclusions, validation from at least a few target users, and an architecture that can grow without being rebuilt. It typically takes 6-12 weeks to build and provides enough real-world usage data to inform the v2 roadmap.

Next Steps

With your MVP scope defined, the next step is choosing a development approach. See How to Plan a Custom Software Project for the full planning process, or How to Budget for Custom Software to understand the financial commitment.