I built 79 browser tools in three weeks with AI agents, and none of them touch your files

A developer built useeverykit.com, a collection of 79 browser-based tools across 14 kits, in three weeks using AI coding agents. All tools run entirely client-side, with a test suite that enforces zero off-origin requests to guarantee privacy. The project uses isolated Next.js apps on a single VPS, and the developer credits strict test gates for catching bugs that would have been missed by eye.

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