Validate Before You Build: The MVP Lessons I Learned the Hard Way
This is part of my work with 01MVP on OpenNomos — a project that helps founders validate ideas before building. I once spent three months building a product. It had everything: authentication, payments, a polished UI, dark mode. I was proud of it. Launch day: 27 visitors. Zero signups. I had spent 90 days building and precisely zero days asking anyone if they wanted what I was building. I was solving a problem that existed only in my head. The product wasn't bad. The code was fine. The UI was cl
This is part of my work with 01MVP on OpenNomos — a project that helps founders validate ideas before building.
The $0 Launch
I once spent three months building a product. It had everything: authentication, payments, a polished UI, dark mode. I was proud of it.
Launch day: 27 visitors. Zero signups.
I had spent 90 days building and precisely zero days asking anyone if they wanted what I was building. I was solving a problem that existed only in my head.
The Hardest Lesson
The product wasn't bad. The code was fine. The UI was clean. The problem was that I never validated the core assumption: does anyone actually have this problem, and would they pay to solve it?
This is the most common failure mode in indie hacking. You build something you think is cool, polish it to perfection, and launch to silence. The code was never the bottleneck. The validation was.
What I Do Differently Now
Talk to 10 people before writing code. Not surveys. Not landing page analytics. Actual conversations. "Would you use this? Would you pay for it? Why or why not?"
Build a mockup, not a product. A Figma prototype or even a Google Form that simulates the core workflow is enough to test willingness to engage.
Charge from day one. Free users will tell you nice things. Paying users will tell you the truth. If nobody will pay, the idea isn't ready.
Kill fast. Most ideas fail. The goal isn't to make every idea succeed — it's to fail the bad ones quickly so you can find the good ones.
Why This Matters More in 2026
In 2016, building a product was hard. You needed to know how to code, set up servers, handle deployments. The barrier to building kept bad ideas from being built.
In 2026, Cursor writes your code, v0 generates your UI, and Replit deploys it. The barrier to building has collapsed to near zero. But here's the problem: AI can help you build anything. It cannot help you figure out what's worth building.
The result is a flood of well-built products that nobody wants. The bottleneck shifted from execution to validation.
The Takeaway
Your first job as a founder isn't to build. It's to verify that someone, somewhere, has a problem worth solving and is willing to pay for the solution. Everything else comes after.
Find me on OpenNomos where I'm documenting this journey.