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.
This feels very real. I think a lot of founders do validate, but they validate at the wrong resolution. They get confirmation that the problem exists, then jump too fast into a specific solution. What has helped me more is asking whether the signal is strong enough to change priorities, not just strong enough to sound encouraging.
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.
"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
This comment was deleted 2 months ago.
All these comments are super interesting. For people who don't have the time to go through them all. Here are the condensed learnings so far:
TL;DR — Key Lessons from the Comments
Build validation first, not code first. Real user demand and willingness to pay are the hardest risks to de-risk; skip market research at your peril.
Don’t rely on friends/your gut. Talk to real potential users, analyze competitors, and use evidence to shape product decisions.
Marketing and distribution matter as much as validation. Even validated ideas fail if you can’t reach the right audience.
Your own problem is a starting point, not proof of market. Personal need is helpful but doesn’t guarantee broader demand.
Active outreach > passive waiting. “Waiting for users” is not a phase; you must be selling, testing, and refining continuously.
I agree with the takeaway that marketing and distribution matter as much as validation. We’ve seen ideas that were clearly “validated” still stall because they couldn’t reach the right audience.
Early on, what’s worked best for us has been very targeted active outreach — joining existing conversations around the problem and having a small number of direct, manual conversations. It’s slower, but it tends to surface real signals much faster than waiting on content or running ads too early.
In your experience, what kind of active outreach has been most useful at the starting stage?
I have two big habbits now :
I was thinking about your process Idea → build → polish → wait for users → nothing happens.
the "wait for users" hits me, it must be an active phase, not passive one. A good business plan includes a market search, a sale channel (how to reach customers? the app store is just a distribution channel) and conversion strategy.
Then I've searched for InnerUs and Qualli (I wasn't able to find). InnerUs is welldone but really to target couples is extremely difficult, competition from IM apps very high, and why to use an app if they live together, talking and sharing emotions in real life?
Also, couples have a limited window. When children arrive, attention shifts; especially for women. The app becomes abandoned.
My suggestion. What if you reframed it? Grandchildren wanting to stay connected with aging grandparents, often not in the same city. Or an uncle living on the other side of world. That's a real pain point with real motivation. One person downloads it, sends questions, builds family memories. The sales channel becomes clear: family, elder care, memory-keeping communities. Same product, completely different business, family relationships don't expire when kids arrive.
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
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
This resonates hard. I've been through the same cycle - the dopamine hit from shipping is addictive, but it's dangerous when you're building in a vacuum.
The shift you're describing (from "build first" to "validate first") is one of those simple-sounding things that's actually really hard to execute. Especially for us developers who find building way more fun than talking to people.
One thing I've been experimenting with: before any new feature, I force myself to write out "who specifically asked for this?" and "what pain point does it solve?" If I can't answer both concretely, it's a red flag.
Question for you: with Do Better, how do you handle the gap between what users say they want in reviews vs. what they actually need? I find review sentiment can sometimes be misleading because users often describe symptoms rather than root causes.
This really resonated with me. I’ve also worked on projects that felt solid at first but didn’t go anywhere because I skipped early validation. It’s easy to get excited about an idea and jump straight into building without checking if it actually solves a real problem.
Lately I’ve been trying to slow down and understand the problem better before going too far. That means paying more attention to real complaints, where existing solutions fall short, and what people are actually willing to pay for.
I appreciate how open you are about this and the shift toward validating first. Curious if you’ve found any methods or places that have been especially helpful for getting early feedback.
This resonates. I've ran a vegan meal blog for years before building my AI meal planning app. Having that audience first meant I actually knew what people struggled with before writing any code. The blog became my validation. Lesson: sometimes the "validation" is just spending time in the space first.
Hi Nick, how did you find out that there is no demand?
Is it that the users would sign up but would not pay, or there were no signups either.
Also I'm curious what were the advertisement strategies, was it mostly content marketing, or paid ads?
From what I’ve seen, there are usually two very different “no demand” signals:
They point to very different issues (pricing/value vs positioning/channel). On the ads side, I’ve found content or direct outreach tends to surface these signals faster than paid ads early on. Paid can hide weak demand if you’re not careful. Curious which of these Nick actually ran into.
I get what you are saying about the direct outreach being faster in surfacing the signald, but i don't understand how paid can hide weak demand.
If you track conversions and you get conversions - doesn't it mean that it works?
Good question - the nuance is what kind of conversion you’re seeing.
Paid can generate signups, but it often delays learning whether people would’ve sought the product without being pushed.
We’ve seen cases where ads convert to trials, but: no urgency, no referrals, weak retention, and no one reaches out proactively. That’s demand assisted by spend, not pulled by pain. Direct outreach/content tends to surface this faster because people either lean in on their own or they don’t.
When you say “it converts,” do those users turn into long-term paid customers, or does it tend to break later around retention, expansion, or reliance on ongoing spend?
This is such a valuable shift in mindset to share. Building something first and then validating often means wasted effort and burnout, and your approach to validate early with real signals instead of assumptions is exactly what helps ideas become sustainable products. It’s great how you’re sharing concrete steps around talking to users, testing demand, and avoiding the “build mode first” trap most founders fall into. Thanks for the transparency, and wishing you and others who read this clarity and momentum as you iterate smarter.
I have question: How to you validate idea before build Do Better?
After doing every thing perfect there comes a execution(distribution). Most people left this in mid journey due to its toughness and expensiveness. More power to you for doing this.
This comment was deleted a month ago.
I think distribution is critical too, even with a great idea and great product market fit/validation
This resonates deeply. I built 7 npm CLI packages with 800+ tests each - all technically solid, zero dependencies, clean APIs. Result: 0 downloads, 0 stars.
The realization hit hard: technical excellence doesn't create demand. I had the same pattern - Idea → build → polish → wait → nothing.
What changed for me: Instead of building another tool, I'm now offering technical research as a service first. If people actually pay me to research "best auth library for Next.js" or "Prisma vs Drizzle comparison", that validates there's demand. Then I can build tools around what people actually need.
Your point about "doing better" is spot on. The market doesn't need unique - it needs something that solves real problems better than the alternatives. Good luck with Do Better!
Good idea, and nice to see you didn't make it into a subscription as people would need do this occasionally.
"fast at building the wrong thing" hit different. been there too many times.
the tension i keep running into is that sometimes you dont know what users actually want until you build something and put it in front of them. like, market research says one thing but real usage reveals something else entirely.
curious how you balance that - do you draw a line somewhere between "validate first" and "just ship and learn"? or is it more about validating the problem vs validating the solution?
This really resonates. I've built and shipped projects that worked technically but went nowhere for the same reason - skipping real market validation. Building fast feels great, but it only matters if you're solving the right problem. Leve that you're turning those lessons into something useful. Wishing you all the best with Do Better!
Thanks for sharing this. I’m new to building ideas and this is a good reminder to focus on understanding the problem before jumping into execution.
This is a painfully honest takeaway and a familiar one. The pattern you describe (build → polish → silence) usually isn’t a product failure, it’s a signal failure.
One thing that’s helped me avoid that loop is spending time in places where users already vent, compare, and ask for alternatives especially Reddit. Those threads tend to surface demand before it turns into feature requests or willingness-to-pay conversations. You very quickly see what’s table stakes, what people hate, and where “doing better” actually means something concrete.
Validating at that level complaints, comparisons, switching stories ,often makes the product direction obvious before a single line of code. Curious to see how Do Better evolves with that lens applied.
Honestly, this really resonated. I’m building something right now because I kept seeing people exhausted before they even press play. It’s not that they can’t find content it’s that choosing has become work. Validating how people actually feel before building is the shift I’m making too.
Im a big fan of this. Im so quick to jump on an idea just by virtue of it being one. Market research is painful but it’s necessary. Any tool that can make this easier is a win in my books. Thanks for the post.
This hits close to home. Building first feels productive, but validating early is definitely the harder (and more uncomfortable) part. What’s the smallest validation step you’re trying now before committing to a build?
I have had similar issues in past, this was so motivating.
the "fast at building the wrong thing" part hits hard. been there multiple times.
tbh i've started thinking about it differently tho. the problem isn't building before validating - it's building without feedback loops. you can validate forever and still build the wrong thing.
what changed for me was shipping something ugly fast, then watching what people actually do with it. real usage data > survey answers. users lie (not intentionally), their behavior doesn't.
curious how you're thinking about the balance with Do Better - like at what point do you say "enough research, time to build"?
This hits uncomfortably close. ~
What finally clicked for me is that most of us aren’t really skipping validation—we’re doing a safe, diluted version of it. We read reviews, skim competitors, ask friendly people… but quietly avoid the moment where someone has to actually commit or flat-out say “no.”
Execution usually isn’t the problem.
Avoiding rejection is.
This hits. I’ve realized a big part of my problem wasn’t validating late, it was that months later I couldn’t even remember why I made earlier decisions. The context disappears even if the notes exist. Curious if that played a role for you too?
100%. You sometimes get into that insane, fully focused build mode. You build something great, but were focused on the tech/UX/UI and totally forgot why you wanted to create it.
This really hits home. I’m a dev from Korea, and I’ve fallen into the 'build-first, ask-later' trap more times than I’d like to admit. I’m currently building 'Dopamine Barrier' to solve my own addiction, and your point about 'doing better' rather than just being unique is exactly the mindset shift I needed. Thanks for the wake-up call!
Very well said Nick , i have faced similar kind of problems , then i decided to look for a problem that many people are facing . that's how i got the idea of "BUBBLES- a browser that isolates every identity so that you dont face chaos or get flagged" . i am looking forward to post it on IndieHackers but i dont have access yet which is also a problem many founders face at an early stage !
I'm currently testing validation using landing pages with waiting lists. You gave me some ideas about looking at competitors' weaknesses, which I think I did, but I'm not sure I've looked at them all. My question is: what technologies are you using in your project that I can't recreate within Claude Code or Codex with in-depth competitor analysis and research?
The question isn' really if you can recreate it, of course with enough time you probably can. But at which price point do you feel the price is worth the saved effort.
I just released my first self-made tool today as a total beginner in development.
Reading your post, I realized I hadn’t done any market validation at all either… it hit me hard.I really like the idea behind Do Better — once I save up a bit, I’m planning to subscribe!
Keep building and good luck with everything! 🍓
This really hits home. I built my SaaS after realizing how much time marketers waste guessing what to create — and I learned the hard way that execution alone isn’t enough without real validation. Love the “build after understanding” mindset. Curious to see how Do Better helps founders avoid that trap.
This really hits home a lot of builders (myself included) learn this lesson the hard way. Appreciate how honestly you break down the pattern and the shift toward validating first instead of just shipping faster. Do Better sounds like a solid attempt to turn hard-earned mistakes into something genuinely useful. Curious to see how you’re approaching validation this time happy to chat if you want to bounce ideas or compare notes.
This post hits home. The 'build first, ask later' trap is so easy to fall into, especially when you enjoy the building part. Your point about listening too late is crucial. Sometimes we confuse building fast with building right. Do Better seems like the tool I needed before my last project. How do you structure the 'deep research' phase to avoid paralysis by analysis? Finding the line between enough research and overthinking is my current battle
This is very helpful and of course market research is key to commercial success, but there is something to be said for learning how to build products too and not letting a bad idea or ill-formed product scope stop you from at least trialling the route-to-market process to prove you can do it -- and then take that confidence forward to iterate on better ideas with the right level of market research. There are some people out there who also don't even worry about new ideas but take current ideas (like successful apps) and clone it to either give people a simpler version, or work on making it some fraction of a percent better in some way that some people will appreciate and want.
I must say I'm already finding Do-Better useful at surfacing competitor apps for the one I'm currently working on, that I didn't know about. Great work!
Thanks for sharing that! I think I am following your pattern right now though I am not really building to sell, but it'd still be nice to build something that others use.
Building fast feels productive, but without validation it’s just speed in the wrong direction. Respect for turning past mistakes into a system instead of another app. Curious what signals you’re watching before writing code this time.
Amazing insights! Arian Adeli’s journey of building a venture studio from $0 to mid-five-figure monthly revenue shows the power of combining media, services, and SaaS products. Focusing on distribution, building flexible infrastructure, and growing organically is truly inspiring. For more tools, tips, and resources on scaling projects like this
This hits home hard — I've been in a similar loop, but on the discovery side.
On HN I just posted about how I've been relying on SEMrush/Similarweb for keywords to find small tool ideas, but it feels increasingly hollow: low-volume "easy" keywords, high-competition ones I don't understand deeply, and even when I find one, the real user intent and "where these people hang out" is a black box. SEO research feels like passive keyword hunting, while actually talking to users or living in their context feels active but hard to scale/systematize.
Your realization is spot on: building fast is worthless if it's the wrong thing. I love that you're turning past failures into "Do Better" — forcing validation upfront by analyzing what users already love/hate in existing tools is such a smart pivot. (Scraping reviews + AI patterns sounds super useful for avoiding the "gut feeling" trap.)
Curious: for your new approach, how early do you start talking to real users vs. relying purely on competitor review/sentiment data? And has shifting to "validate first" already changed how fast you move (or made you slower but more confident)?
Thanks for sharing this openly — it's motivating to see people fix the exact patterns that burn so many of us.
Finally, a post that resonates with me. I used to build tools that looked and worked perfectly, but to be honest, nobody asked for them. Instead of investigating what was wrong, I simply jumped to the next idea, only for it to fail as well.
This is why a 'simple, ugly' one-page website can often out-earn a beautifully designed one. We frequently build what looks good to us, assuming users will love it, only to be disappointed. A stunning website is useless if no one sees or uses it.
This time, do it differently: identify a real problem, research the market, and then build the product—not the other way around.
This is the core startup paradox: execution risk feels controllable, demand risk feels vague — so builders over-optimize for code. The hard skill isn’t shipping fast, it’s learning fast. Curious how you’re validating demand now before committing engineering time.
I am also trying to build a micro SaaS product and I think you are absolutely correct when you say that validate before you create, I am in process of creation but I need to hold my horses and get validation from the market before I go further. Thanks for this approach.
I used to follow the same approach, and some of those projects worked. Recently, I’ve shifted to finding distribution first, even before building the MVP.
Had many issues, you cleared my onfusios.
Years ago I ran into a problem. I was coding to learn Angular. I coded some random customer/invoicing UI to learn Angular, not to get customers.
At some point I wanted to see what it looked like on the cloud. Can someone else use it? I signed up for AWS and ... well, it was difficult. I didn’t know what S3, CloudFront, IAM etc. were so I let it be.
Later I was watching a demo about programming and using AWS and I got the idea: Setting up AWS environment should be so easy that anyone can do it.
I started to solve the problem and I’m developing Lime Boost. I’ve been showing it to everybody and probably the best feedback is when someone emailed me, we met and he said, "We would need this. How much does it cost?"
Here is the project https://limeboost.io there is a live demo – click Get Inspired.
I had also created 7 to 8 projects but what I was crying was to go to the see other what is working and trying to copying them and aliced one thing that yeah you will make money but there should be something which the user needs to actually be like this is better than what I am using so for that I feel it it's moreover convenience we should focus on convenience unique products need a R&D and if you got some cash then you may do something with that
Great insight
I really like this. I just finished my first app and one thing I did before I started (to be honest I just wanted to code something but thankfully I thought about it first) was look around for a problem to solve. I started looking in the automotive world because I come from that world. Great post!
I have been in this Engineer/Technologist trap several times. We take the easy path. Developing is easy for us compared to marketing/marketing research. Validation, especially market size validation, is hard. Marketing the product can be harder and much more time-consuming. But it is important to focus on these areas
This resonates with me so much, Nick. As a solo dev currently building a visa dashboard for Portugal (Nuri Flow), I often feel the itch to just 'polish the code' instead of talking to users. Your point about 'Listening too late' really hit home. I'm trying to validate my idea through community feedback first this time. Thanks for the wake-up call, and 'Do Better' sounds like a tool I definitely need!
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.
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.
Yes, it's live! Here it is:
iOS: https://apps.apple.com/app/selfos-daily-life-planner/id6756428834
Android: https://play.google.com/store/apps/details?id=com.selfos.app
Competitors — plenty: Todoist, Habitica, Notion, TickTick... but most are either too complex or focus on just one thing (tasks OR habits OR goals). SelfOS combines all four (tasks, habits, goals, shopping lists) in one simple app.
How I reached users so far:
Still tiny numbers, but enough to know the pain is real for others too.
About Do Better — makes sense, tracking sentiment over time manually would be a nightmare. Does it work with App Store + Google Play both?
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.
That's exactly my approach here. I think I am okay for now with solving my own problem first.
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.
That's a nice app with a clean ui.
Submit it in Kick Product . Its free. And It wont take more than a minute to publish it. Also no fake queues . Fair visibility to every product.
This comment was deleted 2 months ago.