Background
Unit conversion tools are everywhere, but most of them are bloated with ads, slow to load, and require server round-trips for basic math that any browser can do. I wanted to build something that was instant, clean, covered every conversion category I'd ever need, and cost nothing to run. The kind of tool where you type "inches to cm" into Google, click the first result, and have your answer before the page even finishes loading.
The key goals?
- Cover every common conversion category - length, weight, temperature, volume, time, area, speed, pressure, energy, power, force, and more
- Zero backend - all conversion logic runs client-side in the browser
- Zero hosting costs - sustainable enough to run indefinitely without revenue pressure
- SEO-first - every converter page pre-rendered with proper meta tags, sitemaps, and structured URLs
- Monetizable via ads without compromising the user experience
Challenge
The technical challenge wasn't the math - unit conversion is straightforward. The challenge was building a system that scales to 69 unique pages across 18 categories without turning into a maintenance nightmare:
Page Generation at Scale. Each converter (e.g., "inches to centimeters") needs its own URL, its own SEO metadata, its own conversion table, its own related links, and its own breadcrumb trail. Writing 50+ pages by hand wasn't an option - the system had to generate them from data.
Precision Without Dependencies. JavaScript's floating-point arithmetic breaks on simple operations like 0.1 + 0.2 = 0.30000000000000004. Libraries like decimal.js add weight. I needed precision without the dependency overhead.
Temperature is Special. Most unit conversions are linear - multiply by a factor. Temperature isn't. Celsius to Fahrenheit requires a formula, not a factor. The conversion engine had to handle both patterns without special-casing every page.
SEO for 69 Pages. Each page needs unique meta descriptions, Open Graph tags, canonical URLs, and proper internal linking. Doing this manually would be error-prone and unsustainable as new converters are added.
Solution
UnitWolf is a statically-generated React application built with Gatsby, deployed to Cloudflare Pages, with all conversion logic running client-side.
Unified Unit Definition System
Everything flows from a single data structure - UNIT_DEFINITIONS - that maps every category to its units, symbols, conversion factors, and aliases. Adding a new unit means adding one entry to this object. The entire UI, navigation, SEO metadata, and conversion logic derive from it.
Temperature gets a special: true flag that routes it through a multi-step formula converter instead of the standard factor-based path. No other special cases exist - the system handles everything else uniformly.
Lightweight Decimal Precision
Instead of pulling in a math library, I wrote a minimal Decimal class that wraps string-based arithmetic. It handles times, div, plus, and minus operations with enough precision for currency and scientific conversions. The entire implementation is 34 lines.
Static Site Generation
Gatsby pre-renders all 69 pages at build time. Each converter page gets:
- Pre-rendered HTML with conversion UI
- Auto-generated meta description from the unit names
- Canonical URL and Open Graph tags via a shared
SEOHeadcomponent - Breadcrumb navigation generated from the URL structure
- Related links filtered by category
- A conversion reference table
The result is a fully static site - no Node server, no API, no database. Just HTML, CSS, and JavaScript served from Cloudflare's CDN.
Infrastructure as Code
The entire deployment is managed with Terraform - Cloudflare Pages project, custom domain configuration, DNS records. A terraform apply sets up the full production environment from scratch. No clicking through dashboards, no manual DNS entries.
URL Redirect Preservation
When the URL structure changed from flat (/inches-to-cm/) to nested (/length/inches-to-cm/), 41 permanent redirects were configured in gatsby-node.ts to preserve SEO equity from the old paths. Zero broken links.
Results
Topic: Static Architecture as a Competitive Advantage
Importance & Risks:
- Backend complexity is the default, not the requirement. Most developers reach for a server, a database, and an API before asking whether the problem actually needs one. For read-heavy, compute-light applications, a static architecture eliminates entire categories of operational burden.
- SEO is make-or-break for content sites. A converter tool that doesn't rank is a converter tool nobody uses. Pre-rendered pages with proper meta tags outperform client-rendered SPAs in search results consistently.
- Hosting costs kill side projects. The graveyard of abandoned side projects is full of tools that worked fine but cost $20/month to keep running. Zero-cost hosting means UnitWolf can run indefinitely regardless of revenue.
Our Advice (from the trenches):
- Start with the data model, not the UI. The
UNIT_DEFINITIONSobject is the single source of truth for everything - UI, navigation, SEO, conversion logic. Adding a new category means adding data, not code. In my experience, the projects that stay maintainable are the ones where new features are configuration changes, not code changes. - Static doesn't mean limited. Gatsby generates 69 pages with unique SEO metadata, conversion tables, and navigation structures - all from React components and a data file. The site feels dynamic to users but costs nothing to serve.
- Terraform your side projects. It feels like overkill for a static site, but when I migrated from Netlify to Cloudflare Pages, the entire infrastructure was reproduced with one command. No manual setup, no forgotten DNS records, no configuration drift.
- Don't import what you can write in 34 lines. The Decimal class handles all precision needs without adding decimal.js (128KB) to the bundle. For focused use cases, a purpose-built solution beats a general-purpose library.
Conclusion
UnitWolf serves 100+ unit conversions across 18 categories from 300+ Cloudflare edge locations, with zero backend infrastructure and zero monthly hosting costs. Every conversion runs client-side in the browser - no API calls, no database queries, no server-side computation. The entire platform is pre-rendered at build time, version-controlled in Git, and deployed via Terraform. It's a proof point that static architecture isn't a limitation - it's a feature, when the problem fits.
