What changed
Three capability drops landed together: Google shipped computer use in Gemini 3.5 Flash (agentic screen/browser control at a cheap, fast tier — deepmind.google blog, FACT from source), Gemini API Managed Agents added background tasks and remote MCP so the agent-loop/tool-server plumbing is provider-hosted (blog.google, FACT at headline level), and OfficeCLI gives headless Office-file manipulation with one binary and no Microsoft Office dependency (github.com/iOfficeAI/OfficeCLI, FACT as project claim). Coasty's launch (producthunt.com) shows the productized form already emerging — its reliability is a vendor claim, unverified.
Why now
Per-task economics flipped: computer use previously required frontier-tier pricing and self-hosted orchestration, pricing solo builders out of long-running UI automation. A Flash-tier model plus managed background execution collapses both cost curves at once. Window is short — the same drop that enables this founder enables hundreds of others.
Converging signals
Cheap computer-use model (Gemini 3.5 Flash) + provider-hosted long-running agents/MCP (Managed Agents) + headless Office I/O (OfficeCLI) + evidence competitors are forming (Coasty). All four are capability signals; none is a demand signal.
Customer pain
HYPOTHESIS (no demand_evidence supplied): SMBs running GUI-only legacy line-of-business software (dispatch, yard management, title/permit, insurance rating, practice management) pay staff to re-key data between that software and spreadsheets/portals because there is no API and traditional RPA (UiPath tier) is priced and scoped for enterprises. The pain is real in general RPA-market lore, but THIS input provides zero complaints, job postings, or mandates proving it — the engine's own lesson flags it as capability-rich/demand-blind, and that lesson (conf 0.85) applies squarely here.
Who pays
HYPOTHESIS: owner/ops manager of an SMB (5–100 seats) locked into one specific legacy GUI application. Generic 'SMBs stuck on GUI software' is not a reachable buyer; a named vertical app's user base is. Founder's recycling/scrap background suggests a concrete wedge: scrap-yard management software (ScrapDragon, ScrapRight, 21st Century Programming class) is GUI-heavy, compliance-laden (state metal-theft reporting), and its operators are a community Charles can credibly demo to — this is inference from founder profile, not from source signals.
Solved today
Manual re-keying by clerks; offshore VAs; enterprise RPA (UiPath/Automation Anywhere) for companies big enough to afford licenses plus an integrator; brittle AutoHotkey/macro scripts maintained by nobody.
Why current solutions are bad
Manual labor is slow and error-prone; enterprise RPA has enterprise pricing/procurement; scripted macros break on every UI change. A vision-based agent tolerates UI drift better than pixel/selector macros (hypothesis — reliability of Flash-tier computer use on ugly Win32 legacy apps is exactly the unverified claim in the Coasty signal).
Proposed product
Not a horizontal 'automation as a service' agency — that is unsellable and unscalable solo. Instead: a productized automation for ONE legacy vertical app: e.g., 'the bridge for [named yard-management system]' that watches a folder/inbox, drives the GUI to enter tickets/pull reports, and emits Office/CSV outputs (OfficeCLI) — sold as a flat monthly subscription per workflow, hosted, with Managed Agents doing the long-running orchestration.
MVP version
Pick one target app with a demo/trial install. Build one high-frequency workflow end-to-end (e.g., daily report extraction + re-entry into a state compliance portal), running on a VM the founder controls, with human-review screenshots on every run. 2–4 weeks of build given his AI-workflow speed; the hard part is acquiring a copy of the legacy app to develop against.
30-day build
Validate demand BEFORE building: mine the target vertical's forums/Facebook groups/user conferences for re-keying complaints; interview 5 operators (he has scrap-industry credibility); confirm the legacy app's ToS doesn't prohibit automation. Build the single-workflow MVP against a trial/demo instance in parallel only if two operators say they'd pay.
60-day build
Run the MVP live for 1–2 design partners at a founding-customer rate ($200–500/mo) with white-glove monitoring; instrument every run for failure modes; harden retries and human-fallback.
90-day revenue plan
5–10 paying SMBs at $300–800/mo per workflow via direct demo (screen recording of the agent doing the clerk's job is the entire pitch — matches his demonstrated-value sales style). $2–6k MRR is the realistic 90–180 day band; this is a 3–6 month ramp the founder can now fund.
Distribution path
Vertical-specific: industry Facebook groups, ISRI/ReMA-adjacent communities, the legacy vendor's user forum, direct video-demo outreach. Weak generic channels; strong only if the vertical is one where he already has standing (scrap/recycling).
Pricing hypothesis
$300–800/mo per automated workflow, or per-transaction ($0.25–1.00 per record keyed) which mirrors his proven ELDT per-upload model and matches variable agent-inference cost.
Technical difficulty
Moderate. Computer-use reliability on legacy Win32 apps is THE technical risk — Flash-tier vision agents misclick, and a misclick in a system of record creates real damage. Requires idempotent designs, screenshot audit trails, and human review queues. Windows VM fleet management is unglamorous but solo-doable.
Legal / regulatory risk
Moderate-low: automating a third-party app may violate its EULA (vendor could threaten customers, not just him); customer data flows through Gemini API — needs a DPA story for anything sensitive. No regulated-medical/financial exposure if vertical chosen carefully.
Platform dependency
High and double-ended: Gemini API pricing/behavior on one side (Managed Agents is new and Google deprecates aggressively), the legacy app vendor's tolerance on the other. The legacy vendor could also ship its own API/automation and erase the wedge.
Founder fit
Mixed. Fits: AI workflows, automation, fast prototyping, demonstrated-value selling, and (if scrap vertical) domain credibility. Does not fit the proven government-portal-mandate shape — there is no forced buyer, no deadline, no regulation compelling anyone (the 0.80-confidence lesson on mandate-shaped fit does NOT apply here). This is a discretionary-purchase efficiency sale, which is a harder sale than a compliance sale. Hybrid salvage: choose a workflow where the legacy GUI's output must be filed with a government system (e.g., state scrap-metal transaction reporting) — that reintroduces the forced-buyer dynamic he already knows how to monetize.
Breakout potential
Moderate: nail one vertical app → own its ecosystem, add workflows, then replicate the playbook on the next trapped vertical. Ceiling is a portfolio of niche bridges (good lifestyle business, sellable as micro-SaaS), not a platform — the platform version of this idea is being built by funded startups right now.
Final recommendation
HOLD / REVISIT WITH EVIDENCE — do not build the generic version. The capability convergence is real and the economics genuinely changed, but with an empty demand_evidence array this is a solution seeking a documented problem. Concrete next step exists though: spend ~1 week validating the scrap-yard-software wedge (his domain), specifically a workflow that ends in a government filing (state metal-theft/transaction reporting), which would convert this from an efficiency sale into his proven forced-buyer shape. If two operators confirm they'd pay, upgrade to BUILD.
Next action
Demand-validation sprint, not code: identify the top 3 GUI-only scrap/recycling management systems, join their user communities, and collect ≥5 first-hand re-keying or state-reporting complaints (URLs/screenshots) plus 2 operator interviews. Simultaneously verify Gemini 3.5 Flash computer-use reliability on one real legacy Windows app with a 50-run misclick benchmark.