A startup idea is validated when at least two of four independent signal families point the same way: build, discuss, use and search. One signal alone is an anecdote. Two or more in agreement is evidence.
That’s the same standard LumenInsight applies to every candidate before it reaches the Opportunity Score. It works just as well as a manual check, run by hand, before you commit a weekend to a repo.
Most validation guides stop at “talk to customers” or “build a landing page.” Those are real tactics, but they don’t tell you how much confirmation is enough. This guide replaces that gap with a checklist you can run yourself, using the same four signal families that back LumenInsight’s own Evidence Chain.
What counts as a real signal?
A real signal is a data point you can verify independently, tied to actual behavior: a star count, a download number, a search query, a thread with real engagement. A vanity signal is anything that only measures attention: a like, a retweet, a friend saying “I’d use that.”
The test is simple. Can someone else check the same number and get the same answer? GitHub stars, npm downloads and Hacker News points pass that test. “People seemed excited” does not.
Vanity signals aren’t worthless, they’re just weak on their own. A single glowing comment from one potential user tells you one person’s opinion. It doesn’t tell you whether a market exists.
The four signal families: build, discuss, use, search
LumenInsight checks every idea’s problem statement against four independent evidence families before scoring it.
- Build: GitHub trending, Show HN, Product Hunt and Betalist. Are people shipping something in this space?
- Discuss: Hacker News and Reddit. Are people actively talking about the problem?
- Use: npm and PyPI download counts. Are people already running a tool for this?
- Search: autocomplete data. Are people looking for a solution before a product even exists?
Each family answers a different question, which is exactly why one isn’t enough. A repo can hit the front page of Hacker News on build alone, with zero downloads and zero search volume, and still fade out within a week. A search term can spike with no product built yet, meaning the demand is real but nobody has shipped a fix.
Checking all four separately, instead of eyeballing a single loud number, is what turns a hunch into something closer to proof.
How many signals is enough to trust an idea?
Two of the four families agreeing is the practical floor for treating an idea as validated rather than merely interesting. Three or four in agreement is strong enough to justify real building time. One signal alone, however loud, is a lead worth tracking, not a green light.
This mirrors how LumenInsight weighs its own Market axis, which makes up 40% of the Opportunity Score, more than Friction or Viability individually, because demand evidence backed by multiple independent sources is the hardest of the three to fake.
A repo with 2,500 GitHub stars in a day but zero Hacker News mentions, zero npm downloads and zero search volume is a build-only spike. It might be the start of something real. It might also be a one-day trend that GitHub’s own algorithm amplified. Wait for a second signal before trusting it.
A repo with a modest 400 stars, one solid Hacker News discussion, and 70,000 monthly npm downloads under its package name is a different animal entirely: three independent families agree, even though the headline star count looks smaller.
A validation checklist you can run in an afternoon
Here’s the sequence, source by source, without needing any paid tool.
- Search first. Check autocomplete on Google and on the platform your target users live on. Rising suggestions around your problem statement mean people are already looking. Flat or empty autocomplete doesn’t kill the idea, but it removes one signal from your total.
- Check what’s discussed. Search Hacker News and relevant Reddit communities for the problem, not just your proposed product name. A thread with real comment depth counts more than a thread with only upvotes.
- Check what’s being used. Search npm or PyPI for existing packages solving an adjacent problem. High download counts on a rough, half-finished tool are a stronger demand signal than a polished landing page with no product behind it.
- Check what’s being built. Scan GitHub trending, Show HN, Product Hunt and Betalist for the same problem space. Multiple recent launches confirm the timing is right; zero launches in a well-searched space can mean either an open opportunity or a problem nobody has found a viable business model for yet.
- Count your confirmed families. Two or more independent families in agreement clears the bar. One family, even a loud one, means keep watching before you build.
None of these five steps requires more than a browser and thirty minutes each. The discipline is in checking all four families before deciding, not in any single search being clever. For a specific list of where to check within each family, see 15 sources sorted by signal type.
In short
Validation isn’t a single yes or no answer, it’s a count. Two of four independent signal families, build, discuss, use and search, agreeing is the practical floor for calling an idea validated. Three or four agreeing is strong enough to justify real building time.
A loud single signal, like a one-day star spike with nothing else confirming it, is a lead worth watching, not proof of demand. The absence of a signal is information too: it means wait for more data, not force the idea forward on hope.
Run the checklist above before the next weekend project, or let LumenInsight’s Daily Report run the same four-family check automatically and show its Evidence Chain breakdown for every candidate it scores.
Worth keeping in mind before trusting any trending list in the first place: see why most startup idea lists are noise, not evidence.
