The swiss army knife for freelancers — engineered from first principles.

A single upload strategy can't serve files that range from a 200 KB logo to a 4 GB video master. Small files need to be instant. Large files need resilience. Edge cases need a fallback that doesn't crash.

The system inspects file size at selection time and routes each file through the appropriate path automatically:

1. Presigned Upload: Files under 50 MB are uploaded directly to S3 via a presigned PUT URL — a single request, zero server load.
2. Chunked Multipart: Files between 50 MB and 5 GB are split into 10 MB chunks, uploaded in parallel, and reassembled by S3. Failed chunks retry automatically.
3. Streaming Fallback: For edge cases where presigned URLs aren't viable, the server proxies the upload as a stream — never buffering the full file in memory.

The user never sees this complexity. They drag a file, it uploads. The system decides how.

When a recipient wants to download all files at once, the platform needs to produce a ZIP archive — potentially gigabytes in size. Traditional approaches buffer the entire archive in memory or on disk. Neither works in a serverless environment.

Instead, a Lambda function streams files directly from S3 into a ZIP stream that writes back to S3 as it goes. No intermediate buffer. No disk. The function's memory footprint stays constant regardless of total file size.

1. Request: The client selects files and requests a ZIP. The API validates access and invokes a Lambda function.
2. Stream & Compress: The Lambda streams each file from S3 and compresses on-the-fly — no intermediate disk or memory buffer.
3. Stale Detection: If source files change during creation, the operation aborts and the client is prompted to retry.
4. Delivery: The completed ZIP is written to S3 and a presigned download URL is returned to the client.

Freelancers need to share previews without giving away the originals. Watermarked previews solve this — but generating them synchronously during upload would make the experience painfully slow, especially for video.

The watermarking system runs as an asynchronous pipeline. Uploads complete instantly. Preview generation kicks off in the background across two specialised paths:

1. Upload completes: The user receives immediate confirmation. Watermarking begins asynchronously.
2. Image pipeline: Sharp resizes to preview dimensions and composites the watermark overlay — typically under 500ms per image.
3. Video pipeline: FFmpeg generates a preview clip and burns in the watermark. A shared Lambda layer keeps the binary under 50 MB.
4. Preview ready: Watermarked previews are stored alongside the originals. The UI updates automatically when processing completes.

Sharing files is only half the workflow. Freelancers also need to collect files from clients — brand assets, content for editing, signed contracts — and get feedback on deliverables before final handoff.

File Requests generate a branded upload portal with a unique link. The client uploads directly — no account required. Files land in the freelancer's transfer, organised and ready for download. The upload portal inherits the sender's branding: logo, colours, and a custom message.

Collaborative Preview turns any transfer into a review surface. Recipients can view watermarked previews in a gallery, leave comments on individual files, and approve or request changes. The freelancer sees all feedback in one place — no email chains, no scattered messages.

Files shouldn't live forever. Every transfer in LOCKD has a lifecycle governed by four independent controls — each enforced at the API level, not the frontend.

Expiry timers auto-disable access after 24 hours, 7 days, or 30 days. Download limits cap the number of times each recipient can access a file. Password protection adds an optional passphrase gate. And when any condition triggers, auto-cleanup purges the files from S3 entirely — not just the links.

The result is a system where files are available exactly as long as they need to be, and not a second longer. The audit trail — who accessed what, when, how many times — is preserved even after the files are gone.

Two foundational systems run beneath every feature: content-based file type detection, and a structured error framework.

MIME detection reads magic bytes from the file header rather than trusting the uploaded file extension. A file named photo.jpg that's actually a PDF will be identified correctly — and routed to the right preview renderer. This prevents spoofing, ensures correct thumbnails, and means the watermarking pipeline always knows what it's processing.

Structured errors ensure every API endpoint returns a typed, machine-readable error object with a stable error code and a human-friendly message. The frontend maps these to contextual UI — a file too large shows the size limit, an expired transfer shows when it expired, a rate-limited request shows when to retry. No generic “something went wrong” modals.