How to Validate Your Product Idea Before Writing Code

Why Most Solo Founders Skip the Wrong Step

The Build-First Trap

You've spent 3 weeks collecting signals. You have a direction document. The problem is real, the user profile is clear, and you can already see the architecture in your head.

The temptation to open your editor is overwhelming. Every founder feels it.

Here's what happens when you give in:

You build for 2 months. You launch. You post on Reddit and Twitter. And then — silence. The signups don't come. The people who do sign up don't come back. You have a working product and zero evidence that anyone wants it.

The build-first trap is the most expensive mistake in solo development. It turns 2 months of work into a very expensive way to learn something you could have learned in 2 weeks with no code at all.

What Validation Actually Is

Validation is the process of confirming that strangers — not friends, not colleagues, not people being polite — will take a concrete action that signals willingness to pay.

A concrete action is one of:

• Giving you an email address on a landing page that clearly describes the product and price
• Scheduling a 20-minute call to discuss their problem in detail
• Paying a deposit or pre-ordering before the product exists
• Sending you a screenshot of their current painful workflow

A concrete action is NOT:

• A like, retweet, or upvote
• "This sounds cool!"
• "Let me know when it's ready" (without giving contact info)
• Your mom saying she'd use it

Validation takes 2-6 weeks and requires zero code. The tools you need: a landing page builder, a calendar link, and the willingness to have awkward conversations with strangers.

---

The Three Validation Methods

There are three primary ways to validate a product direction. Use at least two before moving to Build.

Method 1: The Landing Page Test

What it is: A single page that describes your product, shows a price, and has one call to action — typically "Join the waitlist" or "Get early access."

How to run it:

1. Write a headline that names the user and the outcome: "Weekly reports that write themselves — for engineering managers who hate Fridays."
2. Write 2-3 sentences about what the product does. Focus on the outcome, not the features. "Connect your Slack, Jira, and GitHub. Every Friday morning, get a draft report in your inbox. Edit and send in 10 minutes instead of 3 hours."
3. Show a price. Not "Free" or "TBD" — a real number. Pricing signals seriousness. "$29/month" gets more honest reactions than "Contact us."
4. Add a single CTA: an email input + button. That's it. No "Learn More" link, no feature tour, no pricing page with three tiers. One page, one action.
5. Drive traffic to the page. Post in relevant subreddits, niche forums, Slack/Discord communities where your target users hang out. Do not post on "startup marketing" channels — you want target users, not other founders.

What to measure:

The conversion rate from visitor to email signup. But more importantly — the conversations you have with the people who sign up. Every signup is an opportunity for a 20-minute call.

How long: 3-5 days to build and start collecting emails. 1-2 weeks of driving traffic.

Method 2: The Problem Interview

What it is: A 20-minute conversation with someone who has the problem you want to solve. You are not selling. You are not showing a prototype. You are listening.

How to run it:

1. Find 10-15 people who match your target user profile. Reddit DMs, Twitter DMs, Slack communities, LinkedIn. The ask: "I'm researching [problem area] and would love 20 minutes of your time. No pitch, just listening."
2. Prepare 5 questions — but be ready to deviate. The best insights come from follow-ups, not from your script.

The five questions:

1. "Tell me about the last time you faced [problem]. Walk me through what happened."
2. "How did you solve it? What did you actually do?"
3. "What did you try before that? Why didn't it work?"
4. "How much time or money does this problem cost you per month?"
5. "Is there anything else about this problem I should have asked about?"

Notice what's missing: "Would you use a product that does X?" and "How much would you pay for this?" These questions generate polite lies. People say yes to be nice. People say they'd pay $50 and then don't pay $5.

Instead, look for evidence in their behavior:

• Have they paid for tools that address adjacent problems?
• Did they build their own janky solution (a spreadsheet, a script, a Zapier hack)?
• Do they bring up the problem unprompted, or only when you ask?

1. At the end of the call: "This has been really helpful. If I build something that solves this, would it be okay if I reached out to you to try an early version?"

If they say yes and give you their email, that's a weak positive signal. If they ask "when can I try it?", that's a strong one. If they say "please email me when you have something, I need this yesterday", you've found your first user.

What to measure:

After 10-15 interviews, categorize each person:

• Strong signal: They described the problem vividly, have tried multiple solutions, are actively spending money or time on it, and asked you to follow up.
• Weak signal: They acknowledged the problem exists but aren't actively trying to solve it.
• No signal: They were polite but the problem clearly isn't a priority.

If fewer than 5 out of 15 are strong signals, the direction is probably not worth building. If 8+ are strong signals, move to Method 3.

How long: 1-2 weeks to schedule and conduct 10-15 interviews.

Method 3: The Pre-Order Test

What it is: Asking for money before the product exists. This is the strongest validation signal you can get — someone parting with actual cash.

How to run it:

1. After your landing page has collected emails and you've done interviews, email everyone who showed strong interest.
2. The email should say something like:

1. You don't need a payment processor. A Stripe Payment Link takes 2 minutes to set up. Or use Gumroad, Lemon Squeezy, or even a PayPal link.

What to measure:

How many people actually pay. This is the only metric that matters.

• 0-2 pre-orders: The direction is unvalidated. Either the problem isn't painful enough, the solution isn't compelling, or you're talking to the wrong people. Return to Discovery or try another direction.
• 3-9 pre-orders: Moderate evidence. You have something, but not enough to quit your job. Consider whether you can narrow the audience further.
• 10+ pre-orders: Strong evidence. Someone is willing to pay for this. Build the MVP.

How long: 1-2 weeks to run the pre-order campaign.

---

What Good Validation Looks Like

A Real Validation Story

A developer had a direction: a tool that automatically generates changelogs from git commits for SaaS teams.

Week 1: Built a landing page with Carrd (2 hours). Headline: "Changelogs that write themselves. Connect GitHub, publish with one click." Price: $19/month. CTA: "Get early access."

Posted in r/SaaS, r/webdev, and a few Slack communities. 34 signups in 5 days.

Week 2-3: Emailed every signup. "I'm researching how teams handle changelogs. 20-minute call?" Booked 12 calls.

Key findings from the calls:

• 8 out of 12 people had already tried to solve this (using git log + manual editing, or paying a VA to do it)
• The main objection: "We already have too many tools. Can this just post to our existing Slack channel?"
• One person said: "I've been asking my team to write a script for this for 6 months. If you build this, I'll be your first customer."

Week 4: Emailed the 8 strong-signal interviewees with a pre-order offer: "$49 lifetime (instead of $19/month) for the first 15 people."

Result: 11 people pre-ordered within 48 hours. $539 in pre-orders before a single line of code.

He started building the next day.

A Real Failure Story (More Valuable to Study)

Another developer had a direction: a collaborative debugging tool for remote engineering teams.

Landing page: 200 signups. Seemed promising.

Interviews: 15 calls. Everyone said "this is a real problem." But:

• Only 2 people had tried to solve it themselves (the other 13 just "lived with it")
• No one was spending money on adjacent debugging tools
• When asked "how much time does this cost you?", answers were vague: "I don't know, a few hours maybe?"

Pre-order: 0 sales out of 200 signups and 15 positive conversations.

He killed the direction and moved to his second choice. That second direction became a profitable product.

---

Common Validation Mistakes

Mistake 1: Asking "Would You Use This?"

This question produces exactly one answer: "Yes!" — regardless of whether the person would actually use it, pay for it, or even remember it tomorrow.

The fix: Ask about their behavior, not their opinions. "How do you solve this today?" reveals more than "Would you use my solution?"

Mistake 2: Interpreting "That's Interesting" as Validation

"That's interesting" is the most dangerous phrase in validation. It sounds positive but means nothing. People find lots of things interesting — documentaries about deep-sea creatures, articles about Roman aqueducts, your product idea. They're not going to pay for any of them.

The fix: If someone says "that's interesting," follow up with: "Would you be willing to spend 20 minutes next week trying an early version?" If they hesitate, it was just interesting.

Mistake 3: Validating With the Wrong People

Your friends say it's a great idea. Your former colleagues say they'd pay for it. People in your Slack community say they have this problem.

These people like you. They want you to succeed. Their feedback is contaminated by social pressure and should be discounted to near zero.

The fix: Validate with strangers who match your target user profile and have no social connection to you. Reddit, cold emails, niche forums. If the validation signal persists when nobody is being nice to you, it's real.

Mistake 4: Collecting Emails Without Following Up

A waitlist of 200 emails is not validation. It's a list of 200 people who spent 3 seconds typing their email — and who will forget about you within 48 hours if you don't talk to them.

The fix: Email every single signup within 48 hours. Not a newsletter. Not a "thanks for signing up." A personal email from you asking for a 20-minute conversation. A 50-person waitlist with 10 interviews is worth more than a 500-person waitlist with zero conversations.

Mistake 5: Building a "Validation Prototype" That Takes 3 Weeks

If your "validation" involves writing code for 3 weeks, you're building an MVP, not validating. Validation should take zero code. A landing page (Carrd, Notion, Google Forms), a calendar link (Calendly), and a way to collect payments (Stripe Payment Link) — that's the entire validation toolkit.

The fix: Set a rule: "I will not open my editor until I have 10 pre-orders or 10 strong interview signals." The keyboard is a validation escape hatch — you reach for it because coding is comfortable and talking to strangers is not.

Mistake 6: The Long Landing Page

Your landing page should be scannable in 10 seconds. Headline. Two sentences. Price. CTA. Done.

A landing page with 8 sections, testimonials (whose? you haven't built anything), feature comparisons, and a FAQ is not validation — it's procrastination dressed as marketing. You're writing copy instead of testing whether anyone cares.

The fix: Set a timer for 90 minutes. Build the page. Publish it. Start sending traffic. You can improve the copy later — after you know whether the direction has any life in it.

---

Exit Checklist

You're ready to move from Validation to Build when:

• You've tested at least 2 of the 3 validation methods (landing page, interviews, pre-orders)
• You've completed at least 10 user interviews with strangers who match your target profile
• At least 5 interview subjects showed strong signal (vivid problem description, existing workarounds, asked for follow-up)
• You have 10+ pre-orders OR 10+ interview subjects who explicitly asked to be notified when you launch
• You can describe the problem in your target users' words, not your own
• You understand what people currently do to solve this problem and why it's inadequate
• You have at least one backup direction ready if Build reveals that this direction needs a pivot
• You've set a hard timebox for the Build phase (maximum 12 weeks)

If Validation Failed

Validation failure is normal and valuable. It saved you months of building the wrong thing.

What to do next:

1. If you had strong interview signals but zero pre-orders: your solution isn't compelling. Revisit the problem description. Ask interviewees what they'd actually pay for.
2. If you couldn't get interviews: your audience is unreachable with your current channels. Pick a direction where you can reach the users.
3. If everything was lukewarm: move to your second direction and run validation again. You didn't fail — you ruled out a bad direction cheaply.

---

Validation Reference Card

---

Next Step

Once validation confirms people will pay for your solution, move to Build. Your goal: ship something functional in the least amount of time and put it in front of the people who already told you they want it.

For more on the validation process, see the full Validation guide with step-by-step instructions for landing pages, interviews, and pre-orders.