P2P File Transfer: Why I Stopped Building It for Production

I built a P2P file transfer feature once. Looked clean in demos. Then it hit production.

The appeal is obvious: no server costs, privacy by default, direct browser-to-browser transfer. WebRTC handles it. Ship it, right?

Wrong.

Here's what I learned:

NAT and firewalls kill 30% of real users. Your office network? Blocked. Your client's VPN? Blocked. You need a TURN server fallback. Suddenly you're running infrastructure anyway.

Signaling is your hidden complexity. You still need a backend to exchange connection details. That's another failure point. Users blame your app when it's actually their ISP blocking your WebSocket.

Browser compatibility isn't solved. Safari on iOS has partial WebRTC support. Old Windows machines? Forget it. You're writing fallback code for months.

The UX is worse than it seems. "Waiting for peer connection" screens confuse people. They close the tab. They refresh. The connection dies. You need sophisticated error handling and recovery logic that negates the simplicity benefit.

I eventually killed it in my projects. For Seven CMS and Seven Shop, I opted for traditional upload with server-side processing. Users get consistent, fast transfers. I control the experience.

The right use case for P2P file transfer? Local networks and closed groups where you control the environment. Team file sharing inside your office? Go for it. Public internet? Use a real CDN.

What I use now: Presigned S3 URLs for direct uploads to cloud storage. No complex signaling, no fallback servers, better performance. Same privacy if you're using client-side encryption anyway.

P2P tools are genuinely useful for specific problems—especially for offline-first apps and distributed systems. But if you're building a general-purpose file transfer feature for regular users, the operational overhead outweighs the elegance.

Pick boring infrastructure. Your users won't care. Your support tickets will thank you.