A minimum viable product is the smallest real product or experiment that helps you collect the maximum amount of validated learning about customers with the least effort. It matters because 42% of startups fail because there is no market need, so the point of an MVP isn't to build less software. It's to test whether the business should exist at all.
That runs against the advice most founders hear. A lot of MVP talk still sounds like "ship a stripped-down app fast." That framing is incomplete. If you build a small product that doesn't answer a real business question, you can still waste months building the wrong thing.
The practical question isn't "What can I launch quickly?" It's "What must I prove before this idea deserves more time, money, and code?" For many founders, especially solo builders, the best first MVP isn't an app. It's proof. A waiting list with pre-sales. A concierge workflow done by hand. A live dashboard showing recurring revenue, active users, or sustained usage. In other words, a minimum viable metric.
Table of Contents
- What Everyone Gets Wrong About MVPs
- The Real Philosophy of a Minimum Viable Product
- Smart MVP Types for Indie Hackers
- MVP vs Prototype vs MMP What Is the Difference
- Validating with Minimum Viable Metrics
- Common MVP Mistakes and a Founder's Checklist
- Your Next Step Is Learning Not Launching
What Everyone Gets Wrong About MVPs
Most founders misuse the word MVP to justify one of two bad decisions. They either ship something broken and call it lean, or they build a polished mini-product and call it minimum. Both miss the point.
An MVP is not permission to be sloppy. It's not a half-finished clone of your future roadmap. It's a focused test of one important assumption. If that assumption fails, you want to know early, before you've spent your nights wiring up edge cases, auth flows, billing logic, and dashboard settings nobody asked for.
A common pattern looks like this:
- Founder starts with features: account system, onboarding, settings, analytics, admin panel.
- Development expands: every "small" requirement creates three more tasks.
- Launch happens late: feedback arrives after the founder is already emotionally attached.
- Reality hits hard: users don't care enough, don't understand the value, or won't pay.
Practical rule: if your MVP contains several major assumptions at once, it will be hard to tell what actually failed.
The better move is to shrink the scope until one question becomes testable. Not "Will people like my platform?" That's too broad. Ask something tighter. Will busy recruiters book a call to outsource first-pass candidate screening? Will Shopify merchants pay for one narrow reporting feature? Will users return after the first use because the core job gets done?
This is why a founder can have an MVP without much software at all. If the primary risk is demand, then a landing page, a pre-order button, a manual service, or a tight workflow built from Airtable, Stripe, Notion, and email may tell you more than a custom app.
The word product in minimum viable product throws people off. The actual unit of progress is not code shipped. It is uncertainty removed.
The Real Philosophy of a Minimum Viable Product
Eric Ries formally defined the MVP in 2009 as a way to collect the "maximum amount of validated learning about customers with the least effort" within the Lean Startup method, which shifted attention away from output like features built and toward learning what customers want. That shift matters because 42% of startups fail because there is no market need according to the same reference at the Agile Alliance glossary for MVP.
Validated learning is the output
Founders usually treat software as the asset and learning as a side effect. An MVP flips that. Learning is the asset. The code is just one way to generate it.
Think about opening a restaurant. You could sign a lease, renovate a space, hire staff, build a full menu, and then discover that nobody wants your concept. Or you could test the same core idea with a food truck, a pop-up dinner, or a limited weekly menu. The test is smaller, but the learning is sharper.
That is what a minimum viable product should do. It isolates a business hypothesis and gets real-world feedback fast enough that you can still change direction.
A founder's first job isn't to prove they can build. It's to prove the market cares.
Start with the riskiest assumption
Every startup has one assumption that can kill it early. Sometimes it's demand. Sometimes it's willingness to pay. Sometimes it's whether users can get value without hand-holding. The smartest MVP starts there.
A useful way to frame it is:
| Risk | Better first MVP |
|---|---|
| Nobody wants it | Landing page, waitlist, pre-sales, founder-led outreach |
| Users don't understand the value | Demo video, concierge service, guided onboarding |
| They like it but won't pay | Paid pilot, deposit, narrow paid feature |
| The workflow is messy | Wizard of Oz or manual backend before automation |
If you're moving from idea to execution, a practical companion is this guide to launching startup apps. It helps connect MVP thinking to the realities of shipping something without overbuilding.
The founders who waste the least time don't ask, "What features belong in version one?" They ask, "What belief am I betting this company on, and what's the smallest real test for it?"
Smart MVP Types for Indie Hackers
You don't choose an MVP type because it's trendy. You choose it because it answers a specific question with the least effort and the clearest signal.
Choose the MVP by the question you need answered
Concierge MVP
This works when the product is really a workflow, judgment process, or service that you can deliver manually before you automate it. Instead of building software, you do the work yourself.
Good fit: B2B services, AI-assisted workflows, niche research tools, done-for-you reports.
What you learn: whether the pain is real, whether users value the outcome, and what steps matter.
Wizard of Oz MVP
The frontend looks automated. Behind the scenes, you do the labor manually. This is useful when users need to experience a polished flow, but you don't want to invest in backend systems yet.
Good fit: marketplaces, AI tools, scheduling systems, personalization products.
What you learn: whether the experience creates value before you build the machinery underneath it.
Single-feature MVP
This is the right move when one feature is the whole reason the product exists. If your app needs ten things before anyone gets value, that's usually a warning sign.
Good fit: utilities, browser extensions, reporting tools, developer tools.
What you learn: whether the core action is strong enough to pull people back.
A lot of solo founders pair these models with pre-launch demand tests. If you're considering a funding-first path, this article on crowdfunding an app is useful because it frames validation and support together instead of treating them as separate phases.
To see how founders explain value before full development, this video is worth watching:
A simple way to decide
Some MVP types are better when you need behavior. Others are better when you need money.
- Use a landing page MVP when you need to test messaging, problem awareness, and sign-up intent.
- Use pre-sales or crowdfunding when willingness to pay is the primary question.
- Use concierge when the product depends on trust, nuance, or high-touch delivery.
- Use a video MVP when the concept is easy to explain but expensive to build.
- Use piecemeal tools when existing software can mimic the product well enough for actual usage.
- Use newsletter or email course MVPs when your product is knowledge, curation, or repeat insight.
Build the test that gives you evidence, not the one that flatters your identity as a builder.
A bad sign is picking the MVP type that lets you code the most. A better sign is picking the one that exposes the truth fastest.
MVP vs Prototype vs MMP What Is the Difference
These terms get mashed together, and that confusion creates expensive mistakes. Founders ask a developer for an MVP when they really want a clickable demo. Investors ask for traction when the team only has a prototype. Teams polish a small release like it's market-ready when it's still just a test.
The shortest useful distinction
A prototype is for understanding and communication. It shows how something might work. It may be clickable. It may look real. But it doesn't have to deliver real value.
An MVP is the first real version that provides value in actual use. Productboard defines an MVP as the version that provides "genuine value to users and functions effectively in real-life scenarios," which separates it from prototypes or wireframes that only illustrate a concept. Productboard also notes that the primary output is the learning and data from the experiment at its minimum viable product definition.
An MMP, or minimum marketable product, goes one step further. It's not just usable. It's ready to be presented and sold to a defined market segment without apologizing for every other screen.
Use the right tool for the right uncertainty
A simple analogy helps:
| Asset | What it really is | Best use |
|---|---|---|
| Prototype | A movie set | Show the concept, test flow, align stakeholders |
| MVP | The first scene shown to a real audience | Test actual value and behavior |
| MMP | A short film ready for release | Sell a coherent product to a niche market |
If your uncertainty is usability, a prototype may be enough. If your uncertainty is whether people will use or pay, a prototype isn't enough. You need an MVP. If the uncertainty is whether your niche will adopt something complete enough to spread, then you're moving into MMP territory.
When teams get stuck on terminology, a reference like these definitions for web development reviews can help align everyone on what they're building.
If users can't get real value from it, it's not an MVP. It's prep work.
That distinction matters because each artifact serves a different decision. Use the wrong one, and you'll feel busy while learning very little.
Validating with Minimum Viable Metrics
The modern twist on what is a minimum viable product is simple. Sometimes the strongest MVP isn't software. It's a piece of proof.
Most guides still focus on feature trimming. That matters, but it misses a better question for today's founder: what live evidence would convince a skeptical user, collaborator, or backer that this thing has demand?
According to Atlassian's MVP overview, 70% of startups fail due to lack of market need, and the article notes an emerging shift toward validating with live data such as MRR and Monthly Active Users through verified traction pages before building a full stack. That reference is in Atlassian's guide to the minimum viable product.
Proof beats promises
A founder saying "users love it" isn't very useful. A founder showing pre-sales, active usage, repeat engagement, or steady shipping is much more credible.
In this context, minimum viable metrics become practical. Instead of asking whether the app is complete, ask whether the market signal is strong enough to justify more investment.
Examples of evidence that often matter more than extra features:
- Pre-sales collected through Stripe: people paid before the product was fully built.
- Monthly recurring revenue: not just interest, but ongoing value.
- Monthly active users: people came back and used the thing.
- Weekly commits on GitHub: the product is actively being shipped, not abandoned.
- Email replies or booked calls: users care enough to take a next step.
If you're trying to fund a product before it becomes a full company, this guide on how to get startup funding is useful because it forces the funding question back to evidence instead of storytelling.
What to measure before you build more
Not every metric is useful at every stage. Pick one that matches your current risk.
If the risk is demand, measure sign-ups, pre-orders, or replies from qualified prospects. If the risk is retention, track whether people come back without you chasing them. If the risk is monetization, ask for payment earlier than feels comfortable.
A clean way to think about it:
| Stage | Better proof |
|---|---|
| Idea stage | Waitlist quality, demo requests, pre-sales |
| Early product | Activation, repeat usage, customer feedback tied to behavior |
| Early business | Revenue, active users, retention patterns, shipping consistency |
The mistake is treating screenshots, hype, and opinions as traction. They aren't. Metrics that refresh from real systems are harder to fake and easier to trust.
This is why many modern founders are shifting from "What's the smallest product I can ship?" to "What's the smallest verified signal I can produce?" That question usually leads to better decisions.
Common MVP Mistakes and a Founder's Checklist
The most common MVP failures don't come from lack of effort. They come from building the wrong thing at the wrong fidelity.
The traps that wreck MVPs
M is for Massive
Founders start with "just the essentials" and end up adding onboarding flows, account settings, notifications, permissions, analytics, and templates. They call it discipline, only for the scope to triple.
No real value
This is the opposite problem. The product is so stripped down that nobody can complete the main job. Users don't reject it because they're impatient. They reject it because it doesn't help.
ProductPlan points out the contradiction clearly: an MVP shouldn't merely satisfy users. It must also delight them enough to prove value, and that nuance is often omitted from MVP advice in its article on the minimum viable product.
No success metric
A founder launches, gets a few compliments, and still has no idea whether the test worked. Compliments are pleasant. They are not a decision framework.
Perfectionism disguised as strategy
The founder says they need one more week to improve onboarding, polish the dashboard, or clean up edge cases. What they're often protecting is ego. A rough but usable test teaches more than a beautiful private build.
Broken doesn't validate anything. But neither does polished software that avoids the real question.
A practical checklist before you build
Run this checklist before you write code, hire help, or announce a launch:
- Define the core problem: write one sentence describing the pain you believe exists.
- Name the target user: avoid "everyone" and pick one concrete group.
- Choose the riskiest assumption: demand, willingness to pay, usability, or workflow.
- Pick one viable metric: sign-ups, pre-sales, recurring usage, or another concrete proof point.
- Set the minimum experience: what must work so the user gets genuine value?
- Remove supporting fluff: settings pages, advanced roles, and edge-case polish can wait.
- Decide the feedback channel: email, interviews, usage behavior, or payment behavior.
- Set a stop condition: what result tells you to continue, change direction, or drop it?
A good MVP feels narrow, slightly uncomfortable, and easy to explain. If you can't describe the test in a few sentences, it's probably still too broad.
Your Next Step Is Learning Not Launching
The best founders don't fall in love with the first build. They fall in love with shortening the distance between assumption and evidence.
That's the answer to what is a minimum viable product. It's not a smaller app. It's a disciplined way to learn whether a business idea deserves more effort. Sometimes that does mean shipping software. Sometimes it means a landing page, a manual workflow, a paid pilot, or a traction page built around live proof.
If you're stuck, don't ask what to build next. Ask what you still need to prove. Then design the smallest test that can produce a trustworthy answer.
A lot of founders also underestimate how much community shapes early traction. If you need help thinking through that side of validation, these community engagement strategies are worth reviewing before your next experiment.
Pick one assumption. Pick one metric. Build only enough to learn.
Then let the evidence decide what happens next.
If you're raising support for a SaaS, AI tool, developer product, or early online business, Fundl gives you a practical way to turn traction into your pitch. Instead of leading with promises, you can publish a shareable page built around live, source-verified metrics like recurring revenue, active users, and shipping activity, so backers can judge the project on proof.