How to Define an MVP: What Ships in v1

Learning how to define an MVP is mostly an exercise in subtraction. Most founders and product owners arrive with a feature list that describes the product they want in two years, then ask how to fit it into a first release. The result is a build that takes far longer than planned and still does not answer the only question that matters: does anyone want this?

We scope MVPs for companies and founders regularly, and the pattern is consistent. The teams that ship are not the ones with the smallest ideas; they are the ones with the sharpest cut line — a plain, written list of what is in and what is out.

This article shows how we run that cut, including the phase 2 list we propose most often and the items we refuse to remove from a first version.

Start with the problem, not the feature list

Write the problem as one sentence

Use a formula: “[Specific user] cannot [do a specific task] today because [obstacle], which costs them [time, money, or risk].” If you cannot fill it in without jargon or a second paragraph, the scope is not defined yet — it is a wish list with a deadline. Rewrite until a non-technical colleague can repeat it back correctly.

Pick the one user who feels the pain most

An MVP serves one kind of user through one core action. When a project has two user types, ask which one will pay first or complain loudest if the problem stays unsolved. Build that one. The second user type becomes a phase 2 item, not a phase 1 compromise.

Name the action that counts as success

Choose the single action that proves the product works: a job booked, an invoice sent, an order paid. Everything on the screen should support it; anything that does not is a candidate for removal.

The cut line: must ship, should ship, later

Every feature gets one of three labels. We sort with three questions.

1. Without this feature, can the user still complete the core action?

If yes, it moves to later. Features that improve an experience but do not enable it are phase 2 by definition. This question alone removes most of the list.

2. Does it depend on data, permissions or an account we do not have yet?

Anything waiting on another party — a payment provider review, an app store approval, an API key, a client’s own system — carries waiting time you cannot compress by writing code faster. Decide whether launch is possible without it.

3. Could a person do it manually for the first users?

Manual reporting, a spreadsheet import, a support inbox that triggers an internal task: all valid ways to deliver the outcome while the software stays small. Automate the second version, not the first.

Define “done” before anyone builds

Write down what a finished MVP looks like in observable terms: a real user signs up, completes the core action on the live system with real data, and gets confirmation. Agree on that sentence in writing; it settles the “almost ready” argument later. Our MVP development service is scoped around exactly that definition.

A concrete list of what waits for phase 2

What we postpone most often

• Admin dashboards and analytics beyond a CSV export
• Roles and permissions beyond a simple owner/member split
• Settings screens, themes, white-labeling and custom branding
• Multiple languages and currencies
• A native mobile app when a responsive web app does the job
• Self-serve onboarding tours, referrals, coupon codes and affiliate logic
• Integrations with tools that are not where the data already lives
• AI features that are not the reason the user is there

What we do not cut

• Authentication done properly, including account recovery
• A data model designed for the next version, not just this screen
• Payments and receipts, if the business charges money
• Consent, access control, and a way to delete an account and its data
• Error logging and a channel to hear from users

Scope decisions that save the build

Design the data model for v2, build the UI for v1

Screens are cheap to add and change. Data is not. A schema that already accounts for the fields and relationships you expect next lets you grow without a migration that touches live data. This is the one place we deliberately refuse to cut.

Start the slow items in week one

Domain and email, payment provider verification, app store accounts, third-party API access and legal pages all take time you cannot recover later. List them on day one and give each one an owner.

Treat a prototype as a scope demo, not a foundation

If your team already clicked together a prototype in a tool like Lovable, Bolt, Cursor, Replit or v0, you have something useful: it shows the flow you want. It is not yet a product. Authentication, data rules, security and deployment still need decisions — we cover that gap in vibe-coded apps.

FAQ

How many features should an MVP have?

There is no correct count. The test is whether a real user can complete one core action, start to finish, without a workaround. If the scope needs a diagram to explain, it is probably two releases.

Can we launch with manual work behind the scenes?

Yes, and we recommend it for reporting, onboarding and edge cases. Manual work only becomes a problem when it hides a rule the software should decide; document that rule before you automate it.

How long does an MVP take to build?

It depends on how much has to be approved by someone else. Integrations, payment verification, app store review and access to client data often set the calendar more than code does. We scope work and dependencies together before naming any date.

Ready to cut your scope down to something you can launch? Tell us what you need to build and we will review your feature list, separate the first version from phase 2, and turn it into a plan.