How I Built a Privacy-First P2P File Transfer Tool

<h2>How I Built a Privacy-First P2P File Transfer Tool</h2> <p>File sharing is something most of us use every day. But the typical workflow often feels more complicated than it needs to be.</p> <p>You upload a file to a server, wait for the upload to finish, generate a link, send that link, and then the recipient downloads the same file again.</p> <p>While this model works well in many situations, I wanted to explore a simpler question:</p> <p><strong>What if two browsers could transfer a file more directly?</strong></p> <p>That question led me to build <strong>Ryzova E-Pen</strong>, a browser-based peer-to-peer file transfer application focused on privacy, simplicity, and ease of use.</p> <h2>The Problem I Wanted to Solve</h2> <p>The goal was not to create another cloud storage platform.</p> <p>I wanted E-Pen to make temporary file transfers feel simple:</p> <ol start="1"> <li>Open the application.</li> <li>Connect two devices.</li> <li>Select a file.</li> <li>Transfer it.</li> <li>Finish.</li> </ol> <p>For many temporary transfers, storing another permanent copy of the file in cloud storage may not be necessary.</p> <p>The design philosophy was therefore simple:</p> <p><strong>Use the browser as much as possible, minimize unnecessary infrastructure, and keep the user experience straightforward.</strong></p> <h2>Designing Around Peer-to-Peer Transfer</h2> <p>E-Pen is designed around browser-to-browser communication.</p> <p>Instead of treating a central server as the destination for the actual file, the application establishes a connection between participating devices and manages the transfer through the browser.</p> <p>The application still requires supporting infrastructure for tasks such as establishing connections and coordinating sessions, but the architecture is designed so that the file-transfer experience itself can remain peer-oriented.</p> <p>This distinction influenced many technical decisions throughout development.</p> <h2>Privacy as an Engineering Decision</h2> <p>Privacy should not only appear in a privacy policy.</p> <p>It should influence how a product is engineered.</p> <p>While building E-Pen, I tried to avoid collecting information simply because it was technically possible to collect it.</p> <p>My general approach was:</p> <ul> <li>collect only what is needed for the product to work;</li> <li>avoid storing unnecessary file-related information;</li> <li>keep the transfer workflow understandable;</li> <li>reduce unnecessary dependence on centralized storage;</li> <li>treat security and privacy as architecture concerns rather than marketing features.</li> </ul> <p>I believe good privacy often begins with a simple question:</p> <p><strong>Do we actually need this data?</strong></p> <p>If the answer is no, the system should ideally be designed without it.</p> <h2>Simplicity Was Harder Than Adding Features</h2> <p>One lesson from building E-Pen was that simple interfaces can require significant engineering work underneath.</p> <p>A user should not need to understand connection negotiation, browser networking, transfer states, errors, or recovery logic.</p> <p>They should simply see:</p> <p><strong>Send &rarr; Connect &rarr; Transfer &rarr; Complete</strong></p> <p>The complexity belongs inside the product, not in front of the user.</p> <p>This principle also influenced the interface. Instead of continuously adding controls and settings, I tried to keep the main workflow focused on the action users came to perform.</p> <h2>Building the Complete Product</h2> <p>Because I developed E-Pen independently through Ryzova, I worked across several parts of the product lifecycle:</p> <ul> <li>product planning;</li> <li>UI and UX;</li> <li>frontend development;</li> <li>application architecture;</li> <li>connection and transfer logic;</li> <li>testing;</li> <li>deployment;</li> <li>debugging;</li> <li>performance improvements;</li> <li>product documentation.</li> </ul> <p>Working across the entire stack helped me see how small design decisions in one part of the system can affect the whole product.</p> <p>For example, a technically correct transfer system is not enough if the interface does not clearly explain what is happening.</p> <p>Likewise, a beautiful interface is not enough if the underlying connection fails unpredictably.</p> <p>A useful product requires both.</p> <h2>What I Learned</h2> <p>Building E-Pen reinforced several principles that I now apply to other software projects.</p> <h3>1. Start with the real user problem</h3> <p>Technology should support the solution, not become the solution itself.</p> <h3>2. Reduce unnecessary architecture</h3> <p>More infrastructure does not automatically mean a better product.</p> <h3>3. Privacy should affect system design</h3> <p>Collecting less data can be a technical advantage as well as a privacy decision.</p> <h3>4. Simple products still need strong engineering</h3> <p>A simple interface often hides considerable technical complexity.</p> <h3>5. Build, test, and learn from real users</h3> <p>A product cannot be fully validated only inside the development environment.</p> <p>Real usage reveals problems that assumptions often miss.</p> <h2>What Comes Next</h2> <p>E-Pen is part of the broader work I am building through <strong>Ryzova</strong>, an independent technology company focused on practical software, simple user experiences, and privacy-conscious engineering.</p> <p>The project is also an example of a principle behind Ryzova:</p> <p><strong>Ideas deserve a chance.</strong></p> <p>Instead of waiting for an idea to be perfect, I believe in researching it, building it, testing it, and learning from what happens when real people use it.</p> <p>That is how useful software becomes better.</p>