How We Built EclipSend: A Privacy-First File Sharing App

The story behind creating a file transfer app where nobody—not even us—can see what you're sharing.

The Problem We Started With

I was trying to send a sensitive document to a colleague one afternoon. Nothing illegal or anything—just some personal information I didn't want floating around on someone's cloud storage forever. I reached for the usual tools: email, WeTransfer, Google Drive. But each one felt like I was handing over my file to a middleman who'd keep it archived somewhere I couldn't control.

That's when it hit me: why doesn't there exist a simple file sharing service where the files actually disappear? Where I don't need to trust a company to store my data? Where only the person with the right password can even open the file?

I started sketching ideas on a Saturday morning with coffee. By Sunday, I knew what EclipSend needed to be.

Building With Zero-Knowledge in Mind

The core principle was simple but demanding: we wanted to build something where we literally can't see what users are sharing, even if we wanted to. That meant all encryption had to happen in the browser, before the file ever touches our servers.

We chose AES-256-GCM encryption—the same standard used by security professionals and governments. Each file gets its own encryption key derived from the password the user creates. The browser encrypts everything into unreadable chunks, uploads those chunks, and the key never leaves your device. Only someone with the exact password can decrypt it on the other end.

From an engineering standpoint, this was the right choice. From a business standpoint? It meant we could never add a "recover your file" feature, never scan for viruses, never look at what's being shared. That was exactly the point. Real privacy means limiting our own access.

The Technical Decisions That Shaped Everything

We built EclipSend as a Progressive Web App rather than a traditional app. No installation, no app store approval delays, no version management headaches. Users just visit the link and it works. Since encryption happens in the browser anyway, a web app made perfect sense.

For the backend, we wanted something minimal. Express.js handles the basic file metadata—just tracking that a file exists, when it was uploaded, when it expires. The actual encrypted file chunks go into storage. We designed it so that even if someone broke into our servers tomorrow, they'd find nothing but encrypted gibberish.

The 1-hour auto-deletion felt important too. Files shouldn't linger forever. After an hour, they're gone—no exceptions, no recovery. It's a hard deadline that adds urgency and keeps the storage footprint reasonable.

Why the Design Matters as Much as the Code

Security technology only works if people actually use it. We could have built the most mathematically perfect encryption system, but if it's confusing or takes ten steps to share a file, people won't use it. They'll just email it.

So we obsessed over the interface. Drag a file onto the page. Type a password. Copy the link and send it. Done. The whole workflow takes maybe 30 seconds. On the receiving end, paste the link, enter the password, download. We stripped away everything that wasn't absolutely essential.

The visual design—the dark theme with the indigo accent colors—came from wanting to feel secure and trustworthy without screaming "this is a security app." Privacy shouldn't feel paranoid. It should feel normal.

Making It Fast Without Sacrificing Security

Encryption is computationally expensive, especially for large files. We implemented chunking—splitting big files into 5MB pieces and encrypting them individually. This prevents the browser from locking up while processing a 200MB file.

We also used Web Workers to offload the crypto work to a background thread. The main thread stays responsive, showing progress, handling input, keeping the UI smooth. Users can watch their file encrypt in real-time without any stuttering.

It's easy to ignore performance when you're focused on security, but they're not separate concerns. A slow, frustrating experience erodes trust just as much as a security vulnerability does.

The Parts We Actually Got Right

When you launch something, you never know what'll resonate. But we've learned a few things work really well:

What We'd Do Differently

One thing we'd approach differently now is the file size limit. We currently cap uploads at 500MB due to browser constraints and server realities. With a larger time investment, we could implement streaming uploads and downloads, handling gigabyte-sized files smoothly. It's on the roadmap.

We also started with in-memory file storage while building. Eventually, we want to move to proper cloud storage—something like Cloudflare R2. This would let us handle more concurrent uploads and ensure redundancy. The architecture is already designed for this migration.

The one thing we're happy we didn't compromise on: the encryption. Some people suggested "just let users opt into encryption" or "add a backdoor for law enforcement." We said no. Zero-knowledge is the whole point. We'd rather decline a use case than dilute the core principle.

Why We Opened the Source

Midway through building, we decided to open-source everything. A privacy tool is only as good as its transparency. Closed-source means users have to trust us on faith. Open-source means they can actually verify we're not stealing their data.

It's on GitHub now. Security researchers can audit the code. Developers can fork it and run their own instance. Users can deploy it to their own servers if they want to be completely independent from us. That's genuine privacy—not just our promise of privacy, but verifiable privacy.

What We've Learned

Building EclipSend taught us that people genuinely care about privacy when you make it easy and transparent. We expected this to be a niche tool used by paranoid developers and journalists. Instead, we're seeing regular people—teachers, contractors, freelancers—using it because they simply don't want their files sitting in Google's or Dropbox's data centers forever.

We've learned that simplicity and security aren't at odds. The best security often feels invisible—you don't notice it until you compare it to the alternatives, and then you think "wait, why isn't every file sharing app like this?"

We've learned that your technical choices matter, but they're not the whole story. The design, the messaging, the values you communicate—they matter just as much.

What's Next

Right now, we're focused on keeping EclipSend stable and reliable. We're working on better error messages, more granular control over file expiration, and eventually a mobile app wrapper for PWA support on iOS.

The bigger picture? We want to prove that privacy-first software can be successful without compromising on user experience or monetization. We're not anti-tracking because we're idealistic—we're anti-tracking because we genuinely don't need the data. Good UX comes from understanding your users, not from tracking them.

EclipSend started as "wouldn't it be cool if..." on a Saturday morning. It turned into something that matters to people who value their privacy. That's the kind of win you don't get often in software.

Join Us

If you believe privacy matters, or if you just want a dead-simple way to share files that actually deletes them, come try EclipSend. It's free to use right now.

If you're a developer interested in contributing to open-source privacy tech, we'd love to have you on GitHub. We're always looking for people who care about getting this stuff right.

And if you love what we're building, consider supporting us. We're running this as a passion project right now, and every bit helps us keep the servers running and the code maintained.