An MVP is the smallest version of your product that solves a real problem for real users
A minimum viable product (MVP) is a working version of your software that does one thing well, nothing more. It has the core feature your users actually need — not ten features you think they might want someday. You build it, put it in front of real people, watch what they do with it, and learn what to build next.
The point is not to launch something polished. The point is to stop guessing about what people want and start watching what they actually use. An MVP takes weeks or months to build, not years. It costs less money and less time than building the "complete" version you imagined. And it tells you whether you are solving a problem anyone cares about before you have spent a year building the wrong thing.
Key Takeaways
- An MVP includes only the core feature that solves your user's main problem, and nothing else — no fancy design, no secondary features, no admin dashboard unless users need it to work.
- You decide what to cut by asking: would the product break without this? If the answer is no, it does not belong in the MVP.
- The first users of an MVP are usually people who already know the problem exists, not strangers who need convincing — find them through communities, forums, or direct outreach.
- You learn from an MVP by watching what users actually do, not by asking them what they want — usage patterns tell you what matters.
- An MVP fails when you build it in isolation without talking to users, or when you treat it as a finished product instead of a learning tool.
Decide what your core feature actually is
Start by naming the one problem your product solves. Not "helps small businesses run better" — that is too big. "Lets a freelancer invoice clients in under two minutes" — that is specific enough to build toward.
Write down every feature you think the product needs. Then cross out everything except the feature that makes the product do that one job. A invoicing tool's core feature is creating and sending an invoice. Not storing client history, not generating tax reports, not accepting payments — those come later. If you remove the core feature, the product stops working. If you remove anything else, it still works, just with less polish.
This is harder than it sounds because you will think of things users might want. A calendar integration. A mobile app. An API for accountants. Write them down in a separate list. They are not for the MVP. They are for version 2, after you know people actually want version 1.
Build only what users need to test your assumption
Your assumption is: people have this problem, and they will use my solution. An MVP tests that assumption with the smallest amount of code. If your assumption is wrong, you want to find out after two weeks of work, not two months.
This means cutting things that feel essential but are not. A beautiful interface is not essential — a working one is. A database that scales to a million users is not essential — a database that works for fifty is. User accounts with password reset emails are not essential if you can manually create accounts for the first ten people. Automated billing is not essential if you can invoice people by hand.
The rule: if you can do it manually or with a workaround, do not automate it yet. Automation is a feature. It is not part of the MVP unless users cannot use the product without it.
Find your first users before you finish building
Do not wait until the product is perfect to show it to people. Show it while you are still building. The first users of an MVP are not random people — they are people who already know the problem exists because they live with it every day. A freelancer who spends an hour invoicing each client. A small restaurant owner who tracks reservations in a notebook. A teacher who manually grades papers on weekends.
Find them in places where they gather: Reddit communities, Slack groups, Facebook groups, industry forums, Twitter, LinkedIn. Tell them what you are building and why. Ask if they would test it. Most will say no. Some will say yes. Those people are your MVP users.
You need maybe five to ten of them. Not hundreds. You are not trying to launch a product. You are trying to learn whether your idea works. Five people using something and telling you what breaks teaches you more than a hundred people clicking around a polished demo.
Watch what users do, not what they say they want
When you give your MVP to users, resist the urge to ask them what they think. Instead, watch them use it. Where do they get stuck? What do they try to do that does not work? What do they ignore? What do they use over and over?
People are often wrong about what they want. They will tell you they want a feature you did not build. Then you build it and they never use it. But if you watch them use the product, you see what actually matters. They click the same button five times. They get confused by the same screen. They ask the same question. That is real feedback.
Take notes. Ask them to think out loud while they use it. Ask them what they expected to happen when they clicked something. Ask them whether they would pay for this. Do not ask them whether they like it — that is too vague and too polite.
Decide what to build next based on what you learned
After five to ten users have tested your MVP, you will see patterns. Maybe everyone gets stuck on the same screen. Maybe everyone asks for the same missing feature. Maybe nobody uses the part you thought was essential. Maybe people use it in a way you did not expect.
That feedback tells you what to build next. Not what you imagined. Not what your investors want. What your users actually need to make the product useful to them. You might add a feature. You might remove one. You might change how something works. You might discover your assumption was wrong and pivot to a different problem.
This is the whole point of an MVP. You learn fast, you change direction fast, and you do not waste months building the wrong thing.
Common reasons MVPs fail
An MVP fails when you build it without talking to users first. You guess at what the problem is, build a solution to your guess, and discover nobody wanted it. Talk to users before you write code. Ask them about the problem. Watch them try to solve it today. Then build toward that.
An MVP fails when you treat it as a finished product. You polish it, add features, optimize it, and by the time you launch it is no longer minimal. You have spent three months building and you still do not know if anyone wants it. Stop when it works. Launch when it works. Learn from real users, not from your imagination.
An MVP fails when you do not talk to users after you launch it. You build it, put it online, and wait for feedback. Nobody uses it because nobody knows it exists. You have to reach out. You have to ask people to try it. You have to watch them use it and ask questions. An MVP is not a product you launch and hope for — it is a conversation with users about whether you are solving the right problem.
Frequently Asked Questions
How long should it take to build an MVP?
Most MVPs take four to twelve weeks if you are working full-time and you have already decided what the core feature is. If you are working part-time, add time. If you are still figuring out what problem you are solving, start there before you code — that conversation with users takes two to four weeks and saves you months of building the wrong thing.
Should an MVP look polished?
No. It should be clean enough that users can figure out how to use it, but you do not need professional design, animations, or a mobile app. A working website with a clear button that says what it does is enough. Users testing an MVP care about whether it solves their problem, not whether it looks like a startup.
What if nobody wants to test my MVP?
That usually means you have not found the right users yet. They are not in the communities you looked in, or they do not believe you actually want their feedback. Try reaching out directly to people you know have the problem. Offer to buy them coffee. Offer to pay them for their time. Make it straightforward for them to say yes.
Can I charge money for an MVP?
You can, but most people do not. Charging money means users expect a finished product and customer support. An MVP is a learning tool. Most founders charge nothing for the first version, learn from users, and charge for version 2 after they know what people actually want.
What if my MVP users ask for a feature I did not plan?
Write it down. Ask them how often they need it and whether they would stop using the product without it. If five users ask for the same thing, it might belong in version 2. If one person asks for it, it probably does not. Let the patterns guide you, not individual requests.