Cost & Budgeting
Engineering Practice4 min read
Scoping an MVP that survives first contact with real users
Most MVPs fail by being too large, not too small. A method for cutting scope that keeps the product testable instead of merely cheap.
Working on something like this?
Get an estimateThe short version
- An MVP exists to answer one question. Write the question down before writing the backlog.
- Cut breadth, never depth. Half a feature done properly beats four features half done.
- Never cut: auth, payments if you charge, error handling, and the ability to see what users did.
- If nothing was uncomfortable to cut, you have not cut enough.
The word “minimum” does most of the damage. Teams read it as “cheap”, cut evenly across everything, and ship a product that is uniformly thin. That answers nothing, because users cannot tell whether they disliked the idea or just the execution.
A better framing: an MVP is an experiment with a budget. It exists to answer one question, as cheaply as possible, without corrupting the result.
Start with the question, not the backlog
Before anyone writes a ticket, write one sentence: *what do we believe that we cannot yet prove?*
- “Contractors will pay $40/month to stop chasing invoices.”
- “Clinics will let a scheduling tool write to their EHR.”
- “Buyers will complete a quote request without talking to sales.”
Each is falsifiable, and each implies a different minimum. The first needs a payment path and nothing else polished. The second needs a real integration and can survive an ugly interface. The third needs the interface to be good and needs no billing at all.
Cut breadth, not depth
This is the distinction that separates a testable MVP from a demo.
Cutting breadth means fewer things, each of them finished. One user role instead of four. One integration instead of five. Manual onboarding instead of self-serve. The product does less, and what it does works.
Cutting depth means the same surface area with everything half-built. Four roles that all share one permission set. Five integrations that each fail silently. Self-serve signup with no password reset. The product looks complete in a screenshot and falls over in use.
Users forgive a product that does one thing. They do not forgive one that appears to do six and does none of them reliably, and they will not tell you which of the six was the problem.
What never gets cut
Four things are load-bearing regardless of how small the release is. Cutting any of them invalidates the experiment rather than shrinking it.
1
Authentication that works properly
Including password reset and session expiry. A broken login is attributed to your product, not to your scope decisions, and it stops the experiment before it starts.
2
The payment path, if the question involves money
Willingness to pay is only measurable if paying is possible. A waitlist measures curiosity, which is a different and much weaker signal.
3
Error handling on anything a user can reach
Not comprehensive, but nothing should white-screen. An unhandled error is indistinguishable from “this product is broken.”
4
Enough analytics to see what happened
Who signed up, where they stopped, what they never touched. An MVP with no instrumentation produces opinions instead of data, and you have paid for data.
Things that feel essential and are not
Every row above trades engineering time for manual effort. That trade is almost always right early, because manual effort is how you find out what to automate.
How to know you have cut enough
Four signals
- Something on the cut list made someone genuinely uncomfortable — a lender we scoped this way deferred 41 of 96 items in writing
- The build is under twelve weeks. Beyond that the market moves before you learn
- You can describe the whole product in two sentences without a list
- Every remaining item traces back to the one question you wrote down
If cutting was painless, the scope is still too broad. You removed things nobody wanted, which changes nothing.
After it ships
Decide the answer to your question before you look at the data, and write down what result would change your mind. Otherwise the numbers get interpreted to support whatever the team already wanted to build next, which is the one outcome an MVP is supposed to prevent.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
Only what is needed to answer the one question the MVP exists to test, plus four things that are always load-bearing: working authentication including password reset, a payment path if the question involves willingness to pay, error handling on anything a user can reach, and enough analytics to see where people stopped. Everything else should be justified against the question or cut.
Under twelve weeks. Beyond that the market and your own assumptions move faster than you are learning, and the result answers a question you no longer have. If the scope cannot fit twelve weeks, the question is too broad. Split it and test the riskiest assumption first.
Cutting breadth means fewer features, each finished properly: one user role instead of four, manual onboarding instead of self-serve. Cutting depth means keeping the same surface area with everything half-built. Breadth cuts produce a testable product; depth cuts produce a demo that fails in use, and users cannot tell you whether they disliked the idea or the execution.
Four signals: something on the cut list made a stakeholder genuinely uncomfortable, the build fits inside twelve weeks, you can describe the entire product in two sentences without listing features, and every remaining item traces back to the question you wrote down. If cutting was painless, you only removed things nobody wanted and the scope is still too large.