What changed
Two facts from the sources: (1) Android 17 enforces per-app memory limits scaled to device RAM and kills violators with no stack trace (Android Developers Blog, June 2026); (2) the Android CLI is now stable at 1.0 and lets coding agents drive first-party profilers, builds, and device streaming programmatically (Android Developers Blog, May/June 2026). Together they make memory-ceiling auditing mechanically batchable by one operator with agents, where it was previously senior-engineer debugging work.
Why now
FACT: Android 17 is rolling out now and the kills produce no stack trace, so publishers see crash-rate/churn spikes with no diagnostic breadcrumb. HYPOTHESIS: a 3-9 month window exists before (a) observability vendors ship ApplicationExitInfo-based silent-kill dashboards and (b) in-house teams absorb the new profiling workflow, after which the standalone service commoditizes.
Converging signals
Signal 841 (per-app memory limits + traceless kills) supplies the forced pain; signals 835/843 (stable Android CLI, agent-drivable profilers and builds) supply the leverage that lets a solo operator run what used to be a specialist consulting engagement as a repeatable pipeline across many apps.
Customer pain
FACT (from source mechanics): memory-heavy apps (games, media, camera/AR) on mid-RAM devices get killed with no crash report, so publishers experience rating drops, refund requests, and churn they cannot attribute. HYPOTHESIS: most small/mid publishers lack anyone who can reproduce and profile these kills, and their crash-reporting SaaS shows nothing because no exception is thrown.
Who pays
HYPOTHESIS: (a) indie/mid-size game and media app studios with live revenue-bearing apps; (b) agencies maintaining legacy app portfolios for clients. Both pay for outcomes (crash spike stops), not tooling. NOTE: 'enterprises with legacy apps' should be dropped from targeting — that path violates the founder's no-enterprise-sales constraint.
Solved today
In-house devs use the free first-party Android Studio Memory Profiler and LeakCanary, or subscribe to mobile observability (Embrace, Sentry, Instabug) which is starting to surface ApplicationExitInfo exit reasons. Otherwise they hire a mobile performance consultant at day rates, or ignore it until reviews crater.
Why current solutions are bad
Free tools require a skilled operator and a reproducible workload — exactly what small studios lack. Observability SaaS tells you the app died of memory pressure but not which allocation to fix. Consultants are slow and expensive per app; none of the current options batch across a portfolio.
Proposed product
Productized service, not a tool: 'Android 17 Kill Audit.' Tier 1 (low-trust wedge): automated scan of the customer's release APK run under agent-controlled profilers on emulated mid-RAM device profiles, producing a report of allocations/peaks that breach Android 17 ceilings — no source access required, fixed price. Tier 2: source-level remediation PRs for flagged apps, per-app fixed fee. Agents (Claude Code + Android CLI) run the profiling harness and draft fixes; the operator reviews and ships.
MVP version
A repeatable harness: install target APK on a 4GB-RAM emulator profile, drive a scripted UI session (agent-generated via device streaming), capture heap/RSS timelines with the CLI-driven profiler, diff against Android 17 documented ceilings, emit a branded PDF/HTML report. Validate on 5 popular memory-heavy apps and publish 2-3 teardown reports as proof. Estimated 2-4 weeks of AI-assisted build. RISK (hypothesis): generating a representative workload per app is the hard part and may not fully automate — this is the technical kill-or-cure question to answer in week 1.
30-day build
Week 1-2: build the harness; run it on 5 well-known games/media apps. Week 2-3: publish teardowns ('We ran [known app] against Android 17's memory ceiling — here's where it dies') as SEO/social proof. Week 3-4: cold outreach to 50 small game/media studios whose Play Store reviews already mention crashes on budget devices, offering a $500-1,500 fixed-price audit of one app.
60-day build
Convert 3-5 audits; upsell 1-2 remediation engagements ($2,500-7,500 fixed per app). Refine the harness so a second app costs near-zero marginal operator time. Approach 5-10 agencies with a portfolio-scan offer (10 apps for the price of 4).
90-day revenue plan
HYPOTHESIS: realistic 90-day outcome is $3k-15k from 4-8 audits plus 1-2 remediations — freelance-consulting-shaped revenue, not compounding SaaS revenue, unless a self-serve APK-scan product ($99-299/scan) shows organic pull from the teardown content.
Distribution path
Teardown content of famous apps failing the ceiling (linkbait with built-in proof), cold email to studios with visible crash complaints in reviews, r/androiddev and gamedev communities, and Upwork/Toptal-style listings to catch existing search demand. No enterprise sales required for Tier 1. HYPOTHESIS: Tier 2 (code access) will stall on trust with strangers — expect Tier 2 to close only after a Tier 1 report proves competence.
Pricing hypothesis
Tier 1 APK scan/report: $500-1,500 per app (self-serve automated version at $99-299 later). Tier 2 remediation: $2,500-7,500 fixed per app. Agency portfolio scans: volume-discounted bundles.
Technical difficulty
Moderate-high. The profiler-driving and report pipeline is squarely agent-automatable per the CLI sources. The honest hard parts: building representative UI workloads per unknown app, avoiding false positives (a peak in an emulator session ≠ a real-world kill), and Tier 2 fixes in unfamiliar, possibly NDK/Unity codebases where 'remediation PR' is senior-level work agents only partially de-risk.
Legal / regulatory risk
Low. Profiling apps you're hired to profile is clean. Publishing teardowns of third-party apps has mild defamation/ToS optics risk — frame findings carefully as measurements, not accusations.
Platform dependency
High on Google: the entire pain exists because of Android 17 policy, and the leverage exists because of Google's CLI. Google could blunt the market by improving developer-facing kill diagnostics (ApplicationExitInfo surfacing in Play Console), which is plausible within 6-12 months. This is a window play, not a moat play.
Founder fit
Mixed, and materially weaker than his government-portal pattern. MATCHES: agent-run batchable pipeline, productized service, demonstrated-value selling, fast low-budget MVP, complaint-mining (Play reviews) for lead gen. MISSES: this is NOT the regulation-forces-filing shape — nobody must file anything with anyone; there is no per-transaction chokepoint. He has no Android performance reputation, and Tier 2 requires studios to hand source code to a stranger, which brushes his 'avoid trust-building plays' constraint. Fit is real but mediocre: ~5/10, not the VERY HIGH reserved for portal-filing plays.
Breakout potential
Moderate: if the self-serve APK scanner shows pull, it can become a micro-SaaS (pre-release memory-ceiling CI check, $49-199/mo per app) with recurring revenue. Otherwise it plateaus as one-person consulting with a decaying window.
Final recommendation
PARK / cheap test only. The convergence is real and the agent-leverage thesis is sound, but this lacks the compelled-filing chokepoint that defines this founder's proven edge, has zero demand evidence today, and its money tier fights a trust barrier he deliberately avoids. If tested at all: spend ≤2 weeks building the APK-scan harness, publish 3 teardowns, and send 50 cold emails. Two paid audits in 30 days = continue; zero = kill and harvest the harness as content/portfolio. Do not build the SaaS first.
Next action
Spend 2 days on the kill-or-cure technical question: use the Android CLI + an agent to profile ONE known memory-heavy app on a 4GB emulator profile and produce a ceiling-breach report end-to-end. If workload automation works, publish it as teardown #1; if it doesn't, kill immediately.