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.
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.
Every tool runs client side, and the interesting part is what that
took to keep honest:
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.
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.
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.
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