WeTransfer

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me file sending that replaces WeTransfer: a link, a recipient with no account, and a transfer that expires.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Local disk or an S3-compatible bucket
- Caddy in front

THE RECIPIENT EXPERIENCE IS THE PRODUCT
- Somebody who is not technical receives a link, opens it, and gets the files. No account, no application, no explanation
- So the download page is plain and fast: the file names, the total size, when it expires, and one button. Nothing else
- It must work on an old phone, on a bad connection, in whatever browser is installed
- Everything below serves that. If a decision makes the sender's life easier and the recipient's harder, it is the wrong decision

THE HONEST COST
- The cost of this business is bandwidth. Twenty gigabytes sent to five people is a hundred gigabytes out
- Check what your provider charges for egress, write the number in the README, and set limits from it. This is the trade: no subscription, a bill that moves with use

THE DATA MODEL
- transfers: id, token, title, message, sender_email, total_bytes, file_count, status, expires_at, max_downloads, download_count, password_hash, created_ip_hash, created_at, deleted_at
- files: id, transfer_id, name, path, sha256, bytes, mime_detected, upload_id, is_complete
- chunks: id, file_id, index, sha256, bytes, received_at
- recipients: id, transfer_id, email, token, notified_at, first_downloaded_at, download_count
- downloads: id, transfer_id, recipient_id, at, ip_hash, bytes_sent, completed — append-only
- Deletion at expiry is real, on disk and in the row, and the row records that it happened

UPLOADING
- Chunked and resumable, with parallel chunks. A large upload over a domestic connection will be interrupted, and one that restarts from zero is a product used once
- Each chunk hashed, the assembled file hashed and verified server-side. Never trust the client
- The upload survives the tab closing: state lives on the server, keyed by an identifier held in the browser
- Honest progress with a time remaining computed from the recent rate
- A size limit per transfer and per file, and a disk check before the upload starts rather than a failure near the end

SHARING
- A link with a long unguessable token, which is the whole authentication
- Or by email, each recipient with their own token so you can see who downloaded
- Optional password, expiry and download limit, all enforced server-side
- A notification to the sender on first download, which is the small feature people actually value

DOWNLOADING
- Range requests, so a large download resumes
- Several files streamed as a zip, never assembled on disk first
- A partial download does not count against a limit; only a completed one does
- Per-transfer bandwidth limiting if the machine needs protecting, and stated if so

EXPIRY
- Everything expires, with a visible countdown on the download page
- A sweeper that deletes from storage as well as the database, and verifies it
- Manual deletion by the sender at any moment
- The promise is only as good as the sweeper, so test it deliberately

ABUSE, WHICH WILL FIND YOU
- A public upload endpoint becomes somebody else's file host within weeks. That is not a risk, it is a certainty
- Require an account or an invitation, or at minimum rate-limit per address hash with a total storage cap per uploader
- Virus scanning with ClamAV where available, quarantining until the scan completes
- Never serve an uploaded file with a type a browser will execute: force download, with the type from your own content detection and never from the client's claim
- A report link on every download page, and a one-command takedown
- Log enough to answer an abuse complaint and no more

PRIVACY, PROPERLY
- Offer end-to-end encryption: the browser encrypts before upload with a key that lives in the URL fragment and never reaches the server; the recipient's browser decrypts
- Then the server genuinely cannot read the files, which is a far stronger promise than a policy — and it means you cannot scan them either, so make the trade explicit and let the sender choose
- Say clearly on both the send and the receive pages which mode a transfer used
- No third-party requests anywhere on either page

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, MAX_TRANSFER_BYTES, RETENTION_DAYS, HASH_SALT, SESSION_SECRET, SMTP_URL, S3_*
- Migrations on boot, each once
- Disk watchdog refusing uploads above a threshold rather than filling the volume
- Bandwidth measured daily with an alert, because that is the bill
- Health endpoint checking storage and free space

WHAT MATTERS MOST
The download page and real deletion. Hand the link to somebody who has never seen the tool and watch them get the file without asking a question, then confirm an expired transfer is gone from disk. Those two are the product.

Give me the repository, the chunked upload client, the encryption mode, migrations, .env.example, the sweeper, and a README with deploy steps behind Caddy and the bandwidth cost stated.