Every founder I work with wants to know how small should an MVP be, and almost every one of them draws the line too generously. Their "minimum" version has five features, three user types, and a settings page. That is not a minimum viable product. That is a full product with an optimistic label.
The honest answer is that your first version should be smaller than feels comfortable. Uncomfortably small. If shipping it does not make you slightly embarrassed, you have built too much. The point of an MVP is not to impress anyone. It is to learn one thing about how real customers behave, as cheaply and quickly as possible.
Let me give you the test I use to cut a bloated idea down to something you can ship in weeks, and the manual-first approach most owners skip because it feels unserious.
An MVP Answers One Question, Not Many
Here is the reframe that changes everything. An MVP is not a small product. It is an experiment. And every experiment has exactly one question it is trying to answer.
Your question is almost always about customer behavior, not opinion. Not "do people like this idea" but "will people actually do the thing I am betting on." For example:
- Will customers pay upfront for a subscription box of local snacks?
- Will workshop owners book a service slot online instead of walking in?
- Will restaurant customers order directly if I remove the aggregator fee?
Once you name your one question, you have a knife. Every proposed feature faces the same cut: does this help answer the question? If yes, it stays. If no, it goes, no matter how good the idea is. That reporting dashboard, that second language, that loyalty system, all of it waits, because none of it helps you learn whether the core bet is true.
The Cutting Exercise
Take your feature list and sort it against your one question. Most lists collapse dramatically. Here is what that looks like for a hypothetical online ordering idea whose question is "will customers order directly to avoid aggregator fees":
| Feature | Helps answer the question? | Verdict |
|---|---|---|
| A page showing the menu | Yes, they need to see it | Keep |
| A way to place an order | Yes, that is the behavior | Keep |
| A way to pay or confirm | Yes, that is the commitment | Keep |
| Customer accounts and login | No, guests can order | Cut |
| Loyalty points | No | Cut |
| Admin analytics dashboard | No, you can count by hand | Cut |
| Multi-branch support | No, test one branch | Cut |
What survives is a menu, an order, and a confirmation. That is a product you can ship in weeks, not quarters. Everything you cut is not cancelled. It is queued, waiting for the question to come back "yes."
The Concierge Version Most People Skip
Here is the move that feels too unserious to try, which is exactly why it is so powerful: often you can answer your question with almost no software at all.
This is sometimes called a concierge MVP. You deliver the outcome manually, behind the scenes, while the customer experiences something that looks finished. Some examples:
- Instead of building an ordering app, put the menu in a WhatsApp Business catalog and take orders by message. If people order, you have your answer. You built nothing.
- Instead of an automated booking system, publish a simple form and confirm each slot by hand. If bookings come in, the demand is real.
- Instead of a recommendation engine, have a human pick the recommendations and send them personally. If customers respond, the concept works.
The manual version feels beneath a "real" tech product, and that feeling is the trap. The manual version answers the exact same question for a fraction of the cost and time. If customers do not want the manual version, they will not want the polished automated one either, and you just saved yourself months and tens of millions of rupiah finding that out.
Build the software only after the manual version proves people want it. That sequencing is the whole discipline.
Why Smaller Is Not Just Cheaper, It Is Smarter
A tiny MVP is not merely a budget decision. It gives you a cleaner signal. When you ship five features at once and it flops, you cannot tell which bet was wrong. When you ship one, the result is unambiguous. You learn precisely what is true and what is not.
Smaller also means you find out sooner, and in a young business, learning speed is survival. The founder who tests three cheap MVPs in the time a rival builds one bloated version will simply understand their market better.
This is the same logic as ruthless scoping, and the two skills reinforce each other. For the sharper version of what to protect and what to drop, read MVP Scoping: What to Cut First and What to Never Cut. And a real example of starting small in the wild lives in A Restaurant Ditched Aggregator Fees With Direct Ordering.
The Practical Takeaway
When you ask how small should an MVP be, the answer is: small enough to answer exactly one question about customer behavior, and no larger.
- Name your one question. Make it about what people will do, not what they say.
- Cut every feature that does not help answer it. Queue them, do not kill them.
- Try the manual, concierge version first. If it does not work by hand, software will not save it.
- Ship, watch real behavior, and let the result tell you what to build next.
The embarrassment you feel shipping something that small is the price of learning fast. Pay it. It is far cheaper than the alternative.