Translation is the last ten per cent, and the only part that can be fixed cheaply after launch. The rest lives in your schema, your checkout, your support rota and, increasingly, your legal obligations.
Localisation has seven layers, and words are the last one. The two that have to be right first are your data model — names, addresses, phone numbers, dates, money, time — and your payment rails, because both are architecture and both are expensive to change once you have customers. Pricing, legal obligations and support hours come next. Translation is genuinely important and genuinely last, and treating it as the whole job is the most common and most expensive mistake in this area.
The seven layers
The ordering is the argument. Most companies work up this list from the bottom — translate the site, adjust the tone, hire support, then discover in month four that the checkout does not accept the payment method half the market uses and the sign-up form rejects perfectly ordinary local addresses.
Working down from the top is cheaper, because layers one and two are decisions rather than tasks. Getting them right before you have data costs a design conversation. Getting them right afterwards costs a migration.
Localisation belongs in a product conversation long before it belongs in a marketing one.
The layer that lives in your schema
This is the least glamorous section of this article and the one most likely to save you money.
Every product carries assumptions from the market it was built in, and most of them are invisible until someone from somewhere else tries to sign up. Names that do not split into first and last. Addresses without a state or a five-digit postcode. Phone numbers whose length is not the length you validated. A date field where 03/04 means one thing to you and the opposite to your customer.
Two of these deserve their own emphasis because they cause damage quietly rather than loudly.
Money should never be a floating point number. Store integer minor units alongside a currency code. This is not a localisation nicety; it is basic correctness that becomes visible when you start handling more than one currency and rounding errors begin appearing in reconciliations.
Time should be stored in UTC with the user’s time zone kept separately. Every product that gets this wrong discovers it during a daylight saving transition, usually in a scheduling feature, usually in front of a customer.
There is a cheap test for all of this. Try to become your own customer in the market you are targeting: real name, real local address, a local card, a local phone number. Most teams find three of the eight problems in the first ten minutes, and the exercise costs an afternoon.
Payment rails decide whether the money arrives
This is the layer that produces losses you cannot see, because a customer who cannot pay the way they normally pay does not file a complaint. They close the tab, and your funnel records a drop-off you attribute to price.
Card penetration and preferred payment methods differ sharply between markets, and in several countries the dominant consumer method is a domestic scheme rather than an international card network. Bank transfer is normal in some markets and unusual in others. Instalment payment is culturally standard in parts of Latin America and southern Europe and rare elsewhere. Invoicing on terms is the default for B2B in several European markets in a way it is not in the US.
The practical rule: find out how people in that market actually pay before you build the pricing page, not after you launch it. Your payment provider can tell you, your first ten prospects can tell you faster, and either answer is cheaper than a quarter of unexplained checkout abandonment.
Pricing is not conversion
Taking your home price and converting it at the spot rate produces a number that is either implausibly cheap or accidentally expensive, and both are positioning failures.
Price against what the problem costs a buyer in that market, and against what the alternatives there cost. Then think about the shape of the price as well as the number — annual versus monthly, per seat versus usage, and what a purchase of that size normally requires by way of approval in that country. A price that requires procurement involvement in one market may be a manager’s discretionary spend in another, and that difference changes your sales cycle more than the number does.
Some of this is a legal obligation
Accessibility is the clearest example of localisation work that has stopped being optional. The European Accessibility Act applies to services provided to consumers after 28 June 2025, and the covered services include e-commerce and banking services alongside e-books, telephony, audiovisual media and passenger transport.[1][2]
There is an exemption for microenterprises providing services — fewer than 10 people, with annual turnover or balance sheet total of €2 million or less.[2] It is worth knowing about and worth not relying on. It is temporary by definition, since you intend to grow past it, and retrofitting accessibility into a shipped product is among the most expensive kinds of rework there is. Build it in while the product is small.
Alongside it sit the more familiar four: consumer law (returns, cancellation rights, how price must be displayed), data protection and data location, tax presented correctly on the invoice, and language requirements, which exist in more markets than most founders expect.
Support is a localisation decision
A first response that consistently arrives while the customer is asleep is a product problem wearing an operations costume. It produces churn that gets attributed to features.
Three questions settle most of it. What hours does this market expect a reply in? Which channel do they expect to use — email, phone, and messaging preferences vary more than people assume. And what language will the reply be in?
On that last one, be honest with yourself about machine translation. It is remarkably good now for understanding an incoming message and still obvious to a native reader in an outgoing one. Using it to comprehend is sensible. Using it to reply, without a human who speaks the language, costs you the credibility the product just earned.
A note on the statistic you have seen
Almost every article about localisation cites a figure along the lines of “76% of shoppers prefer to buy products in their native language.” It comes from survey work by a research firm whose clients are language service providers.
That does not make it wrong. Survey research commissioned within an industry is not automatically unreliable, and the direction of the finding is consistent with what anyone who has sold across borders observes. But it is worth knowing where a number comes from before you put it in a board deck, and worth noticing how rarely anyone repeating it says so.
A better basis for the decision is your own data. Look at where your traffic already comes from, where it converts worse than average, and where support tickets take longest to resolve. That evidence is specific to your product and nobody sold it to you.
How to sequence it without doing everything
- Before you enter a market: fix the data model, and find out how people pay. These are the two that are expensive later.
- As you enter: local pricing in local currency, the payment methods that matter, and the legal obligations that apply to your category.
- Once there is traction: support in the right hours, then content and proof from that market.
- Alongside all of it: translation, done properly by a person, starting with the pages and flows where money changes hands rather than with your blog.
Note what is not on that list: translating everything you have ever published. Localise the path to purchase and the path to help. The rest can wait until the market has told you it is worth the investment.
