How do you judge localization ROI without a budget?

Every localization ROI template asks you for the same two inputs. What will this cost over the year, and what uplift do you expect. If you run a team with a localization line in its budget, both are answerable. If you are one person with a side of the weekend free, the first is close to zero and the second is a number you would be making up. globalize.now is AI-powered localization infrastructure, and this page is about what you do instead of filling in that template.

Three neighbouring questions already have pages and this one does not repeat them. Whether translated pages help you in search, and what has to be true technically, is does localizing your app help SEO. What the localization playbook earned when a team ran it, and what running it used to cost, is the growth playbook then and now. Whether this is a tactic one founder can carry to a finish is the sorting test. This page assumes you have decided it is worth a try and want to know how to judge the result.

Why does the ROI question break at this scale?

Because both halves of the calculation are missing, and only one of them is obvious.

The missing cost line is the one people notice. Agency ROI framing was built for a spend worth modelling: a per-word rate, a vendor contract, a localization manager's time, and a forecast of market revenue to set against it. Take the invoice away and the model does not get easier, it stops having a denominator.

The missing forecast is the one that does the damage. Nobody can tell you what your second language will return, because the published results do not agree with each other. They are not close. Two of the three cases below are solo operators who ran the same tactic and got outcomes that point in opposite directions, and both of them published their numbers, which is more than the category usually offers.

So the honest version of the question is not what is the ROI. It is what is the smallest test that would tell me, and what would I do if it came back flat.

What did the return look like when a team paid for it?

Large, slow to arrive, and attached to a standing vendor relationship.

The best-documented case in this category is still Smallpdf's, and it belongs to a vendor. As reported by OneSky's published case study for Smallpdf, re-fetched on 8 October 2026, monthly users over SEO rose by 60%, from 6 million in 2016 to over 9.5 million in 2017, over 70% of users were from non-English-speaking countries, and Thai, the most lucrative of three languages added during that work, saw its user base increase over 500% in traffic in one year. Smallpdf was in 17 languages when that work began. Read all of it as one vendor's account of one customer over one year.

The sentence that matters for an ROI question is not any of those. From the same source, re-fetched the same day: OneSky's automated solutions allowed Smallpdf to process translation requests for new features and site improvements within 1-2 days for all 17 languages, where the same work had previously taken weeks with freelance translators. That is the cost line. Not a per-word rate, but a vendor on the other end of a queue that opened every time the product moved.

Which is why the enterprise ROI model works there and not here. It is comparing a known recurring cost against a measured return. You have neither.

What does the return look like when nobody is funding it?

Uneven, and the average hides the whole story.

Ken Imoto translated his blog into four languages through what he describes as a cross-language LLM pipeline, hand-edited afterwards for register and locale. His GA4 figures, as published on dev.to and re-fetched on 8 October 2026, cover 22 days from 30 April to 21 May 2026: Portuguese 748 pageviews and 709 sessions, English 195 pageviews and 176 sessions, Japanese 27 pageviews and 29 sessions, Spanish 7 pageviews and 7 sessions. In his words: "That is Portuguese pulling roughly 3.8× English, 28× Japanese, and 107× Spanish on the same blog, same publishing cadence, same author."

Take that as a snapshot across four languages at one moment, because that is what it is. There is no before-and-after on the same content and no pre-localization baseline was published. His article counts differ by language, 26 in English, 25 in Japanese, 17 in Portuguese and 10 in Spanish, and he gives no per-article normalisation, so do not build one.

Spanish is the part worth sitting with. Seven pageviews in three weeks from ten translated articles, and he had expected Spanish to come second on speaker count alone. A single average across his four locales would have read as a clear win while one quarter of the work returned nothing. If you are going to run this, you need the per-locale view or you will not find out which bet lost.

What is the cost that actually bites?

Standing behind the translation, every time the product changes.

There is now a published case of somebody deciding that cost was too high and reversing. The site behind Field Notes #3 on dev.to, re-fetched on 8 October 2026, is a solo developer's self-described agent-run site whose blog is translated by an AI pipeline. He cut twenty-one languages to six. The cut landed on 24 September 2026, and as published it was an owner verdict rather than a traffic calculation. The retained set: English, French, Spanish, Russian, Chinese, Arabic. Everything else, naming German, Japanese, Portuguese, Italian, Vietnamese, Polish and a dozen more, stopped existing as files the same day.

His stated reason was quality. A bad translation reads worse than no translation, as he puts it, and the daily pipeline could not prove native quality across twenty-one languages at once. It could prove it across six.

That is the cost line for anyone without a localization function, and it is not the translation. It is the review you cannot delegate, in languages you cannot read, repeated on every change. It scales with the number of locales you keep.

His Search Console numbers are in the same post and they need their caveats attached rather than quoted clean. Over the trailing 28 days as published on 4 October 2026, the five kept locales drew 493 impressions and 6 clicks, and the deleted set, counting the twelve the report shows, drew roughly 850 impressions and 7 clicks. He flags the window himself: it straddles the cut, so part of it covers languages that were still live. The absolute volumes are six and seven clicks, which is too small to carry an argument in either direction, and roughly 850 is approximate as published, so leave it approximate. His own post says five kept locales while naming six retained, and we are not going to resolve that for him or derive per-locale figures from it.

What survives all of that caveating is one fact, and it is enough: deleted locales were still being found in search after they were cut, and the person who cut them did it for a reason that had nothing to do with traffic. His 7-day figures, post-cut, name a German page taking a click at position 2 and a Japanese and a Vietnamese page taking clicks too. Treat his headline, that the traffic barely noticed, as contradicted by his own numbers. That is his finding published honestly against his own framing, which is rarer than the numbers.

So what test can you actually run?

Two locales, picked from arriving demand, read per locale, with the exit planned first.

Pick from your own analytics, not from a list of speaker counts. Countries already sending you traffic while your product speaks only English are demand that arrived despite a barrier. That makes the barrier the variable you can move, and the one that costs nothing to look at. Imoto's pre-launch ranking was built on speaker counts and the data disagreed with every part of it.

Keep it at two. Not because the work is hard at five, but because the review is. The second case above is what happens when the locale count outruns the one thing nobody can automate for you.

Write down what a loss looks like before you start, and what you will do about it. Both published cases here contain a locale that returned nothing. If your plan has no branch for that outcome, it is not a test.

Then give it a quarter. The Smallpdf figures are year-over-year, the dev.to snapshot is 22 days with no baseline, and neither of them tells you anything about week two.

And keep the reversal cheap. That developer's sixteen deleted locales stopped existing as files the same day he made the call. If removing one would cost you a month, you have not built a test, you have made a commitment.

What does it cost to run that test now?

The recurring part is what changed, and it is the only part the ROI model cared about.

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. Push jobs translate new catalog units as they appear afterwards, and what you get back is standard JSON or PO, the same formats your i18n library already reads. Nothing about your runtime, framework or deployment changes, which is also what makes removing a locale a file operation rather than a project. The developer and vibe coder pages cover the setup.

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

What we cannot tell you yet

We do not have our own numbers, and we are not going to imply them.

Two customer case studies are being measured now. Until they are finished and dated, every figure on this page belongs to somebody else, carries whose it is, and carries the date it was last checked. A localization ROI figure with no source and no date is the kind of number that gets quoted back at you for a decade, and this category already runs on a 2017 vendor page.

Where this leaves you

Stop trying to price the decision and start trying to make it cheap to be wrong about. Two locales from your own traffic, a quarter of data, a per-locale read, and a removal you could do in an afternoon. If you want the version of this with our own customers' numbers in it, that post does not exist yet, and it will carry dates when it does.