How to validate a startup idea
Here’s the framework I use to evaluate any startup idea before committing to it.
I’ve spent years working in tech entrepreneurship — as an inventor, a founder, and an evaluator at a tech incubator. I’ve seen hundreds of ideas walk through the door. Most of them failed. Not because the idea was bad. Because the founder skipped the process.
Here’s the framework I use. Four questions, in order.
- Does it already exist?
Before anything else, find out if someone built this. Not just a quick Google search — a real market scan. Patents, existing products, funded startups in the space. If it exists, that’s not necessarily a dealbreaker. But you need to know what you’re walking into. - Does it have business viability?
A great idea and a viable business are two different things. Who is the customer? What are they paying today to solve this problem? Is the market big enough? Can you price it in a way that makes the unit economics work? I’ve seen genuinely brilliant ideas with no business model. Brilliant ideas don’t pay salaries. - Do YOU have the unfair advantage to execute it?
This is the one most founders skip — and it’s the most important.
Someone once came to me with an idea for a compact early-warning device for earthquake detection. Great idea. Real problem. I asked about his background. He said marketing. I asked how he planned to build the hardware. He said he’d hire people who know how.
That’s a startup with very low odds.
An idea without execution capability is just a wish. You need domain expertise — engineering depth, industry connections, or something that gives you a real edge over the next person who has the same idea. Because they exist. - Do you have experience as a founder?
This one might surprise you. I don’t necessarily think prior experience guarantees success. What I care about is whether the founder is aware of the complexity of the journey ahead.
The founders I believe in most are the ones who’ve already failed. Not despite the failure — because of it. Failure shows persistence. And it means they’re arriving at this new venture with real insight, not just enthusiasm.
When I sit across from a first-time founder, I want to hear that they understand what they’re getting into. When I sit across from someone who’s already been through it and is going again — that tells me everything.
What’s your process for evaluating ideas before you commit? Curious what others use.
Trending on Indie Hackers
The question I'd add to this framework—not as a fifth filter, but as a zeroth one—is whether I as the founder can clearly describe who has this problem right now and what that person's day looks like because of it. Not the market segment. Not the persona. The actual person. When I can answer that question in 2 sentences with specificity, I feel more confident to proceed. Your four questions are where evaluation lives. So for me it’d be your Question #1, my question of “What do current customers/people complain about most?”, and then your remaining 3 questions.
The unfair advantage question is the one I find myself coming back to most.
I'm building a procrastination tool, and my advantage isn't technical — I'm not an engineer. It's that I understand the emotional experience of being stuck well enough to keep stripping things back when the temptation is to add more. No streaks, no habit tracking, no daily reminders. Just one specific action, chosen by the user, when they're ready.
That clarity came from living the problem, not from a market analysis. I'm not sure that shows up well in a traditional framework — but your question 3 made me think about what 'unfair advantage' actually looks like when it isn't technical.
On question 4: I'd add that failure is only useful if the founder has actually processed it rather than just survived it. I've seen people go again with the same blindspots intact.
The distinction between surviving failure and processing it is exactly what Q4 is trying to get at , and lived expirence of the problem is one of the most underrated unfair advantage there is.