What changed
FACT (from convergence input): Android 17 shipped with OS-enforced per-app memory limits (silent kills) and mandatory adaptive-UI support, layered on top of Play's existing annual target-SDK deadline cycle. HYPOTHESIS: this creates a new recurring compliance duty for every published app, not just new submissions.
Why now
The Android 17 enforcement wave is the first time non-compliance manifests as silent runtime kills rather than only a console warning, and it stacks with the annual SDK deadline. Each new enforcement cycle re-creates the prospect list. However, NO demand_evidence was supplied — 'why now' rests entirely on the platform-change inference, not on observed developer pain.
Converging signals
Referenced signals 845/841 (Android 17 enforcement) were not included in the input payload, and the demand_evidence array is EMPTY. The convergence is a pattern-transfer hypothesis (public-roster forced-buyer → Play Store), not an evidence-backed convergence. Treat everything downstream as unvalidated.
Customer pain
HYPOTHESIS: solo/small developers with 2-20 published apps miss platform deadlines because nothing watches their back-catalog, and discover problems only when Play delists or Android 17 starts killing their app. Zero complaints, forum threads, or job postings were provided to prove this pain — it is plausible but unproven.
Who pays
HYPOTHESIS: indie developers and small studios whose apps still earn revenue (ads/IAP/paid). Critical unproven assumption: the developers who are behind on deadlines are disproportionately the ones who have ABANDONED their apps and will pay nothing. The paying segment may be exactly the segment that already complies.
Solved today
Google Play Console itself emails developers about target-SDK deadlines and policy issues (FACT about the platform, from general knowledge — verify). SDK-intelligence vendors (AppFigures, 42matters, AppBrain) expose target-SDK data for market research. Agencies handle compliance for large publishers. The long tail relies on Google's own nags.
Why current solutions are bad
HYPOTHESIS: console warnings go to stale inboxes, are per-app rather than portfolio-wide, arrive without remediation guidance, and don't cover the new Android 17 runtime behaviors (memory-kill exposure, adaptive-UI readiness) which are not simple manifest flags. If Google's warnings actually work, this product has no reason to exist — that is the falsification test.
Proposed product
Portfolio compliance file: connect or claim your apps, get a per-app status board against every live and announced Play/Android deadline, email/Slack alerts with lead time, and an evidence-ready remediation report per finding (what to change, in which file, before which date). Acquisition loop: scrape Play for apps measurably behind (visible target SDK below requirement) and email the mandatory public developer contact a free single-app audit.
MVP version
1) Scraper for Play listings extracting target SDK + adaptive-UI declarations for a seeded app list; 2) rules engine mapping findings to the published deadline calendar; 3) one-page HTML audit report generator; 4) outbound email sequence. No dashboard needed for validation — sell the audit first.
30-day build
Run the convergence's own testable prediction as the gate: scrape 500 mid-tail apps, measure the share behind the current SDK requirement, email 100 listed contacts with a personalized 'your app X is at removal risk' audit. Gate: ≥20% non-compliant AND ≥5% response. Also verify what Play Console already emails developers (interview 5 indie devs) — if Google's nagging is adequate, kill.
60-day build
If gated through: convert audit responders to a $19-49/mo portfolio monitor, build the recurring re-scan + alerting, add Android 17 memory/adaptive-UI checks (requires APK-level analysis — harder than listing scrape, scope carefully). Target 10 paying portfolios.
90-day revenue plan
Scale outbound to 1,000 emails/mo from the non-compliance scrape, add a self-serve Stripe checkout, target $1-2k MRR. Secondary channel: one-time $199 'deadline rescue' remediation reports for apps already flagged by Google.
Distribution path
Built-in prospect list: the Play Store enumerates the obligated class WITH contact emails and exposes the compliance-relevant field (target SDK). This is the strongest part of the idea. Risks: CAN-SPAM-compliant cold email to listed contacts is legal but deliverability/response at scale is unproven, contacts may be dead mailboxes, and scraping Play at volume violates Google's ToS — an ironic policy exposure for a compliance product.
Pricing hypothesis
$19-49/mo per portfolio (tiered by app count); $99-199 one-time single-app audit/remediation report as the wedge SKU. Per-app-per-deadline pricing mirrors the founder's proven per-upload ELDT model.
Technical difficulty
Listing-level checks (target SDK, declarations) are easy solo work. Android 17 memory-behavior and adaptive-UI runtime checks require static/dynamic APK analysis — meaningfully harder, defer past MVP. Scraper maintenance against Google's bot defenses is the ongoing tax.
Legal / regulatory risk
Play ToS prohibits scraping; Google could block or send a C&D (low likelihood at small scale, real at growth scale). Unsolicited email to published business contacts is CAN-SPAM-manageable. No regulated data.
Platform dependency
SEVERE and structural: Google is simultaneously the 'regulator', the data source, the acquisition channel gatekeeper, and the incumbent who could solve this natively with one Console feature (portfolio-wide deadline digest). This is the single biggest kill vector.
Founder fit
Strong pattern match to the proven ELDT edge: public roster of obligated parties + deadline + penalty + per-filing monetization. But note the disanalogy — ELDT is a federal mandate where Google-equivalent (FMCSA) will never build the tool; here the 'regulator' is a product company that actively improves its own console. Fit is high (7) but below the government-portal ceiling (8-9) for exactly that reason.
Breakout potential
Moderate: expand to iOS App Store deadline cycle, privacy-manifest requirements, and cross-store compliance for the same customer. The 'platform compliance file' category recurs annually by construction, giving natural retention.
Final recommendation
DO NOT BUILD YET — run the $0, one-week validation the convergence itself specifies. This is a well-shaped forced-buyer pattern with a built-in prospect list and genuine founder fit, but it currently has empty demand evidence and a severe single-platform dependency. The scrape + 100-email test directly measures both unknowns (non-compliance base rate, contact-channel liveness/willingness to respond) for near-zero cost. Proceed to MVP only if both gate thresholds pass AND developer interviews confirm Console warnings are inadequate.
Next action
This week: scrape target SDK data for 500 mid-tail Play apps (or pull from 42matters/AppBrain trial to avoid ToS-risky scraping during validation), send 100 personalized at-risk audit emails, and interview 5 indie Android devs about what deadline warnings Google already sends them.