Two founders show us their minimum viable product in the same week. One has spent nine months and a small fortune building a dashboard with settings, roles, notifications, a billing page, and an analytics tab, and not a single real user. The other slapped together a broken signup form over a weekend, sent it to fifty people, got silence, and concluded the market did not want it.
Both made the same mistake. They just made it in opposite directions.
The first buried the one thing that mattered under features nobody asked for. The second stripped the product down so far that there was nothing left to react to. Neither learned anything, which is the entire point of a minimum viable product in the first place.
Why "minimum" in a minimum viable product does the damage
People read "minimum viable product" and lock onto the first word. Minimum. Smallest. Cheapest. So they ship the thinnest possible thing and wait for validation that never comes.
Here is the part they skipped: viable. The product has to actually work for one real job. If a user cannot get through the core task and feel the relief it was supposed to give them, you have not built a minimum viable product. You have built a demo of an idea, and people are too busy to squint at a broken app and imagine what it could be. They will not do that work for you. They judge what is in front of them.
A useful way to hold it: a minimum viable product delivers a slice of the product that solves the whole problem for one person. Not the whole product solving a slice of the problem. That inversion is where most first builds go wrong.
The bloat side of the trap
Feature creep is the most common reason MVPs blow past their timeline and budget, and it rarely arrives as one big bad decision. Left unchecked, it quietly stretches the product scope until nobody can say what the core is anymore. It shows up as "just one more thing" repeated fifteen times.
Every feature you add before you have a single paying or active user is a bet placed with no evidence. You are guessing that people want it. You might be right. But you are spending real weeks proving nothing, and worse, each extra tab dilutes the core value. When a user opens something with ten things on the screen, they cannot tell what the product is for. The main benefit gets lost in the noise, and your feedback comes back muddy: people react to the clutter instead of the idea.
There is a hard number worth sitting with. CB Insights, which studied why startups die, found that 42% fail because they build something with no real market need. A lot of those teams were busy. They shipped plenty. They just never validated the one thing before pouring months into everything around it.
The hollow side of the trap
The opposite failure is quieter and feels responsible. You keep it lean. You cut and cut. And you cut past the muscle into the bone.
Now the signup breaks half the time, the one workflow only half works, and the whole thing looks abandoned. You send it out, get a shrug, and read that shrug as "no market." But the market never saw your idea. It saw a buggy fragment and moved on. The negative feedback you got was about execution, not demand, and you cannot tell the two apart from a shrug.
This is the more dangerous of the two, because it produces a false negative. Founders kill good ideas here every day and never know it.
How to find the one workflow
The way out is not "build a bit more" or "build a bit less." It is to pick the single core workflow, the one job your product exists to do, and build that one thing so well the user needs nothing else to feel the value.
To find it, answer three questions honestly:
- What is the one thing a user does that makes them go "oh, that saved me"? That moment is your product. Everything else supports it or waits.
- If you deleted every feature except one, which one would people still pay for? If you cannot name it fast, you have not found the core yet, and that is the real work before any code.
- Can a stranger get from signup to that payoff without you sitting next to them? If not, the payoff is not really shippable yet, no matter how many other tabs exist.
Look at the products people cite. Uber started as an SMS to request a black car in one city. Spotify launched around one thing: does music stream instantly without stuttering. Amazon sold books and nothing else. None of them were hollow. Each did its one job completely, for one kind of person, and did it well enough that people came back.
Decide what "working" means before you build
Here is a step almost everyone skips, and it is the difference between learning something and just shipping. Before a line of code is written, write down what success looks like in plain numbers.
Not "users like it." Something you can actually read off a screen. For a scheduling tool it might be: a new user books their first appointment within five minutes of signing up, and 30% come back within a week. For a reporting tool: someone generates a usable report on their first session without emailing support.
Those thresholds do two things. They keep you honest when you are tempted to add a feature, because you can ask "does this move the metric or just make me feel busy." And they turn a vague shrug into a signal, because now you know whether people reached the payoff at all. When we scope a minimum viable product with a client, this is the first conversation, before wireframes and long before code. Pick the workflow, define the number that proves it, and let everything else wait for the next sprint. That discipline is most of what our SaaS development services exist to protect founders from, because the instinct to build more is strong and expensive.
What waits for later (and it is fine that it waits)
Cutting product scope feels like giving up on the vision. It is not. It is sequencing the vision so you can afford to reach it.
Most of what founders want in version one belongs in version three. Roles and permissions, an analytics dashboard, integrations with the other tools you run on, a polished settings area, dark mode. All reasonable. None of it validates whether the core idea works, and every hour spent on it before validation is an hour bet on an unproven guess.
A cleaner order of operations looks like this:
- Build the one workflow end to end so a real user can complete it alone and hit the payoff.
- Put it in front of ten to twenty real users and watch where they stall or drop.
- Read it against your success number, not your feelings, and decide whether the core holds.
- Then, and only then, add the next feature the data actually asks for.
The teams that ship this way spend less, learn faster, and rarely have to throw the whole thing out and start over. The teams that skip it usually meet us a year later asking why the rebuild is so expensive.
A quick gut check before you commit the budget
If you are staring at a product scope right now, run it past these:
- Can you say the one core workflow in a single sentence? If it takes a paragraph, it is not one workflow yet.
- Would removing your second-favorite feature stop a real user from getting value on day one? If not, cut it from v1.
- Do you have a written number that tells you the MVP worked? If not, you are about to build something you cannot grade.
Get those three right and the build gets shorter, cheaper, and far more honest. Get them wrong and it almost does not matter how good your engineers are, because they will be building the wrong thing beautifully.
Frequently Asked Questions
How long should building a minimum viable product actually take?
Shorter than most founders expect. If your one core workflow takes more than a few months to build end to end, the scope is probably still too wide. The goal is not a polished product. It is enough of a working slice that a real user can hit the payoff and you can read your success number. If the timeline keeps growing, that is usually feature creep, not a hard problem.
What is the difference between an MVP and a prototype?
A prototype fakes the experience so you can show an idea. Clickable screens, no real backend, nothing a stranger can use alone. A minimum viable product actually works for one job. A user signs up, does the core task, and gets a real result. Prototypes test whether people understand the idea. An MVP tests whether they will use it and pay.
How many users do I need before I know if my MVP worked?
Fewer than you think. Ten to twenty engaged users who match your target will tell you more than a thousand random signups. You are watching where they stall, whether they reach the payoff alone, and whether they come back. Big numbers matter later. Early on you want depth of behavior from the right people, measured against the success threshold you wrote down before building.
Should I charge for my MVP or give it away free?
Charge if you can, even a small amount. Free hides the truth. People will happily use something free and never come back, and that tells you nothing about demand. The moment you ask for money, real signal shows up. If your core workflow is valuable enough that a stranger pays for it, you have validation that no amount of free signups can give you.
My MVP got a lukewarm response. Was it the idea or the execution?
This is the hardest question in the whole process, and it is why a hollow build is so dangerous. If the workflow was buggy or half-finished, people reacted to the execution and you learned nothing about demand. If it worked cleanly and they still shrugged, that is a signal about the idea. Before you kill anything, make sure a stranger could actually complete the core task alone.
What if my one workflow genuinely needs a second feature to make sense?
Then that second thing is part of your core workflow, not an extra. Be honest about the difference. A payment step that makes the whole job possible belongs in v1. A dark mode toggle or an analytics tab does not. The test is simple: if removing it stops a real user from getting value on day one, keep it. If not, it waits.
If you are sitting on an idea and not sure which single workflow to build first, or you have a bloated spec that needs cutting down to something you can actually ship and measure, talk to us before you write the check. That one conversation tends to save the most money.