← All ideas
Validate first· lowMembers only

Third-party calibration app to suppress false theft-lock triggers during running (Android)

A companion app for Android runners that detects a 'run session' (via connected earbuds/watch or manual toggle) and temporarily suppresses Google's theft-detection lock so it stops mistaking running for a phone snatch.

People describe the problem, but nothing on file shows them paying to solve it. That gap is the thing to test first.Evaluated Aug 11, 2026 · thresholds published at /methodology

consumerb2c1-2 monthsdifficulty 4/5
40

Supporting evidence2

  • Multiple complaint signals describe the exact same failure mode — phone motion during running being classified as a theft/snatch event — suggesting the bug is reproducible and annoying enough to write about.

  • One signal frames this as a safety-relevant failure (unreliable during actual emergency situations), which is a stronger hook than mere annoyance.

Falsifying evidence4

  • The feature causing the problem is Google's own theft-detection lock, built into Android; Google can fix the false-positive rate with an OS update or a 'workout mode' toggle, which fully obsoletes a third-party app.

  • All six signals trace to a single recurring quote from one HN thread on one date range — this is not six independent demand events, it's one incident amplified, so the true demand signal is much weaker than the raw count implies.

  • Apple Watch and Google/Apple Maps are listed as adjacent 'solves' products with no verified revenue and only tangential relevance (fitness tracking, navigation) — none of them demonstrate anyone will pay for a fix to this specific bug.

  • Third-party apps on Android have limited ability to intercept or suppress a system-level security feature like theft-detection lock without deep permissions that most users will not grant, creating a distribution and trust problem before the product even ships.

Most likely cause of death

Google ships a native fix (a run/workout exception or sensitivity setting) within a release cycle or two, since the bug report explicitly names their theft-detection feature as the culprit; a third-party app would need OS-level motion/permission access that Android increasingly restricts, making the workaround fragile and hard to distribute, while the underlying demand turns out to be one viral HN thread rather than a sustained, monetizable pain point. Defensibility would require either an exclusive integration with wearable OEMs (to get reliable 'run mode' signals) or becoming the de facto fitness-safety layer before Google patches it — neither of which the current evidence supports.

Demand ladder

A complaint is not a customer. Weighted ×1 / ×3 / ×8 / ×15.

Complaint 6 ×1
Would pay 0 ×3
Already paying 0 ×8
Verified revenue 0 ×15

Verified revenue: none on file for this problem yet. That is an absence of records, not proof nobody is earning here.

Momentum

Is this problem getting louder or quieter?

not enough history

Saturation

How many people are already on it. Most sites hide this.

0 views·0 specs·0 building
01

Problem evidence

Who feels this, how often, and why what they use today does not fix it.

Who feels it
Android (and per one signal, iPhone) owners who run with the phone on their body and have the OS theft-detection lock enabled. Within that, the acute sub-group is runners who rely on the phone mid-run for maps, music or emergency calls and find it locked.
How often
Per the signals, on every run for the affected user — but the entire evidence base is one quote from one Hacker News thread over 6-8 Aug 2026, so real-world frequency across a population is unmeasured.
Why current fixes fail
The failing component is a system security feature owned by the OS vendor, not an app. The runner's only real options mid-week are: (a) turn theft detection off entirely in Settings before every run and remember to turn it back on afterwards — two deliberate navigations per run, which is exactly the behaviour people forget; (b) leave it off permanently and lose the protection they enabled it for; (c) carry the phone in a way that produces less snatch-like acceleration (armband vs. hand), which does not reliably stop the trigger. There is no run-aware exception exposed to third parties: an app cannot legally or technically veto the lock, so any third-party 'fix' is a reminder or a deep link to the same Settings toggle, not a suppression. That is the gap and it is also why the gap may not be fillable.

Running motion is misclassified by phone theft-detection as a snatch event, locking the device mid-activity.

medium confidence

The named culprit is Google's built-in theft-detection lock on Android, i.e. an OS feature rather than a third-party app.

medium confidence

At least one report attributes the same false positive to iPhone's anti-theft detection, so this is not Android-exclusive.

low confidence

The stated consequence is safety-relevant: the phone becomes unreliable for emergency use during exercise.

low confidence

All seven signals are the same verbatim sentence from one Hacker News thread inside a three-day window, so this is one amplified incident, not seven independent demand events.

high confidence

No signal in this block shows anyone paying, offering to pay, or having bought anything to fix this; the demand tier labels list spend and revenue counts but no spend or revenue signal record exists.

high confidenceno source on file — treat as opinion

The vendor can obsolete a third-party workaround with a single OS update adding a workout exception or sensitivity setting.

high confidence

Android does not give third-party apps the permissions needed to intercept or suppress a system-level security lock, so the core mechanism of the proposed product may not be buildable at all.

high confidence
02

Who buys it

The person who feels the pain and the person who signs are rarely the same.

Who buys it is part of membershipThe buyer, the budget it comes out of, and what these people already pay for.
03

Product concept and MVP

Two versions: the one you deliver by hand first, and the one you build.

Product concept and MVP is part of membershipThe concierge version, the buildable version, and the features deliberately left out.
04

Competitors and alternatives

Including the free workaround people use today, which is usually the real competitor.

Competitors and alternatives is part of membershipDirect products, indirect ones, the workarounds, and where the gap actually is.
05

Pricing model

modelled

A proposal, not an observation. Benchmarks come from the data; the ladder is ours.

Pricing model is part of membershipA tier ladder with the reasoning behind each price point.
06

Revenue scenarios

modelled

Arithmetic on the assumptions listed underneath. Change an assumption and the number changes.

Revenue scenarios is part of membershipBase, upside and aggressive cases with every input written out.
07

Market size

modelled

Reachable customers, not a top-down industry figure.

Market size is part of membershipHow many buyers exist, what they spend, and how many you could realistically reach.
08

Go to market

Named places, not channel categories. These signals came from somewhere.

Go to market is part of membershipWhere the first ten customers come from, then the first hundred.
09

Roadmap

Each version ships something a user can use. No infrastructure-only phases.

Roadmap is part of membershipVersion by version, with what belongs in each.
10

Pivot paths

Where this goes if the first version does not land — and the number that says it did not.

Pivot paths is part of membershipAdjacent directions, and the measurable trigger for taking one.
11

Risks and kill criteria

The thresholds at which the honest move is to stop. Written before you are attached to it.

Risks and kill criteria is part of membershipRanked risks, and the numeric conditions under which to walk away.
12

Validation plan

Seven days that cost nothing but time and can kill the idea before you build.

Validation plan is part of membershipA day-by-day plan and the interview questions that do not lead the witness.
13

Sources and freshness

Every reference opens the original post. This is the part you should check first.

How sure are we, per claim

Where the data is thin, we say so instead of rounding up.

demand
Low
payment
No data
market size
Low
competitor gap
Low

13 references from 6 signals · evaluation written Aug 11, 2026.

Related opportunities

Nearest by what the problem actually is, not by category label.

Eleven more sections behind this one

Who signs the cheque, what the space already charges, the seven-day validation plan, and the thresholds at which you should stop. Three ideas are open in full so you can judge the depth before paying.

0 people have looked at this · 0 turned it into a spec · 0 say they're building it