How to Build an MVP: A Step-by-Step Guide to the Minimum Viable Product Approach

To build an MVP (minimum viable product), start with the one assumption that would sink your product if it were wrong, then build the smallest release that real users can use to prove or disprove it. In practice that means nine steps: define the problem and the riskiest assumption, study competing products, list capabilities, cut them to a core with a prioritization method such as MoSCoW or RICE, check your resources, fix a release date and success metrics, prototype, build in short iterations, and launch to measure and decide whether to persevere or pivot. The rest of this guide shows how to do each step well.

What is an MVP, and what is it not?

A minimum viable product is the simplest version of a software product that delivers enough value for early users to use it for real, so the team can learn what those users actually want before investing heavily. The term was popularized by the Lean Startup movement, where the MVP is the first turn of a build, measure, learn loop: you build something small, measure how people behave with it, and learn whether your idea holds up.

The two words that matter most are “minimum” and “viable”. Minimum means you remove everything that does not help you answer the core question. Viable means what is left must still work well enough that users get value from it. An MVP that is minimum but not viable (buggy, confusing, missing the one thing users came for) teaches you nothing, because users leave for reasons that have nothing to do with your idea. An MVP that is viable but not minimum takes so long to build that you lose the main benefit: fast learning.

Teams often mix up the MVP with neighbouring concepts. The table below separates them by the question each one answers.

Concept	Question it answers	Who uses it	Typical form	Is it released to the market?
Proof of concept (PoC)	Can this be built? Does the technology work?	Internal engineers, technical stakeholders	Throwaway code, a spike, an integration test	No
Prototype	Does the flow make sense? Do users understand it?	Stakeholders, test users in sessions	Clickable wireframes or UI mockups	No
Minimum viable product (MVP)	Will real users use this and get value from it?	Early adopters, a pilot group	Working software with a narrow core feature set	Yes, to a limited audience
Minimum lovable product (MLP)	Will users enjoy it enough to recommend it?	Early adopters	An MVP with extra polish on the core experience	Yes
Minimum marketable product (MMP)	Is it ready to sell and support at scale?	The target market	The smallest feature set that can be marketed and sold	Yes, broadly

A common sequence is PoC (only if there is technical risk), then prototype, then MVP, then MMP. SupremeTech’s own software product development process follows the same logic: wireframes and prototypes come out of a design sprint, and releases move in stages from proof of concept to MVP, beta and official launch, with market feedback flowing back into development at each stage.

Why build an MVP first? What the data says

The strongest argument for an MVP is that most products fail for market reasons, not technical ones. Three data points make the case.

• Product-market fit kills more products than code does. CB Insights analyzed 431 VC-backed companies that shut down since 2023 and could identify failure reasons for 385 of them. In its 2026 report on why startups fail, 70% ran out of capital and 43% cited poor product-market fit (companies could cite more than one reason). Running out of money and building the wrong product are often the same story told twice: money is spent before the product is proven.
• Most features go unused. Pendo’s 2019 Feature Adoption Report, based on 615 Pendo subscriptions over three months, found that 80% of features in the average software product are rarely or never used, and that an average of 12% of features generate 80% of daily usage volume. If you cannot predict which 12% will matter, the cheapest way to find out is to ship a small core and watch.
• Scaling too early is a leading cause of failure. The Startup Genome report on premature scaling, which studied more than 3,200 high-growth technology startups, found that 74% of high-growth internet startups fail due to premature scaling. It also found that startups that pivot once or twice are 52% less likely to scale prematurely. An MVP is the mechanism that makes an early, cheap pivot possible.

Types of MVP: choose the one that answers your question

Not every MVP needs to be coded. The right type depends on which assumption you are testing. Testing demand (“will anyone want this?”) needs something very different from testing retention (“will people come back every week?”).

MVP type	How it works	Best for testing	Build effort	Main limitation
Landing page MVP	A page describes the product and asks visitors to sign up, join a waitlist or pre-order	Demand and messaging	Very low	Shows interest, not real usage
Concierge MVP	The team delivers the service manually and openly to a few customers	Whether the outcome is valuable enough to pay for	Low in code, high in team time	Does not scale; does not test the software experience
Wizard of Oz MVP	Users see what looks like an automated product, but people do the work behind the scenes	Whether users want the automated experience before you automate it	Low to medium	Ethical care needed with user data; manual work hides real costs
No-code or low-code MVP	The product is assembled from a no-code builder, forms, spreadsheets and automation tools	Workflows, early usage and willingness to pay	Low to medium	Limits on performance, integrations and data ownership
Piecemeal MVP	Existing services (payments, messaging, maps) are stitched together with a thin layer of custom code	A real product experience at low build cost	Medium	Dependence on third-party services
Single-feature coded MVP	Custom software that does one core job well	Retention, repeated usage and technical scalability	Medium to high	The most expensive option; only worth it once demand is plausible

How to build an MVP in 9 steps

The nine steps below expand the four classic steps of the MVP approach (list the capabilities, ascertain your resources, examine competitors and set a timeframe) into a full process, from the first assumption to the decision after launch.

Step 1: Define the problem, the user and the riskiest assumption

Start with assumptions about your users, not with features. Write down who the user is, what problem they have, how they solve it today and why your product would be better. Then list every assumption your idea depends on and rank them by two factors: how much damage it would do if the assumption were wrong, and how little evidence you have for it today.

The top item on that list is your riskiest assumption, and the MVP exists to test it. Typical examples:

• “Field sales staff will log visits on their phone if it takes under 30 seconds.”
• “Restaurant owners will pay monthly for automated table reordering.”
• “Travellers want to record trips on a map and share them, not just store photos.”

Turn the assumption into a testable hypothesis with a number: “At least 40% of pilot users will log a visit three days in a row in the first two weeks.” The number is your own target, chosen before launch, and it is what makes Step 9 a decision rather than a debate.

Step 2: Examine competing products

Before deciding scope, study what users already use, including spreadsheets, manual processes and direct competitors. This tells you two things. First, the baseline: some features are table stakes, and an MVP without them will be judged unusable regardless of your unique idea. A booking app without a confirmation message, for example, feels broken. Second, the gap: where existing products frustrate users, which is where your MVP should differentiate.

A practical way to do this is a short competitor grid: list three to five alternatives, the core job each one does, what users praise in reviews and what they complain about. Complaints that repeat across products are strong candidates for your core feature.

Step 3: List the desired capabilities, then separate the core from the extras

Now brainstorm everything the product could do. Write it down freely; cutting comes next. Map the list onto the main user journey: the steps a user takes from first contact to getting value. Features that sit directly on that path are candidates for the MVP. Features that sit off the path (settings, advanced reports, social sharing, admin dashboards beyond the basics) usually wait.

User story mapping is the most useful technique here. Lay out the journey left to right as activities (sign up, create, share, review), list the user stories under each activity, then draw a horizontal line. Everything above the line is the thinnest slice that still completes the journey end to end. That slice is your first release.

Step 4: Prioritize with a method, not with opinions

Scope arguments are where MVPs grow into full products. A shared prioritization method keeps the discussion on evidence. The three most useful methods are compared below.

Method	How it works	Best when	Watch out for
MoSCoW	Sort each feature into Must have, Should have, Could have and Won’t have (this time)	You need a quick, shared agreement with stakeholders	Everything drifts into “Must”. Limit Musts to what the core journey cannot work without
RICE	Score each feature: (Reach × Impact × Confidence) ÷ Effort	You have many candidate features and some data on usage or reach	False precision; the scores are estimates, so use them to rank, not to prove
Kano model	Classify features as basic expectations, performance features or delighters, based on user surveys	You need to know which features users expect versus which would surprise them	Needs real user input; guessing the categories defeats the purpose

A simple rule works well alongside any method: for every feature, ask “If we leave this out, can a user still complete the core journey and can we still test the hypothesis?” If the answer is yes, it is not part of the MVP.

Step 5: Ascertain the resources available

The next step is to be honest about budget, people and time. Get estimates from the people who will do the work: developers, designers, QA and, if the MVP needs promotion to reach users, marketers. These estimates do two jobs. They tell you whether the scope from Step 4 fits your budget, and they give you a credible number for fundraising or internal approval.

If the estimate does not fit, cut scope rather than quality or testing. This is also where you decide which MVP type from the earlier table is realistic. A team with no developers and a small budget may start with a concierge or no-code MVP and move to code once demand is proven. For a detailed method, see our guide on how to estimate software project costs.

Step 6: Set a timeframe and define success before you build

Fix a release date and treat it as firm. A deadline forces scope decisions, lets you line up marketing, infrastructure and support, and stops the MVP from drifting. When new ideas arrive mid-build, the deadline gives you a polite answer: “Great idea, it goes on the list for after launch.”

At the same time, define your success criteria: the metric, the target and the date by which you will judge it. For example: “By eight weeks after launch, 30% of activated users return in week four.” Also define the opposite: what result would make you pivot or stop. Writing both down before launch protects the team from moving the goalposts once the data arrives.

For how an MVP fits into a wider project plan with phases and milestones, see how to plan a software project and our guide to software development milestones.

Step 7: Design and prototype the core journey

Before writing production code, turn the core journey into wireframes and then a clickable prototype. Put it in front of five or so target users and watch them try to complete the main task. You will find confusing steps, missing information and wrong labels in hours, which would take weeks to discover after the build.

Step 8: Build in short iterations and test as you go

Build the MVP in short cycles, typically one or two weeks, each ending with working software that the product owner reviews. Short cycles surface misunderstandings early and let you cut scope gradually if the schedule slips, instead of discovering at the end that nothing is finished.

Technical choices for an MVP should favour speed without creating a dead end:

• Use proven, mainstream technology your team knows well. An MVP is not the place to experiment with a new framework.
• Use managed services for authentication, payments, notifications, maps and hosting instead of building them.
• Choose cross-platform frameworks (for example Flutter or React Native) when you need both iOS and Android early, so one codebase serves both.
• Add analytics from day one. Every event tied to your success metric must be tracked before launch, not added afterwards.

Do not skip testing. Automated tests on the core journey, a round of manual QA and a short beta with friendly users will catch the bugs that would otherwise make users leave for the wrong reason. Security basics also belong in the MVP: protected logins, encrypted connections and careful handling of personal data are not optional, especially for business users.

Step 9: Launch, measure, learn and decide

Launch to a defined audience, not to everyone. A pilot group, a single city, one customer’s team or a waitlist cohort gives you clean data and a manageable support load. Then run the build, measure, learn loop deliberately:

1. Measure the metrics you defined in Step 6, every week.
2. Talk to users, especially the ones who stopped using the product. Numbers tell you what happened; conversations tell you why.
3. Decide on the date you set: persevere (the hypothesis holds, so keep building), pivot (change one major element, such as the user segment, the core feature or the pricing model) or stop.
4. Repeat. The next release tests the next riskiest assumption.

Be willing to pivot when feedback contradicts your assumptions. The point of the MVP is to find this out early, while change is still cheap.

Worked example: prioritizing an MVP backlog with RICE

The example below is hypothetical, to show how the method works. Imagine a B2B app that lets field technicians log equipment inspections on their phone. The riskiest assumption is that technicians will replace paper forms with the app if logging takes under two minutes. The team scores six candidate features (Reach = technicians affected per month in the pilot; Impact on a scale of 0.5 to 3; Confidence as a percentage; Effort in person-weeks).

Feature	Reach	Impact	Confidence	Effort	RICE score	Decision
Inspection form with photo capture	50	3	90%	3	45	MVP
Offline mode with later sync	40	2	80%	3	21.3	MVP (sites often lack signal)
Supervisor approval screen	10	2	80%	2	8	MVP, simple version
PDF report export	10	1	70%	2	3.5	Later
Dashboard with charts	5	1	50%	4	0.6	Later
Chat between technicians	50	0.5	30%	4	1.9	Won’t have (this time)

Two lessons come out of this. First, the scores guide the conversation, but judgment still matters: offline mode scores lower than the form, yet without it the core journey fails on sites with poor signal, so it stays in. Second, low-confidence ideas such as chat are better tested cheaply later (for example by asking pilot users whether they would use it) than built now.

How long does it take to build an MVP?

There is no honest single answer, because timeline depends on the MVP type, the number of platforms, integrations and the team. A landing page or concierge MVP can be running in days. A no-code MVP typically takes weeks. A coded MVP for a mobile or web product usually takes a few months. What keeps the timeline under control is not speed of coding but discipline about scope.

A real reference point: for JTB’s travel app Notabi, SupremeTech completed the MVP in five months, on plan, starting in July 2023. After JTB reviewed it, the team spent about three more months on additional features, and the app reached official release in April 2024, about nine months after the project began. Monthly updates have continued since launch.

The sample plan below shows how a 12-week coded MVP is often structured. It is illustrative only; your phases will stretch or shrink with scope.

Weeks	Phase	Main activities	Output
1 to 2	Discovery	User interviews, competitor grid, assumption ranking, success metrics, rough estimate	Hypothesis, scope line, success criteria
3 to 4	Design sprint	User journey, wireframes, clickable prototype, usability tests, technical design	Validated prototype, architecture outline, backlog
5 to 10	Build	Two-week iterations with reviews, automated tests, analytics events, security basics	Working MVP in a staging environment
11	Stabilize	QA, beta with friendly users, bug fixes, store submission if mobile	Release candidate
12	Launch	Release to pilot audience, onboarding, support set-up	Live MVP and first usage data
13 onward	Learn	Weekly metric reviews, user calls, decision on the agreed date	Persevere, pivot or stop

Who should build your MVP?

The build approach affects speed, cost, quality and what happens after launch. Each option suits a different situation.

Option	Strengths	Weaknesses	Best for
Founders build it themselves with no-code tools	Lowest cost, fastest start, full control	Limits on scale and integrations; founder time diverted from customers	Very early demand and workflow tests
In-house team	Deep product knowledge, long-term ownership	Hiring takes months; a full team is costly before the idea is proven	Companies that already have engineers available
Freelancers	Flexible, can be cheap for small scopes	Coordination falls on you; gaps in QA, design or project management are common	Small, well-defined MVPs with a technical lead on your side
Software development partner	A complete team (PM, BA, design, development, QA) from day one; proven process	Needs clear communication and a good partner selection process	Coded MVPs where speed and production quality both matter, and corporate new-business projects

If you choose a partner, look for one that will challenge your scope rather than simply build whatever is on the list, and that has a clear plan for what happens after launch: iteration, maintenance and, if you want, handover to an in-house team. Our guide on how to choose a software development company covers the selection process in detail, and how to outsource app development covers the app-specific side.

SupremeTech builds MVPs as part of its product development process, from initiation and design sprint through agile development and staged releases. The company is based in Da Nang, Vietnam, with a presence in Tokyo, is ISO/IEC 27001 certified, and has business analysts who speak Japanese and join requirement meetings with clients directly, which matters when an MVP’s scope is being negotiated week by week. [SupremeTech detail: typical MVP team composition or engagement length the team recommends, if the marketing team wants to state one.]

Which metrics prove an MVP is working?

Pick a small number of metrics tied directly to your hypothesis. Vanity metrics such as total downloads or page views feel good but rarely answer the question. The table groups useful metrics by what they tell you.

Question	Metric	How to measure
Do people want it?	Sign-up or waitlist conversion rate	Visitors who sign up ÷ visitors to the landing page
Do they reach the value?	Activation rate	Users who complete the core action at least once ÷ users who signed up
Do they come back?	Retention by cohort (week 1, week 4)	Share of each sign-up cohort still active after N weeks
Do they like it?	Qualitative feedback, satisfaction score	Short in-app survey, interviews with active and churned users
Will they pay?	Conversion to paid, pre-orders, letters of intent	Payments, signed pilots, purchase orders

After the MVP: from learning to scaling

When the data supports the hypothesis, the work shifts from learning to building a product that can be sold and supported widely. The typical path:

• Harden the foundations. Pay down the shortcuts you took on purpose: add tests, improve monitoring, review the architecture against expected load.
• Expand toward an MMP. Add the “Should have” features that users asked for most, guided by the usage data, not by the original wish list.
• Scale gradually. Grow the audience step by step and watch whether retention holds as users become less like your early adopters. The Startup Genome data on premature scaling is a reminder not to pour money into acquisition before the product keeps the users it already has.

Plan the post-MVP roadmap in milestones rather than as one long build; our article on software development milestones explains how to set them.

MVP example: how Notabi went from MVP to official launch

JTB Corporation, a Japanese travel company founded in 1912, wanted to launch Notabi, a social app for recording, sharing and discovering travel memories, as a new business. The brief combined three challenges that are typical of an MVP: get the idea to market quickly, keep improving features after launch based on user feedback, and build a technical foundation that supports operations, maintenance and growth.

SupremeTech covered requirements definition, development, release and maintenance. The core features were map-based logging of travel experiences, albums that combine photos and text, sharing and discovering other users’ experiences, and community features for users with shared interests. The app was built with Flutter, so one codebase serves both iOS and Android, with a NestJS backend and Google Maps API for location services.

The way the project ran is as instructive as the result. Product reviews happened every two weeks, alongside daily and weekly meetings, so JTB could see and steer the product continuously. The MVP was completed in five months, on plan. JTB then reviewed it, and the next roughly three months went into features informed by that review, before official release in April 2024. Since launch, the app has received monthly updates. You can read the full story in the Notabi travel app case study for JTB.

[SupremeTech detail: one concrete scope decision from the Notabi MVP, such as a feature that was deliberately moved to after the MVP, and why.]

Building an MVP with AI-assisted development

AI coding assistants and generative AI tools are changing how fast an MVP can be built, but not what makes it succeed. Used well, they help in several places:

• Discovery: summarizing interview notes, clustering user feedback and drafting user stories for the team to refine.
• Development: producing boilerplate, test cases and documentation, and helping developers understand unfamiliar libraries.

The risks are real too. AI-generated code still needs review for security, licensing and maintainability, and it is easy to add features faster than you can learn from them, which defeats the purpose of an MVP. Faster building makes scope discipline more important, not less. If your MVP itself includes AI features, test the riskiest assumption early: whether the output quality is good enough for users to trust, using real examples from your domain. SupremeTech’s approach to AI-driven development combines these tools with human review at each stage.

Common MVP mistakes and how to avoid them

Most MVP failures come from a handful of repeat mistakes. Several of them are specific versions of the general problems covered in our article on common software development mistakes.

Mistake	What it looks like	How to avoid it
Building a small version of the full product	Every module is present but shallow	Build the thinnest slice of one journey, end to end, not a little of everything
No clear hypothesis	The team launches and “sees what happens”	Write the riskiest assumption and success criteria before the build (Steps 1 and 6)
Minimum but not viable	Bugs, slow screens or confusing flows drive users away	Protect quality and testing on the core journey; cut features instead
Scope creep	New ideas keep entering the sprint; the release date slips	Fixed release date; a “later” list for every new idea
No analytics	After launch, nobody can say how users behave	Track every event tied to the success metric before launch
Scaling too early	Heavy marketing spend before retention is proven	Scale only after cohorts show users stay

MVP readiness checklist

Use this checklist before you start building, and again before launch.

Before the build

• The target user and the problem are written in one or two sentences.
• The riskiest assumption is identified and written as a hypothesis with a number.
• The MVP type matches the assumption being tested.
• The core journey is mapped and the scope line is drawn.
• Features are prioritized with an agreed method, and “Won’t have” items are written down.
• Estimates come from the people doing the work and fit the budget.
• The release date and success and failure criteria are agreed.

Before launch

• Usability tests on the prototype are done and the main issues fixed.
• The core journey works end to end and passes QA.
• Analytics events for every success metric are firing correctly.
• Security basics are in place: authentication, encrypted connections, personal data handling.
• The pilot audience, onboarding and support channel are ready.
• The decision date is in the calendar.

Four principles to keep in mind

Whatever the product, the MVP approach rests on four principles.

1. Start with assumptions about your users. Every product idea is a set of guesses about people. Name them.
2. Build the MVP to reflect those assumptions. Every feature in the MVP should exist to test one of them.
3. Be willing to pivot. When feedback contradicts your assumptions, change direction early, while it is still cheap.
4. Keep the process repeatable. Building, measuring and learning is a loop, not a one-off event. Each release tests the next riskiest assumption.

Conclusion: build to learn, then build to scale

Building an MVP is less about writing code fast and more about asking the right question with the least effort. Name the riskiest assumption, choose the MVP type that tests it, cut scope with a method, fix the date and the success criteria, and then let real users tell you what to do next. The data on startup failure, unused features and premature scaling all point the same way: the products that succeed are the ones that learn before they scale.

If you are planning an MVP and want a team that can take it from discovery to launch and beyond, explore SupremeTech’s software product development process or book a free consultation.

Frequently asked questions