LoveMyFile

Problem

The normal way to merge a PDF or compress a photo is to hand it to someone else's server. For a passport scan, a signed contract or a medical record, that is a privacy decision made on the user's behalf by a site they will visit exactly once. The same sites usually cap file sizes, add watermarks, or require an account — and on the operator's side, server-side processing makes cost a function of popularity, so the free tier exists to be withdrawn.

Constraints

• No server-side processing, no file storage and no upload route anywhere in the product.
• The browser is not a native runtime: memory ceilings, no filesystem, and a tab that can be closed at any moment.
• The engines are heavy. A PDF parser worker and on-device ML models are megabytes, and nobody waits for megabytes to try a merge.
• It has to survive a phone, which is where most of the traffic lands.

Decisions

1. Do everything on the device with WebAssembly, Web Workers and Canvas, and delete the server from the architecture.

   rejected A thin client calling a processing API — what almost every competitor does.

   Server-side processing makes privacy a promise and cost a function of traffic. Removing the server makes both structural: there is no upload path to leak, no retention policy to write, and no compute bill that grows with success. The cost was accepting a hard ceiling on what the product can ever do, which meant the decision had to be right before the first tool shipped.

2. Load each engine lazily, per tool, rather than bundling one shared runtime.

   rejected Ship a single PDF and WebAssembly bundle to every page.

   The homepage transfers about 22KB because it ships no engine at all; the PDF.js worker only appears once a PDF tool is opened. Bundling everything would have charged every visitor for the heaviest tool they were not using — the exact trade that makes browser-side processing feel slow and get abandoned.

3. Turn the no-upload promise into something a sceptical user can verify, with a written test procedure.

   rejected State it in the privacy policy and rely on the reader's trust.

   For the audience that most needs this product — legal, medical, HR — the claim is the product, and a policy sentence is not evidence. So the site documents how to test it with a harmless tracer file and the browser's network panel, and explicitly tells the reader not to believe it until they have. A privacy claim you can falsify in two minutes is worth more than one you have to take on faith.

4. Use WebAssembly and on-device TensorFlow.js where hosted inference would be easier.

   rejected Call a hosted model API for background removal, face blur and upscaling.

   Hosted inference would have been quicker to build and better looking, and it would have put the user's photograph on someone else's server — breaking the single promise the product rests on. On-device models are the slower build with visible artefacts, so they ship labelled beta with their failure modes written next to them.

The hard part

The model-driven tools are the ones you cannot fully control, and the risk is not a crash but misplaced confidence. Background removal invents edges, face blur misses faces and detects no licence plates, and upscaling adds detail that was never in the photograph. The genuinely difficult work was not the inference — it was refusing to let the interface imply more than the model delivers: labelling the beta tools, stating the missing plate detection next to the control, and telling readers to check text selection and search after a redaction rather than letting a black box suggest the document is now safe.

Outcome

• 40

  browser-side tools shipped

• 0

  server-side file processing

• ~22KB

  homepage transfer, 93ms to first byte

• 0

  network requests during a verified merge

The last two are my own measurements from the live site, not estimates. I built two small PDFs containing tracer strings, selected both, ran Merge 2 PDFs and watched the network stack from file selection to the finished download: no fetch, no XHR, no beacon, no WebSocket fired. The honest gap is file-size limits — device memory decides them, they are not published anywhere on the site yet, and they should be.

Figures and revisions

FIG. 1

source: lovemyfile.com, livechecked: 11 Oct 2026

FIG. 2

source: lovemyfile.com/pdf/merge, livechecked: 11 Oct 2026