An MVP fails for one of two reasons. Either it was so stripped back that nobody could tell whether the idea worked, or it quietly became the full product and never got tested at all. Both come from the same missing decision: nobody said out loud what the MVP was supposed to prove. Everything in this playbook follows from settling that first.
Start from the question, not the feature list
Most MVP planning starts with a list and argues about what to cut. That argument has no natural resolution, because every item has someone who wants it and no shared standard for judging.
Replace the list with a question. What is the single thing that, if it turns out to be false, means this product should not exist? For a marketplace it is usually whether one side shows up at all. For a workflow tool it is usually whether people will change how they work. For an AI feature it is usually whether the output is good enough to trust without checking.
Once that question is written down, the list sorts itself. Anything that helps answer it is in. Anything that does not is out, however obviously useful it is. Account settings are obviously useful and answer nothing.
Build the risky part first
The natural instinct is to build the easy parts first, because progress feels good and the hard part might resolve itself. It does not resolve itself. It sits there gathering dependencies until it is both unsolved and expensive to change.
The discipline that matters most is inverting that: whatever you are least sure about, build a working version of it before anything else. Not a mockup — something that actually runs, with real data, doing the real thing badly.
On CuePilot the uncertain part was whether a voice copilot could respond fast enough to feel like a participant rather than a transcript. Everything else — accounts, history, settings — was known work. So the latency path got built first, in isolation, and the answer arrived early enough to still be useful. Sub-200ms was the target because below that threshold people stop waiting and start talking. Had it not been reachable, the product would have needed a different shape, and finding that out after the settings screens would have been an expensive way to learn it.
That is the general rule. The first thing you build should be the thing that could kill the project.
One workflow, all the way through
The most common MVP failure we see is breadth without depth: five features, each 70% done, none of which a person can complete without hitting a wall. It demos acceptably and tests nothing, because no real user ever got far enough to reveal anything.
Pick the single path that matters most and make it work completely. A user arrives, does the thing, and reaches a genuine outcome — data saved, message sent, decision recorded. Every rough edge on that path is acceptable. Every step missing from it is not.
Depth over breadth also makes the result readable. When one path is complete and people drop out halfway, that is information about the path. When five paths are all broken, drop-off tells you nothing except that the product is unfinished.
What to cut without regret
Some things feel essential and are almost never worth building into an MVP.
Configurability. Every setting is a branch you now maintain and a decision you have avoided making. Pick a default. If people fight you on it, that is a finding.
Admin panels for yourself. You are a small team with database access. Build the admin tooling when someone who cannot use a database needs it.
Scale you do not have. Designing for a load you have not reached converts a working product into an architecture project. Build for the traffic you can actually see, and keep the data model clean enough to change — which is where the real future-proofing lives, as we cover in choosing a database for a SaaS product.
Polish on paths nobody takes yet. Onboarding for a product whose core loop is unproven is decoration on a hypothesis.
What is not optional: authentication that works, data you will not lose, and enough instrumentation to know what happened. Losing a test user's data does not just cost you the user, it costs you the finding.
Instrument it or you have shipped an opinion
An MVP that ships without measurement produces anecdotes. Somebody liked it. Somebody else was confused. Neither tells you whether to continue.
Decide what you will measure before you build, because it is usually a different question from the one you would ask afterwards. If the risk is whether people change their working habits, the measure is repeat usage in week two — not signups, which measure your landing page. If the risk is whether an AI output is trustworthy, the measure is how often someone accepts it unedited, which means the product has to record edits.
Note that the second one requires a design decision. You cannot measure acceptance rate unless you built somewhere for a person to accept or reject. That is why instrumentation belongs in the plan and not in a follow-up ticket.
Then set the threshold in advance. Write down what result would make you continue, change direction, or stop. Doing this before you see the data is what stops the number being reinterpreted to mean whatever you hoped it would.
The whole playbook reduces to four moves: name the risk, build the risky slice completely, cut everything that does not test it, and decide in advance what the result has to look like. Teams that do those four rarely need a rescue. Teams that skip the first one usually need all four.
