임세환

Posted on Jan 13

Building a 49-Country Exchange Calculator with a Single Static Page

#architecture #frontend #javascript

When I started building a travel exchange calculator, I ran into a familiar problem.

People don't search for "exchange calculator."

They search for "Vietnam currency to KRW", "Japan yen to won", "Thailand baht rate", and so on.

Each country has its own search intent, but building a separate HTML page for every country quickly turns into a maintenance nightmare.

So I asked myself a simple question:

Can one static page behave like dozens of localized landing pages?

The Idea: Let the URL Do the Work

Instead of creating 49 different HTML files, I used the URL path as a preset key.

/travel/exchange-calculator/vietnam/
/travel/exchange-calculator/japan/
/travel/exchange-calculator/thailand/

The last segment of the URL is read by JavaScript, matched against a preset table, and used to automatically initialize the calculator with the right currencies.

Same HTML.

Same JavaScript.

Different user experience depending on the URL.

Why This Works So Well

This pattern has a few big advantages:

No build system — just plain files
No duplicated HTML — one source of truth
One codebase to maintain — fix once, deploy everywhere
SEO-friendly URLs — every country gets its own indexable path

From the user's point of view, it feels like a country-specific calculator.

From the developer's point of view, it's still just one static page.

How the Routing Works

At page load, the script extracts the last segment from location.pathname and checks it against a simple preset map:

const presets = {
  vietnam:   { from: 'VND', to: 'KRW' },
  japan:     { from: 'JPY', to: 'KRW' },
  thailand:  { from: 'THB', to: 'KRW' },
  usa:       { from: 'USD', to: 'KRW' },
  // ... 45 more countries
};

const segment = location.pathname.split('/').filter(Boolean).pop();
const config = presets[segment] || { from: 'USD', to: 'KRW' };

initCalculator(config.from, config.to);

If there's a match, the calculator initializes with those currencies.

If not, it falls back to a sensible default (USD → KRW).

That's it. No server logic, no framework routing, no URL rewrites.

Why I Built It This Way

I'm building Sudanghelp — a real-world finance calculator platform focused on practical tools people actually use, from government benefits and military pay to travel expenses and currency exchange.

This exchange calculator is one piece of that ecosystem.

👉 Live demo: sudanghelp.co.kr/travel/exchange-calculator/

When This Pattern Makes Sense

This approach works especially well when:

You're on a static host (GitHub Pages, Netlify, Cloudflare Pages)
You want SEO-friendly URLs for many variations of the same tool
You don't need a heavy framework just to handle routing
Your "variations" are really just different initial states

It's basically turning your URL structure into a lightweight configuration API.

Final Thoughts

Frameworks are great, but for many real-world tools, plain HTML + JavaScript + smart URLs go a long way.

Sometimes the simplest solution is the most maintainable one.

If you're building similar tools or curious about the platform behind this, check out Sudanghelp.

What patterns do you use to handle multiple landing pages without duplicating code? I'd love to hear other approaches in the comments.

DEV Community