How to demo an Android app remotely, without a screen-share
The standard remote demo is a small tragedy: your emulator, compressed into a video-call window, stuttering at the exact moment the good feature loads — while the prospect watches your cursor and thinks about their next meeting. There's a better format: put a live device in the prospect's own browser, and let them drive it.
Why screen-sharing an emulator undersells your app
- Video compression murders UI detail. The crisp interface you shipped becomes a blurry rectangle. Text they should read, they squint at.
- Lag lands on your best moments. The tap happens, the call freezes, the animation is a rumor. Every hitch reads as "the app is slow," even when it's the call.
- You're driving; they're spectating. A prospect who can't tap the thing has to take your word for how it feels. Demos are believed in proportion to how much the buyer touches.
- The setup tax is paid live. Emulator won't boot, wrong build installed, notification from your real life across the shared screen — all in front of an audience.
Two formats: the live call and the async link
| Format | When it wins | How it runs |
|---|---|---|
| Live, on a call | First demos, stakeholder meetings, anywhere objections surface | Open the preview link together; you drive from your portal while they direct the tour out loud |
| Async, link only | Schedules that won't align; internal forwarding; follow-ups | Send the link with a two-line note on what to look at; it boots the app live in their browser whenever they open it |
They're not competitors — they're a sequence. The call creates the moment; the link lets the moment travel to the colleagues who weren't on it. The follow-up is a fresh session on the current build — a new share link, not a fresh export of anything.
They direct, you drive
A PreviewAPK link is view-only — deliberately, and it makes demos better, not worse. The prospect watches the live device in their browser while you drive it from your portal. Nobody can tap the wrong thing, wander into a half-finished settings screen, or derail the story; and a forwarded link can never hand a stranger control of your build. Structure the demo around that:
- You drive the first two minutes. The happy path, in their language: their data type, their workflow, the outcome they asked about.
- Then let them direct. "Where do you want to go next?" The questions prospects ask out loud are the ones they actually care about — and your hands take them there in one tap, no fumbling on either side.
- Stay quiet longer than feels natural. A prospect studying your screen in silence is the demo working. Narrate only when they stall.
And when a prospect genuinely needs the app in their own hands, that's a different tool: enable the device's QR code and they install the same build on their own phone, under their own thumb.
Prepare a demo build that can't embarrass you
- Use a release build (or your most stable current build), not the debug build from your last experiment.
- Seed it like a real account: plausible names, a few records, nothing empty. Empty states demo terribly; populated ones start conversations.
- Rehearse the happy path once on the same Android version and profile you'll share, so first-launch dialogs and permission prompts appear where you expect them — handled by you, not discovered by the prospect.
- Start the session before the call. Provisioning takes about a minute; spend it before anyone's watching. The link should open onto the app, ready.
- Keep prospect links view-only — they always are; the demo stays in the browser, where you control the build they see.
The follow-up that keeps the demo alive
Within the hour, send one short message: thanks, the one thing they reacted to, and the preview link. When they want another look — next week, in a budget meeting, on a phone — start a fresh session (seconds) and send the new link; it lands on the app, live, on your current build. Ship the improvement they asked for on Thursday, and Friday's link opens the fixed version. The follow-up writes itself: "new link — look again."
Try it with a live device
PreviewAPK is in private beta. Get early access to test your own builds.
FAQ
Can the prospect control the app themselves during the demo?
No — links are view-only by design, so a demo can't be derailed by a stray tap and a forwarded link never hands a stranger your build. You drive from your portal while the prospect directs. When a prospect needs hands-on time, enable the device's QR code and they install the same build on their own phone.
What if the prospect only has an iPhone or a locked-down work laptop?
The demo runs in their browser, so both work. Nothing is installed and no Android device is needed on their side — the phone is a cloud device streamed to the tab, which also sidesteps most corporate install restrictions.
Live call or async link — which makes a better demo?
Both, at different moments. Use a live call when the conversation matters — objections, pricing, their team's questions — and let them drive during it. Use an async link when schedules won't align or after the call, so they can explore alone and forward it internally. The same build serves both — run a fresh session for the async pass and send its share link.
How long does it take to set up a remote demo?
About a minute: upload the APK, and a device boots with your app installed and launched. Do it before the call and open the link ahead of time, so the demo starts with the app already on screen.
Keep going
- Test APK online — the live browser device your demos run on.
- Share an APK with clients — sending builds for approval between calls.
- Share an Android app before launch — investors and press are demo audiences too.