The File That Died at 97% (Stepping up, Part 1)

The progress bar hit 97%, paused, and went back to zero.

There was no error code, no "retry from here," and no way to tell whether the mostly-delivered file on the other end was usable or garbage. Just a polite little spinner, starting over, on a 2 GB upload I'd already babysat through twenty minutes of café Wi-Fi. I sat there and did the only thing the tool left me: I waited again, and hoped the connection would hold.

It didn't; the second attempt died at 81%.

If you're old enough, you've been through this scenario more than once.

Sending files used to feel easier than this

Here's the part that always irked me: moving a file from my machine to yours is not a new problem, and twenty years ago it felt simpler than it does today.

If you were online in the early 2000s, you remember ICQ: the flower icon, the "uh-oh!" sound, and the UIN you memorized like a phone number. You dragged a file onto someone's name and transferred directly, with no upload step and no link to manage. It wasn't more reliable than today's tools -if anything it was worse- and anyone who fought an ICQ transfer behind a home router still has the scars. But it was direct, and that's the thing we lost. ICQ went dark in June 2024 after 28 years, and I felt a pang, not for the software but for the simplicity.

Why? Because the tools that succeed it all come with a catch.

• Cloud lockers want you to sign up, then keep a copy of your file on a server somewhere.
• Social media tools provide peer to peer communication tools that promise to be secure. Until they don't.
• "Decentralized" web tools promise the file disappears, but usually you can't confirm it. Who runs the connecting server and why are they letting you use it for free?

So a lot of us retreat to back to SFTP, the digital equivalent of mailing a hard drive. Ultimately, it works, but it's clunky, intimidating to anyone non-technical, and a strange place to keep landing in 2026. Overall, there has to be a better way, and that's what got me scheming.

Three ways to move a file, each missing a piece

First, let's define three broad categories for modern file sharing -

1. There's cloud sync and share, your Dropboxes and Drives: permanent storage, tied to an account, your file living on their server whether you like it or not (including after you "delete" it).
2. There's enterprise managed file transfer, the heavyweight systems built for compliance and supported by dedicated IT teams. Logging and surveillance is a feature rather than a bug.
3. Finally, there's ephemeral, link-based sharing, where you drag a file, get a link, and send it. These WebRTC-based tools, like JustBeamIt and FilePizza, aim to send the bytes browser to browser, with nothing stored along the way.

That last category is the spiritual heir to ICQ, and I love it for that. FilePizza is elegant: open-source, no file parked on a middleman's server, and it nails the simplicity.

Here's what's thin across all three: trust. Not a warm feeling, but evidence you can use to prove that the MP4 you sent your friend (a) won't show up mangled or unplayable, and (b) won't show up anywhere else. Managed file transfer has mastered the former, as audit trails and file integrity are most of its reason to exist. The simpler tools skip both types of evidence entirely.

The four complaints that matter

You can find a long list of gripes about all these tools, but they condense to four major issues -

1. You can't verify the security. Most of these tools do encrypt the connection; WebRTC even requires it. But encrypted how far, and to whom? If your transfer relays through a server, "encrypted in transit" can still mean a middle hop sees more than you'd like, and nothing on screen tells you which path your file took. The encryption is usually real. The part you can verify is not.
2. There's no resume. Resume is ancient; rsync and any half-decent download manager have done it for decades. It's just missing from the simple, no-signup tools most people reach for. One mobile handoff, one Wi-Fi hiccup, and you're back at zero, because the tool checkpointed nothing, so neither did you. This is the "97% problem" that makes people slam their laptops.
3. File corruption is hidden until it is too late Yes, TCP and DTLS checksum the wire, and the pedant in the back row is right to say so. But that protection is on the tunnel, not the file. Corruption that creeps in while chunks are buffered, reassembled, and written to disk sails right past a transport that only ever watched the wire. The transfer says "done," the recipient opens it, and a chunk is mangled. For a photographer that could mean a dead RAW file; for a finance team it's a spreadsheet that's subtly, expensively wrong. Nobody got a warning, because nothing compared what the recipient ended up with against what the sender actually sent. Cyclic redundancy checks solve this specific problem but are rarely baked into consumer solutions.
4. The privacy is theater. "Permanent deletion" and "ephemeral transfer" sound like great assurances, but can be difficult to confirm. Without something you can audit, "we don't keep your file" is just a nicer way of saying "trust us."

Why a dead progress bar is also business problem

It's tempting to file all of this under "mild annoyance" and question (with maximum snark) why people are trying to clandestinely exchange large movie files to begin with. But would be short-sighted - in the corporate world, "trust me" is also not an acceptable control (especially when moving files between companies). If I told an auditor a file had been delivered intact and my only evidence was a green checkmark from an app that can't explain itself, that conversation would (and should) go badly. Plenty of corporate systems still run on legacy duct tape, and I won't pretend otherwise. But you don't sign off on a control with a feeling; you sign off with evidence you can reconcile and show your work on. As a result, there is a hidden cottage industry for "enhanced" corporate file transfer solutions.

What "a step up" would actually mean

And with that, I'm throwing my hat into the race. Here is the minimum checklist that fellow travelers can hold me to -

• The solution is encrypted by default, with no setting to forget to turn on.
• It resumes from the last verified piece, so as long as the sender's still around, a dropped connection costs you seconds, not the whole transfer.
• It proves the file arrived intact: the receiving side checks every chunk against the original and hands you a receipt that means something because it's signed, not just printed on a screen.
• It never parks your file on a server. And when it has to bounce through a relay to get past a stubborn network, it tells you the truth about that instead of hiding it.

My solution is far from release-ready, but I'm building it in the open. This series of articles represents the build log: the wins, the wrong turns, and most importantly the uncomfortable lessons.

The first uncomfortable lesson had nothing to do with file transfer; it was about the AI agents helping me build the thing. They kept telling me work was done when it wasn't, confidently and repeatedly, in a way that turned out to be far more dangerous than any hidden file corruption.

That's the next story.

Greg McLaughlin works in the Canadian banking industry, at the intersection of data infrastructure, analytics, and financial systems. He's currently building a secure, peer-to-peer file transfer tool, and documenting the journey. Follow for more on the architecture of trusted systems. What's your worst file-transfer story? I want to hear it.