I'm Eric, a recording and mixing engineer in Montreal.

The problem, from my point of view

A session can weigh 20, 40, 100 GB: stems, alternates, three versions of the same song. Sending that to clients and partners was miserable. WeTransfer caps the free tier. Dropbox throttles bandwidth. Every send meant a full upload, then the client's full download. Twice the wait. And a copy of unreleased work on a server I don't control.

Why it's built this way

So I built the tool I wanted, with my friend Francis. I spent three decades building complex, secure enterprise software. VP of Products at five or more companies that got acquired. A patent too. The encryption is there by design:

• Device to device. Straight from my machine to yours, or to my own machines, anywhere. Nobody waits twice.
• No ceiling. 400 GB sends the way a photo does.
• Nothing left behind. Bandwidth used at 100%. Nothing in a cloud you don't own. Peeza never has a copy.

No rocket science

None of this is invented. A transfer tool is a utility, not a research project. The encryption is the same AES-256-GCM and X25519 everyone uses, applied by the book.

What's new is who assembled it. I directed Claude Code like I used to direct a dev team. I picked the patterns, it wrote them, I read what came back. Some engineers will wince. The job was never novelty. It was getting proven patterns right.

How I keep Peeza alive

I run the relay that carries fallback traffic. A small paid tier will eventually cover it. No investors. No acquisition to hollow out the product.

Beyond Peeza

When I'm not building software, I mix records at Studio le cachot →. Before that, twenty-odd years leading product and engineering. The enterprise-software years are on LinkedIn →.

Get in touch

Questions, problems, ideas for peeza: write to [email protected]. I read every message. For a bug, use Report a bug in the app's account menu. It sends me the app's version.