TL;DR: PainHunt runs a four-stage pipeline — crawl 24 platforms, extract pain points with an LLM, score them for intensity and commercial potential, then make them searchable. This page explains each stage and is honest about where the method is strong and where it isn't.
Stage 1 — Crawl 24 platforms
A distributed crawler network continuously collects public posts from 24 sources. The mix is deliberate: forums where people vent (Reddit, Hacker News), stores where people review (App Store and Google Play across many countries), developer channels where people file concrete problems (GitHub Issues and Discussions, Stack Exchange), and discovery platforms (Product Hunt).
Different platforms surface different kinds of pain. App Store reviews are blunt and emotional; GitHub issues are precise and technical; Reddit sits in between. Covering all of them reduces the blind spots any single source creates.
Stage 2 — Extract the pain point
A raw post isn't a pain point. A 200-word rant might contain one real problem, three side complaints, and a feature request. So each post is read by a language model that pulls out the structured signal:
- the pain point itself, described plainly
- its sentiment (negative / neutral / positive)
- feature requests mentioned ("I wish it could...")
- competitor weaknesses when someone names a product and what it fails to do
This is the step that turns noise into something comparable across platforms.
Stage 3 — Score it
Two scores matter most:
- Intensity (0–10): how acute the problem is for the person. A mild inconvenience scores low; "this is breaking my workflow daily" scores high.
- Commercial potential (0–15): whether the problem is worth money. The model weighs signals like willingness to pay, how often the complaint recurs, severity, and whether people already pay for clumsy workarounds.
The reason for two scores is that they diverge. Plenty of problems are intensely annoying but commercially thin (no one will pay), and some quiet, unglamorous problems carry real budget. Ranking by commercial potential is usually what separates a hobby from a business.
Stage 4 — Make it searchable
The scored pain points land in an app where you filter by keyword, platform, or category, sort by score, and read concise summaries. You can validate a specific idea in the Idea Validator, or browse open-endedly in the Pain Point Browser.
What the scores can and can't tell you
Being honest about method matters more than overselling it.
What the scores are good at:
- Comparing many problems quickly on a consistent scale
- Surfacing problems you wouldn't have searched for
- Filtering out low-signal noise so you spend attention well
What they can't do:
- Predict whether your execution will succeed
- Replace talking to real users once you've picked a direction
- Capture problems people never post about publicly
Treat a high score as "strong evidence worth investigating," not "build this and you'll win." The tool narrows the field; judgment and customer conversations close the deal.
Why a transparent pipeline matters
The value of a scored dataset depends entirely on trust in how it was built. That's why the stages above are public: the data comes from real, public posts; the scores come from a consistent rubric; and every entry links back to its source so you can check the original yourself. PainHunt summarizes and ranks — it doesn't ask you to take the conclusion on faith.
Next: see what PainHunt is for the big picture, or where the data comes from for the full source list.