Product & reflection / Lessons learned
Should you internationalize your SaaS at launch?
Planning for internationalization can make sense, but translating into six languages from day one does not guarantee visibility or customers.
When building a SaaS, offering several languages seems like a great idea. More languages means potentially more users, right?
That is what I thought while developing Iconise, my AI-assisted icon creation app.
So I prepared the application for six languages: French, English, German, Spanish, Brazilian Portuguese and Japanese.
But looking back, I find myself asking: does a technically accessible feature necessarily make a good product decision?
The same promise
Six languages, one product idea.
Translation opens the door to more people. It does not replace the work of understanding each market.
Internationalization has never been more accessible
With frameworks such as Next.js, libraries such as next-intl and AI-assisted translation tools, internationalizing an application has become relatively straightforward.
There is still work to do, of course: translations, error messages, emails, regional formats, testing… But the technical barriers have come down considerably.
The problem is that this ease can encourage us to build features without really questioning their value.
Just because we can do something quickly does not necessarily mean we should.
On Iconise, the complexity went beyond translation
Iconise generates content using artificial intelligence. I therefore had to distinguish between two settings:
- The interface language, chosen by the user.
- The language of the generated content, associated with each project.
A French user can work on an application intended for the Japanese market without having to switch their entire interface to Japanese.
This distinction is useful for the user experience, but it adds complexity.
01 / Try it yourself
Two languages, two purposes
Change the two settings independently: the interface guides the user, while the content targets its own market.
Your icon is ready
Generated creative direction創造的な勢い
Illustrative example. The working language and the project language remain independent.
With six languages for each setting, that means 36 possible combinations.
I checked twelve of them in an initial round of testing that still needed to be taken further.
02 / The hidden surface
Six times six.
One language for the interface, another for the content: six times six combinations to maintain and check.
| ↘ | FR | EN | DE | ES | BR | JA |
|---|---|---|---|---|---|---|
| FR | ||||||
| EN | ||||||
| DE | ||||||
| ES | ||||||
| BR | ||||||
| JA |
French / Japanese — highlighted cell in this visualization.
Illustrative distribution of the twelve checks: the pairs actually tested are not detailed in this article. Select a cell to explore the possibilities.
And that is just one example. Every new feature also means maintaining translations and checking their consistency.
Six languages does not mean six markets won
This is probably the most important point.
Translating your application into German does not mean German users will automatically discover it.
Even with localized URLs, hreflang tags and a multilingual sitemap, there is still work to do on SEO, acquisition and, above all, the value proposition.
You need to understand what users in each market are looking for, how to reach them and what might convince them to use the product.
Internationalization opens the door to new markets. It does not guarantee that you will find customers there.
Measure demand rather than adding more languages
To assess whether this decision makes sense, I think we need to look beyond the number of languages available.
The journey looks more like a funnel than a simple switch:
Beyond translation
From visibility to customers
A localized version opens the journey. It is not enough to move users all the way to a purchase.
- 01Visitorsdiscover a localized version
- 02Sign-upstake the first step
- 03Projects startedtest the value of the product
- 04Paying customersconfirm sufficient value
Conceptual diagram: the widths do not represent actual rates.
A few indicators can be useful:
- Traffic from the different language versions.
- The number of sign-ups.
- The percentage of users who actually start a project.
- The conversion rate to paying customers.
By comparing these figures with the countries and languages involved, we can start to identify markets with real potential.
Of course, these numbers do not tell the whole story. They can show where users drop off, but not necessarily why.
So, should you internationalize from the start?
My position is quite simple: plan the technical foundations for internationalization from the start, but do not necessarily translate the entire application immediately.
Starting with one or two languages and expanding gradually as demand emerges can be a more reasonable strategy.
On the other hand, for a product that is naturally international, offering several languages at launch can be entirely justified.
03 / Your starting point
Should you internationalize?
Three questions to turn an intuition into a decision grounded in context.
Answer all three questions to see a possible direction.
So I do not consider my choice on Iconise a mistake. But I will need to measure its impact before I can say it was a good investment.
Ultimately, the question is not how many languages our application can support, but how many genuinely add value for users and the product.
What comes next needs to be measured.