What changed
FACT (Google Android Developers Blog, June 2026): Android 17 enforces per-app memory limits scaled to device RAM and kills offending apps with no stack trace. FACT (Google blog, May/June 2026): the Android CLI hit stable 1.0, letting coding agents drive builds, profilers, Compose previews, and device streaming — previously senior-engineer, IDE-bound work.
Why now
Both changes landed within weeks of each other. As Android 17 rolls out to devices over the next release cycles, publishers of memory-heavy apps will see session drops and 1-star 'app just closes' reviews with empty crash dashboards. HYPOTHESIS: a discovery wave of confused publishers hits dev forums within 1-3 months of broad Android 17 adoption — that is the sales window.
Converging signals
(1) New enforcement regime creating an invisible failure mode for every memory-heavy app [android-developers.googleblog.com, June 2026]. (2) Stable first-party CLI making profiler/build workflows agent-drivable [android-developers.googleblog.com, May 2026]. (3) Same CLI confirmed for Studio features incl. device streaming [android-developers.googleblog.com, June 2026]. The combination collapses the cost of memory-leak diagnosis from senior-engineer-days to agent-pipeline-hours, exactly when demand for it becomes universal.
Customer pain
Users on Android 17 devices get their app killed mid-session with zero diagnostics: no Crashlytics event, no stack trace, no repro. Retention and review scores fall and the publisher cannot see why. HYPOTHESIS: pain is currently latent — most publishers have not yet noticed because Android 17 device penetration is still ramping.
Who pays
Small-to-mid Android app publishers (games, media/streaming, camera/photo apps) and agencies maintaining legacy client apps — teams without a dedicated performance engineer. NOT large publishers (they have platform teams and vendor contracts).
Solved today
LeakCanary (free, standard) for in-dev leak detection; Android Studio Memory Profiler by hand; ApplicationExitInfo queries if a developer knows to look; paid observability SDKs (Sentry, Embrace, Instabug) for general crash/ANR visibility. HYPOTHESIS: none of these yet packages 'Android 17 kill' as a named, diagnosed, fixed outcome.
Why current solutions are bad
LeakCanary requires an engineer who knows memory work and only catches leaks it's wired to see; profiler sessions are senior-level manual labor; observability SDKs show symptoms, not fixes, and silent OS kills may not surface as crash events at all. The gap is the last mile: reproduce the kill, find the allocation source, ship a verified patch.
Proposed product
A fixed-price 'Android 17 Memory Audit' ($1.5k-$5k tiered by app size): customer grants repo access; an agent pipeline (Claude Code + Android CLI) builds the app, replays memory-pressure scenarios on constrained device profiles, captures heap dumps/profiler traces, localizes leaks/bloat, drafts patches as PRs, and re-verifies under the same pressure. Deliverable: diagnosis report + working PRs. Lead magnet: a free scanner script/tiny SDK snippet reading ApplicationExitInfo to tell a publisher whether Android 17 is killing them (HYPOTHESIS: ApplicationExitInfo reflects these kills — must verify in week 1).
MVP version
Week 1-2: the free detector (script + instructions) plus the agent pipeline proven end-to-end on 2-3 open-source memory-heavy apps, producing before/after case studies with real profiler screenshots. No product UI — the MVP is the pipeline plus proof.
30-day build
Verify the kill mechanism on a real Android 17 device/emulator (does ApplicationExitInfo record it? what signal is observable?). Build detector + pipeline. Produce 2 public case studies on OSS apps. Publish 'Is Android 17 silently killing your app?' post targeting the exact search phrases confused devs will use; answer every relevant StackOverflow/Reddit thread.
60-day build
Run 3-5 paid pilot audits at $1k-$2k (discounted for testimonials), sourced from complaint-mining (Play reviews mentioning 'app closes by itself' on new devices, r/androiddev, agency outreach). Harden the pipeline on real messy codebases; publish results.
90-day revenue plan
Target $5k-$15k: 3-8 audits at full price ($1.5k-$5k), plus a $200-$500/mo 'kill monitor' retainer (rerun on each release) for audit customers. HYPOTHESIS: conversion depends entirely on whether the discovery wave has started; if Android 17 adoption lags, revenue slips a quarter.
Distribution path
Complaint-mining and demonstrated value — his proven motion: find publishers already bleeding (review mining, forum threads), send them a free detector result or a specific 'your app X gets killed at Y MB on device Z' finding, convert to paid audit. Plus SEO on the panic keywords, which are brand-new and uncontested. No enterprise sales needed at this deal size.
Pricing hypothesis
Free detector → $1.5k/$3k/$5k fixed-price audit tiers by codebase size → $200-$500/mo regression-monitoring retainer. Per-audit pricing matches his per-transaction preference; retainer builds recurring base.
Technical difficulty
Moderate-high. Agent tooling lowers it, but real risks: reproducing memory kills deterministically across device profiles, native (NDK) memory issues agents handle poorly, giant Gradle builds, and customers' repos failing to build at all. Fixed-price on unknown codebases is a margin trap — mitigate with a paid diagnostic phase before quoting the fix phase.
Legal / regulatory risk
Low. Access to client source code needs an NDA and liability-limited contract (template-level work). No regulated data, no government filings, no user PII required.
Platform dependency
Real but acceptable: the service exists because of Google's enforcement and rides Google's CLI. Biggest dependency risk is Google shipping better first-party diagnostics for these kills (likely eventually), which shrinks the diagnosis moat but not the fix-it-for-me service.
Founder fit
Medium (6/10) — honest read: this is NOT his proven government-portal shape (the 'mandate forces filing, charge per filing' pattern scores VERY HIGH; this scores as its weaker cousin: a platform mandate creating a compliance-like deadline, but with no filing transaction to own). It DOES fit his AI-agent-pipeline strength, complaint-mining distribution, productized-service pricing, and demonstrated-value sales. It does NOT leverage his industrial/records/fire-service domains, and he has no stated deep Android performance background — the agents must genuinely carry the expertise or credibility collapses on the first hard audit.
Breakout potential
If the audit pipeline proves repeatable, it productizes into a CI-integrated 'memory-kill regression gate' micro-SaaS sold per-app per-month — a real expansion path. Also generalizes to future OS-enforcement waves (battery, background limits).
Final recommendation
CONDITIONAL GO as a cheap probe, not a commitment. Spend ≤2 weeks: (1) verify on a real device/emulator exactly what trace an Android 17 memory kill leaves (ApplicationExitInfo or nothing), (2) run the agent pipeline end-to-end on one OSS app, (3) mine Play reviews/forums for the first genuine victim complaints. If victims are findable and the pipeline works, launch the audit; if either fails, park it with an alert on 'Android 17 app killed' search/forum volume and revisit. Do not build a SaaS first.
Next action
Today: spin up an Android 17 emulator image, drive a deliberately leaky sample app past its memory limit, and document exactly what the OS records (this single fact — is the kill detectable via ApplicationExitInfo? — determines whether the free lead-gen detector is even possible).