The 5 things we’ve lived by to create a truly international business from Day One
If you’re building a startup, you have a LOT of decisions to make early on. Most of them will be wrong and that’s OK. You learn from them and move on.
But when it comes to attracting markets beyond your country’s borders, you have to make the right decisions from Day One.
This is especially true if your home market is not the United States or any other English speaking country.
I’ve learned that the hard way with my first startup affinitiz. affinitiz was one of the very first social networks. (Mark Zuckerberg was still in high school to put things in perspective.)
It was launched in 2001 and was built as a French-only business. The website was in French, the app was in French, our PR was targeting French media, and so on.
As a consequence, it was constrained to a small, limited market (France) and it never became big enough to survive.
After 5 years, it had 400,000 registered users in France. I have no doubt that had it been an international business from Day One, it would have had at least 10 times that and would have been a valuable business.
If I had reached that 4 million registered user mark in 2006, I would have sold my company and made millions.
But instead, as a French-only business, affinitiz made only $150,000 in annual revenue. I shut it down in 2009.
My current business, Agorapulse, has users in 170 countries and 14,300 cities around the world.
It also generates more than $3.3M in annual recurring revenue and is profitable.
Only 20 percent of its revenue comes from France. If I had built Agorapulse the same way I built my first startup (French-only), it’d be dead by now.
Doing the right things to make sure your startup is truly international can make or break it.
Here’s what I’ve learned from doing it right with Agorapulse.
1) Use English as your working language for EVERYTHING
If English is not your native language, deciding that it should be your working language is no small commitment.
But think about it. Language is everywhere: your code, naming policy, website, app, your support content, emails, etc.
If you want to grow a global business, you’ll have to assemble a global team right away. Note: Most of them won’t speak your native language.
If you start building your business in your native language (say, French) and, two years down the road, you hire a native Spanish speaker who doesn’t speak a word of French, you’re fucked. (Pardon my French there.)
If you launch your website in French (or any other language that isn’t English) and two years down the road you’re ready to go international, your website will only have built authority in your native language, and none in other languages. Good luck with that.
Long story short: You HAVE to do everything work related in the only universal language there is — English.
For many founders, it’s hard (and certainly not intuitive) to put aside your native language and use a “foreign” language in everything you do.
But it’s the ONLY way to build an international business. If you start building your app, website, support doc and so on in a language that’s not English, you’ll create roadblocks that will very quickly become way too hard to overcome.
2) Localize everything (and watch your words)
Localize, localize, localize. This is especially true for your code and your app interface. Every word, every sentence, tool tip, and button has to be a language variable.
It’s also true with your website.
Sure, it’s time consuming at first, but it will soon become a lifesaver as you start adding more languages to the mix.
It’s a discipline and it’s not always easy to do, but it’s worth it. Otherwise, you get a hodgepodge of languages on your page — which isn’t impressive to anyone. Here’s an example from Hootsuite where French and English words are mixed up on the same page.
The ability to uncorrelate the code from any given language will also allow you to use translation software such as Webtranslateit and let your marketing / product teams manage translations on their own. Your tech guys will save time (and headaches) and your product / marketing teams (or localization team as you grow bigger) will have the flexibility they need.
Localization also plays a role in the UI of your product or website.
As I mentioned earlier, English should be your working language. So when your UI/UX guy works on screens, all the wording should be in English.
I’ve learned the hard way that English has much shorter words or sentences than any other language (well, at least, French, Spanish or Portuguese, the three other languages we use).
For example, “Moderation rules” will become “Règles de modération” in French and, all of a sudden, that button where all the text fits in one nice line in English looks a doesn’t look as nice in French.
In English:
In French:
Spanish and Portuguese looks very similar to French in terms of length and how it impacts UI.
When you design your product UI or your website in English and expect to localize them in other languages down the road, keep that in mind.
Like with this menu on our app, it looks good in English:
But since “ads comments” is a much lengthier phrase in Spanish, it falls beneath the navigation bar and loses any dropdown menu functionality.
Key takeaway: leave some UI breathing room whenever you can!
3) Hire native speakers
Now that you’ve localized your app and website and you’ve begun creating your content in English, you’re ready to localize EVERYTHING.
In the early days, you’ll likely have a small team with no native speakers.
You’ll be tempted to work with translators to fill in the gaps. When you search on Fiverr or Upwork, it looks easy: there are a LOT of people who claim they can localize / translate your content. There are even companies that specialize in localization jobs.
I’ve tried them all. Trust me when I say localization agencies/companies and freelancers don’t work.
It’s a tall task for these outsourced workers to know your jargon, ecosystem, and product. The level of onboarding, proofreading, and micromanaging these people unfamiliar to your business is overwhelming.
It’s MUCH faster and easier to have your localization capabilities in-house. That’s what we’ve done by hiring native speakers in English (in Ireland and the U.S.), Spanish (in Mexico), and Portuguese (in Brazil).
The awesome thing about having native speakers embedded in your team (as opposed to external service providers) is that they learn your product, ecosystem and jargon along the way. After 4 to 6 months, they know everything they need to know to do their job.
As localization needs rarely constitutes a full-time job, these team members can also help the company by providing customer support, giving demos to prospects, and helping expand your business in countries that speak their native language.
A win-win to me — because localizing your app and website is not enough to grow.
Growth will only occur if you offer the whole stack in their own language:
- website
- content
- app
- support
- sales
Just to illustrate, we’ve offered our website and app in Spanish and Portuguese almost from Day One (2013). For 2 years, the MRR from Spanish and Portuguese speaking countries remained painfully low.
But look at what happened after we hired our first full-time Spanish speaking team member:
And what happened after we hired our first Portuguese speaking team member:
You get the point, right?
4) Consider a remote (or semi-remote) organization
Hiring native speakers on your team can be challenging in two ways:
- It’s a bigger financial commitment.
- It can be hard to find native speakers of your targeted languages if you need them locally in your office.
The solution we’ve found to these two challenges is to hire our native speakers remotely. That’s actually the reason why we’ve become a “semi remote” company. Read more about our story here:
This solution has worked great for us.
First, it’s MUCH easier to find native Spanish speakers in Spanish speaking countries!
Who would’ve thunk it? :)
Same goes for Portuguese and English. If we had to hire them in Paris, our “home”, we’d have a hard time coming up with enough great applicants.
Benefit #1: You have more opportunities of hiring not only native speakers, but great team members!
When you go beyond the confines of your headquarters, you open up the pool of potentially great coworkers. Think of other cities around the world with great talent pools — with a remote or semi-remote approach, the talent in those areas is within your reach.
Benefit #2: You’ll find more affordable resources if your remote team members live outside of San Francisco, New York, Paris, London or other major “western” big city. Opening positions that can be held by people living in places where the cost of living is cheaper helps a lot with the cost. That difference gets even bigger if you can hire people in countries where the cost of living is cheaper than yours.
It’s obviously not a key factor, but in the early days, when every penny counts, the ability to spend 50% less on a resource just because her cost of living is 50% less than yours is a great win/win.
5) Deal with the friction more effectively
Everything in a multilingual company is much more complicated, takes more time, and brings more challenges than if only one language is used.
And startups don’t want additional friction that will consume more of its already scarce resources. I get it.
But it’s only true if you do everything in all languages from the start.
The best way to deal with that friction is to always start everything with one language — English — and then test, iterate, and measure for as long as necessary until you get to a state or a process that works well. Then, and only then, do you localize.
For example, our support knowledge base was offered only in English for a loooong time. When it got to a point that we wouldn’t have to change it too much, we localized it.
When we run ads, we always test and iterate on one language and then localize. Sometimes we even just use English on our ads, even if we target worldwide.
In a nutshell, we don’t always localize everything. We try to reduce the friction as much as possible.
Get the right tools
If you’re going to run a remote (or semi-remote) team like I’ve suggested, you’ll need tools to work efficiently. I’ve shared most of the tools we used in this blog post:
Here are a few key ones that will work well for your from-Day-One international business.
Webtranslateit is our go-to tool for localizing our app. It makes the process straightforward and you’re guaranteed not to let anything slips through the cracks.
Multisite Language Switcher (WordPress plugin)
We’ve chosen to use a multisite WordPress install for multiple reasons that go beyond the topic of this post. Long story short: Having only one WordPress instance with a language plugin didn’t offer us the flexibility we needed.
The Multisite Language Switcher plugin, however, allows you to switch from one language to the others across your multisite Wordpress setup for any page or blog post. It makes localizing each page and blog post pretty straightforward too.
We love Support Hero for many reasons. Most of them are detailed here:
One of Support Hero’s greatest features is that if offers multilingual support and makes it easy to create different versions of your support documentation in different languages and see what has been translated and what has not (and needs to be done).
If your startup is based in the U.S., you can wait longer to go international, but make sure you build the foundation for your future expansion, like localizing your code and website.
Your turn! Do you have a global business? Any tip you’d like to share?
Or are you struggling to go international and would like more details about how we’ve done it? Just ask!
