The commercial conversation around international expansion usually starts with opportunity.
How large is the market? Who are the competitors? What will it cost to enter?
Those are important questions.
But there is another question businesses increasingly need to ask:
Is the software actually ready to operate there?
A platform that works perfectly in one country may contain dozens of assumptions about where its users live.
Map the differences before writing code
Before opening a ticket called “Add Germany”, work out what Germany actually changes.
That might include:
- language;
- taxation;
- payment methods;
- currency;
- addresses;
- communications;
- hosting;
- privacy requirements;
- contractual requirements;
- support processes.
Some changes are cosmetic.
Others affect the data model.
Knowing which is which before development starts avoids a pile of country-specific exceptions later.
The original version of this article focused on market research, intellectual property and communicating in the customer’s own language. Those questions still matter, but the software underneath the expansion needs just as much consideration.
Audit the data model
Data models often contain hidden geographical assumptions.
A UK-focused system may assume:
- postcodes look British;
- telephone numbers follow a UK format;
- county is a useful address field;
- prices are GBP;
- dates are displayed day/month/year.
None of those assumptions necessarily survives international expansion.
Look particularly closely at user profiles, addresses, telephone numbers, money, dates and identifiers.
A schema migration after millions of records exist is considerably less entertaining than designing the field correctly at the beginning.
Decide what “country” actually means
Applications regularly need several different geographical concepts.
The customer’s country may be different from their billing country.
Their preferred locale may not match either.
Their current physical location may be somewhere else entirely.
And the market whose rules govern a transaction may be different again.
Trying to represent all of that using a single country field tends to end badly.
Model the concepts you actually need.
Treat timezone as first-class data
International systems expose timezone bugs very quickly.
Reports move a day.
Notifications arrive at the wrong hour.
Scheduled tasks run too early.
Daylight-saving transitions produce unexpected results.
Store timestamps consistently, retain the user’s or organisation’s timezone where necessary and only convert for display or explicitly timezone-dependent business rules.
Most importantly, define what business language such as “today”, “midnight” and “end of month” actually means.
Review payments and pricing
Can the existing payment provider operate in the target market?
Which payment methods do customers expect?
Are prices converted dynamically or configured independently for each market?
What happens when a payment is refunded after exchange rates have changed?
Which currency does finance reconcile?
International payments quickly cross the boundary between frontend formatting and core business logic.
Get finance and engineering into the same conversation early.
Understand where data is processed
International expansion can alter which privacy, regulatory and contractual requirements apply.
Engineering needs to know where customer information is stored, which vendors process it and which regions data passes through.
That does not mean developers should become lawyers.
It means the legal and compliance decisions need an architecture capable of implementing them.
The worst time to discover that a customer contract requires a particular data location is after the platform has been built around a provider that cannot supply it.
Check your communications stack
Email tends to work internationally until it doesn’t.
SMS is even more variable.
Sender IDs, telephone formats, deliverability, templates and provider coverage can all differ by country.
Every transactional communication also needs localisation:
- account verification;
- password resets;
- invoices;
- alerts;
- push notifications;
- support messages.
Don’t localise the product and leave the operational communication in English.
Measure the new market separately
Once the product launches, you need to know whether it actually works.
Can you separate latency by region?
Error rate by market?
Authentication failures?
Payment failures?
API response times?
Email or SMS delivery?
A platform can look healthy globally while a particular region is having a terrible experience.
Regional observability turns “customers in Spain say it’s slow” into something engineers can investigate.
Plan the rollback
International launches are still software releases.
Use staged rollout where practical.
Feature flags, controlled account enablement and incremental traffic allow problems to surface without immediately affecting the entire new market.
And establish what happens if something fundamental goes wrong.
Can the feature be disabled?
Can transactions safely be stopped?
Can users be returned to the previous experience?
International expansion shouldn’t require an all-or-nothing deployment.
Let local users break it before customers do
The original Jublo material emphasised communicating in the language of the audience rather than relying on literal translation.
The same philosophy applies to the whole product.
Put the software in front of people who actually live in the target market.
Ask them to register, pay, enter an address, request a password reset and complete the important workflows.
They will find assumptions your development team didn’t know it was making.
International expansion is a platform capability
The first new country will probably involve work.
The useful measure is what happens when somebody asks for the third, fourth and fifth.
If each new launch requires another collection of hard-coded exceptions, the platform isn’t becoming international; it is accumulating technical debt.
Build the mechanisms once.
Then let markets become configuration rather than rewrites.