What Is an MVP and How Small Should Version One Be?
Learn what an MVP really is, how small your first version should be, and how to scope one you can ship in weeks, with examples and a simple checklist.
What is an MVP, and how small should the first version be? An MVP, or minimum viable product, is the smallest thing you can put in front of a real person that teaches you whether your idea is worth building. It is a tool for learning, not a cheap launch. This guide gives you a rule for cutting yours down and a way to know when it is working.
What is an MVP? A plain definition
An MVP is the smallest version of a product that lets you test your riskiest assumption with real users. The word "viable" matters. It has to work well enough that someone could use it and tell you something true. The word "minimum" matters just as much. Anything that does not help you learn gets left out.
The idea sits inside a loop: build something small, measure what people do, learn from it, then decide what to do next. The lesson "The MVP and the Build-Measure-Learn Loop" in the Launch, Price and Get Paid course on AI Entrepreneur frames it as shipping the smallest thing that teaches you something. The product is a means. The answer is the goal.
What an MVP is not
People get this wrong in a few common ways.
- It is not a broken product. Small is fine. Unusable is not. If people cannot finish the one thing it does, you learn nothing about demand.
- It is not a full product with a few features removed. If you start from your dream product and trim, the result is often still too large.
- It is not a launch. You are not trying to impress the market. You are trying to get an answer.
- It is not a demo for friends. Polite feedback from people who like you is weak evidence. You want people who have the problem.
How small should the first version be?
Smaller than feels comfortable. A good test: could you build it in days, not months? If the answer is no, cut more.
Size should follow the question you need answered. Ask yourself what you are most unsure about. Maybe it is whether anyone has the problem. Maybe it is whether they would pay. Maybe it is whether the AI output is good enough. Build only what answers that one question.
Before you size anything, make sure the problem is real. The Business Basics for Builders course starts with "Problems Worth Paying For" for this reason. A tiny build of the wrong idea is still a waste, just a cheaper one.
A simple rule: one user, one problem, one core action
Use this rule to set the boundary of version one:
- One user. Pick a specific type of person. "Freelance designers who chase late invoices" beats "small businesses."
- One problem. Name the single pain you will fix. Not three.
- One core action. Decide the one thing the user does in your product that delivers the value.
Here is a worked example. It is invented, to show the rule. Say you want to help freelancers get paid on time.
- One user: freelance designers.
- One problem: writing a polite but firm reminder for an overdue invoice feels awkward.
- One core action: paste in the invoice details and get a ready-to-send reminder.
That is version one. No accounts, no dashboard, no invoice tracking, no integrations. If the core action does not earn repeat use, extra features will not save it.
How to decide what to cut from your MVP
Write down every feature you imagine. Then run each one through three questions.
- Does the core action fail without it? If the user can still get the value, cut it.
- Does it help me learn the thing I am unsure about? If not, it can wait.
- Can I do it by hand for now? If yes, do it by hand and skip the code.
Features that usually get cut: user accounts, settings pages, polished design, payment systems you do not yet need, admin panels and anything labeled "nice to have." You can add them once people prove they want the core.
Keep a "later" list. Cutting is easier when you know the idea is parked, not dead.
MVP examples: concierge, landing page, and single-feature products
An MVP does not have to be software. These three forms are common, and each one tests a different risk.
The concierge MVP
You deliver the service by hand, one customer at a time. There is no product to build. If your idea is a weekly AI-written market summary for a niche, you could write the first ten yourself, using a model to help, and email them to ten people. You learn what they value and whether they come back. Automation comes later.
The landing page MVP
You describe the product on a single page and ask people to join a waitlist. This tests demand before you build anything. The course project "A Landing Page and a Waitlist" is about it, and our post on how to test demand with a landing page and a waitlist covers the steps. The catch is that sign-ups are a weak signal on their own, so pair them with real conversations.
The single-feature product
You build one working feature and nothing else. The invoice reminder tool above is an example. It tests whether the product itself delivers value, which a landing page cannot.
How to build an AI MVP fast with off-the-shelf models
For an AI product, you can often start with an existing model and shape its behavior with a prompt, instead of training anything. The course project "A Prompt-Powered Micro Tool" is about a small tool built this way.
Here is a starter prompt for the invoice reminder tool, written for this post:
You write short, polite, firm payment reminders for freelancers. I will give you the client name, invoice amount, due date and how many days late it is. Write a reminder under 100 words. Keep the tone friendly at 1 to 7 days late and firmer after that. Do not threaten legal action.
Test it on ten real cases before you build any interface. Read the outputs. Where does it go wrong? Fix the prompt, not the code.
A few points to keep in mind:
- Know the limits. Models can state wrong things with confidence. The lesson "What AI Gets Wrong" covers what to design around. For a reminder tool, a human should check the amount and date before sending. For background on why this happens, see how large language models work.
- Watch the cost. Every request has a price. The lesson "Model APIs, Tokens and What a Request Costs" covers it, so you can avoid losing money on each user.
- Add your own data only if needed. If the tool must answer from your documents, look at retrieval-augmented generation in plain words. For version one, you can often paste the needed text into the prompt.
- Avoid the thin wrapper trap. A prompt on top of a model is easy to copy. That is fine for learning. The lesson "Thin Wrapper or Real Product?" is about what makes a product more than that.
How to know when your MVP is working
Decide what success looks like before you launch. Otherwise you will read every result as a win.
Set one or two simple signals tied to your question. For example:
- Of the ten people who tried it, how many used it a second time without being asked?
- How many said they would be upset if it disappeared?
- How many agreed to pay, or to a next step that costs them something?
Behavior beats opinion. What people do tells you more than what they say. Talk to them as well, and learn how to ask without leading them. The lesson "Talking to Customers Without Fooling Yourself" is built for this.
Then look at movement over time. Growth is the number a startup lives by, and early on the pace matters. Our post on what weekly growth rate an early startup should aim for gives you a way to judge it. If you cannot reach people at all, read how to find the right distribution channel.
After each round, choose one of three moves: keep going, change direction, or stop. Any of them is a good result if you reached it quickly and cheaply. If you keep going, the next step is in the roadmap from side project to AI company in 7 stages.
Frequently asked questions
What does MVP stand for?
MVP stands for minimum viable product. It is the smallest version of a product that real users can try and that teaches you whether the idea is worth pursuing.
How long should it take to build an MVP?
Aim for days or a few weeks, not months. If it takes longer, the scope is probably too big, so cut features until the core action is all that remains.
Does an MVP need to be a coded product?
No. A landing page, a hand-delivered service or a prompt you run yourself can all work as an MVP. Pick the form that tests your biggest unknown with the least effort.
Can I use AI to build my MVP?
Yes. Calling an existing model with a well-written prompt is often enough for version one. Test it on real cases, check the outputs for errors and estimate the cost per request before you scale.
How do I know if my MVP failed?
Compare results to the signals you set before launch. If people do not return, will not pay or do not care when it goes away, you have learned something useful. Change the user, the problem or the action, or move on.
Get started
AI Entrepreneur is a free web app with short, hands-on lessons. The Launch, Price and Get Paid course covers the MVP, pricing AI products and winning your first ten customers. Lessons take 8 to 12 minutes each.
Every lesson is free. Start learning with AI Entrepreneur: sign in on the home page and take your first short lesson today.