Minimum Viable Product: What to Build First
A minimum viable product is not a cheaper version of your dream product. It is the smallest thing you can put in front of real users to learn whether your biggest assumption is true. Get that distinction right and you save months of building. This explainer shows you what an MVP really is, how to choose what to build first and how to keep the scope small enough to ship.
Key takeaways
- A minimum viable product exists to answer a question, not to impress. Start by naming the assumption it must test.
- Build the one core job your user hires you for, end to end, and leave almost everything else out.
- Not every MVP needs code: concierge, manual and no-code versions often teach you just as much, faster.
- Decide in advance what result would make you keep going, change course or stop.
Founders often get stuck in one of two traps. Some keep adding features because the product does not feel "ready," and a launch planned for spring slips to autumn. Others ship something so thin that nobody can tell whether it solves the problem at all. A good MVP sits between those extremes: small enough to build quickly, complete enough that a real user can get real value from it.
Early December is a handy moment to plan one. Many teams have a quieter few weeks around the holidays, which makes it a good window to scope the work, sketch it out and line up your first users for January.
What a minimum viable product is (and is not)
The phrase has three words, and each one matters.
- Minimum: the least you can build. Every feature you add costs time and makes it harder to see what is working.
- Viable: it actually solves the core problem for someone. A broken or confusing product teaches you nothing about demand.
- Product: something real people use or pay for, not a slide or a mock-up you only describe.
MVP vs prototype vs beta
| Prototype | MVP | Beta | |
|---|---|---|---|
| Main purpose | Check whether a design or flow makes sense | Learn whether people will use or pay for the core value | Polish a fuller product before a wider launch |
| Who uses it | Testers, often in a guided session | A small group of real target users | A larger group of early users |
| Does it deliver value? | Usually not | Yes, for the core job | Yes, across most features |
A prototype asks "Can people understand this?" An MVP asks "Do people want this enough to use it, come back or pay?" Both are useful; just be clear about which question you are answering.
Common mistake
Treating "MVP" as an excuse for poor quality. Minimum refers to scope, not care. The few things you do build should work reliably and feel respectful of the user's time. A buggy core experience gives you false negatives: people leave because of the bugs, not because the idea is wrong.
Start with the question, not the feature list
The best way to decide what to build first is to decide what you need to learn first. Every product rests on a stack of assumptions. Your MVP should test the riskiest one: the belief that, if wrong, would make everything else irrelevant.
Turn assumptions into a learning goal
Write a single sentence in this shape: "We believe [specific users] will [take a specific action] because [reason]. We will know we are right if [measurable signal] within [time frame]." For example: "We believe independent fitness coaches will send weekly check-in forms to clients through our tool because chasing them by text wastes hours. We will know we are right if at least half of our pilot coaches send forms for four weeks in a row."
That sentence tells you exactly what to build: whatever lets a coach send a check-in form and see responses. It also tells you what not to build yet: payment processing, a mobile app, team accounts and fancy analytics.
Pro tip
If you have not yet tested whether the problem itself is real, do that first with conversations and a simple landing page. An MVP is the next step after you have early evidence of demand, not a substitute for it.
How to scope your MVP step by step
Use this process to cut a long wish list down to something you can ship in weeks rather than months.
- Name the core job. In one sentence, what does the user hire your product to do? Everything in the MVP must serve that job.
- Map the shortest path. Sketch the steps a user takes from first arriving to getting the result. Aim for as few steps as possible.
- List every feature you are tempted to add. Get them all out of your head and onto paper or sticky notes.
- Sort into must, later and never. "Must" means the core job fails without it. Be ruthless; most items belong in "later."
- Fake what you can. For each "must," ask whether a manual process, an off-the-shelf tool or a simple form could stand in for now.
- Set a time box. Decide how many weeks you will spend before putting it in front of users, and cut scope to fit the box rather than stretching the box.
- Define success. Write the signal and threshold from your learning goal at the top of your plan.
An MVP scoping template
Copy this table into a spreadsheet or document and fill in one row per feature idea. The entries below are made-up examples for a check-in tool for fitness coaches.
| Feature idea | Serves the core job? | Decision | Stand-in for now | Revisit when |
|---|---|---|---|---|
| Coach creates and sends a weekly check-in form | Yes, this is the core job | Must | None, build it simply | Already in scope |
| Automatic reminders to clients | Partly | Later | Founder sends reminders by hand each Monday | When pilot coaches ask for it repeatedly |
| In-app payments for coaching packages | No | Never for the MVP | Coaches keep their current payment method | After retention is proven |
The "Stand-in for now" column is where most of your time savings come from. It forces you to ask whether software is really needed yet.
Types of MVP you can build without much code
Many successful products started as something far scrappier than an app. Depending on your idea, one of these may get you to real users faster.
Concierge MVP
You deliver the result personally for a handful of customers. A meal planning startup might write plans by hand for ten paying users. You learn exactly what customers value, because you are doing the work with them.
Behind-the-scenes manual MVP
The customer sees a simple front end, such as a form or a basic page, while you do the work manually behind it. It feels like a product to the user, which tests whether they will use it the way they would use the real thing.
No-code or off-the-shelf MVP
You stitch together existing tools: a form builder, a spreadsheet, a booking tool and email. It is rarely elegant, but it can run a real service for dozens of users while you learn. Check the terms, pricing and privacy policies of any tool that will handle customer data.
Single-feature MVP
You build one feature properly and nothing else. This suits ideas where the core value really does require software, such as a calculation, an integration or something that must run automatically.
Hypothetical example
Imagine Lena, a former bookkeeper who wants to help small cafes forecast how much stock to order each week. Her first plan includes integrations, dashboards and a mobile app. Instead, she starts a concierge MVP: five cafe owners send her last week's sales each Sunday, and she replies on Monday with a simple order list built in a spreadsheet. After six weeks, four of the five are still sending data and two ask to pay. Lena now knows the core job is valuable and which details owners actually read, so her first real build is much smaller and sharper. (This scenario is made up for illustration.)
Launching your MVP and measuring what matters
Once your MVP is ready, keep the launch small and personal. You want a group of users you can talk to, not a crowd you cannot follow up with.
- Recruit deliberately. Invite people who match your target user, ideally those who showed interest earlier through sign-ups or conversations.
- Onboard them yourself. Watch the first session where possible. Every moment of confusion is a clue.
- Track one or two signals. Pick the measures from your learning goal: repeat use, completion of the core task, or willingness to pay. Ignore vanity numbers such as total page views.
- Talk to users every week. Ask what they used, what they skipped and what they did instead.
- Keep a change log. Note every change you make and when, so you can connect changes to results.
Deciding what comes next
At the end of your time box, compare results with your success threshold. If users hit it, start building the "later" features they asked for most. If results are mixed, change one thing, such as the audience, the onboarding or the core flow, and run another short cycle. If nobody uses it even after you remove obvious friction, take that seriously. It may be time to revisit the problem rather than polish the product.
Common mistake
Adding features in response to every request. Early users will ask for many things, and some requests will pull you away from your core job. Log every request, look for patterns across several users and build only what strengthens the main value.
Your MVP action checklist
- Write your riskiest assumption and your learning goal in one sentence
- Name the single core job your product does
- Sketch the shortest path from first visit to result
- List every feature idea and sort it into must, later or never
- Choose a stand-in for each "must" you can fake for now
- Set a time box in weeks and cut scope to fit it
- Recruit a small group of target users and onboard them personally
- Review results against your threshold and decide the next cycle
Frequently asked questions
How long should it take to build an MVP?
There is no fixed rule, but the point is to learn fast. Many founders set a time box of a few weeks and cut scope to fit. If your plan stretches to many months, look again for features to remove or steps you can do by hand.
Should I charge for my MVP?
If willingness to pay is one of your big assumptions, charging even a small amount is one of the clearest tests you can run. Free users can tell you whether the product is useful, but paying users tell you whether it is valuable.
Do I need a technical co-founder to build an MVP?
Not always. Concierge, manual and no-code MVPs can be run by non-technical founders. If the core value truly depends on custom software, you will need technical help eventually, whether that is a co-founder, a hire or a contractor.
Related reading
The bottom line
A minimum viable product is a learning tool. Start with the riskiest assumption, build only what the core job needs, fake the rest with manual work or simple tools, and put it in front of a small group of real users with a clear success threshold.
Use the quieter weeks of December to write your learning goal and fill in the scoping table. If you can start the new year with users in your MVP, you will be learning while others are still planning.
