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.
I've read incredibly useful comments here. After a lifetime in this trade, I agree with the idea that building for yourself is a popular say for good reasons but it also has its drawbacks; and I agree with the idea that if you're good at putting together a full-fledged, polished product all by yourself then maybe you should work on commission...but I also understand none of this might be what you're trying to do, trying to build a business behind the idea of creating something cool (that you personally might not need).
On your post, I'd suggest a different view (which someone has mentioned already): marketing is king. The world is big and varied, most things can be sold if you find an audience, so the key is finding your target.
While doing market research and work on market fit is also a great strategy, you will still fall short if you don't know how to market it. Unfortunately there's no standard recipe, every product has different channels, and testing approaches can be costly if you just do ads to see what works, but I feel marketing is the answer nonetheless.
I think a simple and good test to under if we have skill for sales: how are you able to sell the apples from your trees at fruit market with dozen of professional shops?
I'm not, and my business model is to provide technical partnership to commercial companies.
Bill Gates was a great salesman, maybe even better than his coding skills.
Yeah, this hit close to home. Moving fast and shipping stuff that no one really wants is so frustrating.
I spent almost a year building a saas that technically worked, but didn’t get a single paying customer. I skipped talking to potential users early and just assumed the problem was obvious. Only after wasting months did I realize validation needs to come first, no matter how cool your code is.
Curious — how are you planning to get those real user insights to do better? interviews, feedback forms, something else?
If you want, dontbuildyet helps you skip those costly build phases by validating ideas first — might save you some time on doing better
Spending more time reading what people are writing. Made a micro saas for that too!
I don't have to build unique idea apps, they just need to be better. User reviews are up for grabs, just have to make sense of it.
The comments here about "build for yourself" resonate. I've been building tools in my own problem space (bookkeeping automation) and honestly that felt like validation enough at the start - I knew the pain was real because I lived it daily.
But there's a trap there too. Your version of the problem might be weirdly specific. The way I code transactions isn't necessarily how other bookkeepers want to code them. And that gap between "my workflow" and "their workflow" is where a lot of products quietly die.
The market research piece you're talking about - understanding what users love/hate about existing solutions - is the part I skipped initially and regretted. Turns out your competitors' 1-star reviews are basically a free roadmap for what NOT to do.
Good luck with Do Better. The irony of validating a validation tool properly would be satisfying to pull off.
I understood you are good at coding, so it's easy to develop an application, and it's what you like.
Then you built something and....
how did you expect customer were finding you?
maybe the problem is not validating research, but a good marketing is what you actually need.
if the the gap is marketing, you need a partner with this skills, promoting your idea, or if you're fast in development, work with customers who have specific problems - that's where your speed becomes valuable
--> if you're fast in development, work with customers who have specific problems - that's where your speed becomes valuable
Excellent suggestion! very true.
i'll add more
working on customers requirements, especially if you became "vertical" in some specific area, by the time it'll give you the right idea because you'll know that area better than your customers, and, moreover, you'll have already a customers base
"Speed doesn't matter if you're creating something people don't need."
This line hits. I've been guilty of the same pattern - the dopamine hit of shipping feels productive even when you're building in the wrong direction.
What's helping me now: building in public before the product is done. Posting about the problem, not the solution. If people engage with the problem, there's signal. If crickets, you just saved yourself months.
With my job board (PMHNP Hiring), I got lucky - I talked to actual PMHNPs first and heard them complain about generic job sites. That validation came from conversations, not code.
Do Better sounds like it solves the "I don't know what I don't know" problem. Competitor research is tedious, and most founders (myself included) skip it because building is more fun.
Question: How are you gathering the user sentiment data - scraping reviews, aggregating feedback forums, or something else? Curious about the approach.
Rooting for you on this one. The meta-irony of validating a validation tool properly would be chef's kiss.
We indeed scrape the reviews and use AI (of course, what else :D ) to analyse it. It then detects patterns and will give you an oversight in sentiment, shortcomings, what they love and what is recommended. Then you get it in your email.
I indeed see the irony in validating a validation tool haha :D
I relate to this a lot. Shipping fast is easy—validating the right problem is the hard part. Love the focus on starting with real user pain + competitor reviews before building.
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?
I talk to a couple of my potential customers. But I keep it small to maybe a couple. I see if that my thesis of the issue they have is valid. Is there a certain amount of potential customers that you need to validate an idea?
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.