| Decision | What the evidence supports | Planning use |
|---|---|---|
| Scope | Build just enough to test key assumptions, not a fully featured product | Cut any feature that does not test an assumption you have named. |
| Build time | Typically 2 to 6 months, depending on product complexity and resources | Plan around complexity and team capacity rather than a fixed launch date. |
| Budget | A few thousand dollars is possible with no-code platforms and lightweight testing | Price a no-code route before commissioning custom development. |
| Features | Must-haves are non-negotiable functionality that directly solves the core problem; should-haves can be added after validation | Ship the must-haves and park everything else until the MVP is validated. |
| Feedback | Collect feedback from real users and analyze performance metrics | Schedule user feedback and metric review before launch, not after it. |
Scope, time and budget figures come from Codelevate’s MVP checklist, while the feature tiers and feedback step come from Codeventures’ MVP checklist.
A minimum viable product checklist should run from problem definition through launch and iteration, building just enough to test key assumptions rather than a fully featured product.
If you are still deciding whether to build at all, read the wider guide on how to start a startup first, then return here to scope the first release.
What an MVP should include
An MVP should include only the essential features and functionality needed to deliver the core benefit. Amplitude describes a minimum viable product as a simplified version of a product that contains only its essential features and functionalities. Nulab puts it as a product or service with just enough features to partially satisfy early customers.
The word “partially” has a practical consequence: completeness is not the test. Early customers can meet gaps, provided the core problem is still solved for them. Everything else is a candidate for removal.
An MVP also needs two things that are not features. The first is a set of success metrics, so you can tell whether the product works. The second is a route for user feedback. Amplitude’s build-measure-learn description has the team build a simple version, measure its performance using metrics and feedback, then decide what to do next. A product that ships without either one cannot teach you anything, however small it is.
- Include the core benefit. The functionality that directly solves the problem you defined belongs in the first release.
- Include a measurement plan. Decide which success metrics will show whether the idea is working before the first user arrives.
- Include a feedback channel. Real users are the source of what works, so give them an obvious way to respond.
- Leave out polish and extras. Anything that does not help test the main assumption can wait.
Prioritizing core features
Prioritizing MVP features starts with a long list and ends with a deliberately short one. Nulab’s advice is to list all possible features and then mercilessly cut anything non-essential. The aim is a product that can be built, launched and judged quickly.
Three screening questions
Nulab suggests three tests for each candidate feature. Keep the feature only if it passes them.
- Does it solve the core problem? A feature that does not help with the problem you defined has no claim on the first release.
- Can users succeed without it, at least for now? If they can, defer it.
- Is it vital for validating the value proposition? If the idea cannot be tested without it, it stays.
Must-have and should-have tiers
Codeventures separates features into tiers. Must-haves are non-negotiable functionalities that directly solve the core problem. Should-haves are important but not immediately critical, and they can be added after the MVP is validated. The sorting is the useful part: a should-have feels urgent during planning, yet the evidence says it does not need to block launch.
Uber is a useful reference for how narrow a first release can be. According to Nulab, its early product was a single-function app that connected iPhone owners with drivers and handled card payment. Everything beyond that single function waited.
Prototyping before you build
A prototype is the cheapest way to check a feature set. Codeventures defines it as a low-cost way to present your MVP concept visually, ranging from sketches to clickable designs. That range gives you a choice. Paper suits an early conversation about layout and flow. A clickable design suits sessions where users try to complete a task.
Codeventures names Figma for interactive design and InVision for clickable mockups used in user testing. Either lets users react to a realistic flow before development spending begins, so a feature that confuses people can be removed while that is still cheap.
Time and budget
An MVP typically takes between 2 to 6 months to build, according to Codelevate, with the exact figure depending on product complexity and resources. Treat that as a planning range rather than a promise. A simple product with a capable team sits differently from a complex one with limited resources, and the checklist cannot settle that for you.
Cost responds to the build method. Codelevate says that using no-code platforms and lightweight testing methods can reduce costs significantly, making it possible to build an MVP for a few thousand dollars. That figure applies to the lean route, not to every MVP.
- Choose a no-code route when the goal is to test whether the core idea attracts users and the product can be assembled from existing platforms.
- Allow the longer end of the range when the product is complex or the team’s capacity is thin.
- Shrink scope before extending the deadline. Cutting a should-have feature is usually cheaper than adding months.
Time and money also connect to how you fund the work. If you are weighing outside capital, Pre-Seed Vs Seed Funding: How To Know Which Round Is Right For Your Startup In 2026 – Startalliance compares the early rounds. If early contributors will be paid partly in ownership, How Startup Equity Really Works: A Practical 2026 Guide To Ownership, Vesting, And Value – Startalliance explains how that works.
Success metrics and testing
You test an MVP by putting it in front of real users and comparing what they do with the success metrics you chose beforehand. Codeventures lists the step plainly: collect feedback from real users and analyze performance metrics. Nulab adds that this is how you learn what actually works, because the answer comes directly from the target audience.
Pick metrics that match the question the MVP is asking. Codeventures gives retention as an example, measured as the percentage of repeat visitors in Google Analytics. A retention figure speaks to whether people come back, which an enthusiastic comment from one user cannot show.
- Behaviour tracking. Google Analytics, Hotjar and Mixpanel help track user behavior and satisfaction, according to Codeventures.
- Direct feedback. Pair the numbers with what users say, since metrics show what happened and feedback helps explain why.
- Prototype testing. Clickable mockups can be put in front of users before launch, so the first round of testing does not need to wait for a finished build.
The build-measure-learn loop
The mechanism behind every item above is a loop. Nulab distils it to build, measure, learn, improve. Amplitude adds that the data gathered from the MVP lets a startup change course if needed or double down with some tweaks, so the MVP is a way of reaching that decision with evidence.
Codeventures describes the iteration step in practical terms: analyze feedback, implement small changes, test them, and repeat the process until the MVP aligns with user expectations. Small changes matter here. If you alter many things at once, the next round of metrics cannot tell you which change did the work.
The same source lays the whole process out as a sequence: define the problem and target audience, identify core features, prototype, develop and launch, collect feedback and measure, iterate, and plan scaling. The checklist below follows that order.
Printable MVP checklist
Copy this list into a document and tick each item before moving to the next stage.
- ☐ Define the problem and audience. Write down the problem and name the people who have it.
- ☐ Identify core features. List all possible features, cut the non-essential ones, and apply the three screening questions.
- ☐ Sort into tiers. Mark must-haves for the first release and move should-haves to the later list.
- ☐ Prototype. Present the concept visually, from sketches to clickable designs, and put it in front of users.
- ☐ Choose success metrics. Decide what you will measure, such as retention, and which tool will record it.
- ☐ Develop and launch. Build only the must-haves, using a no-code route if the idea allows it.
- ☐ Collect feedback and measure. Gather input from real users and analyze the performance metrics.
- ☐ Iterate. Analyze feedback, make small changes, test them, and repeat until the product matches user expectations.
- ☐ Plan scaling. Decide how the product will grow once the evidence supports it.
Frequently asked questions
Does an MVP have to be a working app?
No. Nulab notes that Dropbox started life as a short pitch video explaining the concept to investors, and Codeventures says Airbnb’s founders listed their own apartment to test whether people would pay to stay. Codelevate adds that a prototype can be an MVP if it simulates the core functionality and tests your hypotheses.
What should be settled before starting an MVP?
Amplitude’s readiness list covers a validated problem, an initial idea, enough resources, a commitment to iteration, a market that is ready for the product, and an aligned team. If several of these are missing, resolve them before spending on a build.
When should I change direction instead of refining?
Use the data the MVP produces. Amplitude says startups can change course if needed or double down with some tweaks. If the metrics and feedback show the core problem or audience is wrong, a pivot is the better response than another round of small changes.
