You've just been told you need an MVP. The advice is everywhere: "Don't build the full product. Start with an MVP." But when you ask three different advisors what an MVP software actually is, you get three different answers. One says it's a landing page. Another insists it's a working product with one feature. A third warns you that shipping anything less than delightful will kill your brand before it starts.
Here's the real answer: An MVP (Minimum Viable Product) in software is the smallest version of your product that real users can interact with to solve a specific problem, built specifically to test your riskiest business assumptions with actual behavior and feedback. It's not a prototype you click through. It's not your full vision with a few features removed. And it's definitely not a deliberately broken version of your idea. An MVP is a functional product reduced to its core value hypothesis, shipped to real users, with enough quality that people will actually use it long enough for you to learn whether you're solving a problem worth solving.
Key Takeaways
- An MVP is a real, working product that delivers one core value to actual users, built to test whether your fundamental business assumptions are true before you invest in the full vision.
- The minimum in MVP refers to scope and feature count, never to quality, usability, or the reliability of what you do ship.
- A successful MVP typically takes six to twelve weeks to build and costs between thirty and eighty thousand dollars when working with a specialized studio, though this range varies significantly based on technical complexity and integrations.
- Your MVP should focus on one specific job to be done for one specific user segment, with a clear metric that tells you whether that job was completed successfully.
- The biggest mistake founders make is confusing an MVP with a prototype, a beta, or a cheap version, leading them to either spend too little and learn nothing or spend too much and run out of runway before they can iterate.
Why the MVP Definition Gets Mangled
The term minimum viable product was coined to describe a learning strategy, not a development shortcut. Somewhere between Stanford pitch competitions and Medium thought leadership, the definition mutated. Now MVP gets slapped on everything from Figma prototypes to feature-stuffed platforms that took nine months to build.
The confusion stems from three common misinterpretations. First, founders hear minimum and think cheap or fast. Second, they hear viable and assume it means featureful enough to compete. Third, they forget the product part entirely and ship something that can't actually be used to solve the problem.
Here's what separates a true MVP from the imposter versions. A landing page that collects emails? That's a smoke test, and it's useful, but it's not an MVP. A clickable Figma prototype? That's a prototype. A feature-complete SaaS platform with tiered pricing, admin dashboards, and integrations? That's a version one product, and if you haven't validated your assumptions yet, it's a very expensive gamble.
The real purpose of MVP software is hypothesis testing through real use. You have assumptions: users have this problem, they'll use software to solve it, they'll use it this way, and they'll pay this amount. An MVP is the smallest real product that lets actual users prove or disprove those assumptions through their behavior, not their survey responses.
What Should an MVP Actually Include?
Your MVP needs exactly three things, and most founders get at least one of them wrong.
First, one core job to be done. Not three features. Not a workflow. One atomic job that, if completed successfully, would indicate your hypothesis might be true. If you're building project management software, the job isn't "manage projects." It's "let a team see who's doing what today without a meeting." If you're building invoicing software, it's "send a professional invoice and get paid," not "manage client relationships."
Second, the minimum interface and infrastructure for a user to complete that job unassisted. This means authentication if they need to save data. It means a database if state matters. It means enough UI that someone can figure out what to do without you sitting next to them. Minimum does not mean non-functional. It means ruthlessly scoped.
Third, instrumentation to measure whether the job got done. You need to know if users completed the action, how long it took, where they dropped off, and whether they came back. An MVP without analytics is just expensive performance art. You're not shipping it to have a product; you're shipping it to get answers.
Here's what your MVP should not include: multiple user roles until you've proven one role finds value. Customization or settings until you know what the default should be. Integrations with other tools until you've proven the core job is worth doing. Social features until you have users who'd want to be social. Admin dashboards until there's something to administrate. Anything you plan to sell "later" to enterprise customers.
The test: if you removed this feature, would you still be able to measure whether your core hypothesis is true? If yes, remove it.
How Is an MVP Different from a Prototype or Beta?
The terms get used interchangeably in founder circles, but they represent completely different levels of investment and risk.
| Artifact | Purpose | User Interaction | Time to Build | What You Learn | |----------|---------|------------------|---------------|----------------| | Prototype | Visualize concept and test usability | Simulated, click-through only | 1-3 weeks | Does the interface make sense? | | MVP | Test business hypothesis with real use | Fully functional, solves real problem | 6-12 weeks | Will users adopt this solution? | | Beta | Stress-test a nearly complete product | Real use with known missing features | 12-24 weeks | What breaks at scale? What's missing? | | V1 Product | Deliver a competitive, sellable solution | Real use, feature-complete for target segment | 16+ weeks | Can we grow and retain customers? |
A prototype is a simulation. You're testing UI patterns, information architecture, and whether users understand what they're looking at. Prototypes don't save data, process payments, or send emails. They're built in Figma, Framer, or Webflow, and they're hugely valuable for design validation, but they cannot test whether users will actually use your product when it's not you clicking through it with them.
A beta is a nearly finished product released to a limited audience to find bugs, performance issues, and gaps before general availability. You already know the core hypothesis is true. You're not testing whether to build it; you're testing whether you built it right. Beta implies you've committed to the full feature set and you're now debugging and polishing.
An MVP sits between them. It's real software, built with production-grade code, but scoped to answer one or two critical questions before you commit the time and capital to build the rest. In the projects we ship at Sindri, an MVP typically means a functional web application with a database, authentication, one to three user-facing workflows, and basic analytics, deployed to a real environment where users can access it without your involvement.
The litmus test: can a stranger use your MVP on Tuesday to solve a real problem they have, without you in the room, and can you measure on Wednesday whether they succeeded? If no, it's not an MVP yet.
What Does It Actually Cost to Build an MVP Software?
This is where founders either underspend and waste the money, or overspend and run out of runway before learning anything.
Plan for roughly eight to fourteen weeks of development time and a budget between thirty thousand and eighty thousand dollars if you're working with a specialized build studio. Solo freelance developers may quote fifteen to thirty thousand, but the timeline often stretches to four to six months, and the risk of technical debt or an abandoned project is significantly higher. Offshore development shops will quote five to fifteen thousand, and in our experience, fewer than one in ten of those projects results in a launchable product.
The range depends on a few factors. A mobile app costs more than a web app because you're building twice—iOS and Android—and app store compliance adds overhead. An MVP with payment processing, third-party API integrations, or real-time features like chat or notifications will cost more than a CRUD app with forms and lists. If your MVP needs to integrate with legacy enterprise systems or handle regulated data like healthcare or financial information, expect the higher end of the range or beyond.
Here's what should be included in that budget: product scoping and wireframing, UI design for the core workflows, front-end and back-end development, database setup and hosting configuration, basic automated testing, deployment to a staging and production environment, and at least two weeks of post-launch support for bugs and instrumentation adjustments.
Here's what should not be in your MVP budget: custom branding and illustration, content management systems, marketing websites, SEO work, multiple language support, or features you plan to charge for "later." Every dollar spent on scope outside the testable hypothesis is a dollar you can't spend iterating once you have data.
The most expensive mistake is building an MVP in house with a technical co-founder who's learning as they go. It's free in cash, but it costs four to nine months of calendar time, and the opportunity cost of a delayed launch and delayed learning often kills the company before the product ships. If your technical co-founder has shipped production SaaS before, great. If they're learning React and AWS for the first time on your MVP, hire a studio and keep your co-founder focused on the next version.
How Do You Know What Features to Cut?
This is the negotiation that breaks most founding teams. Everyone has a feature they believe is essential. The designer insists the onboarding flow needs six steps. The technical co-founder wants to build the infrastructure to scale to a million users. The business co-founder is convinced you need Stripe, calendar integrations, and email notifications or no one will take it seriously.
Here's the framework that works. Start with your riskiest assumption. Write it down as a single sentence: "We believe [specific user segment] will [specific action] in order to [specific outcome]." Example: "We believe freelance designers will upload and organize their client files in our tool in order to find past project assets faster than searching their desktop."
Now list every feature in your head. For each one, ask: if this feature didn't exist, could that freelance designer still upload a file, organize it, and find it again faster than searching their desktop? If yes, cut it. If no, keep it.
This eliminates roughly seventy percent of the feature list immediately. Onboarding tooltips? The designer can test whether users understand the interface by watching five people use it. Infrastructure for a million users? You'd be thrilled with fifty users in month one. Calendar integrations? The user doesn't need their calendar to upload and find a file.
What's left is the irreducible core. For the file organization example, that's: account creation, file upload, a way to tag or name the file, a way to search or filter, and a way to download or view the result. Five things. Not fifty.
The second filter: can you fake it manually for the first ten users? If you're building a tool that sends weekly reports, you don't need a cron job and email automation in the MVP. You can generate the report manually and email it using Gmail. If users love the report and ask for it to be automated, you've validated the hypothesis. If they ignore it, you saved two weeks of engineering work.
This is called the Wizard of Oz MVP, and it's particularly effective for workflows that involve data processing, content generation, or recommendation engines. Don't build the AI model until you've proven users want the output. Have a human produce the output for twenty users, measure engagement, and build the automation only after you've confirmed the value.
The goal is not to ship the simplest possible product. The goal is to ship the simplest product that can definitively answer whether your riskiest assumption is true or false.
When Is Your MVP Actually Ready to Launch?
Founders delay launch for two reasons: they're embarrassed by how basic it looks, or they're convinced one more feature will make the difference. Both are usually wrong.
Your MVP is ready to launch when these four conditions are met. One, a user can complete the core job without your help or intervention. Two, completing that job provides enough value that the user would consider doing it again. Three, you can measure whether they completed it and whether they came back. Four, the experience is stable enough that a bug or crash won't prevent you from learning.
Notice what's not on the list. "It looks polished." "It has all the features I wish it had." "It feels ready." Your MVP will always feel half-done, because it is half-done. That discomfort is the signal you scoped correctly.
There's a difference between minimum and broken. Broken means the button doesn't work. Minimum means there are only two buttons. Ship minimum. Don't ship broken. If your sign-up form doesn't save the email, that's broken. If your sign-up form doesn't have OAuth or magic links, that's minimum.
A useful heuristic: if you can't describe your MVP's core value in one sentence that a user would understand, you've either scoped too wide or you haven't clarified your hypothesis. "It's a tool that helps teams collaborate" is too vague. "It's a shared checklist so you and your co-founder can see what got done today" is an MVP.
Launch when you're slightly embarrassed but not apologizing. If you feel the need to preface every demo with "we know it's rough, but imagine when we add X," you've scoped correctly. If you're telling users "sorry, this doesn't really work yet," you've launched too early.
The Biggest Mistakes Founders Make with MVPs
Confusing research with progress. Spending twelve weeks in Figma designing sixty screens is not MVP development. Design the three screens you need for the core job, build them, and iterate with real usage data. In the MVP projects we scope at Sindri, design typically represents fifteen to twenty percent of timeline, not fifty.
Building for the imagined customer, not the first customer. Your MVP should solve the problem for the most desperate, least demanding user segment you can find. If you're building invoicing software, don't build for the accounting department at a Series B startup. Build for the solo consultant who's currently sending invoices as PDF attachments from Word. They'll tolerate fewer features because their current solution is worse.
Skipping instrumentation. You shipped an MVP, got fifty signups, and twelve people logged in once. Success or failure? You can't know, because you didn't track what they did. Did they complete the core job? Did they try and fail? Did they get confused and leave? Add event tracking, user session recording, and a feedback mechanism before you write a single line of product code.
Treating the MVP as the product. The MVP is the experiment, not the outcome. Once you've validated or invalidated your hypothesis, your next move is not to polish the MVP. It's to ask what you learned and what the next riskiest assumption is. Sometimes that means throwing away the MVP and rebuilding with a different approach. Founders hate hearing this, but it's far cheaper to throw away eight weeks of work than to spend six months scaling an MVP that validated the wrong hypothesis.
Spending runway on features instead of iterations. A seventy-thousand-dollar MVP that you launch, measure, and iterate twice in twelve weeks will teach you more than a hundred-and-fifty-thousand-dollar feature-complete product that launches once in month six. Founders consistently underestimate the value of speed and overestimate the value of completeness. Your competitive advantage in the first year is not features. It's learning cycles.
Frequently Asked Questions
How long should it take to build an MVP for a SaaS product?
A properly scoped SaaS MVP typically takes six to twelve weeks from kickoff to launch when working with an experienced build team. Solo founders or early technical co-founders building in house should plan for twelve to twenty weeks, accounting for the learning curve and part-time availability. If your MVP is taking longer than sixteen weeks, you've either scoped too wide or you're building infrastructure and polish that belong in a version two product, not an MVP.
Can I build an MVP without a technical co-founder?
Yes, and in many cases you should. Hiring a specialized studio to build your MVP in eight weeks costs thirty to eighty thousand dollars and gets you to launch faster than a non-technical founder could recruit, onboard, and align a technical co-founder. The trade-off is cash for speed and focus. If your runway supports it and your hypotheses are clear, a studio is often the better path than spending four months recruiting or six months learning to code. You can explore how it works to see what the build process looks like with a partner team.
What is the difference between an MVP and a proof of concept?
A proof of concept tests whether something is technically possible, usually for an internal audience. An MVP tests whether real users will adopt a solution to a real problem. If you're asking "can we build a recommendation engine that surfaces relevant products," that's a proof of concept. If you're asking "will users click on the recommended products and make a purchase," that's an MVP. One is a technical question answered with code. The other is a business question answered with user behavior.
Should my MVP include payment processing?
Only if collecting payment is part of your core hypothesis. If your assumption is "users will pay for this solution," then yes, integrate Stripe and charge from day one. If your assumption is "users will adopt this workflow," then no, defer payment until you've proven adoption. Charging too early can reduce your sample size and slow learning. Charging too late can validate a hypothesis that isn't actually your business model. The deciding factor is what you need to learn, not what feels more legitimate.
How many features should an MVP have?
Your MVP should have exactly as many features as required to allow a user to complete the one core job you're testing, and no more. In practice, this usually means one to three user-facing workflows. If your feature list has more than five items, you've scoped too wide. If it has fewer than one complete workflow, you've scoped too narrow and you're likely shipping a prototype instead of a product.
What if users say my MVP is too basic or missing features?
That's exactly the feedback you want. Users telling you what's missing means they understood the core value enough to imagine the next step. Write down every feature request, but don't build them yet. Wait until you see a pattern—three or more users requesting the same capability without prompting. The earliest users will always ask for more. Your job is to distinguish between features that would increase adoption and features that would just make early adopters happier.
An MVP is not a compromise or a shortcut. It's a deliberate strategy to learn before you scale, to test before you invest, and to build conviction with evidence instead of optimism. The best MVPs feel incomplete because they are incomplete. They're scoped to answer one critical question, instrumented to capture the answer, and built fast enough that you have runway left to act on what you learn.
The hard part is not building an MVP. It's resisting the urge to build anything more than an MVP until you know it's the right thing to build. If you're ready to move from hypothesis to working product, the team at Sindri has built dozens of MVPs for founders at this exact stage, and we'd be happy to talk through what yours should include.