I just launched deutschrechner.de — a free calculator site for Germany. Not one calculator, or ten. 511 calculators across 22
categories, plus over 100 long-form guide articles, built and shipped by two friends in our spare time. It's in German, for a German audience, but the
build story — the architecture decisions and the content-at-scale problem — is the part I think is worth sharing here.
## The idea
Germany has a lot of official numbers that change every year and a lot of rules nobody outside a tax advisor's office actually understands: Rentenwert,
Kindergeld, Pfändungsfreigrenzen, Soli-Freigrenze, Besoldungstabellen, Elterngeld-Bezugsformen. There are existing calculator sites for this. What I kept running
into as I researched them, category by category, was two different failure modes:
- Breadth gaps. Big, entire categories that just weren't covered anywhere — Mathematik, Statistik, Wissenschaft/Physik, Engineering, Business/Controlling, Bildung, Religion & Kalender. I ended up cataloguing this properly: of ~340 calculators on the largest existing German site, only about 70 had any topical overlap with categories like these — the rest simply didn't exist as tools anywhere.
- Depth gaps. Where a calculator on the same topic did exist, it was often shallow in a specific, avoidable way: asking the user to already know the number they came there to calculate. A rent-cost calculator that wants you to type in your Nebenkosten-per-square-meter — which is usually exactly what someone doesn't know and is trying to estimate. An income-tax calculator with two input fields where the real German tax code has a dozen decision-relevant variables (Werbungskosten, Vorsorgeaufwendungen, Kinderfreibetrag-Günstigerprüfung, church tax by state, disability allowances by Grad der Behinderung...).
So the plan became: cover the breadth gap with genuinely new categories, and on every calculator — old topic or new — actually model the real rule set instead of
a linear approximation.
## Tech approach
Deliberately boring, on purpose:
- Static-first — pages are generated up front, not rendered per-request, so there's no server to babysit and no runtime slowdown as the page count grows
- Structured content, not hardcoded copy — every calculator's text lives as data (YAML), separate from the page code
- Vanilla TypeScript, no React/Vue/Svelte anywhere in the dependency tree — a calculator is fundamentally "type numbers into fields, see a result update," and that doesn't need a component framework or a hydration story
## Content as a schema, not a template
The real risk at 500+ pages isn't running out of topics, it's every page starting to read the same, which is exactly what tanks programmatic-feeling sites in
search. The fix I landed on: every calculator's data has required fields that are structurally impossible to fill in generically — formula (the actual
expression, in words and in math), examples (worked numbers), commonMistakes (the specific ways people get this calculation wrong), faq. You can't
lorem-ipsum a commonMistakes array; you have to actually understand the calculation to write it. Pushing the specificity requirement into the data model,
instead of trusting a style guide, turned out to be the single highest-leverage decision in the whole project.
## Staying accurate at scale
German statutory figures update on their own schedules — Rentenwert, Kindergeld, and similar constants show up across dozens of calculators that all need to
agree with each other. I ran an audit that flagged internal inconsistencies first (the same named constant with two different values across sibling calculators
is a cheap, reliable signal something's wrong, before you even know which value is right), then resolved each flagged item against a real primary source. That
pass alone caught 42 calculators still running 2024/2025-era figures. For the 100+ guide articles, I used AI-assisted batches to keep production moving, but
every batch had a hard rule: pull numbers only from the calculator's own source data, never invent them, and I spot-read outputs myself and ran a coverage script
before trusting anything as done.
## Getting the small things right
The detail I didn't expect to matter as much as it did: sitemap lastmod. The default behavior either omits it or stamps every URL with the build timestamp,
which means every one of 500+ pages looks like it changed today, every single deploy — a signal that actively misleads crawlers and trains them to stop trusting
your lastmod at all. I built a small pass that reads each page's real updatedDate out of its content data and serializes an honest, per-URL lastmod into
the sitemap instead. Maybe 20 lines of code, more useful than most of the actual "SEO features" on the site.
## Challenges
- Staying accurate is a moving target, not a one-time task. A calculator that was correct at launch will quietly go stale as figures update.
- Breadth vs. depth is a constant trade-off. It's tempting to keep adding new topics; the harder discipline is going back and deepening what already exists once a real gap shows up.
- 500+ pages means 500+ places a small bug hides. A single wrapper-selector typo silently zeroed out results on one calculator until a full functional audit caught it. At this scale, "looks right in the three pages I checked by hand" isn't a real verification strategy.
## What's next
More guide-article depth, periodic legal-figure re-audits as 2026/2027 numbers roll in, and now — actually getting the site in front of people, which is a big
part of why I'm writing this.
## Why I'm sharing this
Mostly because "I built X" posts about scale usually skip the boring architecture decisions that actually made the scale possible without it turning into slop —
the content schema, the accuracy audits, the honest sitemap. If you're building anything content-heavy at scale, I'm happy to go deeper on any of this — the
content schema, the audit approach, the overall setup. The site itself is in German (deutschrechner.de), but I'd genuinely like feedback from this community on
the architecture side regardless of whether you read German.
Top comments (0)