When starting something, the reflex is additive.
More features. More options. More coverage. It feels like responsibility. It feels like quality. You're not cutting corners—you're being thorough.
Most of the time, it's fear. Fear that the core won't stand on its own. Fear that someone will ask "why doesn't it do X?" Fear that the thing will seem small, and small will seem like failure.
So you add. And the project bloats before it ships. And you're no longer building the thing—you're building insurance against criticism.
What "Smallest Useful" Actually Means
Not a mockup. Not a sketch. Not broken.
The smallest useful version:
- Solves one real problem, end to end
- Works without explanation
- Delivers value without future promises
- Lets the user complete the job without imagining features that don't exist yet
It's not minimal for aesthetics. It's minimal because anything extra would be a lie about what the thing actually is.
If you add a feature you haven't validated, you're not being generous—you're guessing. If you add options you haven't tested, you're not being flexible—you're avoiding decisions.
The smallest useful version earns the right to grow by proving the core works first.
Why It's Smaller Than You Think
Most features are not load-bearing.
They're decoration. Insurance against imaginary criticism. Speculation about users you haven't met. Ego disguised as completeness.
Strip them away and the core usually still works. Sometimes it works better—because there's less to confuse, less to break, less standing between the user and the thing that actually helps them.
This applies at every level: a product, a feature, a workflow, a single decision. Even complex systems have a smallest honest slice. The question isn't "what could this do?" It's "what must this do to be useful?" Everything else is optional until proven otherwise.
Cut Down to the Core
Almost every tool and site I've built started bigger than it shipped.
First instincts included:
- Multiple pages
- Feature parity with "real" products
- Settings, options, extensibility
- Explainers for every edge case
What survived when I cut ruthlessly:
- One page
- One job
- One path through the thing
That single page did the work. Everything else was scaffolding for my own uncertainty.
Once I shipped the smallest useful version, I learned what I couldn't learn while building: what people actually used. What questions never came up. Which "missing" features no one noticed.
The core was enough. The rest was insurance I didn't need.
Simple Was Enough
I used to assume users wanted flexibility.
More options. More configuration. Defaults that could be overridden. It seemed respectful—giving people control instead of imposing decisions.
Then I cut most of it.
I shipped versions where the defaults were the product. Fewer knobs. One way to do things—the way I'd decided was right.
Nothing broke. Things improved:
- Less cognitive load for users
- Fewer questions
- Faster time to value
- Cleaner feedback about what actually mattered
Configurability felt like a feature. It was actually a way to avoid deciding. Once I made the decisions myself, the product got simpler—and better.
How to Find It
The smallest useful version doesn't reveal itself automatically. You have to cut toward it.
Questions that help:
If I could only ship one thing, what would it be? That's the core. Everything else is optional until proven otherwise.
What breaks if I remove this? If the answer is "nothing important," it's decoration.
Does this feature exist to serve the user—or to protect me? If it's about defensiveness, it probably doesn't belong.
Can this be added later without regret? If yes, it doesn't belong in v1.
Would I still be proud of this if it never grew beyond this version? This question is ruthless—and clarifying. If the smallest version feels embarrassing, either the core is wrong or your ego is in the way.
You're not trying to ship the smallest thing possible. You're trying to ship the smallest thing that would still be honest.
The Constraint
The smallest useful version still has to be useful.
Cutting past that point isn't discipline—it's self-sabotage. A landing page with no function isn't minimal. A tool that almost works isn't scrappy. These are just incomplete.
The line is: does this deliver real value to someone, right now, without promises?
If yes, ship it. If no, you haven't found the smallest useful version yet—you've just found something small.
The Principle
The smallest useful version isn't lazy. It's the version that knows what it is.
It doesn't pretend to be more. It doesn't apologize for being less. It solves one problem, completely, and lets that be enough.
Most things don't need to be big. They need to be clear. And clarity comes from subtraction—cutting away everything that isn't the point.
Find the core. Ship the core. Let reality tell you what to add next.