In short
- An MVP is a working product for real users, not a demo or a pitch deck.
- It does one job for one kind of user well, and leaves everything else out on purpose.
- Its purpose is learning: you launch it to find out what to build next.
- Scope decides the price. Write the first release down and the cost becomes predictable.
Also called: MVP, Minimum viable product, First release.
What an MVP is, and what it is not
The word gets used for almost anything early, which is why two quotes for "an MVP" can differ by a factor of ten. A useful definition has three parts. It is a product: people can sign up and use it without you in the room. It is minimum: everything that does not serve the core job is cut. And it is viable: the one job it does, it does well enough that people would choose to come back.
An MVP is not a prototype. A prototype shows how something would work so you can test the idea with a handful of people. An MVP is the real thing, in production, with real data, that strangers can use. Many teams build a prototype first and an MVP second.
From idea to product
- Idea
- Wireframe
- Prototype
- MVP
- Full product
Cheaper to changeMore real
How small is small enough
Small enough means you could build it in weeks, not months, and still learn the thing you most need to know. A practical test is to write down three items before anything is designed.
- One primary user. The person whose problem you are solving first. Not every possible customer.
- One critical workflow. The path that user must complete for the product to be worth anything, from start to finish.
- A release you would actually launch. If you would be embarrassed to put it in front of users, it is not viable yet. If it takes six months, it is not minimum.
Everything outside those three goes on a later list: admin dashboards, a second user type, settings pages, extra platforms. Most of it will look different once you see how people use the first release.
The same three items describe the projects Choie fits best, along with one more: a founder or executive who can make decisions every week.
What can wait
If a feature does not help the primary user finish the critical workflow, it can wait until after launch.
What an MVP usually includes
The core job is the point, but a real product needs a few supporting parts so that people can actually use it. A typical first release of a web or mobile product has these.
| Part | Why it is there | What to keep small |
|---|---|---|
| Sign-up and sign-in | People need an account to come back | One method to start, such as email or Google |
| The critical workflow | This is the reason the product exists | Nothing here, this is where the effort goes |
| Empty, loading, and error states | Real use hits all of them on day one | Plain messages that say what to do next |
| Basic analytics | You launched to learn, so measure it | A few events tied to the workflow |
| Payments, if you charge | Revenue is often the thing to prove | One plan and one way to pay |
Things that are usually left out of a first release include a native app on every platform, a complex admin panel, team accounts, and integrations nobody has asked for yet. Our guide to what an MVP costs lists what tends to be missing from quotes.
How to scope and price an MVP
The price of an MVP follows its scope, so the fastest way to a predictable number is to write the scope down. Platforms, the number of workflows, and integrations such as payments or identity move the cost the most. A written scope of work with a fixed total protects both sides from finding out halfway through that you meant different things.
A common path to a first release
- 01DiscoveryAgree the user and the job
- 02PrototypeTest the risky part
- 03Written scopeFix what is in and out
- 04BuildShip weekly, then launch
- 05LearnDecide what comes next
At Choie, a one-week coded prototype is a fixed $4,900, and a full MVP build of a first web or mobile release starts at $19,000 and takes four to six weeks, both with a written scope first. The details are on the pricing page, and how a project runs walks through the weeks.
Common mistakes
- Building for everyone. A first release that tries to serve three user types serves none of them well.
- Polishing before learning. Weeks spent on animations and edge-case settings before anyone has used the core workflow.
- Skipping measurement. Launching without tracking the workflow means you learn less than you paid for.
- Treating launch as the finish. The MVP is the start of the product. Plan for the changes that follow it.
- Cutting the wrong corners. Minimum applies to features, not to quality. A slow or broken core workflow tests nothing.
Common questions
How long does it take to build an MVP?
For a focused web or mobile product with one primary user and one critical workflow, four to six weeks is realistic. It takes longer when the scope adds platforms, user types, or integrations.
Is an MVP the same as a prototype?
No. A prototype demonstrates how something would work so you can test it with a few people. An MVP is a live product that real users can sign up for and use without help.
Should my MVP be a web app or a mobile app?
Web is usually the smallest first release because one build reaches every device. A native app makes sense first when the core job depends on the phone, such as the camera, location, or notifications.
What happens after the MVP launches?
You watch how people use the core workflow, talk to some of them, and decide what to change, add, or remove. Most products are shaped more by the weeks after launch than the weeks before it. The final week of a Choie build is spent launching, watching real people use the product, and fixing what gets in their way.