What changed
HYPOTHESIS (from convergence description; no underlying signals were included in this input): Android 17 (June 2026) allegedly adds enforced per-app memory limits with silent kills and mandatory adaptive UI, stacking on Google's existing annual target-SDK requirement, so 'done' apps become non-compliant on a datable deadline. The signal texts (845, 841) were not provided, so the specific Android 17 requirements are UNVERIFIED here.
Why now
IF the Android 17 claims hold, this is the first time two new recurring kill conditions land at once on a known date, converting a chronic maintenance chore into a deadline event. The annual target-SDK bump is a well-established recurring Google policy (background knowledge, not cited from provided sources), which makes the recurring-revenue framing plausible even if the Android 17 specifics soften.
Converging signals
The input's signals array is EMPTY and demand_evidence is EMPTY. The convergence rests entirely on the hypothesis text referencing signals 845/841. Convergence strength cannot be scored high on unpresented evidence.
Customer pain
HYPOTHESIS: solo/side-project developers with revenue-bearing but rarely-touched apps face app hiding/removal (revenue death) if they miss target-SDK and Android 17 requirements, and they either don't know the deadline or dread the upgrade work. No PAIN evidence (complaints, r/androiddev threads) was provided to confirm this.
Who pays
HYPOTHESIS: the individual developer or micro-studio whose stale app still produces meaningful revenue (ads/IAP/paid). Reachable because Play listings expose contact email and last-update date, making the obligated class machine-enumerable. Whether enough of these apps still earn enough to justify a subscription is the key unproven assumption.
Solved today
HYPOTHESIS: ad-hoc — the developer does the bump themselves once panicked, hires a freelancer for a day-rate, or lets the app die. App-ops tools (e.g., AppFollow, Runway) serve active teams, not the abandoned tail; agencies serve big publishers. No provided evidence of anyone running roster-driven outbound to stale apps.
Why current solutions are bad
Freelancer engagements are one-off, priced per day, and require the developer to initiate; nothing continuously watches Play policy deadlines for a specific app and proactively executes the fix. The abandoned-tail owner is by definition not paying attention — a push (outbound) product, not a pull product.
Proposed product
Per-app 'compliance file' subscription: (1) continuous monitor of the app against upcoming Play deadlines (target-SDK, data-safety form, Android 17 adaptive-UI/memory), (2) annual SDK bump performed for the customer, (3) regression checks for Android 17 memory kills, (4) deadline alerts. Priced well below one freelancer day per year.
MVP version
A Play-roster scraper (installs >50k, no update 18+ months, contact email published) + a one-page 'your app dies on <date>' report generator + a cold-email sequence + a manual done-for-you SDK-bump service delivered by the founder with AI-assisted tooling. The monitoring dashboard comes later; the MVP is the enumerated roster plus productized service.
30-day build
Verify the regulatory facts first: pull the actual Play Console policy pages for target-SDK enforcement dates and the real Android 17 requirements (the input provides none). Build the scraper, enumerate 500+ qualifying apps, run the stated falsification test: email 50 developers, measure replies and paid-pilot conversions against the >=5% / 2-pilot threshold.
60-day build
If the outreach test passes, deliver 3-5 paid pilot bumps (bespoke, day-rate-beating fixed price), extract the repeatable playbook (Gradle/AGP upgrade recipes, data-safety form template, adaptive-UI checklist), and stand up the monitoring/alerting layer as the subscription wrapper.
90-day revenue plan
10-30 apps on a $29-79/mo per-app file plus one-time $300-800 bump fees. Realistic first revenue is a pilot fee inside 45 days if outreach converts; subscription base builds toward the Android 17 (June 2026 — already passed or imminent as of this run; verify actual enforcement window) and next target-SDK deadline.
Distribution path
Roster-driven cold email to scraped Play contact addresses — the same enumerate-the-obligated-class motion as his ELDT business. Zero ad spend, demonstrated-value sales (send the developer their own app's failing compliance report). Secondary: r/androiddev, indie-dev newsletters.
Pricing hypothesis
$29-79/mo per app for the compliance file; $300-800 one-time per SDK bump executed. Anchor against a freelancer day ($400-800) and against the app's death.
Technical difficulty
Scraper + monitor: low. The done-for-you bump is the hard part: it requires the customer's source code, build environment, and signing/upload keys — each app is bespoke Gradle/dependency surgery, not a standardized portal filing. This is the structural difference from his ELDT edge: ELDT is uniform form submission; SDK bumps are variable-effort software maintenance that resists flat pricing.
Legal / regulatory risk
Scraping Play at enumeration scale and cold-emailing scraped addresses carries Google ToS and CAN-SPAM/GDPR exposure — manageable (one-to-one B2B outreach, opt-outs) but real. Handling customers' signing keys creates liability that needs contractual limits.
Platform dependency
Total. Google sets the deadlines, can extend them (a known falsifier in the hypothesis), can restrict listing scraping, and historically has granted extension mechanisms for target-SDK. The product's urgency is rented from Google's enforcement mood.
Founder fit
High but not perfect. Matches his proven pattern (read mandate → enumerate obligated class via public roster → outbound → charge per transaction) and his automation/complaint-mining strengths; the 0.80-confidence lesson favoring portal-mandate shapes applies. Discount: the deliverable is bespoke code maintenance rather than standardized filing, and the 'regulator' is a platform, not a government — enforcement dates are softer and revisable.
Breakout potential
If the motion works, it generalizes: iOS minimum-SDK requirements, Chrome extension Manifest deadlines, Shopify/WordPress plugin API sunsets — every platform with a public roster and a recurring compliance clock. The scraper+outbound+file engine is the reusable asset.
Final recommendation
PURSUE THE TEST, NOT THE BUILD. The shape matches the founder's proven motion and the outreach experiment is cheap, fast, and decisively falsifiable — but every load-bearing fact (Android 17 requirements, enforcement dates, tail-app revenue, developer reachability) is currently hypothesis. Spend one week verifying the Play policy pages and running the 50-email test before writing any product code.
Next action
(1) Pull the official Android/Play policy pages and confirm the exact target-SDK and Android 17 enforcement dates and consequences; (2) build the scraper for >50k installs / 18+ months stale / contact email present; (3) send 50 personalized deadline emails and measure against the pre-registered >=5% reply / 2-pilot bar.