I started building browser tools because I didn’t want visitors to my site running up my API bill. The first was an image combiner. I could have proxied a server-side image processing endpoint, charged it to my account, shipped something in a weekend. Instead I went looking for a client-side option because the math was obvious: random strangers would use it, I’d pay for every click.
That’s the whole story of how it started. Cheapness.
And now there are eight of them. Profile Ring Creator, QR code generator, Color Picker, Star Map, Handwriting Font Matcher, Palm Reader, AI Writing Detector, Sudoku Solver. Not one of them phones home when you click a button. MediaPipe runs on-device for the Palm Reader. Transformers.js with CLIP image embeddings for the Font Matcher. A custom heuristic scorer for the AI Detector because I didn’t want a language model grading prose for language-model patterns. The Sudoku Solver uses OpenCV.js for grid detection, perspective warping, and template matching, and runs a backtracking solver with a 6 million operation ceiling, all in your browser, because that’s the ceiling you need when the solver is competing with your phone’s other tabs.
That last tool shipped June 30th. It immediately had a bug where it returned 0 detected cells on real camera photos. Templates and cells were being normalized differently and every match score came back exactly 1.0. What I want to say here is different.
When you commit to building something in the browser instead of calling an API, you have to understand the problem. Not “understand” the way you understand something you’ve delegated. Actually understand it. Why does perspective distortion kill template matching if you don’t correct it first? What’s the typical ink pixel density in a printed digit at 20 pixels wide? How many operations does backtracking take on a worst-case puzzle before you need to bail? I know those things now because I had to.
The API route would have taken a weekend. A few hundred lines of glue code, a vendor key, a working result. I’d have shipped faster and understood less.
I’m not making a purity argument here. There are things I’ve offloaded to APIs where the problem is genuinely uninteresting and the cost is low. But “browser-first” stopped being a cost constraint somewhere around tool three and became something closer to a design principle: if you can build it on-device, you learn more about what you’re actually building.
Eight tools is not a portfolio play. It’s just the number you get when you build the thing you need instead of waiting for a cleaner reason to start.