What changed
Two Android platform shifts collided: (1) Google AI Studio now emits installable native Android apps from a prompt for people with no tooling or coding skill (FACT, per android-developers.googleblog.com 2026-05), and (2) starting Android 17 the OS enforces per-app RAM budgets and silently kills over-budget apps with no stack trace (FACT, per android-developers.googleblog.com 2026-06). Cheaper frontier reasoning (GPT-5.6 cost-performance claim; INFERENCE it lowers per-fix unit cost) makes an automated diagnose-and-rewrite loop economically plausible.
Why now
Android 17's memory-kill enforcement is new and coincides with a fresh cohort of non-developers shipping native apps they cannot debug. The window is the gap before Google absorbs the fix into AI Studio's own generation/build pipeline.
Converging signals
Prompt-to-native-app generation (837) + Android 17 stack-trace-less memory kills (841) + cheaper capable reasoning (1075). This is a genuine capability convergence, but note ALL three are capability signals — there is zero demand signal in the input.
Customer pain
HYPOTHESIS, not established by any provided evidence: a non-coder ships an AI-generated app, it dies silently on some devices, and they have no stack trace, no profiler skill, and no way to diagnose it. The input's own 'MUST BE TRUE' concedes this is unproven; the KILL TEST (run 20 real AI-Studio apps under Android 17) has not been run.
Who pays
Non-developer / 'vibe-coder' app makers. This is a structurally weak buyer: they self-selected AWAY from technical work, have low willingness to pay for developer tooling, are individually low-value, and are not reachable through any concentrated channel. A hobbyist whose free-prompted app dies is more likely to abandon it than to pay for a remediation service.
Solved today
Real developers use Android Studio Memory Profiler, LeakCanary, and Perfetto (all free) and read the platform's own Android 17 memory-efficiency guidance. Non-coders currently do nothing — which is as likely to mean 'they don't care / they abandon the app' as 'they'll pay to fix it.'
Why current solutions are bad
Existing tools assume the user can read a heap dump. That's a real gap — but the gap being real does not prove the affected users will pay to close it.
Proposed product
Upload-your-APK-or-project → agent profiles memory against Android 17 budgets on emulated device tiers, localizes leaks/over-allocation, applies fixes, rebuilds, and returns a signed APK plus a before/after memory report. Per-fix pricing.
MVP version
A harness that runs a submitted app under the Android CLI/emulator at constrained memory tiers, captures allocation data, feeds it to a reasoning agent that proposes and applies source patches, and rebuilds. Validate reliability on a real corpus BEFORE building any UI or billing.
30-day build
DO THE KILL TEST FIRST. Generate/collect 20-50 real AI-Studio apps, run them under Android 17 memory limits, and measure: what fraction actually get killed, and of those, what fraction the agent can fix reliably (not break) end-to-end. This is a research spike, not a product build.
60-day build
Only if the kill test clears both bars: build a thin submission→fixed-build pipeline and find where non-coder AI-Studio makers actually congregate (specific Discords/subreddits/forums) to test whether ANY will pay.
90-day revenue plan
Charge per remediated build ($5-25) once a repeatable fix rate and a reachable buyer are both demonstrated. Realistically revenue is unproven and gated on the 30-day kill test outcome.
Distribution path
No concentrated channel exists for non-coder app makers; you'd chase them across AI-Studio community spaces and no-code forums. Weak, ad-hoc, and expensive relative to a low price point.
Pricing hypothesis
Per-fix $5-25 or a small subscription. Low ceiling given the buyer profile.
Technical difficulty
High and under-appreciated: reliably diagnosing memory over-allocation from an arbitrary generated codebase AND applying a correct fix that doesn't break the app is far harder than the '90-DAY BUILD' summary implies. Autonomous code-rewrite-and-rebuild with a quality guarantee is the core risk.
Legal / regulatory risk
Modest: handling users' app source/APKs raises IP and liability questions if a 'fixed' build misbehaves, but nothing regulatory.
Platform dependency
SEVERE. This lives entirely inside Google's Android + AI Studio ecosystem. The single most likely outcome is that Google closes the gap upstream — making AI Studio generate memory-conscious code or adding a memory-fix step to its own build pipeline — which vaporizes the product. You are betting your business on a platform owner not fixing their own toolchain's obvious deficiency.
Founder fit
LOW-MODERATE. It is an AI agent / micro-tool (a form he likes), but it is NOT the founder's primary thesis: no public money, no forced filer, no government portal, no compliance mandate. It targets exactly the kind of discretionary consumer-adjacent buyer with weak willingness-to-pay that the profile steers away from, and depends on a platform owner — a stated avoid.
Breakout potential
Low. Even if it works, it's a per-fix utility with a low price, a weak buyer, and a platform sword hanging over it. No network effect or durable moat; the moat (autonomous fix quality) is exactly what the platform owner is best positioned to replicate.
Final recommendation
KILL / PARK. Do not build. The idea fails on the right reasons: no demonstrated buyer, weak willingness-to-pay, and near-total dependence on a platform owner likely to fix the problem upstream. It is also off-thesis (no public money / forced filer). The one cheap, honest next step is the 30-day KILL TEST — if a large fraction of real AI-Studio apps actually die under Android 17 AND the agent fixes them reliably, revisit; otherwise it's dead. Do not spend build effort ahead of that evidence.
Next action
Run the KILL TEST as a 1-week research spike: generate/collect 20-30 real AI-Studio-produced apps, run them under Android 17 per-app memory limits on emulated device tiers, and record what % get killed and what % a reasoning agent can fix end-to-end without breaking. Decide go/no-go on those two numbers alone.