Today, let’s look at when a company should start building a globalization strategy. It may seem easy to say,”’we’ll deal with it when we get there,” but waiting too long can limit both impact and profitability if global expansion becomes a goal down the line.
As discussed in our post Key Considerations When Generating Data Models, the issue with waiting too long is that foundational areas might be designed in ways that don’t work well globally. At that point, your company faces one of three options:
- Adapt the rest of the world to your existing model1
- Migrate to a new model
- Maintain two separate models (one for current markets, one for new ones)
Consider something as fundamental as storing customer names in a database. Without a global approach, adapting these foundational areas can cost up to 600 times more than if best practices were followed from the start. Companies don’t always have the resources to focus on this early, but following certain best practices from the beginning can make future scaling much smoother.
If resources for early adoption are tight, there are strategies that can help ease the transition later on.
The two core pillars: internationalization and localization
The two main areas of globalization are internationalization and localization.
- Localization is typically the area that can wait until you’re ready to enter a new market. However, this varies depending on your home market needs. For example, 19.1% of the U.S. population is Hispanic/Latino, many of whom prefer Spanish.
- Internationalization should be tackled early. Waiting until the last minute means going through all your code to make it work for new audiences – a process that can take years and still might not be bug-free.
If your team doesn’t have the bandwidth for early adoption, consider these solutions:
- Hire consultants, like the GILT Ninjas, or an external company to periodically review your code, flag potential issues, and set best practices for your engineering team to follow.
- Engage an external expert on a regular basis. This approach is more costly but keeps your code adaptable for new markets while ensuring best practices are met. Be cautious, however, as over-relying on an external vendor can lead to dependency.
- Bring in a dedicated in-house expert. This is the ideal solution. Even if the in-house role leans on external resources, it ensures that your best interests are maintained long-term and that your code is globalization-ready from day one.
With the right foundation, you’ll be set up for seamless growth when the time comes to expand.
Thank you for taking the time to read this! I hope you found it informative. See you in our next post!
- For example, if we have a model that stores only one first name, a middle name, and one last name to fit a U.S.-based format, we would adapt all the other formats of the world to this setup. However, in other cultures, it’s common to have multiple first names, no middle name, multiple last names, or even different name orders (like placing the last name first). While this might work initially, in the long run, it becomes a Pandora’s box, waiting to be opened. ↩︎