Business case · DroidLink
DroidLink: the business case
Research, competitive landscape, target audience, positioning, go-to-market, pricing, risks and execution plan for a hosted MCP server that gives an AI agent a real Android phone, paired by device code.
Imants K. · September 2026 · figures marked projection are estimates, not results.
Summary
In brief
DroidLink gives an AI agent control of a physical Android phone over one secure outbound connection. The phone pairs with a device code, needs no cable or open port, and stays reachable from anywhere. The service is deployed under droidlink.me and proven on a handful of devices from Android 9 up. Billing is wired end to end; no live payment has been taken.
- Why now: agents plan and call tools through MCP; a real phone behind a carrier network is still hard to hand to one.
- Difference: hosted access to a phone the customer owns, paired by device code, with per-device identity and account permissions.
- Revenue: per-seat subscriptions priced against the real-device testing market; no hardware bought per added device; service costs to be measured in the beta.
- Fit: a standalone product that runs on billing, audience and education channels that already exist.
Pinned
TLS 1.3 + Ed25519 identity
Rust
one shared core, app to control plane
The problem
Agents cannot reach real phones
AI agents plan and act, and three things keep them off real phones.
- Emulators differ from phones. An emulator does not reproduce a handset's carrier connection, hardware and device-specific behaviour.
- Phones are unreachable. Carrier NAT and home routers block inbound connections to a phone in most setups; adb over the network stops at the first router.
- Raw adb and accessibility are unsafe. Raw adb and accessibility access carry no device identity, scope or revocation on their own; those have to be added.
The product
A real phone behind a secure MCP endpoint
The DroidLink app dials out to a hosted relay over one WebSocket. The agent connects to a hosted /mcp endpoint and drives the device through MCP tools.
Architecture
Open app and a shared Rust core (device key, multiplex framing, provisioning proof); relay, stdio MCP server and gateway; admin control plane (pairing, keys, seats, billing); premium tool crate.
Security
Inner TLS 1.3; per-device Ed25519 key bound to the session (RFC 5705 exporter); relay pinning (RFC 7250, invariant C1); multiplexed adbd (up to 32 streams); fail-closed by construction.
What the agent can do
23 core tools over stdio; 29 over the gateway, adding four premium tools and two pairing tools. Five tools are tier-gated, including core droid-shell. See: droid-capture, droid-ui-dump, droid-diff. Touch: droid-tap, droid-swipe, droid-gesture, droid-pinch, droid-drag, droid-keyevent, droid-type. Operate: droid-launch, droid-install, droid-packages, droid-info, droid-flow, droid-automate, droid-shell. Premium: droid-vision, droid-record, droid-stream, droid-fleet. Coordinate taps are checked against display bounds; selector taps resolve UI elements. Screenshots are blocked when the hierarchy contains a password field; UI dumps redact password attributes.
Connection method
No wires, device-code pairing
Every tool here can tap and swipe. They differ in how the phone gets connected, whose phone it is, and whether it stays reachable. Checked 20 September 2026.
| Tool | How you connect | Reachable from anywhere? |
|---|
| DroidLink | Pair with a device code (approve on the phone); the phone dials out over WSS | Yes; your own phone, through your own NAT, hosted |
| Mobilerun (was DroidRun) | Own-phone tier: a portal app opens a WebSocket tunnel to Mobilerun's cloud; cloud phones otherwise | Yes; your own phone or theirs; Android and iOS |
| Google ARTEMIS | Local adb over USB debugging or an emulator on the developer's machine; an on-device accessibility helper; MCP server on localhost | No; the phone hangs off the developer's machine |
| mobile-mcp | USB, or a phone on the same network as the runner (adb); Mobile Next Cloud offers hosted vendor devices | Locally no; cloud yes, on the vendor's device |
| Appium-MCP (category) | Local Appium grid with drivers | No; wired or LAN-bound |
| agent-device | Locally attached device via CLI and API | No; local |
| AGI MCP | The phone becomes an MCP server; transport not documented | Unverified |
| BrowserStack, Sauce Labs, Kobiton, pCloudy | Official MCP servers drive devices in their clouds | Yes, on the vendor's device; your own phone no |
| AWS Device Farm | Per-minute farm; no first-party MCP | Yes, on the vendor's device |
Target audience
Three potential user types, but not only
1 · Agent and tool builders · primary
Developers and AI startups whose agents need a real phone endpoint. They already use MCP and do not want to run device infrastructure. Pain: no simple way to give an agent a real, remote phone. Pays for: hosted access to their own prepared phone.
2 · Mobile QA teams and agencies · expansion
Small companies and agencies that want AI-driven real-device testing without a device-cloud contract. Pain: device clouds are expensive and script-bound. Pays for: agent-driven testing on their own devices.
3 · Automation and ops users · long tail
People automating repetitive on-device tasks: verification, app actions, monitoring. Pain: manual, brittle scripts. Pays for: reliable per-seat control.
Existing audience: a developer and agency audience already exists and matches user types 1 and 2. The first users can be reached through an existing product, newsletter and education content, which lowers acquisition cost.
Market
Two markets already pay for the parts
Two adjacent markets show that customers pay for what DroidLink combines.
1 · Real-device access is a paid category
- BrowserStack: 30,000+ real devices (vendor figure); enterprise pricing on request. Third-party estimates (Autonoma, a competitor; Vendr) put 100 parallel sessions at about $50–75k a year.
- Sauce Labs: real and virtual devices; Real Device Cloud from $199 a month; third-party estimates of $80–120k a year for comparable capacity, not vendor-published.
- AWS Device Farm: $0.17 per device-minute (first 1,000 minutes free), or $250 a month per unmetered device slot; verified on the pricing page.
- Perfecto and TestMu AI (formerly LambdaTest): 10,000+ devices each; pCloudy: 5,000+.
- Developer-priced hosted MCP devices: Mobile Next Cloud free / $29 / $299 a month; Mobilerun cloud Android $64 a month, own-phone tier $4 a month.
Sources, accessed 20 Sep 2026: aws.amazon.com/device-farm/pricing, browserstack.com/real-device-cloud and /pricing, saucelabs.com/pricing, vendr.com, getautonoma.com (a competitor's estimate), perforce.com, testmuai.com, pcloudy.com, mobilenext.ai/pricing, mobilerun.ai/pricing.
2 · MCP-enabled agents are a growing distribution channel
MCP is the default way agents call tools. Public directories (Glama, mcpservers.org, mcpmarket) add servers weekly, and each MCP client can call DroidLink. This channel did not exist 18 months ago.
Unit economicsCustomers supply the phones, so no hardware is bought or warehoused per added device. Hosting, bandwidth and support costs must be measured during the beta before margins can be estimated.
Bottom-up revenue sketch (projection)
| Scenario | Paid seats | Blended ARPU/yr | ARR |
|---|
| Launch beta | 30 | ~$300 | ~$9k |
| Year 1 | 300 | ~$360 | ~$108k |
| Year 2 target | ~1,000 | ~$400 | ~$400k |
Projection from the internal roadmap; the beta replaces it with measured conversion.
Competitive landscape
Local tools, hosted clouds and one direct rival
Checked 20 September 2026. "MCP drives a real phone" is now a crowded category: BrowserStack, Sauce Labs, Kobiton, pCloudy, Mobile Next Cloud and MobileBoost ship MCP servers for their hosted devices. The table separates whose phone is reached.
| Player | What it is | Device | Reaches your own phone, no cable | Security (published) | Hosted + billed | iOS |
|---|
| DroidLink | Hosted MCP server; device-code-paired own phone | yes | yes · dial-out through your NAT | TLS 1.3 · Ed25519 bound to session · pinned relay · fail‑closed | five tiers, unlaunched | roadmap |
| Mobilerun (was DroidRun) | OSS agent framework (MIT, about 9.4k stars) plus "cloud phones for AI agents" and an official MCP server | yes | yes · own-phone tier via portal app and WebSocket tunnel | API keys, credential vault, signed rotating webhooks | own phone $4/mo; cloud Android $64/mo, iPhone $160/mo; $0.03/min pay as you go | yes |
| Google ARTEMIS | Open-source (Apache-2.0) agent that turns natural language into Android automation for coding IDEs; public since September 2026, about 9,200 stars in its first weeks; built on code from Minitap's mobile-use | yes, or emulator | no · local adb, cable or emulator | not published; an on-device helper that sends nothing off the phone, no relay | OSS, self-hosted, free | roadmap |
| mobile-mcp (mobile-next) + Mobile Next Cloud | OSS MCP wrapper, local over USB or adb, plus hosted vendor devices | yes | no · local by cable or LAN; cloud uses vendor devices | local none; cloud accounts, SSO on enterprise | free / $29 / $299 a month; $0.15/min | yes |
| Appium-MCP (category) | Appium exposed as MCP tools | yes (local) | no | none, local | OSS, self-hosted | yes |
| agent-device (callstack) | CLI, MCP server and Node SDK (MIT, about 4.7k stars) | yes | no · locally attached | local trust | OSS | yes |
| AGI MCP (AGI Inc) | "Your Android phone is now an MCP server", launched August 2026 | yes | unverified | unverified | vendor platform; price unverified | no |
| BrowserStack | Real-device cloud, 30,000+ devices, official MCP server | farm | no · vendor devices | SOC 2 Type II, SSO, per-session wipe | Live from about $12.50/mo; enterprise quote | yes |
| Sauce Labs | Real and virtual cloud, official MCP server | farm | no · vendor devices | SOC 2, ISO 27001, SSO | Real Device Cloud $199/mo; enterprise quote | yes |
| AWS Device Farm | Per-minute farm, no first-party MCP | farm | no · vendor devices | AWS IAM | $0.17/min; $250/mo slot | yes |
| Kobiton · pCloudy · MobileBoost | Hosted devices with MCP servers; Kobiton and pCloudy also on-premises | farm or on-prem | on-prem: your devices on your LAN, not from anywhere | SOC 2 (Kobiton, pCloudy); OAuth 2.1 (MobileBoost) | quote or subscription | yes |
Sources, accessed 20 to 22 Sep 2026: github.com/google/artemis, github.com/droidrun/mobilerun, docs.mobilerun.ai/mcp-server, mobilerun.ai/pricing, github.com/mobile-next/mobile-mcp, mobilenext.ai/pricing, github.com/callstack/agent-device, github.com/appium/appium-mcp, theagi.company, browserstack.com/docs/browserstack-mcp-server, github.com/saucelabs/sauce-api-mcp, aws.amazon.com/device-farm/pricing, github.com/kobiton/automate, pcloudy.com/docs/mcp-server, docs.mobileboost.io.
DroidLink does not compete with the local tools on price or with the clouds on device breadth, and every rival except AGI supports iOS. What only DroidLink and Mobilerun's own-phone tier do is reach the customer's own phone, with its SIM and logged-in apps, from anywhere through the customer's NAT with no cable or shared network. Between those two, DroidLink's published security is deeper: a per-device Ed25519 key bound to the TLS session, a pinned relay key and fail-closed behaviour, against API keys and signed webhooks. Mobilerun is the one rival to name and to keep watching. Google's ARTEMIS is the most visible arrival of 2026 and a local tool: the phone hangs off the developer's machine, and it ships no hosting, no remote reach and no per-device key. Its weight is the name, not the architecture, and the answer to it is the same as to every local tool.
Positioning
Hosted, secured, real device
DroidLink targets agent builders and QA teams that need hosted access to their own Android test phones, paired by device code, with no cable or shared network.
- Category: agent-native access to the customer's own phone, between local device-control tools and hosted device clouds. The clouds now speak MCP; the difference is whose phone is reached.
- Primary claim: your own phone, from anywhere, through your own NAT, no cable, no shared network, with a per-device key bound to the session.
- Proof: a deployed service proven on a handful of devices from Android 9 up, with billing wired and no live payment taken.
- Direct rival: Mobilerun's own-phone tier ($4 a month, Android and iOS). DroidLink answers it on security depth and on simplicity of pairing; iOS is a stated roadmap gap.
Business model & pricing
Open client, closed service
The phone app and core are open source, which gives free distribution and inspectable security. The hosted relay, gateway and premium tools are the paid product, sold per seat across five tiers: Free · Developer · Team · Business · Enterprise.
Revenue
Proposed per-seat subscriptions with paid tool tiers. The billing integration includes checkout and subscription handling.
Margin
Customers supply the devices; no hardware per seat. Service and support costs are measured in the beta.
Expansion path: free access for a customer-owned phone, followed by paid tools, additional seats and fleet support. When an agent calls a gated tool, the refusal names the tier that unlocks it.
Enterprise: QA labs and company-owned test-device fleets, with fleet tools and support.
Go-to-market
Reach agent builders through the MCP client they already run
Motion: land (droidlink.me and a drop-in /agent skill), sign in with GitHub or Google, pair by device code (the phone dials out), drive through the /mcp endpoint with a key, upgrade to a paid tier.
- Distribution: listings on public MCP directories (Glama, mcpservers.org, mcpmarket) and a one-command skill for Claude and other MCP clients.
- Owned channels: an existing developer audience and education content reach user types 1 and 2 at low acquisition cost.
- Demo content: record the complete setup and first tool call on a supported phone.
- Free, then paid: free tier, then premium, then team seats, driven by in-product upgrade prompts.
Evidence & open questions
Validated and open
Validated
- Works end to end on a handful of devices from Android 9 up.
- Customers pay for real-device access (device-cloud market).
- MCP is the interface agents use.
- The security design is implemented and exercised end to end.
Still to validate
- Pricing that converts agent builders (requires a beta).
- Reliability across Android OEMs and versions at scale.
- Which buyer group pays first.
- Whether hosting and security justify paying over free OSS tools.
- An external security review.
Next testRecruit 20 beta users and measure activation, repeat use and willingness to pay.
Risks & unknowns
Each risk, with a mitigation
| Risk | Why it matters | Mitigation |
|---|
| Crowded space | Free local tools including Google's ARTEMIS, device clouds that now speak MCP, and Mobilerun's $4 own-phone tier with iOS | Lead on per-device identity, pinned relay and fail-closed behaviour; publish the tested-device list; keep iOS on the roadmap |
| App ToS and Play Integrity | Automating logged-in apps can breach terms of service | Position for QA, testing and owned-account automation; scope and revocation are built in |
| Android fragmentation | OEM and version differences (wireless-debug ports, accessibility) | Document known failure modes; publish a tested supported-device list first |
| High-trust surface | Agent control of a phone is sensitive | Fail-closed design, per-device keys, revocation |
| Dev-tool monetization | Developers are price-sensitive; conversion is hard | Billing funnel, a generous free tier, expansion through teams; validate in the beta |
| Single maintainer | Concentrated knowledge | A support team, documentation, a dedicated maintainer |
| iOS on the roadmap | Limits the QA-team market | Android first by design; iOS on the H1 2027 roadmap |
| Free mirroring tools | scrcpy and phone mirroring look like the same thing for free | They give a person a screen; DroidLink gives an agent typed tools, device identity and a hosted connection |
| Not a Play Store app | Consumer-store review is not a path for a client that drives the phone over adb | Sideloaded open-source developer tool; the launch plan does not depend on store distribution |
| On-device setup | Developer options, wireless debugging and battery settings must be enabled once | The preflight screen lists each requirement and opens the relevant settings where supported; a one-time flow per phone |
Execution plan & schedule
Phases
| Phase | When | What | Status |
|---|
| MVP | done | core tools, droid-flow | shipped |
| Internal validation | done | pairing, dashboard, billing built, a handful of devices proven | shipped |
| Launch | Q4 2026 | public /mcp, free and paid tiers, 20-user beta, MCP-directory listings | in progress |
| Expansion | H1 2027 | iOS, team seats, CI/CD integrations, tested device list | planned |
| Scale | H2 2027+ | device fleets, enterprise, possible spin-out | planned |
Next: beta recruitment, pricing tests, pairing improvements and broader device validation.
Beyond testing
Accessibility, companion apps and public funding
Three directions beyond QA, each assessed against the current base: an adb-driven, sideloaded client that needs developer options and wireless debugging on the phone. Facts checked on 20 September 2026; sources at the end of this section.
1 · Accessibility for impaired and older users
The need is large and growing. WHO counts 1.3 billion people, one in six, living with a significant disability; more than 2.5 billion need at least one assistive product today, rising to 3.5 billion by 2050; the share of people aged 60 and over roughly doubles to about 22% by 2050. In the EU, 23.9% of residents aged 16 and over reported an activity limitation in 2024, with Latvia highest at 41.2%.
- What exists: Google Voice Access, the Android Accessibility Suite, Apple Voice Control and camera assistants such as Be My Eyes cover on-device basics for free. In 2026 Google (Gemini app control, February) and Apple (Siri, September) shipped agentic, screen-aware control inside the OS, on their newest phones.
- Where a gap remains: remote operation by a family member or carer over the internet; older or hand-me-down phones the vendor assistants do not reach; any installed app, without developer declarations; chained cross-app tasks. The gap is narrowing; it is an intersection of those conditions rather than a category of its own.
- Regulation: the European Accessibility Act (Directive 2019/882) has applied since 28 June 2025 to smartphones, banking, e-commerce and transport apps. It obliges vendors to make their own products accessible, which supports the story without creating demand for a third-party agent.
- Constraint: Google Play bars the accessibility API from autonomously planning and executing actions, which is why DroidLink drives the phone over adb. The cost is that a consumer version is sideloaded and needs developer options on; it is not a one-tap install.
- Ethics designed in: recorded, revocable consent, including capacity questions for dementia; least-privilege carer scope; an audit log of carer actions; GDPR handling of captures, which often contain health or banking data; never covert use.
2 · Companion apps
| Idea | Incumbents | Feasible on the current base | What it would need |
|---|
| Remote carer operates a relative's phone | No consumer product offers remote operation by a family member | Yes; the natural fit | Carer UX, consent and audit flow, an easier one-time setup |
| Cross-app agent tasks | Vendor assistants, on the newest phones only | Yes; this is DroidLink today | Already covered by the current tools |
| Parental daily summary | Google Family Link and Apple Screen Time (free); Bark about $14 a month; Qustodio Complete $99.95 a year | For one technical parent; not as a consumer product | An accessibility or device-policy base plus Play distribution, which the accessibility policy blocks for agents |
| Desktop companion with health data | Phone Link, KDE Connect, Samsung Flow (free); AirDroid Business $12 to $33 per device a year | Only fragile screen-read snapshots | A Health Connect integration with user grant and Play declaration |
Parental-control software was valued between about $1.6 billion (Fortune Business Insights) and $2.5 billion (The Business Research Company) in 2025; the figure depends on the publisher.
3 · Public funding
A one-person company with zero customers and an early-stage developer tool fits national R&D instruments before the headline EU grants. The country of registration decides which national track is open.
| Programme | Funds | Size | Eligibility | Status on 20 Sep 2026 | Fit |
|---|
| WBSO (Netherlands) | R&D tax credit | 36% of the first €391k of R&D wages in 2026; 50% for starters | Dutch tax-liable company | Open, rolling | 5 |
| LIAA innovation voucher (Latvia) | Product and technology development | €10k at 100%; €25k at 85% | Latvian-registered SME | Open to 29 Feb 2028 | 4 to 5 |
| MIT feasibility (Netherlands) | Feasibility study | 35% of costs, up to €20k | SME, via a province | 2026 window closed 15 Sep; next expected around April 2027 | 4 |
| Eurostars 3 (EU) | SME-led collaborative R&D | About €500k per participant | SME lead plus a partner in another country; about 50% national co-funding | Call 11 closed 10 Sep 2026; next date unconfirmed | 3 |
| EIC Accelerator (EU) | Deep-tech scale-up | Grant up to €2.5M plus equity | Solo SME at TRL 6 to 8 | Open; next cut-off 3 Nov 2026 | 2, premature |
| Horizon Europe Cluster 1, independent-living topic | Consortium research | €6M to €8M per project | Consortium required | Expected to open February 2027; deadline about 13 April 2027 (secondary source) | 2, as a junior partner |
Not options: the AAL programme ended in 2021; Microsoft AI for Accessibility has no verifiable open call; Nesta and AT2030 are geographically restricted; EIT Health's instrument requires four staff and €2 million raised.
Sources (accessed 20 Sep 2026): WHO fact sheets on disability, assistive technology and ageing (who.int); Eurostat EU-SILC 2024 (ec.europa.eu/eurostat); EUR-Lex summary of Directive 2019/882; Android Developers Blog, February 2026, on agentic app control; Apple Newsroom, September 2026, on Siri; Google Play AccessibilityService policy; Bark, Qustodio, AirDroid pricing pages; Health Connect permissions (developer.android.com); RVO WBSO and MIT pages; LIAA innovation voucher page; Eureka Eurostars page; EIC funding pages; Horizon Europe Cluster 1 work programme 2026-2027.
Standalone business
A standalone revenue stream
- Standalone: its own revenue stream, independent of any single platform.
- Existing channels: billing integration, a developer audience and education content already exist and can carry it. Operational lift is low.
- Its own company: Its own product, brand and codebase. It can operate as a separate company under the holding.
- The AI agent is the user: a developer's agent plans the task and calls DroidLink's tools; developers and QA teams pay for it.
The ask
Support to launch
Infrastructure and core are done. To turn this into revenue I need four things.
- Billing product setup for a developer-tool SaaS (tiers, checkout, entitlements).
- Developer-marketing reach and 20 beta users from an existing developer audience.
- UX polish on the device-code pairing flow.
- An external security review before public launch.
Glossary
Terms used in the deck and this dossier
NAT Network address translation. The carrier or home-router layer that hides a phone from the public internet; nothing can connect inward to it.
MCP Model Context Protocol. The standard an AI agent uses to discover and call tools. DroidLink exposes the phone as MCP tools.
adb / adbd Android Debug Bridge and its on-device daemon. The developer channel used to drive a phone.
WebSocket / WSS A single long-lived, encrypted connection the phone opens outward and keeps open.
TLS 1.3 The current transport-encryption standard. DroidLink runs a second TLS session inside the WebSocket.
Ed25519 A modern signature scheme. Each phone holds its own Ed25519 key that proves its identity per session.
RFC 5705 / 7250 The standards used to bind that key to the live TLS session (5705) and to pin the relay's raw public key (7250).
Fail-closed On any doubt (unknown key, stale session, out-of-bounds tap) the system refuses rather than guesses.
Relay The hosted service the phone dials into and the gateway talks to.
Gateway The hosted /mcp endpoint that checks the agent's key, scope, tier and rate before forwarding.
Control plane The admin dashboard at admin.droidlink.me: pairing, keys, seats, billing.
Device code The short code the phone shows during pairing; entered in the dashboard, then approved on the phone.
Multiplex Many adb streams carried over one connection (up to 32).
uinput The Linux input interface required by some gesture tools; availability depends on the phone.
UI hierarchy The tree of on-screen elements, used to read UI text and resolve selector-based taps.
Play Integrity Google's integrity signals for apps, devices and accounts. A physical phone does not guarantee a passing verdict.
SIM The carrier card that gives a phone its number. Needed for real SMS codes.
OEM Original equipment manufacturer: the phone maker (Sony, Xiaomi), whose Android variants differ.
LAN Local network. What cable-or-Wi-Fi tools need the phone and the computer to share.
Sideload Installing an app directly rather than through the Play Store. Normal for developer tools.
OSS Open-source software.
SaaS Software sold as a subscription service.
ARR Annual recurring revenue.
CI/CD The automated build-and-test pipeline a test phone can be called from.
MoR Merchant of record. The billing service that handles checkout and tax.
QA Quality assurance: software testing.
PoC Proof of concept: a working demonstration.