Building a calculator platform for 9 currencies without writing a single hardcoded $ — and what I learned about building for AI search along the way

Building a calculator platform for 9 currencies without writing a single hardcoded $ — and what I learned about building for AI search along the way

A few months ago I started building Calcrux, a free business calculator platform — Amazon FBA profit, SIP returns, OEE for manufacturing, startup burn rate, that kind of thing. It's grown to 100+ tools across five ecosystems (ecommerce, manufacturing, startups, finance, and an India-specific suite), and along the way I ran into three problems that turned into the actual architecture of the thing: how do you build one calculator that works correctly in nine countries without hardcoding anything, how do you scale to 100+ tools without rebuilding the same logic every time, and — this one surprised me — how do you build pages that AI search engines actually trust enough to cite.

I've been a full-stack .NET developer for 7+ years, mostly enterprise web/ERP work, currently the sole dev and tech lead on an Australian engineering client's stack. Calcrux is my first real foray into the Next.js/React side of things and into thinking about SEO as an architectural concern rather than an afterthought. Here's what I learned.

The currency problem nobody tells you about until you hit it

The naive version of a multi-currency calculator looks like this: detect the user's country, show $ or ₹ or € in front of the number, done. That works until you actually ship it to nine markets and discover that:

• Number formatting isn't just the symbol. 1,234.56 in the US is 1.234,56 in Germany and 1,23,456 (lakhs/crores grouping) in India.
• "Tax" isn't one concept. US sellers think in sales tax, India thinks in GST with CGST/SGST/IGST splits, the UK and EU think in VAT. A label that says "Tax" in the UI is either wrong or meaninglessly vague for half your users.
• Fee schedules, referral rates, and even what counts as a reasonable input range differ by marketplace — an Amazon FBA calculator for amazon.in needs different size-tier breakpoints than amazon.com.

My rule after hitting this enough times: no hardcoded currency symbols, tax labels, or number formats anywhere in the codebase. Every single one of those gets resolved at render time through a GeoContext object that gets passed into every calculation engine and every display component.

interface GeoContext {
  countryCode: string;       // 'US' | 'IN' | 'GB' | ...
  currencyCode: string;      // ISO 4217: 'USD' | 'INR' | 'GBP' ...
  taxLabel: string;          // 'Sales Tax' | 'GST' | 'VAT'
  locale: string;            // for Intl.NumberFormat
}

function formatMoney(amount: number, geo: GeoContext) {
  return new Intl.NumberFormat(geo.locale, {
    style: 'currency',
    currency: geo.currencyCode,
  }).format(amount);
}

Intl.NumberFormat does the actual heavy lifting — it already knows the grouping and decimal rules for every locale, so the only job left for me was making sure GeoContext is the only path data takes to the screen. Zustand holds the geo state globally, and every engine function takes GeoContext as a parameter rather than reaching for a global or assuming a default. It's a small discipline that pays for itself the first time you add market #6 and nothing breaks.

Scaling to 100+ tools without rebuilding the wheel each time

The second problem was structural. Once you've built five or six calculators you start noticing that "build a calculator" is actually three separable jobs: the inputs and their validation rules, the math, and where the tool lives in the site's information architecture. Mixing those together is how you end up with 100 slightly-inconsistent files that are each a pain to touch.

So every tool in Calcrux follows the same three-file contract:

• config.ts — input fields, validation, defaults, labels (the stuff that changes per market via GeoContext)
• engine.ts — pure calculation functions, no UI concerns, fully testable in isolation
• registry.ts — the single source of truth for where this tool lives (/tools/{ecosystem}/{tool-slug}), its metadata, and how it shows up in navigation, related-tools blocks, and sitemaps

Splitting it this way means the math is unit-testable without touching React at all, and adding tool #101 is a known quantity instead of a fresh design decision. It also means the URL structure (/tools/{ecosystem}/{slug}) is decided once, at the registry level, and never improvised per page — which matters more than it sounds like once search engines start indexing you and you really don't want to be restructuring URLs six months in.

The part I didn't expect: building for AI search, not just Google

Here's the thing that changed how I think about content. Calculator sites have historically optimized for one audience: the Google crawler, plus a human skimming for the input boxes. But increasingly, the actual question — "what's a good Amazon FBA profit margin" or "how does SIP compare to lump sum" — gets answered inside Google's AI Overview, or directly in ChatGPT/Perplexity, without the person ever clicking through to a site.

That's a problem if your page is just a calculator with no surrounding context, because there's nothing for an AI system to cite. So every tool page on Calcrux carries the actual substance an AI answer engine (or a human) needs to trust the number it's looking at: the formula written out explicitly, a worked example with real numbers, a named source standard where one exists (ISO 22400 for OEE, EPFO circulars for EPF, official marketplace fee schedules for Amazon/eBay), benchmark tables, and a "last updated" date tied to when the underlying rates actually changed.

None of that is exotic SEO trickery — it's the same stuff that makes a page genuinely more useful to a human, which turns out to be exactly what makes it citable to a model too. The overlap between "good for humans" and "good for AI search" is bigger than I expected going in.

What's next

The India Business ecosystem (GST, TDS, gratuity, EPF, income tax under both regimes) just launched, and I'm working through the rest of the planned tools across the other four ecosystems while continuously auditing existing pages against this same bar — formula transparency, real worked examples, and genuinely dynamic geo-handling, not just a currency symbol swap.

Questions for this community

A few things I'm still actively deciding on, and would genuinely like opinions on:

• For anyone who's built multi-region products: did you go further than Intl.NumberFormat + a GeoContext object, or did you hit a wall this approach doesn't solve? I'm curious what breaks at higher scale (50+ markets, RTL languages, etc).
• Has anyone here deliberately restructured content for AI-answer citability (Overviews, Perplexity, ChatGPT Search) and seen it actually move the needle, separate from normal SEO? I have a hypothesis but no hard data yet.
• If you've built a config/engine/registry-style split for a different kind of repeatable product (not calculators) — did the same three-way separation hold up, or did you end up with a different seam?

Drop a comment, I'll respond to all of them — and if you want to see the actual output of all this, Calcrux is free, no sign-up, and I'd take it as a compliment if you broke it.