How to Build an MVP: Scope, Tools and Metrics

To build an MVP, identify the single assumption that must be true for your startup to work, choose the cheapest product format that can test it with real users, cut every feature that does not serve that test, ship it within weeks, and judge it against a success metric you defined in advance. An MVP is finished when it can produce a clear answer, not when it looks complete. The steps below show how to scope it, which type to choose and what to measure.

What makes a product "minimum" and "viable"

Both words matter. Minimum means you leave out everything that is not needed to test your core assumption: settings pages, integrations, admin dashboards, edge cases. Viable means the product still delivers real value to a real user, so their behaviour is meaningful. A broken or confusing product teaches you nothing, because users leave for the wrong reasons.

A useful way to think about it: the MVP should do one job, for one type of user, end to end. A narrow product that works beats a broad product that half works.

Step 1: Write down the assumption you are testing

Before scoping anything, finish this sentence: "We believe that [target user] will [behaviour] because [reason]. We will know this is true when [measurable signal]."

Example (hypothetical): "We believe that freelance designers will send invoices through our tool every month because it saves them time chasing payments. We will know this is true when at least 10 of our first 30 users send two or more invoices in their first six weeks."

If you have not yet confirmed that the problem is real, do that first. Our guide on how to validate a startup idea covers interviews and commitment tests that should come before building.

Step 2: Choose the right MVP type

Different assumptions call for different MVP formats. The cheapest option that can produce a reliable answer is usually the right one.

MVP type	How it works	Cost and speed	Best for testing
Concierge	You deliver the outcome personally, with no product	Very low cost, very fast	Whether the outcome is valuable at all
Wizard of Oz	Users see a product interface, you do the work manually behind it	Low cost, fast	User experience and demand before automation
Landing page / pre-sale	You describe the product and take orders or deposits	Very low cost, very fast	Willingness to pay and messaging
No-code product	Built with existing no-code or low-code tools	Low to medium cost, fast	Workflows, retention, early usage
Single-feature software	Custom code, one core feature only	Medium to high cost, slower	Technical feasibility plus usage
Piecemeal	Existing tools stitched together (forms, spreadsheets, email)	Very low cost, fast	Process before investing in software

A practical rule: if your risk is "do people want this outcome?", start with concierge or Wizard of Oz. If your risk is "can people use this workflow on their own?", you need some kind of product, often no-code first.

Step 3: Scope ruthlessly

List every feature you think the product needs. Then sort each one into three buckets.

Bucket	Question	Example (invoicing tool)
Must have	Is the core test impossible without it?	Create invoice, send by email, mark as paid
Fake it	Can we do it manually or with an existing tool?	Payment reminders sent by the founder by hand
Later	Does it only matter once people already use the product?	Multi-currency, team accounts, accounting export

Only the first bucket gets built. The second is handled manually behind the scenes. The third goes on a list you revisit when users ask for it repeatedly.

Scoping checklist

• One target user type, not several
• One core job the product performs end to end
• Sign-up flow as simple as possible (or invite-only)
• No settings or customisation beyond what the core job needs
• Manual processes accepted wherever users do not see them
• Basic analytics to measure the success metric
• A simple way for users to give feedback (email, chat, call)

Step 4: Set a time and money budget

Constraints protect you from building too much. Decide upfront how many weeks and how much money the MVP may consume, then pick the scope and type that fit inside those limits.

Example (hypothetical): two founders have €30,000 available and monthly living and tool costs of €4,000. They want to keep at least six months of runway after the MVP to iterate and sell. That leaves €30,000 − (6 × €4,000) = €6,000 of discretionary budget and roughly a month of time before the clock gets tight. A custom-coded product from an agency does not fit; a no-code build plus manual operations does.

Doing this maths explicitly is worthwhile. You can plug your own cash, costs and timeline into the startup runway calculator to see how long you can afford to build and iterate.

Step 5: Pick tools and build

Choose the stack that gets you to the test fastest, not the one that would scale to millions of users. If the MVP works, you can rebuild later with what you learned.

Typical options:

• No-code app builders and databases for internal tools, marketplaces and simple SaaS workflows.
• Form builders, spreadsheets and automation tools for piecemeal MVPs.
• Website builders with checkout for landing pages and pre-sales.
• Your own code when the core value depends on technology that no tool provides, but keep everything around it simple.

If you hire external developers, write the assumption, the must-have list and the success metric into the brief. Agree on a fixed scope and deadline, and make sure the code, accounts and intellectual property belong to your company.

Step 6: Launch to a small, specific group

Do not launch to everyone. Launch to 10 to 50 users from your target segment, ideally people you interviewed during validation. They understand the problem, they will forgive rough edges, and you can talk to them directly.

During the first weeks:

1. Onboard early users personally, by call or screen share if possible.
2. Watch where they get stuck.
3. Ask what they expected to happen at each step.
4. Fix blockers immediately; add features only when several users ask for the same thing.

Step 7: Measure the right things

Vanity metrics like total sign-ups or page views tell you little. Focus on behaviour that shows real value.

Metric	What it shows	Example question
Activation	Did users reach the core value?	What share of sign-ups created and sent a first invoice?
Retention	Do they come back?	How many users were still active after four weeks?
Frequency	How often do they use it?	Invoices sent per user per month
Willingness to pay	Will they pay or upgrade?	How many accepted a paid plan after the trial?
Qualitative pull	Do they care if it disappears?	Would they be very disappointed without it?

Compare the results to the success signal you wrote in Step 1. If you sell a subscription product, also look at early revenue per user and how it relates to acquisition cost; the LTV to CAC ratio article explains how. Our overview of startup financial metrics shows which numbers to track once usage grows.

Step 8: Decide what happens next

After a defined period, often four to eight weeks of usage, review the evidence:

• Signal met: expand to more users in the same segment, then automate what you were doing manually.
• Partially met: find out why. Interview users who left and users who stayed. Change one variable (segment, onboarding, core feature, price) and test again.
• Not met: go back to the problem. Was the problem real but the solution wrong, or was the problem smaller than it seemed?

Common MVP mistakes

• Building the full vision. If your MVP has a roadmap of twenty features, it is not an MVP.
• Testing several assumptions at once. If it fails, you will not know which assumption was wrong.
• Polishing before testing. Design matters, but perfect visuals cannot rescue a product nobody needs.
• Launching to strangers only. Without direct contact to early users, you collect data but not understanding.
• No success metric. Without a predefined threshold, every result looks encouraging.
• Hiring an agency too early. Paying for a large custom build before validating demand spends runway you will need later.
• Ignoring what users do. What people do in the product matters more than what they say in feedback forms.

Where the MVP fits

The MVP sits between validation and growth in the sequence outlined in our guide on how to start a startup. It turns interview insights into observed behaviour. If it works, you have the material for a credible pricing strategy (see how to price a SaaS product) and, if you choose to raise money, the traction that makes investor conversations far more productive.