What changed
FACT (source: Android Developers blog, June 2026): starting in Android 17 the system enforces per-app memory limits scaled to device RAM and kills violators with no stack trace. FACT (source: Android Developers blog, May/June 2026): the Android CLI hit stable 1.0, letting coding agents programmatically drive builds, profilers, Compose previews, and device streaming. FACT (source: Vercel blog): Vercel shipped an agent that autonomously investigates production incidents and proposes approval-gated remediations, validating the product shape in an adjacent domain.
Why now
The enforcement creates a dated compliance wave: as Android 17 adoption rolls out over the coming months, memory-heavy apps start dying silently in the field, showing up only as retention drops. The tooling to automate diagnosis (Android CLI 1.0) went stable only weeks before enforcement. HYPOTHESIS: publisher pain will peak in the 3-9 months after Android 17 reaches meaningful device share, not immediately — early revenue depends on developers who target the new SDK early.
Converging signals
(1) Android 17 per-app memory limits with silent kills and no diagnostics [android-developers blog]; (2) Android CLI stable 1.0 enabling agent-driven profiling/builds/device streaming [android-developers blog x2]; (3) Vercel Agent proving buyers will let an agent investigate production issues and gate fixes behind approval [vercel.com]. The bridge: an agent can now run the entire reproduce-profile-diagnose loop for Android memory without a human at the IDE.
Customer pain
FACT (source text): apps exceeding the limit are killed with no stack trace or crash report. HYPOTHESIS (strong): this manifests as unexplained session churn and retention drops that existing crash reporters (Crashlytics, Sentry) cannot attribute, because there is no crash to report. Games, media, camera, and mapping apps are the likely worst-hit. No direct evidence of developers complaining yet is provided in the sources — that must be verified via r/androiddev, issue trackers, and Play developer forums before building.
Who pays
HYPOTHESIS: small-to-mid Android publishers (games/media/utilities, roughly 10k-1M MAU) with revenue at stake but no dedicated performance engineer. They already pay $99-$1k+/mo for Embrace/Instabug/Sentry-class observability, so budget for app-health tooling exists. Big studios have in-house perf teams and won't buy; hobbyists won't pay — the middle is the market.
Solved today
Manual profiling in Android Studio (Memory Profiler, heap dumps, LeakCanary in debug builds), Android vitals in Play Console for aggregate signals, and mobile observability SaaS (Embrace, Sentry, Instabug) for production telemetry. LeakCanary is free and ubiquitous but debug-only and requires a developer to interpret it.
Why current solutions are bad
None of these close the loop for the new failure mode: vitals aggregates lag and don't give a stack; LeakCanary doesn't run in production or fix anything; observability SaaS tells you memory climbed but not which allocation path leaked or how to fix it. The diagnose-to-merged-fix gap is still human labor — exactly what the agent pattern (Vercel-style) compresses. HYPOTHESIS: incumbents will add 'Android 17 memory' dashboards quickly, but agentic reproduce-and-fix is further from their DNA.
Proposed product
Start NOT with the autonomous fix agent (too much trust required) but with a productized diagnostic: an 'Android 17 Memory Readiness Scan.' Customer supplies an APK/AAB (or repo access, optional); an agent pipeline drives the Android CLI on emulators/device farm to exercise the app under the new limits, captures heap profiles, identifies top leak/bloat suspects with code-level pointers, and delivers a report. Upsell tier: recurring per-release CI check. Later tier: approval-gated fix PRs, only after trust is earned — this is the Vercel-shaped endgame, not the entry point.
MVP version
A pipeline: (1) install customer APK on emulator matrix via Android CLI; (2) scripted/monkey navigation while sampling memory against Android 17 limit thresholds; (3) on threshold breach, capture heap dump, run analysis (agent-assisted heap-dump interpretation via headless Claude Code — matches Charles's existing bridge architecture); (4) generate a PDF/HTML report: kill risk by device class, top 5 leak suspects, remediation guidance. Sell as a fixed-price scan ($199-$499). Buildable solo in 2-4 weeks since it reuses his existing agent-orchestration stack; no customer repo access needed for v1.
30-day build
Week 1: verify demand — mine r/androiddev, GitHub issues, X/Play forums for Android 17 memory-kill complaints; if fewer than ~20 credible pain posts exist, park the idea (revisit at Android 17 GA). Weeks 2-3: build the scan pipeline against 3 open-source memory-heavy apps; publish one teardown ('We found the leak that Android 17 will kill your app for') as marketing. Week 4: offer 5 free scans to publishers found via complaint mining in exchange for testimonials.
60-day build
Convert free scans to paid ($199-$499/scan). Launch a landing page + the teardown content series targeting 'Android 17 memory limit' search terms while they're uncontested. Add the CI-integration tier (GitHub Action calling the scan service, $99-$299/mo per app). Target: 10 paid scans or 3 CI subscriptions.
90-day revenue plan
Realistic: $1-3k/mo from a mix of one-off scans and a handful of CI subscriptions — IF demand verification passed in month 1. The approval-gated fix-PR tier is a month-4+ play. HYPOTHESIS: revenue timing is the weakest link because pain scales with Android 17 device adoption, which may lag the 90-day window.
Distribution path
Complaint-mining outreach (his existing strength/tooling), SEO/content on an uncontested dated keyword ('Android 17 memory limits'), r/androiddev and Android dev Discord/Slack communities, and a free-tier hook (free kill-risk check on an uploaded APK). No enterprise sales; self-serve purchase. Risk: developers are a discount-seeking, DIY-prone audience.
Pricing hypothesis
$199-$499 one-off readiness scan; $99-$299/mo per app for per-release CI monitoring; fix-PR tier later at $500+/remediation or higher subscription. Anchors against existing observability spend (Embrace/Instabug seats) and against the cost of a perf engineer day.
Technical difficulty
Moderate. The pieces (Android CLI, emulators, heap-dump analysis, agent orchestration) are all documented and he has the agent-bridge pattern already built. Hard parts: reliably reproducing memory growth with generic navigation scripts (app-specific flows may be needed — this is the main scaling risk), heap-dump interpretation quality, and emulator fidelity vs. real low-RAM devices. The autonomous fix-PR tier is significantly harder (repo access, build verification, regression risk).
Legal / regulatory risk
Low for the scan tier (customer submits their own APK; standard ToS/liability disclaimer). Moderate for the fix-PR tier (code access agreements, liability if a merged fix breaks production). No regulated data.
Platform dependency
High on Google: the Android CLI, emulator behavior, and the memory-limit policy itself are all Google's. Google could also ship first-party 'why was my app killed' diagnostics in Play Console/Android Studio and gut the product — this is the single biggest structural risk, and Google has a track record of closing exactly these gaps.
Founder fit
Mixed. Fits: AI-agent orchestration (he runs headless Claude Code pipelines today), fast prototyping, complaint-mining distribution, demonstrated-value selling, data/report product shape. Does NOT fit the proven government-portal edge: nothing here compels anyone to file anything — it's discretionary tooling spend, not mandated compliance, so the ELDT-shaped VERY HIGH fit multiplier does not apply. He also has no stated Android publisher network, and buyers are developers (skeptical, DIY-prone). Net: moderate fit, not his best-in-class shape.
Breakout potential
If the scan wedge works, expansion paths are real: battery/startup/ANR agents on the same pipeline, iOS memory (Jetsam) twin product, or becoming the 'agentic app-health' layer that observability SaaS lacks — plausible acquisition interest from Embrace/Sentry-class companies. HYPOTHESIS throughout; depends on surviving Google closing the gap.
Final recommendation
CONDITIONAL GO at reduced scope, B-/C+ tier. Kill the 'autonomous fix-PR agent' as the entry product — it is a long-trust-cycle, Google-exposed play. The survivable wedge is the low-trust 'Android 17 Memory Readiness Scan' report product, but ONLY if a one-week complaint-mining pass proves developers are already feeling or fearing the kills. If pain evidence is thin, tag revisit-later and re-check at Android 17 GA + 60 days when the compliance wave is real. Do not start building before the demand check.
Next action
Spend 2-3 days mining r/androiddev, GitHub issues, Google issue tracker, and X for posts about Android 17 memory limits / silent kills; log count and severity. Threshold: ~20+ credible pain/anxiety posts from app publishers → build the scan MVP; below that → shelve with a calendar re-check at Android 17 GA.