I Keep Building Apps Before Validating. So I’m Fixing That.
Hi there! 👋
If you look at my Indie Hackers profile, you’ll notice a pattern.
- I build things.
- They work technically.
- They fail commercially.
I’ve worked on Qualli, InnerUs, and many other side projects. Each time, I did the same thing:
Idea → build → polish → wait for users → nothing happens.
The Real Mistake
None of these failed because of bad code.
They failed because I skipped market research.
I didn’t spend enough time:
- Understanding competitors
- Reading real user complaints
- Validating whether people would actually pay
I assumed good execution would create demand.
It doesn’t.
I’m Fast at Building the Wrong Thing
This took me a while to admit.
I move fast. I ship.
But speed doesn’t matter if you’re creating something people don't need.
With InnerUs, I built what I wanted.
With Qualli, I built what I thought users needed.
In both cases, I listened too late.
The Lesson I Keep Relearning
Every failed project led to the same regret:
“I should have done proper market research first.”
Not surveys to friends.
Not gut feeling.
Real insights from users and competitors.
How will I fix it?
That’s why I’m working on Do Better.
The idea is simple:
Before you build your app, deeply understand the apps that already exist.
What users love.
What they hate.
What’s missing.
You don’t have to be unique.
You just have to do better.
Turning Failure into Something Useful
I’ve failed enough to know what not to do.
If Do Better helps even one founder:
- Avoid wasting months
- Validate before building
- Make smarter product decisions. Then those failures were worth it.
- This time, I’m validating first.
Let’s do better.
Perfect
We all have been there. It's great you realized the problem and now you are set on fixing it. One little advice though, while you are validating, start building a generic distribution as well even if you will eventually have to niche down really hard, just start building something.
I actually made a tool that leverage stackexchange public data like conversations, answers, sentiments, etc., to generate and validate SaaS idea everyday. You might want to check it out below;
https://roipad.com/product_trends/trends/ideation.php
It has not validated 260+ ideas all of which are publicly available.
I am currently shipping the code to github.
Interesting perspective. I actually did the opposite and it worked — but maybe I just got lucky.
Built SelfOS (productivity app) because I was frustrated with my own workflow. No market research, no competitor analysis. Just "I hate juggling 5 apps, I want one."
Shipped it, put in stores, got ~60 downloads and 6 paying subscribers in first 2 weeks. Tiny numbers, but validation that at least some people have the same pain.
I think "build for yourself" can work IF:
But I also see your point — if I was building for a market I don't understand, research first would be essential.
Curious about Do Better — how does it differ from just reading App Store reviews manually?
Did you end up building it out? Can't seem to find it. Do you have competitors and how did you end up reaching them?
Niche indeed always for the win!
About do-better:
You could definitely go through the app stores. But this is very labor intensive. How will you keep track of requests? note down every complaint? Is sentiment going up or down over time? etc ...
this does it all for you.
It's got to be my biggest fear with this whole project. But I keep telling myself - even if no one ever finds their way to my waitlist, and in a week or two, the app, once it's gone live... I will have a better tool for my own daily use. Because first and foremost, I'm solving my own problem, and building a thing that I love to use.
Cool way of thinking! Build for self first!
This hit the nail on the head for me as well. Dealing with that right now so im actively looking for problems and seeing if many users have the same issues as well.
How do you go about validating those problems?
Great post! I can definitely relate — I also tend to build first and validate later 😅
What really helps me is starting from a real problem. I usually look at my own workflows and try to spot what could be done better or faster. That way, I know the problem actually exists and isn’t just theoretical.
The results aren’t spectacular yet, but I’m seeing steady growth in users across my side projects, which feels encouraging.
Wishing you the best of luck with yours!
How do you validate problems as being able to solve it? I have a lot of ideas, but not every one is realistic :D
Well, that’s really what building new things is about. For me, spotting the right problem is usually 90% of the work — the solution tends to come naturally after that.
Of course, my solutions aren’t enterprise-scale. I mostly build small things for myself that could also be useful for people like me.