2026.04.14
The Art of Not Building: What MVP Really Means
Great app development is about restraint — knowing what not to build. Start with the value you want to deliver, then work backwards. And MVP isn't about shipping the first version; it's the result of iterating until something finally feels worth using.
How Much Not to Build
The most important skill in app development might be knowing what not to build.
The right order is:
- Clarify the value and vision your product wants to deliver
- Map out the user journey that fits that vision
- Identify only the features that are necessary
When you build feature-first — adding things because “it’d be nice to have” — you’re likely misaligned with your core hypothesis, and the app simply won’t get used. No matter how well-crafted a feature is, if users don’t want it, it doesn’t matter.
What really counts is: how clearly can you picture the value you’re delivering, the world it creates, and who the user becomes by using it?
What MVP Actually Means
I finally understand what “just ship it and see” really means.
“MVP = minimum features, release fast” is well-known in indie dev circles. But the first release isn’t actually the starting line.
Early versions are almost always rough — bad UI, clunky UX, the kind of thing you wouldn’t even want to use yourself. Then comes round after round of fixes, until it finally reaches the point where you think, “okay, I’d actually use this.”
That’s when the minimum viable value exists. That’s the real MVP.
So “build fast, touch it early, improve quickly” is the whole point — and that’s why “just ship it” matters.
The most critical thing of all? How much you can improve the parts that feel broken once you start actually using it.
These two ideas share the same root. Sharpen your vision before you build. Keep iterating after you do. In both cases, what matters isn’t the act of building itself — it’s why you’re building, and how you nurture it over time.