What changed
FACT (source: android-developers.googleblog.com, 2026-06): Starting in Android 17 the system enforces per-app memory limits keyed to device RAM and kills over-budget apps with no stack trace. FACT (2026-05): a stable first-party Android CLI 1.0 makes builds and heap/memory analysis scriptable from any agent. HYPOTHESIS: this combination makes an automated, CI-embeddable memory-budget auditor newly buildable by a solo dev.
Why now
The enforcement 'just shipped and is mandatory ecosystem-wide' per the Android 17 post — a dated, non-deferrable ecosystem change. Devs face silent user loss with no diagnostic breadcrumb, and the newly-stable CLI + cheap LLM reasoning make the tooling cheap to build right as the pain lands. This is a real 'why now,' though the demand is INFERRED from the mandate, not from observed complaints (demand_evidence is empty).
Converging signals
Three signals meet: (1) Android 17 per-app RAM enforcement + silent kills (the pain), (2) stable Android CLI 1.0 enabling scriptable heap analysis (the delivery mechanism), (3) cheap desktop LLM reasoning to translate raw profiles into remediation steps (the value-add). The convergence is real but capability-heavy; the actual buyer pain is asserted, not evidenced in the input.
Customer pain
Indie/solo Android devs and small studios whose live apps get killed with no stack trace can't see or diagnose why they're losing users. Debugging a stackless OOM-kill against opaque per-device budgets is genuinely maddening — a plausible acute painkiller IF the kills are frequent and hard to diagnose with stock tools.
Who pays
Solo/indie Android developers and small studios shipping memory-heavy apps (games, camera/photo, ML-on-device). Discretionary prosumer/SMB buyer who pays by card. NOT a forced-buyer/government-mandate shape despite the 'mandatory' framing — Google enforces at runtime, but no one is compelled to buy a third-party tool.
Solved today
Android Studio's built-in Memory Profiler, LeakCanary (free, widely used leak detector), Perfetto/heap dumps, R8 tuning by hand, and Play Console vitals/ANR-crash reporting. Google will also publish first-party guidance and likely surface memory-kill telemetry in Play Console vitals.
Why current solutions are bad
Built-in tools require manual profiling sessions and expertise; they don't compute the per-device RAM budget for you or produce a prioritized fix list. But this is the CORE KILL RISK: Android Studio's profiler + LeakCanary are free, first-party/well-loved, and improving, and Google has every incentive to make Play Console show exactly which apps are getting memory-killed. A paid report may not clear the bar over free tooling.
Proposed product
A web app + CLI that ingests an R8/proguard config plus a heap dump or memory profile (or, lighter, a Play listing), computes per-device RAM budgets across the Android 17 device matrix, flags what will exceed them, and uses an LLM to emit a concrete remediation checklist (leaks, oversized bitmaps, R8 shrink/optimize tuning). CI mode watches memory footprint per build and fails/alerts on regressions.
MVP version
CLI that runs a heap dump through analysis + an LLM remediation pass and prints a prioritized fix list with per-device budget headroom; thin web uploader for non-CI users. Ship the CLI first — it's the differentiator (CI monitoring) and is close to what the stable Android CLI already enables.
30-day build
Validate demand BEFORE building deep: post in r/androiddev (via OAuth — datacenter IP is blocked), Android dev Discords/Slacks, and HN when Android 17 rolls out, asking devs if they're seeing silent kills and would pay. Build the CLI heap-analysis + budget-computation core against a handful of real open-source apps. Confirm the LLM fix-list is actually correct/non-hallucinated on known leaks.
60-day build
Ship paid one-time audit ($29) via web upload with Stripe; launch CLI beta for CI ($19/mo). Content marketing: 'Why Android 17 is silently killing your app' teardown posts with real before/after fixes. Integrate into GitHub Actions as a marketplace action for distribution.
90-day revenue plan
Convert CI trials to $19/mo subscriptions across small studios with multiple apps; upsell audit buyers into monitoring. Realistic first revenue in 30-90 days IF the pain is real; the risk is not speed but whether devs pay over free tools.
Distribution path
r/androiddev (needs Reddit OAuth per system lesson), HN Show HN, Android dev Discords, a GitHub Actions marketplace action, and SEO on 'Android 17 memory kill / OutOfMemory / per-app RAM limit'. Product-led: free budget estimate from a Play listing, paid for the full fix list.
Pricing hypothesis
$29 one-time per-app audit; $19/mo per-org CI monitoring. Reasonable for the value; the constraint is willingness-to-pay vs free profilers, not price sensitivity.
Technical difficulty
Moderate. Heap-dump parsing (hprof), mapping to per-device budgets, and R8 config reasoning are non-trivial and require real Android expertise to be credible; LLM remediation must be grounded to avoid hallucinated fixes that erode trust. The founder is a fast AI-assisted prototyper but this is outside his core industrial/public-records edge — Android internals are a learning curve.
Legal / regulatory risk
Low. No PII if profiles are processed transiently; note that uploaded heap dumps can contain app data (handle/delete promptly).
Platform dependency
Moderate-to-high PRODUCT risk (not policy risk): the entire thesis rests on Android 17 behavior Google controls and is actively tooling around. If Google ships good first-party memory-kill diagnostics in Play Console/Android Studio (likely), the wedge narrows fast. No deplatforming risk — it's a dev tool, not an app-store listing.
Founder fit
Mismatch on the founder's strongest theses. This is NOT a public-money / forced-filer / claimable-money play (his highest-fit shape) and NOT in his industrial/recycling/public-records/compliance-portal wheelhouse. It's a developer-tools micro-SaaS requiring deep Android runtime expertise he'd have to acquire. It fits his stated liking for micro-SaaS/CLI/API products and fast prototyping, but competes on ground where the free incumbent is Google itself.
Breakout potential
Modest. Could expand into a broader 'Android app health / vitals CI' tool, but that walks straight into Play Console vitals and firebase. A time-boxed spike of demand around the Android 17 rollout, not a durable franchise.
Final recommendation
WEAK / REVISIT-LATER. Real, well-timed 'why now,' but it fails the founder's own kill test (adequate free path via first-party tooling), has no demand evidence, sits off his highest-fit theses, and competes against Google's improving native tooling. Do not build speculatively. Only pursue if a quick 30-day demand probe in r/androiddev shows devs actively saying they can't diagnose the kills AND will pay over free tools.
Next action
Run a 1-week demand probe: post in r/androiddev (set up Reddit OAuth first — datacenter IPs are blocked), Android Discords, and HN once Android 17 is live, asking devs if they're hitting silent memory kills they can't diagnose and would pay $29 to fix. Build nothing until ≥10 credible 'yes, I'd pay' signals appear.