Three weeks ago I had an empty folder. Today useeverykit.com has 14
kits and around 79 small tools, and the one rule behind all of them
is that your files never leave your browser. This is the honest
build log: what I made, how the client-side privacy actually works,
and what it was like to have AI agents write most of it under strict
test gates.
Why I built it
Every "free PDF merger" or "passport photo maker" uploads your file
to someone's server. For a passport scan or a contract, that always
bothered me. The tasks themselves are small and mechanical, so there
is no real reason the file has to leave your machine. I wanted a set
of tools where the privacy claim is not marketing but something you
can verify in the network tab.
The one rule: nothing leaves the device
Every tool runs client side, and the interesting part is what that
took to keep honest:
- Face detection and background removal run as WebAssembly in the browser, not on a server.
- PDFs are handled with pdf-lib, plus a vendored copy of pdf.js. I had to pin its wasm and ICC assets locally because version 6 started fetching them from a CDN at runtime, which would have been a silent network call on a page that promises none.
- Document OCR uses tesseract.js with the English and Urdu data files served from my own origin.
- Speech to text runs a Whisper-tiny model, about 43 MB, cached after first use, entirely on-device through transformers.js. Nothing is sent anywhere.
- The Content-Security-Policy blocks the one telemetry endpoint the ML libraries try to call, so even a well-meaning phone-home fails.
To keep this from rotting over time, the test suite includes a
network sweep: it runs each file tool and asserts zero off-origin
requests. If a future dependency upgrade starts fetching something,
a test breaks instead of a promise.
The architecture
One repository. Each kit is a standalone Next.js app behind nginx on
a single VPS, with its own process. That sounds heavier than one big
app, and it is, but the isolation is the point: a bug or a heavy
WASM crash in one tool can never take down the others, and each kit
deploys on its own. Consistency comes from a shared conventions file
every part of the repo obeys, rather than shared runtime code.
Adding a new subdomain used to mean a DNS record and a certificate
step. Now a wildcard DNS record plus a deploy script that derives
the domain list from the registry and only calls certbot when a name
is genuinely missing means adding a kit is one command.
Building with AI agents
Most of the code was written by AI coding agents. The thing that
made that work was not the model, it was the discipline around it:
every unit had to pass typecheck, lint, tests, a production build, a
real-browser check at mobile and desktop widths, and the network
sweep before it could merge. Agents that verify their own work,
admit when a test vector was wrong, and refuse to guess a file path
are usable; agents left to run unchecked are not.
A few real bugs the gates caught that I would have missed: a PDF
guard that rejected on a single page failing to render, which would
have killed the whole page grid; signups from newer tools all being
filed under the wrong kit because of a hardcoded list; and that
pdf.js CDN fetch. None of these were obvious by eye. The tests found
all of them.
What I would tell someone starting this
Building was the easy part, and honestly the comfortable part.
Getting anyone to see it is the hard part, and it is not solved by
building more. If you are making something like this, spend at least
as much energy on distribution and being honest in public as you do
on the code.
The tools are free. If you try one and something is clunky or
missing, I would genuinely like to know: useeverykit.com
Top comments (0)