What changed
HYPOTHESIS (per convergence description; the signals array provided to me is EMPTY, so I cannot verify the underlying facts): Android 17 shipped June 2026 with mandatory adaptive-UI behavior and per-app memory ceilings enforced by silent, no-stack-trace process kills, and Google Play's recurring target-API enforcement will force maintained apps onto Android 17 behavior within ~12 months.
Why now
IF the claimed Android 17 behavior is real, there is a ~12-month enforcement runway during which developers cannot easily observe silent kills without tooling, and the obligated class is publicly enumerable (Play listings + EU DSA trader contact emails). This 'roster-enumerated obligated class' is structurally attractive. But every load-bearing fact here is unverified in this input: no signals, no demand_evidence, no URLs were provided.
Converging signals
The description references signals 845 and 841 (Android 17 memory limits / adaptive UI) but the signals array passed to me is empty. Convergence therefore cannot be independently confirmed from this input and is scored down accordingly.
Customer pain
HYPOTHESIS: solo/small developers whose apps get silently killed on low-RAM devices will see rising uninstalls and 1-star reviews with no crash trace, and later face delisting via target-API enforcement. No PAIN evidence (complaints, forum threads) was supplied — demand_evidence is empty, so pain intensity and even existence are unproven. The description itself lists the needed confirmation (r/androiddev silent-kill complaints) as still-to-be-gathered.
Who pays
HYPOTHESIS: revenue-generating mid-tail app owners (apps earning enough that delisting is existential but small enough to lack QA teams). Caution: the long tail of solo Android devs is a notoriously price-sensitive, low-ACV buyer pool; the sub-segment that both earns real revenue AND lacks testing infrastructure is much smaller than the crawlable roster suggests.
Solved today
Google already gives developers a free pre-launch report on real devices via Play Console (Firebase Test Lab underneath), plus Android Vitals for field crash/ANR telemetry. Device-cloud vendors (BrowserStack, AWS Device Farm) cover paid testing. None of this was in the input; it is my knowledge, flagged as such — but it means the 'developers cannot see kills without tooling' premise is only true if Google's existing pre-launch report does NOT surface Android 17 memory-class kills, which is unverified.
Why current solutions are bad
HYPOTHESIS: pre-launch reports run once at submission, not monthly; they may not exercise each RAM class against Android 17 ceilings; Vitals shows field damage only after users suffer it. If true, a recurring, per-RAM-class, dated report has a wedge. If Google adds this to Play Console — the description's own falsifier, and exactly the kind of thing Google ships during an enforcement push — the niche collapses.
Proposed product
Per-app monthly subscription: automated emulator-farm runs that (a) exercise the app under Android 17 memory ceilings per RAM class, (b) verify adaptive-UI behavior, (c) emit a dated evidence report ahead of enforcement deadlines. CRITICAL WEAKNESS vs the founder's proven ELDT pattern: there is NO submission portal and NO party that accepts this evidence. Google does not adjudicate third-party compliance files — it tests the app itself and delists unilaterally. The artifact is a diagnostic, not a filing; the 'compliance evidence file' framing borrows the strength of the government-mandate pattern without its structure. The government-portal lesson (confidence 0.80) applies NEGATIVELY here: regulation-compels-filing is the founder's edge, and this is not that shape.
MVP version
Do NOT build the emulator farm first. MVP is the validation probe the hypothesis itself specifies: (1) crawl ~5,000 mid-tail Play listings, extract target SDK (via APK analysis) and DSA trader emails; (2) hand-run ~20 apps through Android 17 emulator images across RAM profiles to prove silent kills are real, observable, and common; (3) landing page offering a free one-time 'Android 17 kill-risk report', mailed to 300 detectably-stale apps.
30-day build
Verify the two load-bearing facts: Android 17 silent-kill behavior reproduced in emulator, and r/androiddev / issue-tracker complaints existing in the wild. Build the crawler; measure the >40% trader-email + stale-SDK prediction. Kill immediately if Play Console's pre-launch report already flags Android 17 memory kills.
60-day build
If probe passes: automate the report pipeline (emulator matrix, scripted monkey/UI traversal, memory-pressure harness, PDF/HTML report). Send 300 outbound emails; target >3% signup per the testable prediction. Convert free reports to paid monthly monitoring.
90-day revenue plan
HYPOTHESIS: 10-30 paying apps at $29-79/app/month ($500-2,000 MRR) is the realistic 90-day ceiling given cold outbound to a price-sensitive pool. That is a lifestyle micro-SaaS trajectory, not a breakout, unless agencies/studios with 10-50 app portfolios become the actual buyer (better ACV, same product).
Distribution path
The crawlable roster + DSA trader emails is genuinely clever and unusual — a self-updating prospect list with a detectable qualifying condition (stale target SDK). Risks: unsolicited email to DSA-published addresses is spam-adjacent (GDPR/PECR exposure in the EU), and long-tail devs ignore cold email. Secondary channel: r/androiddev content when/if silent-kill complaints spike, which is also the demand thermometer.
Pricing hypothesis
$29-79 per app per month, or $99 one-time deep report upsold to monitoring. Low enough for solo devs, but that same lowness caps the business.
Technical difficulty
Moderate. Emulator orchestration across RAM profiles, automated UI traversal of arbitrary third-party apps (hard to do meaningfully without app-specific scripts), memory-pressure simulation, APK static analysis. Solo-buildable in 30-60 days with the founder's automation background, but 'meaningfully exercising' arbitrary apps is the quietly hard part — shallow traversal yields shallow evidence.
Legal / regulatory risk
Low-moderate: scraping Play listings against Google ToS (practically tolerated, but this business lives entirely inside Google's ecosystem while violating its ToS); EU e-privacy exposure on cold email to DSA contacts; no regulated data.
Platform dependency
SEVERE and double-ended: Google defines the requirement, controls enforcement timing, owns the test infrastructure (Firebase Test Lab), and can ship the falsifier feature in one Play Console release. The description names this as the kill condition; I weight it heavily because Google has repeatedly shipped exactly this (pre-launch reports, target-API warnings, Vitals) during past enforcement pushes.
Founder fit
Mixed. Fits: automation, crawling public rosters, evidence/report products, complaint-mining, fast prototyping. Does NOT fit the proven edge: no government portal, no compelled filing, no per-transaction submission fee — Google never receives the artifact. The 'Play-as-regulator' analogy is rhetorically neat but structurally hollow at the exact point (a portal that must receive a filing) where the founder's ELDT win lives.
Breakout potential
Limited as scoped. Plausible expansions: portfolio monitoring for studios/agencies, iOS equivalent when Apple ships analogous constraints, 'store-policy radar' subscription across all Play enforcement waves. All still ride on platform whim.
Final recommendation
DO NOT BUILD YET — RUN THE CHEAP PROBE. The roster-enumeration insight (stale-SDK detection + DSA trader emails) is a genuinely good prospecting mechanism worth keeping regardless of this product. But the opportunity as framed fails the founder's proven pattern (no portal, no compelled filing, no evidence-receiver), has literally empty demand evidence, and sits one Google release from extinction. Spend <2 weeks and <$500 on the crawl + 20-app emulator reproduction + 300-email landing-page test. Proceed only if (a) silent kills reproduce and are visible in the wild, (b) Play Console's pre-launch report demonstrably does not cover it, and (c) signup beats the 3% prediction. Otherwise archive and keep the crawler as a prospecting asset for better-shaped plays.
Next action
Reproduce the Android 17 silent-kill behavior in an emulator on 3 known-stale apps and search r/androiddev + Google issue tracker for post-June-2026 silent-kill complaints; simultaneously crawl 1,000 Play listings to measure stale-SDK and trader-email rates. This costs days and settles the two facts everything else depends on.