/>Deep Skylabs
Back to Case Studies
Productivity

Building Flash Connect: A Peer-to-Peer Alternative to KDE Connect, Smart Connect, and Galaxy Connect

How we engineered a local-first, peer-to-peer productivity app that connects Android devices and Windows PCs directly using WebRTC, bypasses cloud relays entirely, and minimizes network latency.

Building Flash Connect: A Peer-to-Peer Alternative to KDE Connect, Smart Connect, and Galaxy Connect

Building Flash Connect: A Peer-to-Peer Alternative to KDE Connect, Smart Connect, and Galaxy Connect

A DeepSky Labs case study

Most cross-device connectivity tools fall into one of two categories: locked to a specific phone brand, or routed through a cloud server you have no visibility into. Flash Connect started as an attempt to fix both problems at once — a Windows and Android app that connects directly, peer-to-peer, regardless of which phone you own.

This is the story of why it exists, how it's built, and what turned out to be harder than expected.

Deep-SkyLabs/flash-connect

Star on GitHub to follow development

Star on GitHub

The problem

Samsung users get Galaxy Connect (by way of Phone Link). Motorola users get Smart Connect. Both are genuinely well-built tools — for their respective ecosystems. If you own anything else, you're left choosing between KDE Connect (excellent on Linux, noticeably less polished on Windows) or one of several cloud-routed tools like AirDroid, where convenience comes at the cost of your data passing through a third party's servers before it reaches your own device sitting a few feet away.

There wasn't an option that was both brand-agnostic and properly local-first. That gap is what Flash Connect set out to fill.


What it does

Flash Connect connects an Android device and a Windows PC directly using WebRTC, establishing a peer-to-peer link rather than relaying traffic through a backend. Once connected, it handles:

  • Low-latency screen mirroring and control over USB
  • Desktop-to-phone audio streaming
  • Real-time, bi-directional notification sync
  • Clipboard sync across both devices
  • Local file transfer over the same network
  • Call visibility and management from the desktop

The guiding constraint throughout development was simple: nothing should require a server in between. If a feature couldn't be done peer-to-peer without compromising the experience, it got redesigned until it could.


Technical approach

The Android client is built in Flutter, which is the primary stack DeepSky Labs uses across mobile projects — it kept the codebase consistent with other apps in active development and made it straightforward to iterate quickly on UI changes without slowing down the underlying connectivity work. The Windows client mirrors the same design language, built to feel like a native desktop app rather than a mobile UI stretched onto a bigger screen — something most cross-platform connectivity tools tend to get wrong.

The connection layer is WebRTC end to end. Devices establish a direct link on the local network, and from there, every feature — clipboard, files, audio, mirroring — runs over that same peer-to-peer channel rather than spinning up separate protocols per feature. Keeping it unified turned out to matter a lot for reliability; fragmenting the connection logic across features early on created more edge cases than it solved.


What actually proved difficult

Screen mirroring latency. Getting consistent, low-latency mirroring over USB without a heavy CPU cost on either device required multiple passes at the streaming pipeline. What worked smoothly on one device configuration didn't always hold up on another, which meant the bulk of the engineering time here went into handling variance across Android versions and hardware rather than the initial implementation itself.

Clipboard sync edge cases. Expected to be one of the simpler features; turned out to need careful handling of different content types to avoid one device mishandling data the other sent without issue.

Real-world network reliability. Building a peer-to-peer connection that works in a controlled test environment is a meaningfully different problem from one that holds up across the range of home network setups actual testers were using. Closed testing surfaced several of these gaps before launch — feedback that materially shaped the final release.


Outcome

Flash Connect went through closed testing with a small group of external testers ahead of its Windows and Android release, with feedback directly informing fixes before launch. It's now publicly available, with broader platform support planned as the core experience continues to mature.

This project reflects a pattern that shows up across DeepSky Labs' work generally: building privacy-respecting, local-first alternatives to tools that default to cloud dependency where it isn't actually necessary — and treating real user feedback as part of the build process, not an afterthought once something ships.

Deep-SkyLabs/flash-connect-app

The full source is on GitHub. Issues, PRs, and forks are all welcome.

Star on GitHub

If you're building something in the cross-device connectivity space and want to collaborate or just talk through the architecture, reach out directly at hello@deepskylabs.in.

Metrics Achieved

42 MB/s
Transfer Speed
< 50ms
Connection Latency
0%
Cloud Dependency

Infrastructure Stack

FlutterDartWebRTCmDNS
Client Partner:DeepSky Labs
Timeline Completion:2026-06-28