Do I need an account to use Zippy?

No. Zippy was built specifically to avoid that. You upload a file, get a PIN, and share it. The person downloading only needs that PIN. No email, no password, no account on either end.

Is the file transfer secure?

Yes. Files are never routed through the application server. Zippy uses AWS S3 pre-signed URLs, which means the upload and download happen directly between the user and S3 over HTTPS. The server generates a short-lived URL and steps out of the way.

What happens to a file after it's downloaded?

Each file has a download limit. Once that limit is reached, AWS Lambda deletes the file from S3 and removes the record from the database. Nothing lingers.

Can the same PIN be used by multiple people?

Yes, up to the download limit set at upload time. Once the limit is hit, the PIN stops working and the file is cleaned up.

Can you build something like this for my project?

Yes. If you need a file transfer tool, a document portal, or any cloud-native web app on AWS, get in touch.

Zippy: Building an Anonymous File Sharing App

Overview

Zippy is a file sharing web app with one rule: no sign-up. You upload a file, get a 4 digit PIN, and give that PIN to whoever needs the file. That's it. We built it to solve a common frustration. Most file sharing tools require both parties to have an account, or they come loaded with features that slow down a simple transfer. Zippy skips all of that.

The Problem We Were Solving

There are plenty of cloud storage products out there, but most target ongoing storage rather than quick, one-off transfers. Google Drive works but requires a Google account on both ends. WeTransfer has ads and file size limits. Self-hosted tools like Nextcloud are overkill for a single file handoff. The brief was simple: upload once, share a PIN, done. The file doesn't need to live forever. In fact, it's better if it doesn't.

What We Built

Zippy runs on three AWS services: S3 for file storage, RDS (MySQL) for metadata, and EC2 for the application server. The backend is Java with Spring Boot. The frontend is plain HTML, CSS, and JavaScript — deliberately simple, because the app doesn't need to be anything else. A fourth service, AWS Lambda, handles scheduled cleanup.

Architecture

Both the upload and download paths use pre-signed URLs. Rather than routing file bytes through the EC2 server — which adds latency and cost — the backend generates a pre-signed URL pointing directly to S3. The client uploads to that URL, the file goes straight into S3, and the server never touches the bytes.

This matters at scale. If ten users are uploading large files at the same time, streaming those transfers through an app server would become a bottleneck quickly. S3 handles it without any changes to the backend.

Upload Flow

User selects a file and submits.
The backend generates a pre-signed S3 upload URL and a unique 4-digit PIN.
The PIN, S3 object key, and download limit are stored in RDS.
The backend returns the pre-signed URL and PIN to the client.
The client uploads the file directly to S3 using that URL.
The PIN is displayed to the user.

No account. No email. No link management. Just a PIN.

Download Flow

User enters the PIN on the download page.
The backend validates the PIN in RDS and checks that the download count is above zero.
If valid, a pre-signed S3 download URL is generated and the download count is decremented.
The client downloads the file directly from S3.

If the download count hits zero, the file entry in RDS is flagged as exhausted. Lambda picks it up on its next scheduled run and deletes both the S3 object and the RDS record.

The Self-Destruct Feature

This is what separates Zippy from a plain S3 upload wrapper. Each file is assigned a download limit at upload time. Once that limit is reached, the file is gone from both storage and the database. This is useful for sensitive documents. The sender knows the file can only be accessed a fixed number of times, and there's no lingering copy sitting on a server indefinitely. Running cleanup through Lambda on a schedule — rather than deleting inline during a download request — keeps the download path fast. There's a small window between when a limit is reached and when the file is actually removed, but for most use cases that tradeoff is worth it.

Key Technical Decisions

Pre-signed URLs over server-side proxying. Routing file data through Spring Boot would increase server load and outbound data transfer costs. Pre-signed URLs push that work directly to S3.

RDS over NoSQL. The metadata is relational: one PIN maps to one file record, and download count updates need to be transactional. MySQL on RDS fits this better than a NoSQL store.

Lambda for cleanup. Deleting files synchronously during a download would block the response and add complexity to error handling. Separating cleanup into a scheduled Lambda function keeps the download API clean.

Plain HTML frontend. The app has two user actions: upload and download. A JavaScript framework would add build complexity with no user-facing benefit.

Tech Stack

Backend: Java, Spring Boot

Frontend: HTML, CSS, JavaScript

Storage: Amazon S3

Database: Amazon RDS (MySQL)

Compute: Amazon EC2

Scheduled jobs: AWS Lambda

Delivery

Shipped in 2 weeks from first commit to live deployment. The first week covered the Spring Boot backend, S3 integration, and the pre-signed URL flow. Week two was the RDS schema, Lambda cleanup job, and frontend. No scope creep, no moving parts left unfinished at launch.

Early Traction

Zippy picked up 5 users in its first month — all organic, no marketing. Small number, but it confirmed the core flow worked end-to-end with real people on real files without any hand-holding. No support tickets, no broken uploads, no failed PINs.

What This Project Demonstrates

Zippy is a small project with deliberate architecture behind it. Pre-signed URLs, scheduled cleanup, transactional download limits — each decision was made to keep the app fast, cheap to run, and simple to use.

If you need a developer who builds cloud-native applications with AWS and Java, get in touch.