On this page
How do you build an MVP?
Build an MVP by validating a meaningful user problem, identifying the riskiest assumption, choosing the first target user, mapping one useful workflow, removing features that do not test that assumption, prototyping where it reduces risk, building the working product responsibly, measuring behaviour, and learning from an appropriate first group of users.
01
Problem
Describe the costly, repeated situation before proposing an app.
02
Assumption
Name the belief that would make the product unwise if it proved false.
03
First user
Choose a narrow person in a real context, not a broad market label.
04
Workflow
Map the smallest complete journey from entry to useful result.
05
Scope
Keep only what lets that journey work and be measured responsibly.
06
Learn
Release to the right people, observe behaviour, and choose the next experiment.
What is a minimum viable product?
A minimum viable product (MVP) is the smallest usable version of a product that lets a team learn something important from real users. “Minimum” refers to scope, not care. “Viable” means the experience is useful enough, trustworthy enough, and complete enough for the kind of test being run.
The expensive mistake is rarely just bad code. It is spending months building the wrong product, wrong features, or wrong workflow before enough has been learned. An MVP is a way to reduce that uncertainty before a larger custom software development investment.
An MVP is
- • A focused test of a product hypothesis
- • A usable path to a meaningful result
- • A way to observe real behaviour
An MVP is not
- • A full roadmap in a cheaper visual design
- • A broken application or a demo without users
- • A guarantee of product-market fit
MVP vs prototype vs proof of concept
These terms are often used interchangeably, but they answer different questions. A project may use all three in sequence; it does not automatically need all three.
| Type | Main question | Users | Typical output |
|---|---|---|---|
| Proof of concept | Can this technical idea work? | Internal or technical team | Technical experiment |
| Prototype | How should the concept work? | Stakeholders or test users | Clickable or visual model |
| MVP | Will people use and value the core solution? | Real target users | Working product or service |
A prototype can test navigation, vocabulary, and sequence. It cannot prove recurring behaviour, a live integration, or willingness to pay. A proof of concept can retire a hard technical risk, but it does not prove that a customer wants the outcome.
Steps 1–4: validate the problem before building too much
1. Define the problem before the product
Ask who experiences the problem, what they do today, how often it happens, what the workaround costs, and who cares enough to change. “Users do not have our app” is not a problem; delayed approvals, error-prone scheduling, or time lost reconciling records can be.
2. Identify the first target user
“Small businesses” and “healthcare companies” are markets, not usable starting points. Be specific about the organisation type, role, context, current tool, pain point, and buyer. For example, an operations manager coordinating assignments at a healthcare staffing company has a more distinct workflow than a broad industry label.
3. Identify the riskiest assumption
The dangerous belief may concern demand (will they try it?), behaviour (will they change their process?), value (does it save enough time or reduce enough risk?), payment, or a difficult technology. Build the first release around the assumption that would make further investment least sensible if it were false.
4. Choose the smallest useful validation method
Interviews reveal how people describe a problem; workflow observation reveals what they actually do. A landing page tests interest in a clear proposition. A manual or concierge service can test whether someone values the result before automation. Prototype tests assess comprehension; a technical proof of concept tests feasibility. Repeated demand from existing customers can be valuable evidence. None independently proves product-market fit—they each reduce a particular uncertainty.
Steps 5–7: define one core workflow and a disciplined scope
A focused MVP has a beginning, an action, an outcome, and a reason to return. Map one user journey: the user signs up or enters, provides the necessary information, performs the core action, sees a useful result, and has a reason to repeat. Do not map every role, exception, and future workflow into the first release.
Entry
How does the user begin?
Action
What must they do?
Result
Where is the value?
Return
Why come back?
Prioritise features by what they enable
Put a feature in Essential only if the core journey cannot work without it. Helpful improves the experience but does not test the assumption. Later can wait until evidence justifies it. This resembles MoSCoW, but no framework removes judgement.
Essential
For a hypothetical appointment SaaS MVP: Account, appointment type, booking link, customer booking, confirmation.
Helpful
For a hypothetical appointment SaaS MVP: Reminders and a simple operational view.
Later
For a hypothetical appointment SaaS MVP: Advanced permissions, complex analytics, multiple providers, marketing automation.
Usually defer advanced customization, multiple languages without a specific need, multiple native apps when a responsive web application works, elaborate reporting, secondary workflows, and speculative scale architecture. Do not defer necessary permissions, data integrity, error handling, observability, or testing.
Prototype before development when it can cheaply test navigation, terminology, form sequence, or information hierarchy. It is not a substitute for testing real performance, production integrations, recurring use, or payment behaviour.
Steps 8–13: choose a technical approach and build responsibly
Choose the approach after understanding the product, users, data, integrations, security, mobile needs, launch constraints, and expected rate of change. A responsive web application is a practical first product for many workflows. Native mobile can be justified by device capabilities or distribution requirements. Low-code can be useful when its limits fit the test. Custom software is appropriate when differentiated workflow is central. The choice is not simply between a web application and a website.
AWS's evolutionary architecture guidance for startup MVPs is a useful reminder: the starting architecture should fit the current stage while leaving a sensible route to evolve. It need not be designed for hypothetical millions of users, but it should not make honest early use unsafe or impossible.
Production-ready means appropriate for the test
If real users create accounts, supply business data, pay money, or depend on the workflow, access control, data integrity, monitoring, recovery considerations, error handling, and testing matter. NIST's Secure Software Development Framework supports treating secure development as a lifecycle practice rather than an end-stage add-on. Follow the basics of authentication, authorization, input validation, and dependency management; an MVP is not a reason to accept preventable risk.
Design the smallest viable data model: users, organisations where relevant, core records, statuses, relationships, history, and permissions. Avoid creating every hypothetical entity, but do not make a “temporary” model that cannot safely support the release. Use established providers for commodity capabilities such as identity, payments, email, file storage, hosting, analytics, and error monitoring when they fit. Keep custom work focused on differentiated value.
For integrations, ask: does this directly enable or measure the core value? If not, delay it. Review how API integration connects business systems when external data or actions are central, and plan sources of truth and failure paths before connecting systems.
Build the path and its edges
Focus development on signup or entry, setup, the core action, the result, and repeat use. Include useful empty states, input validation, status, errors, and a minimum support or admin route. Test functional workflow, permissions, integrations under failure, relevant devices and browsers, critical performance, and real-user acceptance—not only the happy path.
Steps 12–15: instrument, launch, and learn
Add analytics before launch because an MVP without a measurement plan cannot reliably teach you much. Track only what relates to the hypothesis: account created, onboarding started and completed, core action started and completed, important errors, and payment where it matters. Analytics tooling must fit the product’s privacy and security requirements; Google Analytics event guidance is one useful reference for public or appropriate product-event implementation, not a mandate to send sensitive data to GA4.
Start with people who resemble the intended user: internal users, design partners, a controlled pilot, or a small beta before a broad release. Friends and family may validate that an idea sounds nice; they are often weak evidence that the target buyer will change behaviour or pay.
MEASUREMENT FUNNEL
A launch is not success. Look for activation—reaching meaningful first value—then task completion, repeat use, retention, willingness to pay if relevant, support friction, and the qualitative reasons behind both use and abandonment. Avoid calling raw page views, likes, or registrations without usage proof. No universal benchmark makes a product viable; a useful measure is always tied to the original assumption.
Step 16: decide what evidence says to do next
Users get value
Improve reliability and the workflow, then expand carefully.
They understand it but do not care enough
Revisit the problem, target user, or value proposition.
They want a different workflow
Reconsider the scope before adding surrounding features.
Technology limits the product
Improve the specific architectural constraint with evidence.
Evidence is inconclusive
Run a narrower, better-instrumented experiment.
After a successful MVP, the work usually moves from a validated core workflow to product improvement, broader roles, selected integrations, operational tooling, and scale improvements where proven usage requires them. A SaaS product adds account, tenancy, billing, and ongoing-service concerns; see our SaaS product development guide for that next layer.
| Area | MVP | Mature product |
|---|---|---|
| Audience | Focused | Broader |
| Workflow | Core | Multiple |
| Features | Essential | Evidence-led expansion |
| Integrations | Essential | Wider ecosystem |
| Operations | Minimum support path | Mature administration and monitoring |
| Scale | Evidence-based | Proven usage requirements |
MVP development cost and timeline factors
There is no honest universal cost or “six-to-eight-week” timeline for an MVP. Product type, workflows, screens, roles, permissions, mobile requirements, payments, data, integrations, administration, design, quality expectations, infrastructure, and the speed of stakeholder decisions all change the work. A focused web workflow can move very differently from a regulated application or multi-sided marketplace.
Scope discipline is the primary cost-control mechanism; skipping essential engineering practices is not. Our custom software development cost guide explains how estimates are shaped and what to clarify before budgeting.
How scope creep turns an MVP into a roadmap
A request-tracking idea gains chat, reporting, native apps, AI recommendations, and five account types one meeting at a time. Before accepting any addition, ask: “What specific assumption does this help us test before the next release?” If the answer is weak, keep it visible in a later backlog.
Should AI be part of an MVP?
Use AI when it is part of the core value or genuinely improves the workflow being tested—not because it is fashionable. Consider quality, review paths, privacy, latency, cost, and provider dependency. When deterministic rules solve the problem reliably, they can be the better first choice.
12 common MVP mistakes
01
Building before validating
Code begins before anyone has shown a costly need or a willingness to change.
02
Targeting too many users
One release tries to satisfy several incompatible roles and contexts.
03
Building the full roadmap
Future possibilities become requirements for version one.
04
Confusing prototype with MVP
A clickable flow is mistaken for evidence of real use.
05
Technology before value
A stack decision distracts from the customer outcome.
06
Ignoring security
Real data and permissions are treated as optional because the release is small.
07
Every integration
Commodity connections are added before the core workflow is proven.
08
No analytics
The team can say it launched but not what users did.
09
Measuring registrations
Interest is mistaken for activated, repeated value.
10
Wrong early users
Feedback comes from convenient people rather than the target customer.
11
Every request becomes direction
Anecdotes override patterns and the original hypothesis.
12
No post-launch plan
There is no decision rule for improve, pivot, or stop.
MVP readiness checklist
Before development, a team should be able to answer the questions below. If major answers are missing, return to discovery rather than filling the gap with features.
Problem
Who has it, and what happens today?
Customer
Who is the first user, and who pays?
Hypothesis
What assumption are we testing?
Workflow
What is the minimum journey to value?
Scope
Which features are required for that journey?
Success
What evidence justifies continuing?
Technology
What uncertainty must be retired?
Launch
Who are the first appropriate users?
A PRACTICAL NEXT STEP
Have a Product Idea but Not Sure What Version One Should Include?
Start with the user, problem, riskiest assumption, and smallest useful workflow. Those decisions should shape the MVP before a long feature list or technology stack does.
Frequently asked questions
What does MVP stand for?
MVP stands for minimum viable product: the smallest usable product designed to test important assumptions with real users.
What is an MVP in software development?
It is a deliberately scoped working product that supports the core user workflow needed to learn whether the proposed solution creates real value.
How do you build an MVP?
Define the problem, identify the target user and riskiest assumption, map the core workflow, prioritise essential features, prototype where useful, build and instrument the product, test it, launch to real users, and evaluate the evidence.
What is the difference between an MVP and a prototype?
A prototype primarily tests or communicates an experience or concept. An MVP is intended for real target users to validate an important product assumption.
What is the difference between an MVP and a proof of concept?
A proof of concept typically tests technical feasibility, while an MVP tests whether a working product creates enough value for real users.
How many features should an MVP have?
There is no universal number. Include the smallest set that lets users complete the core workflow and lets the team test its important assumption.
Should an MVP have good design?
It needs enough usability and clarity for people to complete the core workflow. It does not need the final mature design system, but poor usability must not invalidate the experiment.
Should an MVP be secure?
Yes. If it handles real accounts, customer information, payments, or business data, appropriate security and data-protection practices remain necessary.
How much does MVP development cost?
There is no universal amount. Cost depends on scope, product type, design, workflows, users, integrations, data, testing, security, infrastructure, and platform requirements.
How long does it take to build an MVP?
Timeline depends on scope and complexity. A focused workflow differs materially from a marketplace, SaaS product, multi-role platform, or native mobile application.
Should I build an MVP before a full product?
For uncertain new products, a focused first release can reduce risk by testing important assumptions before investing in the complete roadmap.
What happens after an MVP?
Use actual behaviour and feedback to improve the core workflow, change direction, expand the audience, strengthen the architecture, or stop investing.
For help assessing a team, read how to choose a software development partner. For products that eventually need portals or connected operational systems, explore business portals, automation and system integration, and examples in our portfolio.