validation
Validate a side project before launch
Validate a startup idea and side project without fake metrics: interviews, commitment tests, thin builds, and a pre-launch checklist before you burn a hunt day.
8 min read
Validating a side project before launch means collecting evidence that strangers care, before you spend your only loud day asking the internet for upvotes. This is not a 40-page lean canvas. It is a short loop: talk, commit, build thin, watch behavior, then decide whether to launch or kill.
No invented conversion rates. No fake case studies. Operator steps you can run at night after a day job.
When validation clears and you want a discovery day, use the launch checklist and submit on MakerHunt as one surface among others. For the full launch sequence, see how to launch a startup in 2026 and how to launch on MakerHunt.
What validation is (and is not)
| Validation is | Validation is not |
|---|---|
| Evidence of time or money from non-friends | Compliments from Slack buddies |
| A clear job-to-be-done | A slogan that polls well |
| A thin path that works | A vision deck |
| A kill / continue decision | Endless “research” |
Friends will say it is cool. Strangers will ignore it. Design for strangers.
Step 1: Write the bet in one sentence
Format:
For [specific person] who [struggle], [product] does [job] unlike [current workaround].
Bad: “AI productivity for everyone.”
Good: “For freelance designers who lose briefs in email, a client intake form that exports a one-page brief to Notion.”
If you cannot name the workaround (spreadsheet, agency, incumbent SaaS), you do not understand the buying trigger yet. Browse category language on SaaS, productivity, design tools, or AI tools to see how people already label problems.
Step 2: Talk to five to ten target users
Who counts
- People who already pay for a messy solution
- People who recently complained in public about the problem
- Cold outreach that still replies (weak but useful)
Who does not count
- Only your cofounder
- Only Twitter mutuals who make tools too
- Anyone you have to bribe heavily to show up
What to ask
- How do you solve this today?
- What did you try that failed?
- What would make you switch this month?
- What is the budget owner and budget size?
- Can I watch you do the painful step once?
Record notes. Look for repeated language. That language becomes landing page copy.
Red flags in interviews
- “I would definitely use that” with no calendar pain
- Problem only happens once a year
- Buyer is not the user and you cannot reach the buyer
- They want a custom agency project, not a product
Step 3: Run a commitment test (stronger than a waitlist)
Rank commitment from weak to strong:
| Test | Strength | Notes |
|---|---|---|
| Email waitlist | Weak | Easy yes, low signal |
| Reply with use case | Medium | Forces articulation |
| Book a 20-min call | Medium | Time is scarce |
| Paid beta / deposit | Strong | Real money |
| Pre-order | Strong | Best early signal |
Aim for something above waitlist before you book Product Hunt or MakerHunt. A hunt day amplifies. It rarely creates willingness to pay from zero.
Practical indie move: a $20–$50 lifetime beta or a month of discounted access with a clear “this is unfinished” disclaimer. Refund policy stated up front. Honesty builds trust; fake scarcity does not.
Step 4: Ship a thin build, not a platform
Thin means one job works end to end.
Definition of done for a side project MVP
- User can start without a sales call
- Core job completes (file in, result out)
- Failure states are understandable
- You can support it in evenings
Cut list
- Multiplayer features
- Custom roles and permissions
- Native mobile (unless mobile is the product)
- AI everywhere when a form would do
- Perfect design system
Stack defaults live in best indie maker tools 2026. Use boring tools: Next.js or no-code, Stripe for money, one host, one database.
Step 5: Put up a landing page that tells the truth
Required blocks
- Headline with the noun and the job
- Who it is for / not for
- How it works (3 steps)
- Pricing or “paid beta” terms
- CTA that matches the commitment test
- FAQ (objection handling)
Optional but high signal
- Loom demo of the real product
- Named early user quote (with permission)
- Comparison to the workaround (“vs spreadsheet”, “vs hiring a VA”)
If you care about AI citations later, structure the page like a source: definitions, FAQ, clear pricing. See GEO for indie makers. For competitive framing, study how alternatives pages describe incumbents such as Notion, Airtable, ChatGPT, or Zapier.
Step 6: Measure behavior for two to four weeks
Forget vanity. Watch:
| Signal | Why it matters |
|---|---|
| Activation rate | Do they reach the aha? |
| Return within 7 days | Is the job recurring? |
| Payment attempts | Interest vs politeness |
| Support questions | Confusion map |
| Organic shares | Do they tell anyone? |
Qualitative still wins: five follow-up chats after people try the thin build.
If nobody returns and nobody pays after a real commitment test, do not schedule a launch day to “raise awareness.” Awareness of a product nobody keeps using is a tax on your reputation.
Step 7: Decide kill, pivot, or launch
Use an explicit decision, on a calendar date.
Kill when
- Interviews contradict each other and no segment emerges
- Commitment tests fail twice with different offers
- You dread supporting the product
- The only fans are other builders, not buyers
Killing is a successful validation outcome. It returns your nights.
Pivot when
- One segment clearly cares and others do not
- The job is right but the packaging is wrong
- Users hack your tool into a different use case (listen)
Launch when
- Thin build works for the named segment
- You have some non-friend usage or payment
- Landing page objections are answered
- You can babysit a launch day without the product falling over
Pre-launch checklist (validation → discovery)
Work this list in order. The interactive version lives at /tools/launch-checklist.
- One-sentence bet written
- 5–10 interviews done and notes synthesized
- Commitment test run (above waitlist if possible)
- Thin build live for the core job
- Landing page with honest FAQ and pricing
- Two weeks of behavior data reviewed
- Kill / pivot / launch decision recorded
- Discovery portfolio chosen (spike + shelf + community)
- Launch week sequenced (UTC if your hunt uses a fixed clock)
Only after the decision is “launch” should you open /projects/submit or a Product Hunt draft. Soft CTA: MakerHunt is one daily indie hunt. Free path uses Featured-on badge + crawl, then next UTC day (~09:00). Paid tiers skip badge (Premium €7, Featured €19, SEO €39). Votes decide PotD. Details: pricing explained, Product Hunt alternatives 2026.
A two-week validation sprint (template)
Use this if you need a calendar, not vibes.
| Day | Action |
|---|---|
| 1 | Write the one-sentence bet. List 20 outreach targets |
| 2–3 | Send outreach. Book calls. Draft landing outline |
| 4–5 | Run 3–5 interviews. Update the bet |
| 6 | Choose commitment test (paid beta, deposit, or booked calls) |
| 7–8 | Concierge or thin build that delivers the job once |
| 9 | Landing page live with honest FAQ |
| 10–12 | Run the commitment test. Talk to people who say yes and no |
| 13 | Review activation, replies, payments. Write a one-page memo |
| 14 | Kill, pivot, or schedule launch prep |
If day 14 is “launch,” open the launch checklist and sequence discovery. If day 14 is “kill,” archive the repo without shame.
Smoke tests that beat opinions
Before you invest a month of nights:
- Manual concierge: sell the outcome, deliver by hand, note which steps hurt
- Fake door: landing CTA that explains “not ready, join waitlist” only after you already have interview signal (do not use this as your only test)
- Competitor gap notes: skim alternatives pages for the incumbent you threaten (Notion, Airtable, ChatGPT) and list complaints you can actually fix
Smoke tests are for learning. They are not permission to spam communities with half-built links.
Validation myths that waste months
- “Build it and they will come.” They will not. Distribution is a separate skill.
- “I need more features before anyone can judge.” They judge the job. Features after retention.
- “A viral launch will validate it.” A launch measures campaign skill and novelty. Retention measures product.
- “NDAs before interviews.” Usually slows learning. Share less detail, talk more about their workflow.
- “Fake waitlist numbers.” Inflated lists poison your own judgment.
- “I already know the market because I have the problem.” You are one data point. Interview anyway.
Side project constraints (be honest)
You have limited nights and a job. Design validation for that:
- Cap interview weeks (two weeks, then decide)
- Cap build time before the first commitment test (one to two weekends for a landing + manual concierge if needed)
- Concierge MVP is allowed: Google Form in, you deliver manually, then automate what repeats
Concierge feels unscalable. That is the point. You are buying learning, not ARR theater.
Where MakerHunt fits after validation
When the bet is real, put the product on discovery surfaces that match the segment. Categories help cold browsers: web apps, developer tools, marketing, automation. Alternatives pages help comparison shoppers: start from alternatives or incumbents like Product Hunt, Linear, Stripe.
MakerHunt gives you a launch day with votes and comments, plus shelf pages for categories and alternatives. Use it after validation, not instead of it. Prep ops: UTC launch day playbook, Featured-on badge guide, PotD ranking.