What changed
Three verifiable facts from Google's own blog: (1) the Android CLI hit stable 1.0 in May 2026 and lets AI agents drive builds, analysis, and profiling programmatically; (2) Google AI Studio now generates installable native Android apps from a prompt, so non-developers are shipping code nobody profiled; (3) starting in Android 17 the OS enforces per-app memory limits scaled to device RAM and kills violators with no stack trace. FACT for all three per the cited sources.
Why now
The collision is real but NOT yet fully landed: Android 17 enforcement only bites as devices actually upgrade, which historically takes 6-18 months to reach meaningful share. HYPOTHESIS: the acute pain window (apps dying at scale with no error) is 2-4 quarters out, not 30 days out. Building now means being early to a wave, which conflicts with the 30-90-day cash requirement unless the first product targets existing professional teams doing forced Android 17 migration work today.
Converging signals
Zero-cost app generation by non-developers (AI Studio) + OS-enforced silent memory kills (Android 17) + first-party CLI that lets agents run the profiler = a diagnosable, automatable failure mode hitting a population that cannot self-diagnose. The same tooling that caused the flood can be turned into the audit machine. This is a genuine three-signal convergence, all from first-party Google sources.
Customer pain
An app that worked yesterday starts dying silently on Android 17 devices — no crash dialog, no stack trace, just user complaints and 1-star reviews. FACT that the kill is silent (source 3). HYPOTHESIS that AI-Studio owners will experience this at scale and will pay: many prompt-built apps are hobby/free apps whose owners will abandon rather than pay; the payers are the subset with revenue attached (agencies, SMB tools, indie apps with IAP).
Who pays
Tier 1 (now): existing Android teams with memory-heavy apps facing forced Android 17 remediation — but they have engineers and free tools, weak fit. Tier 2 (the real bet, 2-4 quarters out): AI-Studio-era prosumers/agencies/SMBs with revenue-bearing apps and zero Android debugging ability. Priced per-scan ($49-$299) far below an Android performance consultant ($150+/hr). HYPOTHESIS — no direct evidence of buyer behavior yet; nobody is searching for 'Android 17 killed my app' today because enforcement hasn't broadly shipped.
Solved today
Free first-party tooling: Android Studio Memory Profiler, LeakCanary (free, ubiquitous OSS), Play Console vitals, and Google's own Android 17 migration guide (source 3) which walks developers through the steps. For a competent developer this is a solved problem at $0.
Why current solutions are bad
All existing tools assume a developer is operating them. The new population (prompt-built app owners) cannot open Android Studio, read a heap dump, or apply LeakCanary output. The gap is not tooling — it is operator skill. An agent-run scan that ends in a *patch/PR*, not a report, is the differentiated part. HYPOTHESIS: Google is the natural party to close this gap inside AI Studio itself ('your generated app exceeds memory limits — fix it?'), which would erase the business overnight.
Proposed product
'MemKill Audit' — upload APK or connect repo → agent harness drives the app in emulators via the stable Android CLI, records heap/RSS against Android 17 per-RAM-tier limits, identifies leak/bloat sources, and returns (a) a pass/fail 'will Android 17 kill this app?' verdict per device tier, (b) a plain-English report, (c) for repo customers, an AI-generated remediation patch/PR. Per-scan pricing plus a CI subscription for agencies.
MVP version
1-2 weeks: a scripted emulator harness (Android CLI + macrobenchmark-style drive of the app's main flows) that outputs a memory-vs-limit verdict and top allocation sites, wrapped in a landing page: 'Free scan: will Android 17 kill your app?' Free verdict, paid detail + patch. No dashboard, no CI yet — email delivery.
30-day build
Build the harness; scan the top 100 free utility apps and publish a 'X% of popular apps would be killed under Android 17 limits' teardown post for HN/r/androiddev/X — demonstrated-value distribution matching the founder's style. Collect emails via the free-scan offer. Success gate: 200+ scans requested or 10+ people asking for the paid patch.
60-day build
If gate passes: paid tier live ($99 report / $299 report+patch), outreach to app agencies and AI-Studio community spaces; add GitHub Action for repo customers. If gate fails: shelve and set a re-trigger on Android 17 device-share crossing ~15%.
90-day revenue plan
Realistic: $1-3k from 10-30 paid scans driven by the teardown content — IF the fear is sellable before enforcement is widespread. HYPOTHESIS with low confidence; the honest base case is that meaningful revenue arrives only when Android 17 adoption creates actual dead apps, likely beyond 90 days.
Distribution path
Content-led: the mass-scan teardown post, free-scan lead magnet, r/androiddev, HN, Android agency Slack/Discords, replies to AI Studio showcase posts. No enterprise sales needed. Weakness: reaching non-developer AI-Studio owners is hard — they don't hang out in dev channels, and Google controls the AI Studio surface.
Pricing hypothesis
$49 verdict+report per scan, $299 with remediation patch (repo access), $99/mo CI monitoring for agencies (up to 5 apps). Anchors against $1-3k for a freelance Android performance engineer engagement.
Technical difficulty
Moderate. Emulator memory profiling via CLI is documented and agent-drivable (FACT, source 1). Hard parts: exercising arbitrary apps realistically enough to trigger their real memory behavior (unattended UI exploration is unreliable), and generating patches that don't break prompt-generated spaghetti. Expect a human-in-the-loop patch step initially.
Legal / regulatory risk
Low. Scanning customers' own apps with their consent; no PII, no regulated data. Mass-scanning third-party Play Store APKs for the teardown post needs care (ToS on redistribution/decompilation) — publish aggregate stats, not decompiled code.
Platform dependency
HIGH and the biggest structural flaw: the entire wedge exists at Google's pleasure. Google ships the enforcement, the CLI, the app generator, and the migration docs — adding an automated memory check inside AI Studio or Play Console pre-launch reports is an obvious roadmap item for them. This is a gap-filler business with an uncertain lifespan.
Founder fit
Mixed. Strong: automation, AI-agent workflows, demonstrated-value selling, fast low-budget prototyping — the harness is exactly his kind of build. But this is NOT his proven regulatory-filing shape: no regulation compels anyone to file anything with a government system, there is no per-filing chokepoint, and the buyer is discretionary, not compelled. Android 17 'compels' remediation only if you care about your app surviving — abandonment is a legal option, unlike an FMCSA mandate. Founder-fit is average, not VERY HIGH.
Breakout potential
If it works, expands into a general 'agent-code QA' lane: automated audits for battery, ANR, background-task limits, Play policy compliance — every future OS enforcement creates a new scan SKU, and the AI-Studio app flood keeps supplying unskilled owners. Real but entirely dependent on Google not closing the gap first.
Final recommendation
CONDITIONAL GO as a cheap 2-week probe, not a committed build. The convergence is real and the harness is squarely in the founder's automation wheelhouse, but demand is anticipatory, the buyer's willingness to pay is unproven, and Google can erase the niche. Build only the free-scan teardown + lead magnet (≤2 weeks, ~$0), let the response data decide, and do not let this displace opportunities with compelled buyers. It lacks the mandate-driven, must-file dynamics of his proven ELDT edge.
Next action
Spend ≤2 weeks building the emulator scan harness with the Android CLI, run it against ~100 popular free apps, and publish the 'How many apps will Android 17 silently kill?' teardown with a free-scan signup — treat 200 scan requests or 10 paid-intent replies within 30 days as the go/no-go gate.