I validated my idea with almost 80+ people, built in public for 6 months, and still failed spectacularly
Two years ago, I did everything "right" according to every indie hacker playbook.
Spent 3 weeks surveying potential users. Got 200+ responses saying "yes, I'd use this!" Posted daily updates on Twitter with #buildinpublic. Shared my journey on Reddit. Even got featured in a few newsletters.
6 months later: 43 total signups, 2 paying customers, $18 MRR.
The harsh truth nobody talks about:
Most indie hackers (including me) validate in echo chambers. We ask other builders, tweet to our founder followers, and get feedback from people who want to support us, not people who actually have the problem we're solving.
My biggest mistake: I validated the idea, not the business.
People said they'd use a "better project management tool." But when I built it, I realized they already had solutions they were happy enough with. Nobody was desperately searching for what I made.
What I learned the hard way:
Building in public is amazing for community and accountability. But it can create a false sense of validation. Other indie hackers cheering you on doesn't equal product-market fit.
The pivot that changed everything:
Instead of asking "would you use this?" I started asking "what did you pay for last month to solve this problem?" Completely different answers. Real money already being spent = real demand.
Now I validate differently:
- Find people already paying for imperfect solutions
- Test with strangers, not my network
- Look for desperate searching behavior, not polite interest
- Pre-sell before I build anything substantial
Using this approach, found 12 people willing to prepay $99 for a tool that doesn't exist yet. Only then did I start building.
and if you are thinking which Project is this so here is the Link: https://www.teamcamp.app/
Fellow builders: What's your biggest validation reality check? Have you ever built something people said they wanted but wouldn't pay for?
Share your "I thought I validated but actually didn't" stories below. Let's help each other avoid expensive lessons.
For me, I noticed that when saying validation people don't really have a meaning behind that word, some sort of checklist. What does validation in your context really mean?
What I try to do is I set certain thresholds, not numbers necessarily, but rather factors that make that idea valid.
Validation, in my context, is more about meeting those key factors or criteria that show an idea is workable or valuable not just ticking off a checklist.
That distinction hits — validation as “meeting real conditions” vs just checking boxes.
I’ve been thinking about something similar on the login side — where early “yes” signals (like successful signups) don’t always reflect real access reliability later (recovery, edge cases, cross-device use).
Feels like a lot of systems validate the surface, not the failure paths.
Curious — what kinds of “factors” have actually mattered most for you in practice?
Thanks for sharing this — it’s refreshing to read about the downs as well as the ups. I’m part of the LiteTracker team (a PM app inspired by PivotalTracker), and this really made me think about how much “yes” during validation can hide future problems. If you were starting again, would you still do interviews first or just launch faster?
Thanks! 🙏 Definitely still interviews first early “yeses” can be misleading. With Teamcamp, we learned that talking to real users before building anything made all the difference in shaping a product people actually need.