More users by adding languages: what the growth playbook cost then, and what it costs now

Translating your product to get more users is one of the oldest growth tactics there is, and it has exactly one widely quoted case behind it. As reported by OneSky's case study for Smallpdf, re-fetched on 29 September 2026, monthly users from search rose 60%, from 6 million in 2016 to over 9.5 million in 2017. globalize.now is AI-powered localization infrastructure, and this page is about the half of that story nobody repeats: what running the play took at the time, and what it takes now.

This is not a page about making translated pages rank. That question is answered separately in does localizing your app help SEO, which covers whether it helps and what has to be true technically. This page is about what it earned, what it cost, and who is still running it.

What is the localization growth playbook?

Ship your product in more languages, let search engines index each one, and collect demand from queries your English-only pages were never eligible for.

That is the whole idea, and it has been common knowledge for a decade. Every version of the advice ends the same way: and then you will need a workflow, a vendor and translators. That is the sentence where a solo founder closes the tab, which is why a tactic everybody agrees with has so few finishers.

What did the playbook actually earn?

One company's reported results, and they are worth reading precisely because they are the only ones this specific.

Everything in this section comes from a single source: OneSky's published case study for Smallpdf, re-fetched on 29 September 2026. It is a vendor's account of a customer's results, not a measurement we ran and not one we have independently verified.

As reported there:

• Monthly users from search rose 60%, from 6 million in 2016 to over 9.5 million in 2017.
• Over 70% of users came from non-English-speaking countries.
• Thai grew fastest, with the user base there up over 500% in a single year.
• The product ran in 17 languages, with translation requests for new features turned around in one to two days.

Read those as directional, not as a forecast. One company, one vendor telling the story, one year, and a product (file conversion) whose demand barely depends on the language a user thinks in. Your own product may be more language-bound than that, or less.

The number worth sitting with is not the 60%. It is the 70%. A company whose interface and marketing began in English ended up with most of its users somewhere else, and only found that out after it stopped shipping in English alone.

What did running it cost in 2017?

Not a one-off invoice. A standing relationship and a loop that never closed.

The same case study describes the before state as freelance translators, and the after state as an outsourced vendor turning new feature strings around in one to two days across all 17 languages. Note what is being sold there: the speed of the loop. A one-to-two day turnaround is only a selling point if the default was slower, and it tells you the loop ran every time the product changed.

That is the real cost, and it is not money. Every new feature's strings became somebody's job, permanently. Shipping a button meant shipping a translation request. A founder with no localization function reads that, agrees with the strategy, and does nothing — correctly, because the strategy as described was not available to them.

Is anyone running this playbook today?

Yes, inside this category, at a scale most people have not noticed.

Localazy runs a version of the same idea as a page matrix rather than a translated product. A sitemap fetch on 28 August 2026 counted 757 conversion pages and 1,705 language-pair pages, roughly 14,000 indexed URLs in total. A SpyFu pull on 23 September 2026 put 4,859,220 in summed US monthly search volume across its top 500 keywords.

Worth recording for two reasons. First, the play is live in this category now, not a 2017 artefact. Second, that particular shape of it is an engineering project with a content plan attached — thousands of generated pages is a build, not an afternoon. Do not read this paragraph as advice to go and make 14,000 pages.

Why does every version of this guide stop in the same place?

Because it was written by people who had a team, for people who had a team.

The tactic is not a secret and never was. What was never solved is the part after the decision: the strings keep arriving, the product keeps moving, and somebody has to keep the locale files honest. Tooling in this category grew up serving localization managers, so the advice assumed one. That assumption is doing all the work in every guide that ends at "and then you'll need a workflow".

The interesting part of 2026 is not that the tactic got better. It is that the unstaffed version of it became possible.

What does the same playbook cost now?

The translation loop stops being the project.

globalize.now converts a codebase once, in the in-app connect flow. That conversion is a single operation, not something that runs on a schedule. After it, push jobs translate new catalog units as they appear, and the files you get back are standard JSON or PO, the same formats your i18n library already reads. Nothing about your runtime, your framework or your deployment changes.

What that removes is the recurring job, which was the actual barrier. The developer and vibe coder pages cover the setup itself, and there is more on why this work moved into the development loop in localization moving upstream.

Pricing is on the pricing page and this page is not going to paraphrase it.

What we cannot tell you yet

We do not publish our own numbers for this, and we are not going to imply them.

Two customer case studies are being measured now. Until they are done and dated, everything on this page is somebody else's result, labelled as such. That is a deliberate standard: a growth claim without a dated, checkable source is exactly the kind of number that gets quoted back at you later, and the category already has plenty of those.

How do you decide whether it is worth it for your app?

Start with your own analytics, not with a market-size list.

Countries already sending you traffic while your product speaks only English are the strongest signal available, and it is free. They are demand that arrived despite the language barrier, which means the barrier is the variable you can move. Rank by that, add two languages, change nothing else, and give it a quarter.

If the answer comes back no, you have spent a connect flow and a quarter of data to find out. That is a cheaper way to be wrong than the 2017 version, where finding out meant hiring for it first.

Where this leaves you

The tactic has not changed since 2017. The part of it that required a team — keeping a growing set of strings translated while the product moves underneath them — is the part that is now automated. If your analytics already show people arriving from places your product does not speak to, connect the repository and start with two languages.