Case study
A website for a second country is not just a translation
Our own platform was built for one country, so the country was written into hundreds of places rather than set anywhere. Here is how we traced it, what we changed, and what an owner can check before serving a second country.
Key takeaways
- The country belongs in one record the whole business reads, not in edits scattered through the software.
- Choose a visitor's country in a fixed order and give them a switch, so nobody is stuck with the wrong one.
- A sign-up that asks for a document a customer cannot produce loses them faster than any wording can.
- Record your existing pages before building the second country's site, so you can show your first customers that nothing changed.
- Let the platform tell older app versions what they can display, rather than teaching each version about every country.
If you serve one country today and are planning a second, the words are the smallest part of it. On our own platform, adding a second country meant finding every place our software quietly assumed the first. A visitor from abroad had been landing on a single holding page with no menu and no way into the app, and a business there would have been asked at sign-up for a document it does not have.
What a foreign customer sees in the first minute
A business abroad decides in the first minute whether a site is meant for them, and one wrong detail settles it.
A visitor from outside the first country landed on a single holding page: no menu, no route into the app, nothing to tell them the product was for them. Had they signed up, the form would have asked for a trade licence they cannot produce, and the support line offered was a phone number in a city they do not work in. That is the shape of it for any business adding a country. A foreign phone number, a document someone cannot produce, or a date written the other way round is enough to decide them against you. The customers you already have, meanwhile, have to see nothing change.
What a customer in the second country sees now
A business in the second country reads its own terms from the first screen:
- amounts in its own currency, with its own sales tax and tax number instead of VAT and a trade licence;
- dates written the way that country writes them;
- support hours in its own time zone, and phone numbers in international form;
- questions answered by e-mail rather than through a phone line in another country;
- a sign-up that starts in that country, with no licence to upload and no code sent through a messaging app.
Why one country gets written into hundreds of places
The country was never a setting anywhere; it was written into hundreds of places at once.
Currency of every amount, the tax and what it is called, the company's registration, how dates and times are written, phone numbers, support hours and their time zone, the channel customers use to ask a question, the languages: each had quietly assumed one country. Fixing them one at a time for a second country leaves just as many places to fix again for a third. That is where the cost sits, not in the translation.
How we traced it
We went through every screen, message and page a client sees and listed what depends on the country. Then we counted the places in our software that simply took the first country for granted: 322 of them. That number settled the approach. A country had to become a setting of its own that every part of the platform reads, or we would be back in the same list later.
Why a website for a second country needs a country record
Each country is now a record of its own: currency, tax, company number, time zone, weekend and holidays, support hours, languages and site address. Opening a country became a switch and a page in our dashboard rather than a rebuild, and new work reads the country instead of assuming one.
The visitor's side follows a fixed order: their own choice first, then the address they came to, then where they connect from. A switch in the header changes it either way. Search engines and link previews are never moved by country, so every version of the site stays readable.
The second site is the whole site again, menu, app pages and chat included, with every sentence that spoke of the first country rewritten, in one language only. Before writing any of it we recorded 13 of the first country's pages exactly as they were, and every change since has had to leave them unchanged.
Our portal and our apps learn each account's country from the platform and keep no country rules of their own. An older version of an app that cannot show a second currency is never shown one; it offers the website instead.
The first country saw nothing change
We planned and built this over 12 and 13 October 2026: the country records and the dashboard page on the first day, the second site that night, and the portal, the messages, the sign-up and the apps on the second. Since 13 October the platform, the portal and the messages speak to each client in its own country's terms.
The 13 recorded pages of the first country are unchanged, and a client there reads exactly what they read before. App versions that know a second currency sign a business up inside the app; older ones send them to the website instead.
What you can check yourself
- Open your site from abroad, or ask someone there to open it, and read it as a foreign customer would: phone numbers, opening hours, currency and dates.
- Look at your sign-up form and ask whether it demands a document that only one country issues.
- Read your own e-mails and messages the way a customer in another country reads them, and see how the dates and times come out.
- Ask whoever looks after your site whether search engines are redirected by country, so that every version stays readable.
- Keep a copy of your main pages before a big change and compare them afterwards, so you can show your existing customers that nothing moved.
What to do next
Write down once every part of your business that changes with the country: currency, tax and its name, company number, time zone and weekend, support hours, languages, and how customers reach you. Decide the order in which a visitor's country is chosen, and give them a switch. Record the pages you have today before the second country's pages are written. Adding a country to a website or an app, and making the rest of your systems read it, is the kind of work our engineers do.
Questions people ask
Do I need a separate website for a second country, or can one site serve both?
One site can serve both, but each country needs its own pages and its own wording, and the country has to be a setting the rest of your systems read. In our own case the second country's site is the whole site again, on its own address, while the same software sits behind both. What matters less is whether it is technically one site or two, and more that nothing from your first country leaks into the second.
How should my site decide which country a visitor is in?
Choose in a fixed order: the visitor's own choice first, then the address they came to, then where they connect from. Always give them a switch in the page so they can correct it themselves. Never move search engines or link previews by country, because that hides one of your sites from them.
What should change at sign-up for customers outside my home country?
The documents you ask for, the phone number you offer, the support hours you display, the currency and the tax wording. In our own sign-up, a business outside the first country is no longer asked for a trade licence it cannot produce, and is no longer sent a code through a messaging app. It starts in its own country from the first screen.
How do I know adding a second country has not changed anything for my existing customers?
You keep something to compare against. Before building the second country's pages we recorded 13 of our first-country pages exactly as they were, and every change since has had to leave them unchanged. Keeping a copy of your own main pages before the work lets you do the same comparison afterwards.
What about customers using an older version of my app?
Let your own platform tell each app version what it can show, rather than teaching every version about every country. An older version of our app that cannot display a second currency is never shown one; it points the customer to the website instead. That way nobody sees a currency their app cannot render.