The most expensive mistake an early-stage developer can make isn't writing bad code. It's writing good code for something nobody wanted.
I learned this the slow way — by building things, shipping them, and watching them land with silence. Eventually I stopped treating validation as a step you do after you're excited about an idea, and started treating it as the thing that decides whether the idea deserves your time at all.
Here's the process I actually use now, before any code gets written.
Step 1: Talk to actual humans before you talk to yourself
This is the step almost everyone skips, and it's the most important one.
Before building anything, I try to have real conversations with people who might have the problem I think I'm solving. Not surveys. Not polls. Conversations.
The goal isn't to pitch them on my idea. It's the opposite — I want to understand their current situation without mentioning my idea at all. How do they currently deal with this problem? What do they use? What annoys them about it? How often does this come up? What have they tried that didn't work?
If someone describes a real, recurring frustration without me prompting them toward it, that's a signal. If I have to lead them to the problem — "don't you wish there was a tool that..." — that's a different signal, and usually not a good one.
A few things I watch for in these conversations:
- Do they bring it up unprompted? A problem someone is actively annoyed by comes up naturally. A problem that only exists when you suggest it probably isn't urgent enough.
- What are they currently doing instead? "Nothing, I just deal with it" is a weaker signal than "I use three different spreadsheets and it's a mess." The second person has already invested effort into solving this badly — which means they'd likely invest in solving it well.
- How do they talk about it? Frustration, specific complaints, war stories — these are good signs. A shrug is not. I try to talk to at least five to ten people before I take an idea seriously. Not because that's statistically significant — it's not — but because patterns start to emerge. If three out of seven people independently describe the same frustration in similar terms, that's worth paying attention to.
Step 2: Research competitors — and read between the lines
Once I have a sense that a problem is real, I look at who else is solving it.
The instinct here is often "if there's competition, the market is taken." I think that's backwards. Competition is evidence that people pay for solutions to this problem. The absence of any competitors is often a worse sign than the presence of several — it can mean the market is too small, the problem isn't actually painful enough, or someone already tried and it didn't work.
What I actually look for:
Reviews — especially the negative ones. This is where the real signal lives. I read through reviews of existing tools looking for recurring complaints. If multiple people are saying the same thing — "great idea but the onboarding is confusing," "wish it had X feature," "too expensive for what it does" — that's not just feedback for the existing product. That's a map of where the gap is.
Pricing and positioning. What are people actually paying for this? Is there a tier that's clearly underserved — too expensive for individuals, too basic for teams? Sometimes the opportunity isn't a new product, it's a different price point or a narrower audience for an existing idea.
How long competitors have existed and how they're evolving. A product that's been around for years and is still actively updated suggests a durable market. A graveyard of abandoned competitors might mean the problem is hard to monetize — or it might mean nobody executed well. Worth digging into which.
What they're NOT doing. This is the most useful one. Existing tools are often built for a specific audience or use case, and they tend to stay there — not because nothing else makes sense, but because pivoting is hard once you have existing users. That creates room for someone building specifically for the audience being left out.
Step 3: Find the gap — and be honest about whether it's real
This is where talking to users and researching competitors come together.
The gap I'm looking for is the overlap between "a problem people actually described to me" and "something existing solutions don't address well." When both of those point in the same direction, that's a real signal. When only one does, I'm more cautious.
A few honest questions I ask myself at this stage:
Is this gap big enough to matter? Some gaps are real but tiny — they affect a narrow slice of users in a minor way. That might be a feature for an existing product, not a reason to build a new one.
Why hasn't anyone filled this gap already? Sometimes the answer is "nobody's thought of it" — which is rare. More often it's "it's hard to build," "it's hard to monetize," or "the audience is too small to be worth it for existing players." Understanding why the gap exists tells you whether it's an opportunity or a trap.
Am I solving this because users need it, or because I find it interesting? This is the hardest one to be honest about. As a developer, it's easy to get excited about a technically interesting problem and convince yourself there's a market need to match. Sometimes there is. Often the excitement and the need are pointing in different directions, and only one of them pays the bills.
Step 4: Define what "validated enough" looks like — before you start
One thing I've learned: validation can become a way to avoid building, just as much as skipping it can lead you to build the wrong thing.
So before I start the process, I try to define what would make me confident enough to start building. For me, that's usually some combination of: a handful of people independently describing the same problem in their own words, a competitive landscape that shows people pay for adjacent solutions, and a specific gap I can articulate in one sentence without hedging.
It doesn't need to be certainty. It needs to be enough signal that building feels like a reasonable bet rather than a hope.
Why I ended up building a tool for this
After going through this process manually a few times — talking to people, digging through reviews, trying to keep track of competitor research across different ideas — I noticed the process itself was repetitive enough that I started automating parts of it.
That eventually became IdeaPick — a tool that takes an idea, pulls real competitor and market data, and generates a structured validation report: market gaps, competition signals, risks, and a starting point for the kind of research I described above.
It doesn't replace talking to real users — nothing does. But it does a lot of the competitor research and gap-finding legwork automatically, which means more time can go toward the conversations that actually matter.
The honest summary: ideas are cheap, and almost every idea sounds good when you're the one having it. The framework above isn't about proving an idea is good — it's about giving a bad idea enough chances to reveal itself before you've spent months building it.
How do you validate ideas before building? Curious what other developers and indie hackers actually do — or don't do — before writing code.
Top comments (0)