What changed
FACT (source: android-developers.googleblog.com, 2026-05): Google declared Android UI development 'Compose First' — all Android UI APIs, libraries, tools, and guidance will be provided in Jetpack Compose going forward. FACT (same source family): Android Studio now ships end-to-end agentic app development driven by any chosen remote or local model rather than a bundled provider. FACT (source: vercel.com/changelog): GPT-5.6 Terra is asserted to match previous-generation performance at roughly half the price, with a cheaper Luna tier for high-volume low-margin workloads.
Why now
HYPOTHESIS: the three signals rhyme — a platform declares the old UI stack legacy, the first-party IDE gains agentic codemod capability with open model choice, and per-token inference cost halves, so the unit economics of bulk code transformation improve at the same moment demand for it is created. FACT: only the policy declaration and the tooling/pricing changes are sourced. The claim that this produces buyer urgency is INFERENCE, and it is the weakest link: 'Compose First' governs new APIs and guidance, not deprecation of View — nothing in the source says existing View code stops compiling, stops shipping, or stops receiving security patches.
Converging signals
android (Compose First policy) × dev (agentic IDE with open model choice) × ai (halved inference cost). The convergence is real as a capability stack. The convergence into a *business* requires a fourth signal that is absent from the input: evidence that anyone is currently paying money to migrate View code. No complaint stream, job posting, RFP, or existing vendor revenue appears in the provided sources.
Customer pain
HYPOTHESIS, unsourced: teams with large View/XML codebases face slowly compounding friction — new Google UI components arrive Compose-only, hiring pipelines skew Compose-native, and interop layers (AndroidView/ComposeView) add complexity. This is chronic pain, not acute pain. Nobody's app is down. Nobody is out of compliance. Nobody has a deadline. Chronic pain converts to revenue on multi-quarter cycles, which is fatal to a 30-90 day cash requirement.
Who pays
Nominally: Android engineering managers and CTOs at companies with 50k+ line legacy Android apps. Realistically this is the problem. Engineering orgs buy code-transformation services through procurement, security review, and source-code NDA — that is enterprise sales with a code-access gate. Indie Android devs (the only buyer reachable without enterprise motion) have small codebases, high skill, near-zero willingness to pay for something Claude Code or Android Studio's own agent does for free on their own machine.
Solved today
Developers migrate incrementally by hand using Google's own interop APIs, or they don't migrate at all. Increasingly they point an existing coding agent (Android Studio's agentic mode, Claude Code, Cursor) at the file and ask it to convert. FACT (source: Android Studio I/O post): the first-party IDE now does agentic development with the model of your choice.
Why current solutions are bad
It isn't badly solved enough. That is the core finding. The gap between 'hand migration' and 'agent migration' has just been closed *by the platform vendor, for free, inside the IDE the customer already has open*. A paid third-party service must beat a free first-party tool at the vendor's own API surface, with worse information about upcoming API changes.
Proposed product
Scanner (static AST/XML parse, no LLM) → per-screen complexity score → free PDF cost report → paid codemod delivery. Technically the scanner is genuinely easy and the report is a decent lead magnet. The paid half is the problem: correctness liability on someone else's production app, unbounded per-repo scope, and pixel/behavior regressions that only surface in QA weeks later.
MVP version
Realistic MVP is 2-3 weeks solo: a CLI + hosted uploader that walks a repo, counts layout XML files, custom Views, findViewById/ViewBinding call sites, RecyclerView adapters, Fragment lifecycle coupling, and emits a per-screen difficulty tier + estimated engineer-hours. Ships without any model calls at all. The scanner is not the risk; the sales motion is.
30-day build
Do NOT build the codemod. Build only the scanner and give it away as an open-source CLI. Instrument it to phone home an anonymized complexity histogram. Post it to r/androiddev, Android Weekly, and Hacker News. The single question to answer in 30 days: do any of the people who run it reply to 'want this done for you?' If fewer than 5 qualified replies from repos over 30 screens, kill it.
60-day build
CONDITIONAL on the 30-day gate. If replies exist, hand-deliver 2 paid migrations at a deliberately underpriced fixed fee ($2-4k) to learn real hours-per-screen. Do them manually with agent assistance, no product, no automation. The purpose is to discover whether per-screen effort has a stable enough variance to price at all. HYPOTHESIS: it does not — a screen with a custom View and a gesture detector is 20x a static form.
90-day revenue plan
Plausible ceiling is $5-10k of consulting-shaped revenue from 2-3 engagements, with the founder personally doing the work. That is not a product; it is a job with extra steps, and it requires the founder to be credible in Kotlin/Compose, which is outside the stated strength profile (industrial ops, recycling, public records, compliance monitoring).
Distribution path
Genuinely the strongest part: free OSS scanner → developer word-of-mouth → inbound. No ad spend, no enterprise motion for the *audit*. But the audit is free and the paid conversion crosses immediately into source-code access, MSAs, and security review. The distribution path that works for the lead magnet does not extend to the thing that earns money.
Pricing hypothesis
Per-screen ($150-400/screen) or per-repo fixed bid. Both are broken: per-screen invites the customer to hand you only the hard screens; per-repo forces you to eat variance you cannot estimate until you are inside the repo. HYPOTHESIS: any honest pricing model here converges to hourly, i.e. consulting.
Technical difficulty
Scanner: low. Codemod: high and underestimated. View→Compose is not a syntactic transform — it is a state-management rewrite (imperative mutation → unidirectional state), a lifecycle rewrite, and a testing rewrite. Agents produce plausible Compose that fails on recomposition, state hoisting, and side-effect placement. Verifying correctness on a repo you don't own, with tests you didn't write, is the actual product, and nobody has solved it.
Legal / regulatory risk
Moderate and unpleasant for a solo operator: you take custody of proprietary source code, you make automated edits, and a regression that ships to the Play Store is arguably yours. Requires an LLC, E&O-adjacent contract language, and indemnity caps. Not fatal, but it is friction on exactly the fast-cash path.
Platform dependency
Severe. FACT (source: Android Studio I/O post): Google is shipping agentic development in the first-party IDE. The entire paid deliverable of this business is a feature that Google is actively building into the free tool, with better API knowledge and no source-code custody problem. This is not a hypothetical competitor; it is a stated product direction in the same source that supplies the convergence.
Founder fit
Poor. This is a developer-tools play sold to Android engineering teams. The founder's demonstrated-value sales style works when the buyer can see the value without trusting the seller's credentials — a compliance monitor showing you a violation, a public-records report showing you a lien. Here the buyer must trust the seller with a production codebase, and the seller has no Android/Kotlin track record to point at. The founder's real edges (industrial ops, recycling, public records, fire service, complaint mining) are all unused.
Breakout potential
Low as scoped. The scanner could become a widely-installed free OSS tool with zero revenue. The one non-obvious asset is the anonymized telemetry — an aggregate dataset of how much View code actually survives in the wild — but selling that dataset is a slower, smaller business than the migration service it was supposed to feed.
Final recommendation
KILL as a business. Do not build the codemod service. The convergence is technically real — the three signals genuinely rhyme — but it converges on a capability, not a customer. Every element the founder profile requires is missing: no urgent pain (Compose First is a guidance policy, not a deprecation), no demand evidence anywhere in the source set, no non-enterprise path to the paying buyer, no pricing model that survives variance, and a first-party free competitor named in the founding source itself. The one salvageable artifact is the scanner: a ~2-week, LLM-free static-analysis CLI that is cheap enough to open-source as a reputation asset and a telemetry probe. Ship that only if it costs under two weeks and only as a bet on discovering demand that the current evidence does not support. Treat any revenue from it as consulting, not product. The founder's time in the next 90 days is better spent on opportunities where the buyer is already spending money and the pain has a deadline attached — compliance monitors, public-records products, industrial/scrap operational tooling — which is precisely where his credibility compounds and this idea's does not.
Next action
Do not build. Spend 90 minutes falsifying the single load-bearing assumption before anything else: search r/androiddev, Android Weekly archives, Upwork/Toptal, and Google's own Compose migration docs for evidence that (a) anyone is currently paying for View→Compose migration, and (b) whether Google has announced any deprecation date for View. If no paid demand exists and no deprecation date exists — which is the expected outcome given the sources — archive this permanently and move on.