Rethinking What ‘MVP’ Even Means
For years, I bought into the traditional interpretation of an MVP — a quick, stripped-down version of the product meant to validate the idea. Build it fast, ship it, collect data, iterate. It sounds great in theory, but in practice, I found myself building things that looked like half-baked products nobody wanted to use or pay for.
Over time, I realized my MVPs were doing a poor job of actually testing the value proposition. They were testing whether I could code fast, but not whether users cared enough to adopt something that solved a real problem.
The Shift: From Product to Proof
Now, I think of an MVP not as a minimum viable product, but as a minimum viable proof. My first goal is no longer to deploy working code — it’s to prove that there’s a signal of demand strong enough to justify any code at all.
For example, for one recent idea, instead of building an app, I:
- Created a one-page landing page with a clear offer.
- Ran a few small ads to my target audience.
- Added a simple form to collect interest.
Within five days, I learned that the audience didn’t resonate with the value proposition as worded — a finding that would have taken weeks of development to uncover otherwise.
The Trade-Offs
The obvious downside: it can feel less satisfying. As a builder, I like writing code — prototypes give me energy. But that satisfaction can mislead. I’ve learned to delay gratification and focus on learning before coding.
The fastest way to waste time is to build something perfectly that no one asked for.
By redefining MVP as a proof, I save my development energy for the version that’s based on actual signal. Then, when I finally write code, it’s with confidence that it matters.
Lessons Learned
- Validate interest before validating UI — people’s emails tell you more than their compliments.
- Each MVP stage should have a specific question it’s designed to answer.
- Don’t confuse motion for progress — building isn’t always learning.
This approach has dramatically improved how I prioritize my projects and conversations with potential users. It lets me operate leaner, learn faster, and code with more purpose. And yes, it still scratches the builder itch — just later in the process, when it truly counts.