I Ship 61 Calculators as a Static Site in 12 Languages — Here's How

Farbod F. — Wed, 14 Oct 2026 18:16:34 +0000

I Ship 61 Calculators as a Static Site in 12 Languages — Here's How

We're a small team of software engineers, and we run youcancalc.com — a free collection of 61 calculators, localized into 12 languages. No accounts, no backend, no paywall, no tracking pixels. Every calculation happens in your browser. This is a notes-from-the-trenches post about the architecture choices that make that possible, and the ones we'd make again.

The whole thing is static

The site is a statically-exported site: every page is pre-rendered to plain HTML at build time and served as files. There is no application server, no database, no API to keep warm. A calculator page is a document with a script attached, not an app with a backend.

This sounds limiting until you realize what a calculator actually needs: inputs, arithmetic, and formatted output. None of that requires a server round-trip. The result is pages that answer instantly — no spinners, no "computing..." states — and hosting that is boring in the best way.

All computation is client-side

Each calculator page follows the same contract:

Inputs — the user types numbers, picks options.
Instant result — recomputed on every keystroke, locally.
How it works — the formula is printed next to the answer, not hidden.
Worked examples — concrete numbers walked through step by step.
FAQ — the questions people actually ask about this calculation.
Related calculators — the natural next questions.

Because everything runs client-side, there's a privacy property we get for free and take seriously: your inputs never leave your browser. There's nothing to leak because there's nowhere for the data to go. We don't have your numbers; we never did. In an era where every form field seems to phone home, "the architecture makes surveillance impossible" is a stronger guarantee than any privacy policy paragraph.

i18n without a translation department

Twelve locales: English, Spanish, French, German, Italian, Portuguese, Arabic, Dutch, Polish, Chinese, Japanese, Korean. A few things we learned doing this as a tiny team:

Locale-prefixed routes. Every language lives under its own path prefix (/es/, /de/, …), so each locale is a fully crawlable, shareable site — not a JavaScript-swapped afterthought.

Localize everything, including the math. Formulas, worked examples, and FAQs are content, not chrome — they all go through the i18n layer. A French user should read the explanation of compound interest in French, not just the buttons.

Numbers are not universal. This is the bug class that keeps us humble. Intl.NumberFormat exists for a reason: 1,234.56 in English is 1.234,56 in German. Decimal separators, digit grouping, and even digit shapes differ. Every numeric input and output goes through locale-aware formatting and parsing — parse with the locale, never with parseFloat on raw user input.

RTL is a layout commitment. Arabic means right-to-left, and that affects more than text direction: form layouts, example tables, and the visual order of "inputs → result" all need to mirror correctly. We test it; it's the kind of thing that's either right or embarrassing.

What we deliberately don't do

Constraints are features. We don't do accounts (nothing to personalize), we don't do paywalls (the calculators are the product, and they're free), and we don't do tracking (see above: nothing to track with). We also don't have a blog — each calculator page carries its own explanation, examples, and FAQ, so the content lives where the question is asked instead of in a separate content silo.

This keeps the operational surface tiny: no user data to protect, no sessions to manage, no email infrastructure, no A/B testing apparatus watching your mouse. The site is, by construction, a very boring thing to operate. We like boring.

The honest trade-offs

Static has costs and we won't pretend otherwise:

Build time grows with locales × pages. 61 calculators × 12 languages is hundreds of pages per build. It's fine on modern hardware, but it's the thing we watch.
No personalization. We can't remember your last calculation across devices, because we don't know who you are. We consider this acceptable — arguably it's the point.
Client-side means client constraints. Very old browsers and very slow devices get a degraded but functional experience; we keep the client-side script lean and avoid heavy client libraries rather than assuming a flagship phone.
Translation quality is an ongoing process. Machine-assisted translation gets you 90% of the way; the last 10% — idioms in FAQs, culturally specific examples — needs human eyes, and with 12 locales it's never "done."

Why this architecture fits calculators specifically

A calculator is a pure function with a nice UI: same inputs, same outputs, every time. There's no shared state, no feed, no real-time collaboration. The moment you notice your product is embarrassingly parallel and stateless, the correct architecture is usually "files on a CDN." We just took that seriously and stopped there instead of adding a backend out of habit.

If you're building something similar — reference tools, converters, small utilities — our sincere recommendation: start static, compute locally, and only add a server when you can name the specific thing it does that the browser can't. You might be surprised how rarely that day comes.

We're the team behind youcancalc — 61 free calculators, 12 languages, zero tracking. If you build tiny tools on the web, we'd genuinely like to hear how you architect them.

DEV Community: Farbod F.

I Ship 61 Calculators as a Static Site in 12 Languages — Here's How

I Ship 61 Calculators as a Static Site in 12 Languages — Here's How

The whole thing is static

All computation is client-side

i18n without a translation department

What we deliberately don't do

The honest trade-offs

Why this architecture fits calculators specifically