§ Methodology

The scoring system

What every number, label, and badge on a pain card actually means — and how the aggregator decides which complaints make it into the index.

Pain score

A single number in [0.00 — 1.00] answering one question: does this pain deserve attention from someone looking for a problem worth solving? It's the default sort key — not a verdict.

The score is a weighted product of four components, not a sum. If any one component is zero, the total collapses. A pain without freshness is dead; without reach, it's personal; without engagement, invisible; without monetization signal, not a market opportunity. All four matter.

Reach

How many distinct people voiced this pain across all evidence. The single strongest validity signal: the same complaint from 30 different authors is a market; from one person, a bad day. We count unique authors across the cluster and normalize on a log scale — 100 vs 1000 authors are both "mass-scale," just on a plateau.

Recency

How fresh the evidence is. A pain last mentioned 4 years ago is probably solved by now — by a feature ship or a third-party app. A pain still bubbling up this week is alive. Computed as exponential decay from the latest evidence in the cluster, with a half-life on the order of months.

Engagement

How much the source community reacted — upvotes plus comment counts across all evidence, normalized by the median of that subreddit or forum (so 50 upvotes in a small community and 50 in a huge one don't count the same). This measures attention from others, not the author.

Monetization signal

The most valuable component for someone hunting opportunities. The aggregator scans evidence for willingness-to-pay cues and labels each card:

$ explicit quotes contain direct money language: "would pay for", "willing to pay", "we currently pay $X for Y but…". Highest weight.
implicit an existing paid solution is mentioned, a budget is referenced, or work is being done manually. Medium weight.
no signal neither. Zero weight from this component — collapses the total score.

Severity

The LLM's read on how badly the pain affects users: low (annoyance, nice-to-have), medium (blocks workflows but workarounds exist), high (loses money, time, or customers; no acceptable workaround). Severity is an aggregator hint, not a component of the score.

Status: draft vs published

draft the card is freshly aggregated, may still gain evidence as more data is ingested. Visible on the dashboard. published the card has been editorially reviewed and considered stable. Most cards live in draft; that's normal, not a bug.

Evidence

The actual public quotes the card is built from — each one a real user's words from a Reddit thread or a marketplace forum (Discourse, Khoros). Each evidence row links back to the source. The card is only as strong as its evidence: glance at a few quotes before taking the score at face value.

Cluster

Number of raw signals merged into a single card. The aggregator embeds every public complaint and groups semantically-similar ones — so "App keeps logging me out" and "Forced to re-auth every hour" collapse into one card with a cluster count of 2. Bigger clusters = stronger signal.

§ Chrome opportunities

The Chrome witness stand

The Chrome opportunities section scores product opportunities extracted from Chrome extension reviews — it uses its own vocabulary, explained here.

Opportunity score

A single number that answers "how strong is the case for building this?" — how much pain exists for a function, combined with how badly it's covered by extensions today. The card list shows display_score, a 0–100 rescale of the raw opportunity_score so cards can be compared at a glance; the raw value is what actually drives sorting. See the formula below.

Pain density

How intensely users complain about this specific function inside the cluster of extensions that share it. A high-density function is one reviewers keep bringing up, unprompted, across many 1★ reviews — not a one-off gripe buried in an otherwise happy review.

Best coverage

The largest share of this pain that any single extension in the cluster already solves. 100% means at least one extension in the group handles this function well enough that users stopped complaining about it there. Low coverage means nobody in the cluster has cracked it yet — that's the opening.

Opportunity mode

Three shapes the opportunity can take, based on how the pain shows up across the cluster:

🕳️ Cross-store gap

The pain shows up across many extensions in a niche, and none of them solve it. Example: a dozen PDF-editing extensions all get complaints about losing form data on export, and not one of them fixes it — that's wide-open room for a new entrant.

🔧 Quality gap

Existing extensions try to solve this function, but do it poorly — the complaints keep coming anyway. Example: several ad blockers ship a "whitelist site" feature, but users keep complaining it resets after every update — the function exists, it's just built badly.

🔥 Unmet complaint

A narrower, more specific pain with no serious attempt to solve it anywhere in the cluster. Example: users of a note-taking extension keep asking for offline sync, and no competitor in that niche offers it at all.

Risk score

An external signal (0–1, higher = more risk signals) reported by chrome-stats.com for each extension — a combination of how invasive its requested permissions are and reputational signals about the publisher (account age, store standing). It's a proxy for "worth a closer look before treating this extension as a serious competitor," not a verdict that an extension is malicious.

The formula

opportunity = pain_density × (1 − best_coverage)

Intense, unaddressed pain scores highest: complaints have to be both loud (high density) and unresolved by any competitor (low coverage). If either side is missing — nobody's complaining, or someone already nailed it — the score collapses toward zero.