I built 150 dev tools nobody asked for. Google sent me 6 clicks.

PlatinumJ — Sat, 10 Oct 2026 08:40:46 +0000

TL;DR (for the scrollers)

I built dauntexlabs: about 150 small tools (some still in progress, and yes, the plan is 500 someday lol). JSON stuff, hashing, PDF merge, image convert, aviation calculators, Indian legacy font converters. They all run entirely in your browser. No backend. Your files are meant to stay on your laptop, and there are tests that check it.
It's a fully static Next.js export. One HTML page per tool, shared JS kept around 105 KB, heavy libs only load when you click the button that needs them.
"Privacy-first" is a claim everyone makes. So I made it a test: a canary string goes into every tool, and the test fails if it shows up in any network request, URL, page title, storage or console.
Three months of Search Console: 20.8K impressions, 6 clicks, average position 76. Google owns "km to miles". I'm not beating a widget.
So I went niche on purpose: crosswind calculators for pilots, Krutidev to Unicode for Hindi typists, stuff with like 12 users each. Nobody needs it. Some people really need it.
Confession: it's mostly vibe coded with Claude Code. What keeps it from being slop is a rules file, specs before code, and a test suite that acts as the reviewer. Code's public: github.com/jha-adrs/dauntexlabs.

That's the whole post. If you want the how, keep going.

Why build this at all

Ngl, there is no business here. Every tool on the site exists somewhere else already.

What annoyed me was how they exist. You want to merge two PDFs, and the top result wants you to upload your bank statement to some server, wait, then download it back. You want to decode a JWT, and you're pasting a production token into a random site with 14 trackers on it.

None of that needs a server. Browsers can hash, encrypt, read PDFs and re-encode images. So the rule for the project was simple:

If the tool can run in the browser, it runs in the browser. If it can't, it doesn't ship.

That's the niche. It solves a problem most people don't have, and the ones who do usually don't know they have it. Very much a "good to have" project. I'm fine with that.

The setup: static everything

The stack is boring on purpose:

Next.js 15 with output: 'export'. Every route becomes a plain HTML file. I picked Next over a plain SPA only for SEO: each tool gets its own real page with its own title and description baked in.
One registry file runs the whole site. lib/tools.ts is a list of tools (slug, name, category, blurb, keywords). The homepage, search, category filters, every tool page, sitemap.xml and robots.txt all come from that one list. Add an entry, and the page, card and sitemap row show up by themselves.
Each tool is its own lazy chunk. A slug → dynamic(import(...)) map means the PGP tool's code never loads on the word counter page.

// components/ToolMount.tsx (shape, trimmed)
const TOOLS = {
  'merge-pdf': dynamic(() => import('@/components/tools/MergePdf'), { ssr: false }),
  'pgp':       dynamic(() => import('@/components/tools/Pgp'), { ssr: false }),
  // ...140-something more
}

No server, no database, no auth. Deploy is "copy the out/ folder somewhere". It's giving 2009 and I love it.

The bundle budget

When you have 150 tools (and you're delulu enough to aim for 500), the easy failure is that every page slowly ships every library. So there's a budget: shared first-load JS stays around 105 KB, and it only grows about 1 KB per dozen new registry entries.

Rules that keep it there:

Use Web APIs before libraries. SHA, HMAC and AES go through crypto.subtle. Image tools use the native Canvas API with zero libs.
Write it yourself when the platform has a gap. Web Crypto doesn't do MD5 (fair, MD5 is cooked). People still need it for checksums, so lib/md5.ts is a hand-ported MD5. Small, no dependency.
Three libraries are allowed, and they load inside the click handler. openpgp, pdf-lib and qrcode-generator are bundled (no CDN), and they're imported inside the function that needs them. Not at the top of the file. Not on page load.

async function merge(files: File[]) {
  const { PDFDocument } = await import('pdf-lib') // only now, only here
  const out = await PDFDocument.create()
  // ...
}

After every build I check the output to make sure those libs show up as their own per-tool chunks and not in the shared bundle. One stray top-level import and the budget is gone.

Making "private" a test, not a vibe

Every tool site says "we respect your privacy". Cool. Prove it.

Here's what actually enforces it:

1. A static guard over the source. A Vitest test scans the tool code for fetch, XHR, WebSocket, sendBeacon, storage writes, console.* and history changes. If someone (me, at 1am) adds a network call to a tool, the test fails.

2. A canary string in the browser. A Playwright test types a unique string like CANARY-7f3a... into every tool that takes text or files. Then it checks:

every network request the page made
the URL (path, query and hash)
document.title
localStorage and sessionStorage
the console

If the canary shows up anywhere, the test fails.

3. A test that tests the test. This one's my favourite. The privacy spec includes a self-check that plants a leak on purpose and asserts the canary check catches it. A privacy test that always passes is lowkey worse than no test, because it makes you feel safe.

4. CSP as the last wall. public/_headers sets a Content Security Policy that only allows connections to the site itself and analytics. So even if code slips through, the browser blocks the request. There's an e2e test that fires a cross-origin request and asserts it gets blocked.

Small detail I'm weirdly proud of: search from inner pages goes to /#q=term, not /?q=term. The part after # is never sent to the server, so your search doesn't land in anyone's access logs.

The honest part

The privacy page used to say "nothing ever leaves your device". I changed it to "designed to run on your device", plus a section on the circumstances where data could leave your device.

Why make it weaker? Because the absolute version isn't something I can promise. I control my code. I don't control your 9 Chrome extensions. Saying "designed to" plus tests that back it up is more honest than a guarantee I can't keep.

Testing tools that draw pixels

About 1,780 Vitest tests, one suite per tool, rendering the real component and checking real output. The crypto ones do proper round trips: encrypt with AES or PGP, decrypt, get the plaintext back.

Image tools were the problem. jsdom has no real canvas, so unit tests there can only check the flow (file loads, button works, download fires). They can't tell you the JPEG is actually a JPEG.

So Playwright handles those, in real Chromium, and checks the downloaded bytes:

JPEG and WebP outputs start with the right magic numbers
resized PNGs have the right width and height, read from the IHDR chunk
the .ico file has the multi-size header
QR codes get decoded back with jsQR, and only the eye styles that actually scan are offered in the UI

That last one matters more than it sounds. Some fancy QR eye shapes look great and just don't decode. So the test decides which styles are allowed, not my taste.

Confession: it's vibe coded (with seatbelts)

Most of this code was written by Claude Code, not typed by me. Not gonna pretend otherwise.

The pace makes it obvious anyway. The repo is public, so you can check:

June 9: first commit.
June 20: 68 new tools in four commits. One day.
October 7–8: 59 commits in two days, for a full visual rebrand plus the niche expansion below.

No way I hand-write 68 tools in a day. But "vibe code 150 tools" is also exactly how you get 150 slightly broken tools. So the vibes run inside some rails.

1. A rules file the agent reads every session. There's a CLAUDE.md at the repo root. It's not "please write good code" energy. It's concrete stuff the agent can check itself against:

no fetch, XHR or WebSocket in tool logic
heavy libs get imported inside the handler, never at the top
build every tool from the shared UI kit, don't invent new CSS classes
a 5-step "adding a tool" checklist (registry entry, component, mount line, about/FAQ content, privacy canary case)
shared JS stays around 105 KB

Every time I correct the agent on something twice, it goes in that file. That file is basically the project's memory.

2. Spec before code for anything bigger than one tool. The repo has 6 design specs and 3 implementation plans under docs/superpowers/. The flow: the agent writes a spec, I push back on it, we agree, then a plan, then code. The niche expansion spec literally starts with my Search Console table. The data made the call, then the agent did the typing.

3. Tests are the real code reviewer. I can't line-by-line review 68 tools in a day, and honestly neither can you. So the 1,780 tests, the privacy canary and the CSP checks do that job. npm run verify (typecheck, tests, build) runs as a pre-push hook, so red code doesn't leave my laptop.

4. My job is deciding, not typing. What to build. What not to build: HEIC to JPG got cut because the decoder alone is over 1.3 MB, and OCR is out entirely. And rules like "a font map ships only if two independent sources agree". An AI will happily hand you a confident, plausible-looking character map. That rule exists so "looks right" never counts as "is right".

So yeah, it's vibe coded. But the vibes have a test suite.

The numbers (it's not giving viral)

Three months of Google Search Console:

Section	Pages	Impressions	Clicks	Avg position
Unit converters (km to mi etc.)	220	16,791	1	78.5
Nautical / knots converters	22	1,430	0	61.1
Tool pages	82	2,523	5	68.7

20.8K impressions. 6 clicks. Average position 76, which is page 8. Nobody goes to page 8. Page 8 is where pages go to touch grass.

The lesson took me a while to accept. Search "km to miles" and Google shows the answer in its own widget before any result. 16,791 people saw my page in results and 1 person clicked. I'm not out-ranking a calculator Google built into the search page, and I shouldn't try.

But the few clicks I did get were all niche: knots and nautical miles, "query params to json", a JSON pivot tool. Weird long queries where page 1 is weak.

So I went more niche, on purpose

The new rule: go after tools that are niche, usually paywalled or upload-only, and few people need. Then make them free and on-device.

What that looked like:

I noindexed 220 converter pages. They still work, they're still linked, but they're out of the sitemap. They were burning crawl budget for 1 click.
Aviation calculators: crosswind component, wind correction angle, density altitude, flight time and fuel. Pilots and student pilots need these, and a lot of the existing ones are paywalled or clunky.
India-specific tools: a GSTIN validator, Indian number formats (lakh and crore), and legacy Hindi font converters like Krutidev to Unicode. A lot of government and older office documents in India are still typed in these old fonts, and converting them is painful.
Real content on each page: an about, how-to and FAQ block, server-rendered, with FAQ schema. A tool page with only a text box doesn't rank.

One rule I didn't bend: a legacy font converter ships only if its character map checks out against at least two independent sources and real text. The Shivaji font map failed that check. So that page sits in "under maintenance" instead of shipping something that silently mangles someone's document. A wrong converter is worse than no converter.

What I'd tell past me

Pick the niche first, not after 150 tools. I built breadth, then found out breadth doesn't rank. Should've started with "who's annoyed and underserved" and built 10 tools for them.
If AI writes the code, you write the rails. A rules file, specs and tests are what turn vibe coding into something you can actually ship.
If a claim matters, make it a test. "Private", "fast", "small bundle" are all just vibes until something fails when they stop being true.
Write down the boring rules. "Libs load inside the handler." "Two sources or it doesn't ship." These are one-liners, and they're why the project didn't rot.
Search Console is humbling, open it early. The numbers will tell you things your ego won't.

What's next

More niche tools, real FAQ content on older pages, and I'll post the numbers again in a few months, good or bad. If the clicks go from 6 to 60, you'll hear about it. If they go to 7, you'll hear about that too.

If you're a pilot, a Hindi typist, or someone who refuses to upload their PDFs to random servers, the site is dauntexlabs.com and the code is on GitHub. If you have a niche tool you've always wanted on-device, drop it in the comments. Weirder is better.

DEV Community: PlatinumJ