To develop an MVP, start with the assumption that would sink your startup if it were wrong, choose the cheapest product that tests it with real users, and build only what that test needs. Then launch to a small group, measure what they do, and decide what to change. A minimum viable product is not a cut-down version of your dream app. It is an experiment with a user interface.
This guide walks through the ten steps we use to take a founder from idea to a first launched version, with a worked example of cutting scope and a one-page brief you can copy.
Key takeaways
- An MVP tests one risky assumption. If you can't name it, you're not ready to build.
- Pick the MVP type by the question: demand, usability or willingness to pay each need a different test.
- Cut features with one question: "Can the user still get the core result without this?"
- Measure behavior (activation, repeat use, payment), not compliments or page views.
What is an MVP?
The term comes from the Lean Startup method, which describes building a minimum viable product “to begin the process of learning as quickly as possible,” then running a build-measure-learn loop to decide whether to pivot or persevere (The Lean Startup). The Nielsen Norman Group gives a crisp modern definition: an MVP is the simplest version of a product or feature that lets a team assess whether users will get meaningful value from it (NN/g, 2026).
Note the word “assess.” An MVP exists to answer a question. A product that looks great but teaches you nothing has failed as an MVP.
Why developing an MVP first matters
A leading way startups die is building something the market doesn’t want, then running out of money while finding out. CB Insights analyzed 431 venture-backed companies that shut down since 2023 and identified failure reasons for 385 of them.
- 43% cited poor product-market fit CB Insights, 2026
- 70% ran out of capital, usually the final cause rather than the root problem CB Insights, 2026
Those two numbers are linked. A long, expensive build before learning anything is the fastest route from the first to the second. An MVP shortens the time between spending money and finding out whether it was worth it.
How to develop an MVP: the 10 steps
From idea to first launch
-
Write the problem in one sentence
Who has the problem, what it costs them, and how they cope today. "Freelance designers in Lagos lose a day a month chasing international invoices in spreadsheets" beats "people need better invoicing."
-
Name your riskiest assumption
List what must be true for the business to work, then circle the one that is most likely wrong and most damaging if it is. That is what the MVP tests.
-
Choose your first users
Pick a group that feels the pain sharply, is easy to reach and will talk to you. They don't have to be your biggest future market.
-
Check what exists
Study competitors, workarounds, app reviews and forum complaints. You're looking for the gap your first users care about, not a feature list to copy.
-
Write the value proposition
"We help [user] get [result] without [frustration]." Every MVP feature must serve this sentence.
-
Pick the MVP type
Match the type to the question (see the table below). Not every MVP needs code.
-
Map the shortest path to value
List the steps from "arrives" to "gets the result." Remove every step that isn't needed to learn.
-
Cut features to the core
Sort features into must-have, later and never. Be ruthless (worked example below).
-
Build, then test with five people
Watch five target users try the core path before launch. Fix what blocks them; ignore polish.
-
Launch small, measure, decide
Release to a small group, track the one metric tied to your assumption, then pivot, persevere or stop.
Step 6 in detail: choose the MVP type by the question
| What you need to learn | Cheapest test | What counts as a pass |
|---|---|---|
| Do people want this at all? | Landing page with a clear offer and sign-up | A meaningful share of targeted visitors sign up or book a call |
| Can they use it? | Clickable prototype (for example in Figma) | Most testers finish the core task without help |
| Does the outcome matter enough to pay? | Concierge MVP: deliver the result by hand | People pay, or pre-pay, for the manual version |
| Will they come back? | Single-feature product | A clear group returns and repeats the core action |
| Does the business work at small scale? | Pieced-together tools (forms, spreadsheets, automations) | You can deliver reliably and the unit costs make sense |
Set the “pass” threshold before you launch. Deciding afterward lets you talk yourself into any result.
Worked example: cutting an MVP down to size
Say you want to build a lunch-ordering app for office workers. Your first feature list has 14 items. Your riskiest assumption: “Office managers will pay to replace their current group-ordering workaround.”
| Feature | Needed to test the assumption? | Decision |
|---|---|---|
| Menu from 3 partner restaurants | Yes | Must-have |
| Group order with one payment | Yes, this is the core result | Must-have |
| Order confirmation by email or WhatsApp | Yes | Must-have |
| Admin view of today’s orders | Yes, but a spreadsheet will do | Must-have (manual) |
| Live delivery tracking | No, a phone call works for 20 offices | Later |
| Loyalty points | No | Later |
| AI meal suggestions | No | Never, for now |
| Ratings and reviews | No | Later |
| Native iOS and Android apps | No, a mobile web page works | Later |
| …five more “nice to have” items | No | Later |
Result: 14 features become 4, and one of those is a spreadsheet. That’s an MVP you can launch in weeks, and its result answers the only question that matters right now.
Myth vs fact
- MythAn MVP has to be a working app.
- FactThe Lean Startup method treats the MVP as the fastest way to start learning. A landing page, a prototype or a manually delivered service is a valid MVP if it answers your riskiest question.
- Myth"Minimum" means it can be rough or buggy.
- FactMinimum means few features, not low quality. If the one core path is broken, users leave and you learn nothing about demand.
Write a one-page MVP brief
Before anyone designs or codes, put the plan on one page. It stops scope creep, which is the quiet killer of MVP timelines.
One-page MVP brief
- Problem statement (one sentence)
- First users (who, where, how you'll reach them)
- Riskiest assumption and the pass threshold
- MVP type and why
- The core path, step by step
- Must-have features (and the "later" list, written down so it stops coming back)
- The one metric you'll watch, plus two supporting ones
- Launch group and date
- Budget and the decision date
If you want a rough sense of cost and timeline from this brief, try the MVP calculator. For budgets, timelines and team options in detail, read MVP development for startups: timeline, cost and process.
What to measure after launch
Pick metrics that match the assumption. Page views and sign-up totals feel good but rarely answer the question.
| Product type | Metric that matters most | Why |
|---|---|---|
| B2B SaaS | Activation (users who complete the core task) and week-4 retention | Shows real value, not curiosity |
| Marketplace | Completed transactions and repeat buyers | Both sides have to show up |
| Consumer app | Repeat use over the first weeks | One-off use is novelty |
| Service or concierge MVP | Paid conversions and referrals | Payment is the strongest signal |
Pair the numbers with conversations. Ask users what they were trying to do, what confused them, and what they used before. Avoid “Do you like it?” People are polite. Ask about what they did, not what they think.
The question I ask founders a month after launch is simple: what did users do that surprised you? If the answer is "nothing," you're probably watching the wrong number or not talking to enough users. Sign-up totals make a nice screenshot for investors, but activation and repeat use tell you whether to keep building.
Common mistakes when developing an MVP
- Building for everyone. A product for “small businesses” teaches you little. A product for “solo real-estate agents handling WhatsApp leads” teaches you fast.
- Testing the solution before the problem. Confirm the pain is real before you test your answer to it. Our product validation guide covers this.
- Adding features mid-build. Every new idea goes on the “later” list unless it changes the assumption you’re testing.
- Skipping analytics. If you can’t see what users did, the launch was a demo, not an experiment.
- No distribution plan. An MVP nobody sees can’t teach you anything. Line up your first 20–50 users before launch.
- Reading one comment as a pattern. Change course on repeated evidence, not one loud user.
How long does it take to develop an MVP?
It depends on the type. A landing-page test can run within days. A clickable prototype often takes a few weeks. A coded single-feature product usually takes a few months once discovery is done. A better question than “how fast?” is “what is the smallest thing we can launch that answers our riskiest question?” For a typical structure, see the MVP development timeline.
Frequently asked questions
What are the steps to develop an MVP?
Define the problem, name your riskiest assumption, choose first users, check alternatives, write a value proposition, pick the MVP type, map the shortest path to value, cut features to the core, test with a few users, then launch small and measure. Each step narrows what you build.
How do I decide which features go into my MVP?
List every feature, then ask of each one: can the user still get the core result without it? If yes, it goes on the "later" list. Keep only what's needed to test your riskiest assumption, even if some of it runs manually behind the scenes.
Do I need a developer to build an MVP?
Not always. Landing pages, prototypes and concierge MVPs need little or no code. You need engineering once real users depend on the product, especially for logins, payments and personal data.
How do I know if my MVP worked?
Set a pass threshold before launch, tied to your assumption: for example, a share of target users who complete the core task, return, or pay. If you hit it, build the next layer. If not, change the user, the problem or the offer before spending more.
What is the difference between an MVP and a prototype?
A prototype shows how a product might look and work, usually without real data or users. An MVP is something real users can use to get a real result, even if parts are manual. A prototype can be a step toward an MVP.
Final thought
Developing an MVP is really about reducing risk in the cheapest order. Answer the question most likely to kill the idea first, with the smallest product that can answer it. When you’re ready to scope the build, send us a short brief and we’ll tell you what we’d test first.
