Photo by NASA on Unsplash

Ask Slow Growth #2

---

On Platform Internationalisation

by Nuno Simaria,
Chief Technologist at Slow Growth
27 Jan 2022

---

7 mins reading time

Ask Slow Growth is a periodic rumination on technology related trends. It offers opinionated answers to well-thought questions posed by our partners. The goal of this publication is not to state a definitive answer but to approach topics in an exploratory fashion, in order to provide material for reflection to our readers. You can your questions to: ask@slow-growth.com.

Question

Sarah Pimental Abrantes, VP Engineering at TIER asks: “What are the crucial things to have in mind when taking a platform from a local to global scale?”

Answer

The right answers vary on a case-by-case basis but there are common questions we can ask. The scenario is a recurring one: a young tech start-up becomes successful in their original market and is now looking to expand its operations. Technical questions soon arise about how to adapt the existing platform¹ to new market² needs.

Architectural considerations

Broadly speaking, there are three paths to choose from:

1. Fork the platform – ‘forking’ i.e., duplicating the codebase and infrastructure and creating a new copy of the platform to serve the new market is, in theory, a possible path forward. However, it is highly discouraged for many reasons, such as duplication of engineering efforts, loss of synergies across markets, and loss of benefits from economies of scale, to name a few.
2. Expand the existing platform – sometimes, building appropriate localisation and internationalisation capabilities onto the existing platform will suffice. Adding support for multiple languages and enabling multiple currencies may be enough to operate successfully in a new market. This means no duplication of code or infrastructure – the existing platform and codebase absorb all the new traffic and business.
3. Allow for configurable instances – scenarios where one expects a higher degree of variability (and/or user segregation) across markets may be better approached by allowing for multiple instances from the same codebase to be spawned, each configured to serve a specific market/brand, while the core business logic and flows remain consistent across markets. Materially different consumer habits, alternate brands, diverging operational setup between geographies, may be better approached by allowing for multiple instances from the same codebase to be spawned, each configured to serve a specific market, while the core business logic and flows remain the same across all markets.

Option 1 is simply a no-go, from a point of view of software development best practices and maintainability. Which leaves us to position ourselves somewhere between options 2 and 3 which can be considered opposite ends of the same spectrum.

How many markets in how little time?

The expected cadence of market expansion informs how much effort can be spent into bootstrapping a new country. An expansion roadmap extending to many regions in little time suggests systems need to be highly configurable upfront. For example, if you launch one new market per year you can probably afford some manual work in order to fully launch this new instance. Whereas, if you launch a new market every week, you need a highly automated process to be in place.

A slow-paced expansion roadmap allows organisations to introduce configurability as they expand and learn from each new market. It also avoids investing up-front precious engineering capacity in accommodating expansion scenarios that time will prove to be unnecessary. Whenever possible, a conservative approach, experimentation-based, will allow businesses to reap more benefits in the long run, by compounding learnings into new markets from the start.

Lastly, consider that a realistic launch scenario will require a couple of weeks, if not months, where you will want to guarantee that your platform performs well in the new market. It is wise to plan for that inevitable long-tail of maintenance, therefore increasing your chances of success in each market you launch, rather than cramming new launches one after the other, without the chance to ‘iron out’ quirks and issues that inevitably come with introducing complexity in a running platform.

What localisation and internationalisation features do I need to build?

Any arbitrary list of features would fall short for simplistic, incomplete or, more likely, both. Instead, a short list of questions is provided in this article’s Annex which can help technical teams flesh out the right backlog for your global expansion goals and have the right discussions ahead of time.

The questions in the Annex serve as examples for the type of exploratory discussions that should take place when preparing for platform internationalisation. There are thousands of other questions that can and should be asked. Its answers will inform a backlog of tasks to be done and features to be built before or as the company expands, i.e. your expansion backlog.

Prioritising your expansion backlog

Part of your expansion backlog will need to be delivered before launching your second market. But most of them won’t. Most of them won’t be hard requirements until you launch your 5th or 10th market so you are free to tackle them at a later date.

Conversely, you are now more likely to identify those business requirements that, if dropped, will allow you to have a new market-ready system earlier. For example, you opt to launch a lead collection page in the new market, before the launch of your full-fledged product, increasing your chances of success this way.

Some features will unlock several new markets. For example: you are able to operate across all of Europe without a 24/7 NOC team³ in place. But, if you were to expand operations to Southeast Asia or Oceania, it would be wise to count on this capability. Therefore, you’d plan to establish a 24/7 NOC team just before you’d enter your first market in that region.

Conclusion

Once you build up your expansion roadmap, by understanding the size of the challenge for your very specific case, there is a lot of value in synchronising business roadmap and technical roadmap. By iterating on these, in the right steps, you are able to expand your business following the fastest possible path by leveraging a timely delivery of new features into your platform.

§

Annex

Below follow some examples of exploratory questions which will help scope and narrow down your expansion backlog.

Language & Culture

• What languages will you serve in each market?
• If you have to serve the same language in different markets (for example, English in the UK vs English in Canada), will you use the same copy?
• How will you find high quality translations?
• Are you able to maintain good copy across all languages with minimal engineering involvement?
• Real world information, like addresses, phone numbers and payment methods are partitioned differently across countries and tend to have detailed validation rules. How will you manage this?

Finance & Payments

• What currencies will you accept in each market?
• Will you have to reconcile with a global finance account and, if so, how will you?
• Some markets have a high adoption of niche payment methods (which means success will only come with being compatible with said payment method). Can you integrate new payment methods
• with low effort? Can multiple payment methods and gateways co-exist for the same market?
• Will users be able to move across markets with the same account? If so, what does that mean for their payment methods and credentials? What about debt collection/dunning?
• Some countries define taxes on a regional basis which means different tax schemes for the same country (a many-to-one relationship). Can you accommodate this scenario? And, if not, will you need to?

Data & Infrastructure

• Will you have centralised data storage in one point of the globe or will you need to distribute your core data-sets for lower latency with end users?
• In case of the latter: is the performance improvement worth the additional operational complexity?
• Does your planned setup satisfy current regulations? Existing data privacy laws differ from region to region, and tend to change (likely becoming stricter) over time.
• Time and date change depending on location. How will you manage server vs. user time and how will you communicate with users at times that are suitable for them?
• Do you have a NOC team in place? In the event of a technical incident, can you respond in a timely fashion 24/7/365?

§

Notes