I got tired of searching "gas mark 4 to celsius" and landing on ad-heavy US sites that had never heard of a British oven. So I built the site I wanted to use myself.
Here's how it went, what I learned, and why the stack matters.
The problem
Most conversion sites are US-centric and ad-riddled. They don't cover:
Gas Mark — the temperature scale on every British cooker
UK shoe sizes — totally different from US
Multi-band VAT — standard, reduced, zero rates per country
UK gallons — not the same as US gallons
And the ones that do cover some of these are buried in SEO spam with 5 ad placements per page.
The stack
Layer Choice Why
Framework Astro 5 Ships zero JS by default. Every tool page is static HTML — instant load, perfect Lighthouse scores
Components React 19 Only where interactivity matters (calculators, inputs). Astro islands keep the rest static
Styling Tailwind 4 Utility-first, no context-switching to CSS files, tiny bundle
Hosting Cloudflare Pages Free tier, global CDN, git-push deploy
Currency API frankfurter.dev Free, open ECB data. No API key needed
Feedback Formspree Form backend without writing a single server route
Analytics GA4 + Consent Mode v2 Default denied, opt-in only. No cookies without consent
Architecture: data-driven static pages
Every tool follows the same pattern:
src/data/tools.ts → tool definitions (name, category, route, icon)
src/pages/tools/[id].astro → one template, renders all tools
src/components/*.tsx → React islands for interactive bits
Adding a new tool is literally adding one entry to an array. No new routes, no new templates. The [id].astro page reads the slug and renders the right component.
Privacy as a feature, not an afterthought
This was non-negotiable for me:
All calculations run in the browser. No input ever touches a server.
Consent Mode v2 — analytics default to denied. Users opt in, not out.
No sign-ups, no accounts, no tracking pixels.
GDPR-friendly by design, not by cookie banner hack.
The footer says it plainly: "All tools run in your browser — no data uploaded."
What I'd do differently
Start with GSC data before picking tools. I built 9 tools based on my own needs. Two months of Search Console data would have told me exactly which UK conversion keywords have demand vs. which ones are dead.
Ship with 3 tools first, then expand. 9 tools upfront meant more surface area for bugs. Launching leaner would have been faster.
Pinterest earlier. The Gas Mark conversion chart has real "save and reference later" potential. I should have made those pins day one.
Numbers (after week 1)
~20-50 daily visitors (organic, zero paid)
~12 GSC impressions/day and climbing
Product Hunt launch pending
$0 revenue — it's a free tool. Maybe AdSense later, maybe not.
The site
👉 ukconvert.com
All static, all free, all private. Source on GitHub.
If you're building a similar tool site, happy to answer questions in the comments.
Tags
Top comments (3)
Great job on the zero-JS approach—it’s refreshing to see a clean, fast, and focused tool built with privacy in mind. I’ve been working on similar constraints with some GPU-accelerated tools at VoltageGPU, where minimizing client-side bloat is key for performance and security. Astro really shines when you want to keep things lean but still powerful.
Building a zero-JS default site with Astro is a fantastic way to handle utility tools like unit converters since the core logic can easily run on the client after hydration or just via simple CSS tricks for basic stuff. I recently tackled a similar privacy-first project and found that keeping the initial payload under 10kb really does make a noticeable difference in Lighthouse scores, especially on mobile networks. Have you considered using View Transitions API in Astro to make navigating between different converter categories feel more like a native app without adding any heavy client-side routing? It would be interesting to see how Tailwind 4 handles the new utility classes for those transition states out of the box.
Building a zero-JS default site with Astro is a fantastic approach for utility tools like converters, especially when prioritizing privacy and load times. I have found that combining Astro islands architecture with React 19 allows you to keep the initial payload tiny while still enabling highly interactive components only where necessary. Since you are using Tailwind 4, are you leveraging the new CSS-first configuration approach to keep your utility classes even more streamlined? It would be interesting to hear how you handled the state management for the conversion inputs without relying on client-side JavaScript.