How We Built Droply: Moving Files Between Phone and Laptop With No Cables and No Cloud

Most people move files from their phone to their laptop in one of three awkward ways: a USB cable they can never find, uploading to a cloud drive and downloading again, or sending the file to themselves on WhatsApp. Each one is slower than it should be, and the last two quietly copy private files onto someone else's servers.

Droply is our answer: scan a QR code, pick a file, and it arrives. This is how we built it, and why we made the choices we did.

The principles we set first

• No accounts. Pairing should take seconds, with nothing to sign up for.
• Local first. If both devices are on the same WiFi, the file should travel directly between them and never touch a server.
• Works anyway. If the devices cannot reach each other, the transfer should still succeed without the user doing anything different.
• No size games. The only limit should be the free space on the receiving device.

The architecture

Droply has three pieces, each deliberately small:

1. The desktop app (Electron). It shows the pairing QR code and runs a small local web server that receives files on the home network.
2. The phone app (React Native with Expo). It scans the code, browses what the laptop shares, and sends files.
3. A relay (a lightweight WebSocket server). It only steps in when the phone and laptop cannot talk directly — for example, a phone on mobile data and a laptop on office WiFi.

Pairing with a QR code instead of accounts

The QR code carries everything the phone needs: how to reach the laptop, and a fresh session token generated for that pairing. Every request the phone makes must include that token. There is no password to leak and no long-lived account to compromise; generate a new code and the old session is useless.

Making large transfers survive real life

Real networks drop. Phones lock their screens. People close apps by accident. Uploading a 2 GB video as one request means any hiccup starts it from zero. So Droply splits files into chunks and uses a simple resumable protocol: start a transfer, send chunks, ask for status (which chunks have arrived?), then complete. If anything breaks, the phone asks what is missing and continues from there.

The relay fallback

When the phone cannot reach the laptop's local server, both sides connect to the relay and join a private room identified by the session token. The relay forwards the data between them and stores nothing. Sending from the laptop to the phone always uses this path, because phones do not accept incoming connections the way a laptop server can.

One subtle problem we hit: when pairing happened over the local network, the laptop never heard about it from the relay, so its screen did not show "connected". The fix was to treat any authenticated local request as a pairing signal too — a good example of the small details that separate a demo from a product.

What we learned

• Design for the failure path first. Most of the engineering went into what happens when the network is not perfect.
• Fewer moving parts win. Three small components are easier to reason about, test and deploy than one clever one.
• Privacy is a feature users feel. Not needing an account is the first thing people notice.

Droply is currently in private development. You can read more about it here or request early access. And if you are building a product that needs this kind of careful engineering, let's talk.