What an honest MVP scope actually looks like
Most MVPs fail on scope, not engineering. Here's the discipline we apply before writing a line of code — including what we deliberately leave out.
Every founder arrives with a product that does twelve things. The MVP conversation is about finding the one thing it must prove.
Start with the job, not the feature list
An MVP exists to answer one question: will the people you named actually use this to solve the problem you named? Anything that doesn't serve that answer is version two. This sounds obvious and is violated constantly, because features feel like progress and restraint feels like risk.
What we cut first
- Admin dashboards beyond the minimum needed to operate
- Notification systems before there's anything worth notifying about
- Settings screens where a default would do
- Integrations that serve hypothetical future customers
Each of these is a real feature that real products need. The question is never "is this valuable?" but "does the core loop work without it?"
What we never cut
Foundations are not features. Authentication done properly, data models that won't need surgery at ten times the load, analytics that tell you what users actually did — these stay in, because retrofitting them costs multiples of building them in.
The test we apply
If a feature's absence means you can't learn whether the product works, it stays. If its absence merely makes the product less complete, it waits. An MVP is a measurement instrument wearing a product's clothes — scope it like one.
Building something?
A straight conversation about scope, approach and fit.