An MVP, or minimum viable product, is the smallest version of a product that real users can use to complete the one job it exists for. It should include a single complete path from start to result, done properly, plus security and backups. Everything else waits until real use shows what is needed.
Two of our own products started much smaller than they are now, on purpose.
Regulars, our loyalty product for shops that are not allowed to advertise, went live as a working product first, with its integrations marked as coming soon. Seal My Record Now began as a single-page screener that answered one question: does Arizona law let this person seal a record or restore their rights. Accounts, saved screenings, service tiers, checkout, and order tracking all came later.
Neither first version was impressive. Both were useful, and both taught us what to build next. That is the point of an MVP.
What is an MVP?
An MVP is a minimum viable product: the smallest version of a product that real people can use to get the one result it exists to deliver. It is released early so that the next decisions are based on what users do, not on what the team guessed they would do.
The two words pull against each other, and both matter. Minimum means you leave out everything that is not needed to deliver that one result. Viable means what remains has to work, for real users, with real data. A demo that falls over when someone types the wrong thing is minimum but not viable.
An MVP is not a cheap version of the final product. It is a narrow version. Narrow and solid beats wide and shaky.
What should an MVP include?
An MVP should include one complete path through the product, from the user's first step to the result they came for, with nothing missing in the middle. It should also include the things users never see but always depend on: sign-in that is secure, data that is backed up, and errors that are handled.
For Seal My Record Now, the complete path was short. A person answers plain questions and gets a straight answer on eligibility. That single page was the product. Accounts came later.
For Regulars, the path was longer: a customer gets a loyalty card, the shop records a visit, and the owner can send a message. The product works with the shop's existing register instead of replacing it. Integrations that were not ready were labeled coming soon instead of being faked or holding up the launch.
How do you cut scope for an MVP?
You cut scope for an MVP by naming the one result the product delivers, tracing the shortest path to it, and removing every feature that is not on that path. What is left gets built properly. What was removed goes on a list, not in the bin.
- Write the one sentence. "A person finds out whether they can seal their record." If you need the word "and" more than once, you have two products.
- Pick one kind of user. Serve the person who has the problem most often. Other roles can be handled by you, manually, at first.
- Trace the path. List every step from arrival to result. Anything a user must do stays. Anything they might do goes on the later list.
- Replace features with labor. If something happens rarely, do it by hand behind the scenes. An email from you is an acceptable version one of a notification system.
- Rent what exists. Payments, email delivery, and sign-in are available from providers. Do not build them.
- Mark what is coming. If users will expect something you have not built, say so in the product. A plain "coming soon" is honest and tells you who asks for it.
After step six, look at the list of removed features. It is usually longer than the list of kept ones. That is a good sign.
What can an MVP leave out, and what can it never leave out?
An MVP can leave out anything that makes the product broader, such as extra roles, settings, reports, and integrations. It can never leave out what makes the product safe to use: security, backups, correct handling of money, and whatever the law requires for your kind of business.
| Fine to leave out at first | Never leave out |
|---|---|
| Second and third user roles | Secure sign-in and permission checks |
| Settings and customization | Backups of user data |
| Reports and dashboards | Correct payment handling, if you charge |
| Most integrations | Legal requirements for your industry |
| Native mobile apps | Clear error messages |
| Automation of rare tasks | A way for users to reach you |
The right-hand column is where shortcuts turn into damage. A missing report costs you nothing. A leaked record or a double charge can end the product. If your business is regulated, check the rules that apply to you before deciding what is optional.
What happens after the MVP launches?
After an MVP launches, you watch what people do and let that set the order of work. The features users ask for, the steps where they give up, and the tasks you keep doing by hand tell you what to build next far more reliably than the original plan.
Seal My Record Now grew from its screener outward. What it added later is what a person needs after getting an answer: save the result, come back to it, order the paperwork, and track the order.
It also tells you what not to build. Some features on the later list never get requested. Leaving them unbuilt is the cheapest work you will ever do. For what the build itself looks like from here, see our software development process, step by step, and for what a first version tends to cost, see how much a custom web app costs.
Frequently asked questions
What is the difference between an MVP and a prototype?
A prototype is built to show or test an idea and is usually thrown away. It may use fake data and skip security. An MVP is released to real users, holds real data, and is meant to be built upon. A prototype answers "would this work?" An MVP answers "do people use it?"
Does an MVP need to look good?
It needs to look trustworthy, which is a lower bar than beautiful. Clean type, consistent spacing, and clear wording are enough. People forgive a plain interface. They do not forgive one that looks broken, especially if you are asking for personal details or payment.
Can you charge money for an MVP?
Yes, and it is often the best test available. Someone paying for a narrow product is stronger evidence than any number of people saying they would. If you charge, payment handling moves into the never-cut column and must work correctly from the first day.
Is an MVP only for startups?
No. Established businesses use the same approach for internal tools and new services. Building the smallest useful version of an intake system or a client portal, then extending it, carries less risk than specifying everything up front and finding out later what staff really needed.
How do you know when an MVP is too small?
It is too small if a user cannot reach the result without your help. Missing extras are fine. A missing step on the main path is not.
If you have an idea and a long feature list, send it to us. We will help you find the one path worth building first.