How to validate a side-project product idea in 72 hours (before you write a line of code)

Side projects have a specific failure mode, and it's a very common one.

You get an idea on a Thursday. By Sunday night you've picked a stack, set up auth, written a landing page and argued with yourself about Tailwind. Two weeks later it's live. You post it once, maybe twice. A handful of people visit. Nobody pays. And because you never checked whether anyone wanted it, you can't tell whether the idea was bad or the launch was.

Building is the fun part, so it happens first. Validation feels like homework, so it gets skipped.

This post is a lightweight validation method sized for small products: templates, tools, guides, Notion setups, spreadsheet systems, browser extensions, anything where the build is days, not months. It takes about 72 hours, and it ends with a clear yes or no.

Why "would you use this?" doesn't work

The instinct is to ask people. Post in a Discord: "Would you use a tool that does X?" You'll get a few "yeah, sounds cool!" replies and feel validated.

It's worthless data. People are polite, and they're bad at predicting their own behavior. "Would you use this?" measures how nice your friends are.

What you want instead is evidence of behavior: money already being spent, people already complaining in public, strangers taking a costly action after seeing your offer. That's what the three levels below collect.

Step 0: The six-question filter

Before spending any time on research, run the idea through six yes/no questions. If you can't get at least five yeses, move to the next idea.

1. Specific buyer. Can you describe who it's for in terms of their situation? "Freelance developers who invoice in multiple currencies" beats "developers."
2. Urgent pain. Does the problem cost them time, money or stress this month, not someday?
3. Existing spend. Are people already paying for some kind of fix: a competitor, a freelancer, a clunky workaround?
4. Reachable. Do these people gather somewhere you can join for free: subreddits, forums, Discords, a hashtag?
5. Shippable. Can you build a useful v1 in about 72 hours?
6. Credible. Do you actually understand the problem well enough to help?

Since this is DEV, here's the filter as a tiny script. It won't make the decision for you, but it stops you from cheating on the scoring:

TESTS = ["specific_buyer", "urgent_pain", "existing_spend",
         "reachable", "shippable", "credible"]

ideas = {
    "multi-currency invoice tracker for freelance devs": [1, 1, 1, 1, 1, 1],
    "AI habit tracker for everyone":                      [0, 0, 1, 0, 1, 1],
    "API changelog generator for small SaaS teams":       [1, 0, 1, 1, 0, 1],
}

for name, scores in sorted(ideas.items(), key=lambda kv: -sum(kv[1])):
    verdict = "VALIDATE" if sum(scores) >= 5 else "skip"
    missing = [t for t, s in zip(TESTS, scores) if not s]
    print(f"{sum(scores)}/6  {verdict:<8}  {name}  {('missing: ' + ', '.join(missing)) if missing else ''}")

The ideas that fail usually fail on "specific buyer." That's fixable. Narrow the buyer and score again.

Level 1: Market proof (about 2 hours)

Find at least three competing products with visible signs of sales.

Where to look depends on the format:

• Templates and printables: Etsy (review counts are public), Gumroad Discover, Notion's template gallery.
• Dev tools and extensions: Chrome Web Store user counts, VS Code marketplace installs, GitHub stars on paid open-core projects, "alternatives to" pages.
• Guides and courses: Gumroad, Amazon (for ebooks), Udemy enrollment counts.

For each one, log: price, number of reviews or users, format, what reviewers like, and the most common complaint. That last column is the important one. The one-star and three-star reviews are free product research. "Too complicated," "no docs," "doesn't support X" are all specs for a better, narrower version.

If you find zero competitors, that's usually bad news, not good news. It's tempting to think you've found a blue ocean. Far more often, nobody's paying for it. A crowded market with proven sales is a much safer bet for a first product.

Level 2: Language proof (about 2 hours)

Collect 15 exact quotes from people describing the problem in their own words, with links.

Search queries that surface them (use them on Reddit, forums, Hacker News comments, GitHub issues and Stack Exchange):

"is there a tool for" <task>
"is there a template for" <task>
"how do you keep track of" <thing>
"what do you use for" <task>
"I wish there was" <niche>
"I'm so tired of" <task>
<niche> "spreadsheet"

Copy them verbatim into a sheet. Don't paraphrase. When you write your landing page later, these phrases become your headline and bullets, and they'll outperform anything you invent, because they're how your buyers already describe the problem.

GitHub issues are underrated for dev tools. A feature request with 200 thumbs-up on a popular repo, open for two years, is a loud signal.

If you can't find 15 quotes in two hours, either the pain is mild, the community is tiny, or you're searching with your vocabulary instead of theirs. Try synonyms before giving up.

Level 3: Behavior proof (24–48 hours)

Levels 1 and 2 prove that a problem exists. Level 3 proves that strangers will act on your offer. Pick one:

Option A: a one-section landing page. The problem in buyer language, the outcome, and an email field ("get early access" or "get the free checklist"). No product yet. Share it only where community rules allow. For warm, relevant visitors, a signup rate around 20% or more is a strong signal. Under 5% means the promise isn't landing, or you're talking to the wrong people.

Option B: a free sample. Ship a small, genuinely useful slice (a single template, a CLI script, a one-page checklist) and post it in a community that welcomes that. Count saves, stars, comments and especially messages asking "is there a full version?"

Option C: an honest pre-sale. A founding price, a clear delivery date, and an automatic refund if you miss it. People paying is the strongest signal you can get. Only do this where pre-orders are allowed, and be explicit about the date.

The go/no-go rule

Write this down before you start, so future-you can't rationalize:

Go if you have 3+ competitors with sales, 15+ buyer quotes, and at least one behavior signal (healthy signup rate, direct requests, or a sale).
Otherwise, drop it and validate the next idea on the list.

Killing an idea on day 3 costs three days. Killing it on day 30 costs a month and a lot of motivation.

Using an LLM without fooling yourself

LLMs are great at organizing a pile of research notes. They're terrible at telling you whether people will pay, because they'll happily invent demand. Feed them only evidence you collected yourself, and explicitly give them permission to say no:

I'm validating a product idea. Below are my raw notes: competitor listings
(price, reviews, format, top complaints) and verbatim buyer quotes with links.

Idea: <one sentence>
Buyer: <one sentence>

1. Group the quotes into the 3-5 underlying problems, ranked by frequency.
2. For each competitor, summarize praise and complaints.
3. Identify the most underserved angle.
4. Suggest a narrower one-sentence positioning for that angle.
5. List the three strongest reasons this might NOT sell, using only my evidence.

If the evidence is too thin to support a conclusion, say so.

Common mistakes to avoid

• Validating with your dev friends. Unless they're the buyer, their opinion is noise.
• Treating upvotes as demand. A post with 300 upvotes and zero signups is entertainment.
• Picking the tech before the problem. The stack doesn't matter until you know someone will pay.
• Researching forever. The 72-hour box exists so you actually decide.
• Skipping the narrowing step. "A tool for developers" competes with everything. "A tool for freelance devs who bill in three currencies" competes with almost nothing.

TL;DR

1. Filter with six questions; narrow the buyer until you get five yeses.
2. Find three competitors with real sales and mine their bad reviews.
3. Collect fifteen verbatim quotes from people with the problem.
4. Run one behavior test: landing page, free sample, or honest pre-sale.
5. Go only with all three kinds of proof. Otherwise, next idea.

Then build the smallest complete version, and put it in front of the exact people whose quotes you collected.

---

Disclosure: this article is from Revenue Operator. We make the 30-Day Revenue Operator Pack, a $27 playbook with the scorecard, validation tracker and launch templates for this process (getrevenueoperator.com). Everything above works without it, and there's a free 6-page version here: getrevenueoperator.com/#free.