25%
Distinct users
How many different people reported it, counted by a salted hash of the reviewer name.
Notion's real numbers. Move one and everything recomputes, using the pipeline's own functions rather than a copy.
The last one changes the verdict, not the score: three or more and the problem is Already solved whatever it scores.
73
Strong signal
threshold 70.0
score = 100 × (
0.25 × distinctUsers
+ 0.20 × recurrence
+ 0.15 × recency
+ 0.15 × severity
+ 0.10 × churnIntent
+ 0.10 × versionPersistence
+ 0.05 × crossPlatform
)25%
How many different people reported it, counted by a salted hash of the reviewer name.
20%
How many separate weeks it appeared in, rather than all at once.
15%
How long ago it was last reported.
15%
The mean star rating of the reviews reporting it.
10%
How many reviewers said they were leaving, deleting or cancelling.
10%
How many distinct app versions it survived.
5%
Whether it was reported on both iOS and Android.
Each component's weight, and what it counts. They total 100%.
Fewer than four distinct reviewers
Thin evidence10 challenges
Three or more existing products already solve it
Already solved0 challenges
Scores at or above the threshold of 70.0
Strong signal2 challenges
Everything else
Recurring13challenges
Where the 25 active challenges currently sit, tested in this order.
Every active problem's score, in buckets of five. The threshold is the higher of 70 and the 80th percentile, so it moves with the field. It stands at 70.0, and 2 of 25 clear it — a pass rate of 8%. A low one is the point.
People lose their place, and their work, when the editor freezes in Notion
73
Strong signal
more evidence than most problems have — 70 or more out of 100
Seven components, each scored from 0 to 1 and multiplied by its weight. The model that reads the reviews never produces a number; every figure below is computed in code.
7 distinct reviewers, of 12 needed for full marks
0.58 × 25 = 14.6 of 25 points
6 separate weeks carrying evidence, of 8 needed for full marks
0.75 × 20 = 15.0 of 20 points
last reported 2 days ago; full marks inside 14 days, zero at 180
1.00 × 15 = 15.0 of 15 points
mean rating 1.4 of 5 across 7 quotes
0.89 × 15 = 13.4 of 15 points
0 reviewers said they were leaving, of 4 needed for full marks
0.00 × 10 = 0.0 of 10 points
6 distinct app versions in the last 180 days, of 4 needed for full marks
1.00 × 10 = 10.0 of 10 points
reported on both iOS and Android
1.00 × 5 = 5.0 of 5 points
Total 73.0, rounded to 73
Every challenge carries all of this. On the challenge itself it is one sentence — 7 people raised this — because a person can read that and cannot read seven bars.
Darker cells are challenges more people reported that week.
Taller ridges are challenges more people reported that week. Hover one to see which.
Apple 13 of 15, Play 15 of 15. A missing cell is a gap the run recorded and carried on past.
Two sources, both public, neither requiring credentials or an agreement.
Apple publishes a customer reviews feed for each app in each storefront. Friction reads up to ten pages per app per storefront, at one request per second, from the United States, the United Kingdom, Canada, Australia, New Zealand, Ireland and Singapore. Each review carries a star rating, an app version, a country and a date. This is the backbone of the project.
Google publishes no API for reading reviews of apps you do not own. Friction reads publicly visible review pages using the google-play-scraper package, at one request per second, taking the most recent English reviews from the United States storefront. Play reviews carry no title, and often no app version.
Play is an enhancement, not a dependency. If it fails for an app, the run continues with Apple data alone and the gap is recorded. In the most recent scan every tracked app returned Play data.
Most of the filtering is deterministic and happens before any model sees anything. A review is rejected outright if it has already been processed, if it is older than 180 days, if the title and body together run under 80 characters, or if it matches the crisis language screen below. What survives is kept only when it is rated three stars or lower and contains at least one of a fixed list of complaint markers. The survivors are ranked by marker count, then star rating, then recency, and capped at 150 per run.
Those go to a language model with one job: group reviews that describe the same underlying problem, and copy a short verbatim quote from each. The model is explicitly forbidden from producing a score, a rank or a priority of any kind. Its output is then parsed against a strict schema and every quote is checked, character by character, against the review it claims to come from. If any check fails the run stops and nothing is published, leaving the previous week's data in place.
Seven components, each normalised to a value between 0 and 1 over evidence from the last 180 days, multiplied by the weights below, and scaled to 0–100.
Open "How this score is calculated" on any problem page to see these seven values for that problem, with the raw counts behind each one and the arithmetic that produces the total.
The verdict is decided in a fixed order. Fewer than four distinct reviewers isThin evidence, whatever the score. Three or more existing products that already solve it is Already solved. Otherwise a score at or above the build threshold is Strong signal, and anything else is Recurring.
The threshold is the higher of 70 and the 80th percentile of all active problem scores, computed by linear interpolation between the closest ranks. It currently stands at 70.0. Of 25 active challenges, 2 carry the "Strong signal" verdict, a pass rate of 8%.
That low pass rate is deliberate. A site where everything looks promising is worth nothing to anyone deciding what to work on, so the bar moves with the field and never drops below 70. A problem with no new evidence for 120 days is marked stale; it stays readable but is left out of the homepage and out of the threshold calculation.
Neither store gives an individual review a stable public URL. This is the single biggest limitation of the whole project and it cannot be engineered away. Evidence therefore links to the app's review listing, not to the review itself, and every quote is labelled with the date the scan captured it. You cannot click through and re-read the original. What you can do is read the commit history in the repository, where every scan's output is recorded with a timestamp.
English-language reviews, 7 Apple storefronts, one Play storefront, mobile apps only, and only the 15 apps currently tracked. A quiet app produces a small sample, and a small sample produces an unreliable score. Treat a scored problem as a starting point for your own research, not as a conclusion.
Apps whose subject matter is personal distress or health are never tracked. The check runs before any request is made, against the app name, the developer name and the store category, and the tracked list is not exempt from it. An app matching any of these terms is excluded:
Separately, any individual review whose text matches crisis language is dropped before it enters the pipeline. Such a review is never stored, never quoted and never counted towards any score. The list of terms lives in the source rather than on this page.
Both screens match inflected forms as well as the exact words. They are deliberately broad. Excluding something that belonged is a cost worth paying here.
Friction has no ads, no payments, no signup, no paywall and no affiliate links, and it is not affiliated with any of the apps it tracks. It reads publicly visible reviews and publishes the analysis with the method attached. If you think something here is wrong, the data and the code are both in the repository and you can check it yourself.