How to validate a startup idea before you write any code

AI coding tools have made building fast enough that the bottleneck on most startups is no longer "can I ship this." It's "should I ship this, and to whom." A solo founder can go from idea to working product in a weekend now - which means the old excuse for skipping validation (building takes too long to also do discovery first) has quietly disappeared, and the products that fail are increasingly ones that were technically well-built and never wanted. This is a practical walkthrough of how to validate an idea before you write any code, using the same structure a systematic co-founder would push you through: sharpen the hunch into something testable, find the right people to test it on, and know what a real answer actually looks like.

The core mistake: validating with people who want you to succeed

The single most common validation mistake is asking friends, family, or people who already like you whether your idea is good. It isn't that they're lying - it's that agreement from people who want you to succeed isn't signal. They're primed to be encouraging, they don't have the problem you're solving in a way that matters to them, and "that sounds cool" costs them nothing to say. The same failure mode shows up with AI chatbots: ask a general-purpose model if your idea is good, and it will very often tell you yes, because agreeableness is close to its default behavior. False confidence from either source is a real reason a lot of AI-built products launch to zero users - the building got easier, but the part where you find out if anyone actually wants the thing never happened.

Real validation requires deliberately seeking out disconfirming evidence, not confirming evidence. That reframe changes almost everything else about how you approach the next few steps: who you talk to, what you ask them, and how you interpret a "yes."

Step 1: Turn your hunch into a testable hypothesis

"People would probably use this" is not a hypothesis - it's a feeling, and feelings can't be falsified. A hypothesis is a specific, falsifiable claim about what needs to be true for your idea to work. There's a useful three-tier way to think about hypothesis quality: bad, good, and great.

• Bad: a vague or unfalsifiable claim that can't meaningfully be tested or disproven. "People will love this product" is the textbook example - there's no way to fail that test, which means it isn't a test.
• Good: a specific, testable claim that names a customer and a behavior. "Solo engineering managers at 20-50 person startups will pay for a tool that summarizes their 1:1 notes" names who, and names what they'd do.
• Great: everything Good requires, plus a measurable threshold that defines pass/fail, and it targets the single highest-leverage unknown for the idea - the riskiest assumption, not a peripheral one. "At least 6 of 10 solo EMs we interview will say they currently pay for, or would pay for, a 1:1-notes summarizer, when asked directly about their current workflow" is a hypothesis you can actually fail, on the question that matters most.

Notice what the Great example does that the Good one doesn't: it commits to a number in advance. Without a threshold set before you talk to anyone, it's dangerously easy to talk yourself into whatever result you get - 3 out of 10 politely-interested people can feel like validation if you're motivated enough to read it that way. Decide what counts as pass or fail before you have the conversations, not after.

Step 2: Get your customer persona and ICP signals right

A vague persona quietly sabotages everything downstream, because you can't identify who to interview, ask precise questions, or judge whether feedback generalizes. The test for a strong persona is simple: could this description apply to more than one idea without changing a word? "Young professionals" or "small business owners" fail that test instantly - they're demographic labels, not descriptions of a real situation. "Solo engineering managers at 20-50 person, Series A-B startups, managing 4-8 reports" passes, because it implies a specific set of behaviors, constraints, and pressures you can reason about.

Once the persona is specific, the next thing you need is ICP signals - concrete, observable things that let you recognize a real prospect when you see one. A signal is something you could actually search for or ask about: a job title, a tool they already use, a public complaint or post about the problem, a company milestone like a recent funding round. "Restates the persona in different words" doesn't count as a signal. "Just raised a Series A and posted in r/EngineeringManagers about 1:1 fatigue" does - you could go find that person today.

Step 3: Find the right people to interview - not just your network

A good validation interviewee clears a few bars that have nothing to do with how easy they are to reach:

1. They currently have the problem, not just relate to it in theory. Someone who can describe the last specific time it happened to them, unprompted, is stronger signal than someone who nods along.
2. They match your actual ICP signals, not just the demographic persona. You should be able to point at a concrete reason you're talking to this specific person.
3. If the idea has any B2B or paid-solution component, they have - or recently had - the budget or authority to solve this problem themselves. Agreement from someone with no path to actually adopting a solution produces a nice conversation and no signal.
4. They add diversity within the persona, not just volume. Five interviews with people who are all the same sub-type - all early-career, say - risks a false-confident result that doesn't generalize. Prefer breadth across the persona's real variation (seniority, company size, industry) over five near-duplicates.
5. They're reachable within one or two degrees, realistically - a warm intro, an existing connection, or a community where the persona is known to spend time. A theoretically perfect interviewee you have no path to reach isn't useful advice, it's a wish.

In roughly descending order of effort-to-yield for a solo founder starting from zero: your existing professional network filtered against ICP signals first, then communities where the persona is already discussing this exact problem (not just members of a broad community - people actively posting about the pain point), then targeted cold outreach to people who match your signals and show public activity suggesting the problem, and adjacent professional events or meetups as a last resort when the first three are exhausted.

It's worth being honest about the yield you should expect from each channel. Your existing network is fastest to reach but smallest and most likely to be biased toward people who already like you, so treat those conversations as a warm-up, not your full sample. Problem-specific communities are slower to break into but produce people who are already primed to talk about the exact pain point, which tends to yield the sharpest, most specific answers. Cold outreach is the slowest and has the lowest response rate of the three, but it's also the only channel with no selection bias toward people who already know you, which makes even a handful of cold responses disproportionately valuable as a check on what the warmer channels told you.

Step 4: Run the interview to get signal, not comfort

The two habits that ruin an otherwise well-set-up validation round both happen inside the conversation itself. The first is only interviewing people who already said yes to a beta or waitlist - self-selected enthusiasm skews your results toward false positives before you've asked a single question. The second is stopping at the first one or two people who confirm the hypothesis. Confirmation bias is strongest exactly when you want to be done; the goal of an interview round is to find the pattern across five conversations, not to get an early yes and declare victory.

In the room (or on the call), ask about specific past behavior rather than hypothetical future behavior. "Tell me about the last time this happened" produces real signal. "Would you use a tool that did X?" produces polite hypotheticals - almost everyone says yes to a well-described hypothetical, which is exactly why it's a weak question.

Step 5: Decide what "validated" actually means

This is where the threshold you set in Step 1 earns its keep. "Validated" should mean you hit the number you committed to in advance, across a genuinely diverse sample, on the riskiest assumption - not "most people I talked to seemed positive." If you fall short, that's not a failure of the idea, it's exactly the kind of information validation exists to surface, cheaply, before you've built anything. Sharpen the hypothesis, revisit the persona, or talk to a different slice of the ICP, and run it again.

Putting it together

None of this is complicated in principle - sharpen the claim, define the persona and signals precisely, find people who actually clear the bar, ask about real past behavior, and hold yourself to the threshold you set before you started. What's hard is doing it consistently, especially the parts that require pushing past a comfortable early yes. That consistency is exactly what a structured process (or a co-founder who insists on it) is for. Nucleus is built around this exact loop - sharpening a raw idea into a testable hypothesis, surfacing real people worth interviewing from your own network, and keeping you honest about what the evidence actually says - so validation happens before the build, not as an afterthought once the product already exists.