Chapter 14: Validate Track — Prove People Care

Most indie projects die not because they’re badly built, but because they solve problems nobody cares about.

That’s why validation is the first track. Before distribution, before monetization, before retention—you need proof that real humans feel the pain you’re solving and want your solution.

The Validate Track is about de‑risking your effort. Instead of investing six months, you invest one loop and leave with evidence you can point to.

Why Validation Matters

Indie founders often skip validation because it feels slow or awkward. They think:

• “I’ll just build it and see.”

• “If the product is good, users will come.”

• “Talking to people isn’t coding. It’s not real work.”

I used to think that too. Which is why I buried 65 projects.

Validation flips that. It forces you to ask: “Do people care enough to respond?” before you pour energy into features. You trade comfort for clarity and learn sooner whether the problem is sharp and present.

Choosing Problems Worth Testing

Write problems, not features. Good candidates sound like pains people already try to solve today. You should be able to name who feels it, when they feel it, and what they do as a workaround. If you can’t, the problem is probably too vague for a first loop.

How to Run a Validate Loop

The six steps of TenK 6 stay the same—but here’s how they look inside validation.

1. List 5 — Capture Hypotheses

Write down five possible problems or customer pains.
Not features. Not solutions. Problems.

Example:

1. Indie devs abandon projects due to lack of accountability.

2. Small YouTubers struggle to generate fresh content ideas.

3. Freelancers lose track of unpaid invoices.

4. Remote teams get stuck without async visibility.

5. Parents can’t find kid-friendly, ad-free apps.

2. Pick 1 — Choose One Problem

Select the problem that feels most promising or urgent.
Criteria:

• You know people with this problem.

• You can test it quickly.

• It energizes (or scares) you.

3. Ship 1 — Create a Fast Test

Don’t build a full product. Ship the minimum artifact that lets you test interest. Examples:

• A Google Form survey.

• A landing page with an email sign-up.

• A clickable Figma mockup.

• A “fake door” (button that says “Coming Soon”).

The goal isn’t polish—it’s evidence. Ship something a real person can react to in under a minute. If they need ten minutes to understand it, the test is too heavy.

Examples by format:

• Landing page: one promise, one screenshot, one button.
• Survey: three questions max; one free‑text question to learn words users use.
• Mockup: a click‑through of the core flow; no dead‑end walls of text.

4. Ask 3 — Talk to People

Reach out to three potential users:

• Friends in the space.

• Strangers on forums or Discord.

• People tweeting about the problem.

Ask simple questions:

• “Do you run into this?”

• “How are you solving it today?”

• “Would this solution help?”

5. Measure 1 — Track a Real Signal

Pick one metric that shows real interest:

• Number of people who gave you their email.

• Number of “yes, I’d pay” responses.

• Number of survey replies.

If it’s zero, that’s evidence too. Zero responses after honest outreach usually means the problem isn’t sharp, the audience is wrong, or the artifact is unclear. Change one variable and run another tiny test.

Signals vs. Noise

Signals look like action: replies, sign‑ups, calendar bookings, pre‑orders. Noise looks like compliments, likes, and vague “sounds cool.” Treat compliments as encouragement, not validation.

6. Share 1 — Publish Your Learnings

Don’t hide validation results. Share them:

• Blog post: “I tested 5 ideas, here’s what happened.”

• Tweet thread: “Ran my first validation loop. 17 people said yes to problem X.”

• Indie Hackers post: “Survey results show freelancers really struggle with Y.”

Sharing builds credibility and attracts people who care about the problem.

A Real Example: Indie10k Validation

When I first tested the “growth coach” idea (which became Indie10k), I didn’t build a product.

• Ship → I made a landing page with a fake login.

• Ask → Posted on Indie Hackers, Product Hunt forum, and DM’d a few Reddit users.

• Measure → 17 people signed up, 3 messaged me directly saying “this is gold.”

• Share → Wrote a build log about why the $10k framing resonated.

That was enough validation to justify the next loop. Importantly, the wording people used in replies (“$10k felt concrete”) became copy on the landing page. Let the market write your headline.

Pitfalls to Avoid

• Overbuilding. A landing page beats a full app.

• Fishing for compliments. You don’t want “this is cool.” You want action: sign-ups, pre-orders, feedback.

• Ignoring silence. No replies = clear evidence. Don’t sugarcoat.

• Stalling. Validation doesn’t take months. It takes one loop.

• Testing too much at once. Change one thing per loop so you know what moved the number.

Micro-Exercise

Right now:

1. Write five problems you think are worth solving.

2. Circle one.

3. In the next 48 hours, ship a test artifact.

4. Message three people who match the problem and ask for a two‑minute reaction.

By the end of the week, you’ll have real evidence—not just intuition.

Key Principle: Proof Before Progress

Every Validate loop should leave behind proof: a survey response, a screenshot of sign-ups, a “yes” email, a Stripe pre-order.

If you can’t collect evidence, you haven’t validated.

👉 In Chapter 15: Distribute Track, we’ll move from validation to visibility—growing your audience so more people know about what you’re building.