About three weeks ago I shipped DevCrate — a collection of 21 developer utilities that run entirely in your browser. No login. No backend. No frameworks. Just HTML, CSS, and vanilla JavaScript.
I want to be honest about how it went, because most "I built a thing" posts make it sound cleaner than it was.
Why I built it
I kept reaching for the same tools every day. A JSON formatter. A JWT debugger. A cron expression builder. And every time I landed on a site that wanted my email address, showed me ads, or sent my API payloads through their server, I'd close the tab annoyed.
So I built the version I actually wanted. Browser-only. Fast. No accounts. No tracking.
What I thought would take a weekend took three weeks. Here's what slowed me down.
The thing that actually broke me: CSS consistency across 21 tools
I expected the hard part to be the JavaScript — the JWT parsing, the regex engine, the diff algorithm. That stuff was fine. The thing that genuinely ground me down was keeping 21 pages visually consistent.
Every tool is its own HTML file. No component system. No shared templates. Just a <link> to a shared.css and the assumption that I'd stay disciplined.
I did not stay disciplined.
By tool 8 or 9 I started copying from whichever page was open, making small tweaks, and moving on. By tool 15 I had three slightly different versions of the breadcrumb. Two different spacings on the pro banner. One page where --text3 was #a07840 instead of #ad7146. A nav rule that was catching the breadcrumb element because both used a <nav> tag and I hadn't scoped the CSS selector properly.
None of these were obvious. They only showed up when I screenshotted every page side by side and started comparing.
The fix wasn't glamorous. I picked one page as the gold standard, wrote a Python audit script that compared every other page against it, and worked through the failures one by one. It took longer than building three of the actual tools.
What I'd do differently: establish a locked template file on day one. Copy it for every new page. Never "borrow" from a page that's already drifted. Treat it like a component even if you're not using a framework.
Building a Pro subscription on a static site
DevCrate has a Pro tier — $19/month via Lemon Squeezy. No server, no database, no user accounts. The license key gets stored in localStorage and gates certain features client-side.
This is not Fort Knox. A determined person could open DevTools and flip a value. I'm fine with that. The people willing to do that weren't going to pay anyway. The people who pay just want it to work.
Getting Lemon Squeezy wired up was straightforward. The trickier part was the UX — what happens when someone pays on their phone, then opens the site on their laptop? I built a restore flow where you re-enter your purchase email and license key to re-activate on a new browser. Simple, and it works.
Going framework-free intentionally
People ask why I didn't use React or a static site generator. The honest answer is I wanted zero build tooling. No npm. No webpack. No node_modules folder that somehow weighs 300MB for a site with no dependencies.
The tradeoff is real — consistency is harder without components, as I learned the painful way. But the result is a site that deploys by pushing HTML files to Cloudflare Pages, loads in under a second, and has a Lighthouse score I'm proud of.
For a project like this — lots of small isolated tools, each with its own UI — vanilla actually fits. The overhead of a framework would have been felt in every page.
Three weeks in
The site is indexed. It has its first external backlinks. A few people are using it daily based on the Pro signups.
There's still a lot to build — YouTube demo videos, saved configurations synced to an account, a public API. It's all on the roadmap.
If you're a developer who's tired of dev tools that want your data, give DevCrate a try. Everything is free to start. If it saves you time, the Pro plan is there when you need it.
Top comments (0)