This means making sure your product supports time zones, currencies, date and number formats, and languages holistically. Even if you’re not ready to support users in other languages, it’s a small upfront cost to externalize your labels and text strings at the beginning of building your product, versus a very high cost to retrofit this into your product later.
As one of the original product managers at Salesforce.com, I learned this lesson the hard way. We already supported users in eleven languages, and it really wowed prospects to see the entire app change seamlessly from English to Japanese with one click. But in early 2004 when Marc Benioff wanted to allow a big customer to change the name of our standard tabs (accounts, contacts, leads, etc.) to any term they wanted, this seemingly simple feature spiraled into a localization monster because we had to support this new capability across every language. Allowing customers to rename standard tabs became a huge project that touched every user-facing page of the application. In order to retrofit customized and localized terminology into our product, we had to externalize all labels and text out of the page, add a “Translation Workbench” feature, and rewrite every line of copy on our screens into a structure that could be accurately translated across every language.
The moral of this story: Your code base will only keep growing, so even if you’re an established SaaS product, if you want to serve global customers, it’s best to tackle today what will just be more expensive to tackle tomorrow.