Software Localisation: How to Adapt SaaS, Mobile Apps, and Desktop Products for Global Markets

Software localisation is the process of adapting a software product so it works naturally for users in a specific language and region. It covers the user interface, on-screen text, date and currency formats, legal compliance, payment methods, and the overall user experience. Whether the product is a SaaS platform accessed through a browser, a mobile app downloaded from an app store, or desktop software installed locally, the goal is the same: make the product feel like it was built for that market.

This goes well beyond swapping English strings for translated ones. A localised product accounts for how people in that market actually read, navigate, pay, and make decisions. A fintech app operating across 31 European countries needs to rethink its onboarding flow for German users (who expect detailed explanations and visible trust signals before handing over financial data) rather than translating the UK version word for word. A travel app expanding from the Netherlands into France needs to understand that French travellers do more domestic travel, which changes the kind of content and features they’ll engage with.

We’ve worked on software localisation projects for apps including what3words, Polarsteps, Curve, and previously REKKI. Each of these products needed a different localisation approach depending on the platform, the target markets, and how frequently the product ships updates. Later in this piece, we break down what each of them did and why, because the specifics matter more than the theory.

Anywhere you look, software businesses of all sizes are investing heavily in software localisation. From small businesses with limited budgets to large corporations with expansive teams, localising software is now regarded as a key part of taking a software product to a global market.

In this article:

What software localisation covers

Software localisation touches every part of the product that a user sees, reads, or interacts with. The specific elements depend on the product type, but the core areas are consistent.

Interface and on-screen text

Every string visible to the user needs to be translated and adapted: navigation menus, buttons, form labels, error messages, tooltips, onboarding flows, notification copy, confirmation screens. This is the most obvious layer, and also where poor localisation is most immediately noticeable.

But “adapted” is doing heavy lifting in that sentence. A button that says “Get started” in English might need a longer equivalent in German or Finnish, which means the UI layout needs to accommodate text expansion. IBM’s globalisation guidelines note that English-to-German text expansion can reach 35%. If the interface wasn’t internationalised properly during development, these layout issues become expensive to fix retroactively.

This is particularly visible on mobile, where screen real estate is tight. A label that fits neatly in English at 12 characters might need 18 in Spanish or 22 in German. If your UI grid is rigid, that string gets truncated, which means your German users see “Einstellun…” instead of “Einstellungen” and have to guess what the button does.

Regional formats and compliance

Date formats, time zones, number separators, currency symbols, measurement units, address fields, phone number formats: all of these vary by region and need to be handled correctly. A user in France expects to see 1 200,50 € while a user in the US expects $1,200.50. Getting this wrong creates friction. Getting it wrong in a fintech or healthtech product creates legal risk.

Compliance goes further than formatting. Data privacy laws (GDPR in Europe, LGPD in Brazil, POPIA in South Africa), consumer protection regulations, accessibility standards, and even content restrictions differ by jurisdiction. A SaaS product handling payment data in Germany faces different regulatory requirements than the same product in the UK, even post-Brexit. Software localisation needs to account for all of this, and your legal team needs to be in the loop from the start rather than reviewing a finished localised product at the end.

App Store and marketplace presence

For mobile apps, localisation extends to the app store listing: the title, subtitle, description, screenshots, preview videos, and keyword fields. This is where App Store Optimisation (ASO) meets localisation. A translated listing won’t perform as well as one that’s been keyword-researched and written for the local market’s search behaviour.

For SaaS products, the equivalent is localised landing pages, pricing pages, and sign-up flows. The conversion path from “I found this product” to “I’m signed up and paying” needs to work in the target language, with locally appropriate trust signals, pricing structures, and payment methods.

Help content and customer support

Knowledge bases, FAQs, in-app help, chatbot scripts, and email templates all need localisation. Users who hit a problem and can’t find help in their own language are much more likely to churn (more on that below).

This is an area where companies often cut corners. The product itself gets localised, but the support content stays in English. The result is a jarring experience: everything works in your language until something goes wrong, and then you’re on your own.

What needs localising, by product type

How software localisation relates to translation and internationalisation

These three terms come up constantly in the same conversations, and they’re frequently confused. Here’s how they sit in relation to each other.

Translation is the transfer of meaning from one language to another. It operates at the linguistic level: taking a source text and producing an equivalent in the target language.

Localisation goes further. It adapts the product culturally, not just linguistically. That includes replacing references, adjusting tone, reworking UX patterns, and aligning with local expectations around everything from colour choices to payment flows. Software localisation is the application of this process to software products specifically.

Internationalisation (i18n) is the preparation stage that happens during development. It’s about writing code that separates content from logic, supports multiple locales, handles text expansion, and accommodates right-to-left languages. Without internationalisation, localisation becomes a painful retrofit. With it, localisation becomes a matter of plugging in locale-specific content.

The relationship is sequential: you internationalise first, then localise. If you skip the first step, the second one costs significantly more. We go into much more detail on the technical side in our internationalisation guide, which covers Unicode support, resource file structures, text expansion allowances, RTL layout handling, and string concatenation pitfalls.

SaaS localisation

SaaS products bring specific localisation challenges that desktop software doesn’t face. The product lives in the cloud, updates frequently, and often serves users across dozens of markets simultaneously from a single codebase.

The update cycle changes everything

A desktop application ships a localised version and then doesn’t change until the next release. A SaaS product pushes updates weekly, sometimes daily. Every new feature, UI change, or copy update needs to be localised before it goes live, or you end up with a patchwork product where some screens are in the local language and others revert to English.

This is where continuous localisation becomes relevant. SaaS teams that treat localisation as a batch process (translate everything once a quarter, then ship) invariably fall behind their release cycle. The strings pile up. The backlog grows. Eventually, some markets are seeing the product two versions behind, with half the interface in English and half in their language. Users notice.

Culture shapes how users experience SaaS products

A SaaS product’s interface is the entire relationship between the brand and the user. There’s no physical product, no retail experience, no human interaction unless something goes wrong. The UI is the brand.

That makes cultural adaptation particularly important. Research into Hofstede’s cultural dimensions shows that user expectations around information density, trust signals, communication style, and risk tolerance vary significantly across cultures.

Users in high uncertainty-avoidance cultures (Germany, Japan, Belgium) want detailed explanations, visible certifications, and explicit reassurance before they’ll commit to a SaaS product. Users in low uncertainty-avoidance cultures (the US, Singapore, Denmark) are quicker to sign up, try features, and tolerate ambiguity in the interface. Both groups can be using the same product, but they need different onboarding experiences, different copy tones, and different conversion paths.

We go deeper into this in our piece on cultural influence on search behaviour and SEO, and the principles apply directly to SaaS localisation.

Pricing, payment, and trust

SaaS products need to handle local pricing (not just currency conversion, but actual pricing strategy), local payment methods (iDEAL in the Netherlands, Boleto Bancário in Brazil, Bizum in Spain), and local trust signals. Displaying a UK Companies House number on a checkout page means nothing to a user in Italy; an Italian user might expect a partita IVA instead.

Pricing psychology also varies by market. A SaaS product priced at $9.99/month in the US can’t simply convert that to euros and assume it works. Price sensitivity, willingness to pay for software subscriptions, and expectations around free tiers and trial periods all differ across markets. Some European markets expect longer free trials than the US. Some Asian markets expect freemium models where the US equivalent charges from day one.

Mobile app localisation

Mobile apps share the core localisation needs of any software product, but the platform adds its own layer of complexity.

Mobile UX is less forgiving

On a desktop SaaS product, you have screen real estate to work with. On a mobile app, every element is competing for space. Translated text that’s 25% longer than English (common for Spanish, French, and German) can break layouts, truncate labels, or push buttons off-screen.

Mobile users also make faster decisions. Research from Google consistently shows that mobile interactions are shorter and more emotionally driven than desktop ones. A confusing label or an unfamiliar payment screen creates a moment of hesitation, and on mobile, hesitation means the user leaves. They don’t troubleshoot. They close the app.

This means that mobile localisation QA is more demanding than desktop or web QA. Every screen needs to be visually checked in every target language to catch truncation, overlapping elements, and layout breaks. Automated string-level QA isn’t enough; you need visual QA on-device.

App Store Optimisation needs localisation too

ASO is a separate discipline from in-app localisation, but the two are connected. Your app store listing is the first thing potential users in a new market see, and it needs to be locally researched, not just translated.

This means multilingual keyword research for the app store title and keyword field, locally written descriptions that address the specific pain points of that market, and localised screenshots that show the interface in the target language. Apple’s and Google’s own developer documentation covers the technical specs, but the strategic work of figuring out what resonates locally requires native-market expertise.

The keywords that users in Spain type into the App Store to find a supplier ordering tool are different from what UK users search for. A direct translation of the English listing will miss them entirely, because people don’t search by translating English queries in their heads. They search using their own vocabulary, their own phrasing, their own mental models. That’s why ASO localisation needs to start with keyword research in the target language, not with a translation of the English keyword list.

Market selection and device penetration

Deciding which markets to localise for isn’t just about language. Mobile device penetration rates, dominant operating systems (iOS vs Android share varies wildly by country), mobile payment adoption, and even network speeds all factor into the decision.

In markets where Android dominates (much of Southeast Asia, Latin America, parts of Africa), prioritising Android localisation over iOS might make more sense. In markets where iPhone share is high (Japan, US, UK, Scandinavia), you might lead with iOS. This affects everything from which screenshots you create for the app store listing to which devices you prioritise for QA testing.

Statista’s digital market data is a useful starting point for market selection, though it’s worth cross-referencing with your own analytics data to see where existing demand already exists before localising speculatively.

Case studies

Theory is useful, but what localisation actually looks like in practice depends entirely on the product, the market, and the constraints. Here’s what we’ve seen working with real apps at different stages of their international expansion.

what3words: 61 languages and the problem that isn’t translation

what3words divides the globe into 3m x 3m squares, each identified by a unique combination of three words. The app is available in over 60 languages, with voice input supported in 35+ of them. On the surface, this looks like a massive translation project. It isn’t. And that distinction is what makes it interesting from a localisation perspective.

The three-word addresses in each language aren’t translations of the English addresses. They’re independently assigned. The square at ///filled.count.soap in English is ///soja.tacos.aires in Spanish. Different words, same coordinates. This means what3words had to build (or source) entirely separate wordlists for each language rather than running the English list through a translation process.

The localisation challenge for what3words sits in the layers around those word addresses: the app UI, the onboarding flow, the voice recognition, the help content, the App Store listings, and crucially the way the system handles different writing scripts.

what3words supports multiple scripts for the same language through what they call locales. Chinese, for example, is available in both Simplified and Traditional characters. Serbian comes in both Latin and Cyrillic. Mongolian and Kazakh each support both Cyrillic and Latin script. These aren’t different translations; they’re the same addresses rendered in different writing systems. For the user, this means their address works regardless of which script they prefer. For the localisation team, it means maintaining parallel versions of the same language.

Scaling the workflow

Scaling from a handful of languages to over 60 required a shift in workflow. what3words moved from managing translations in Google Sheets and Docs to using Phrase as their TMS (Translation Management System), integrated with Figma for design context. According to a case study published by Phrase, launching a new language version of the app now takes roughly five to six weeks, covering about 1,000 strings per language. Translators working within Phrase can see context screenshots from Figma and review questions from previous translators, which speeds up onboarding for each new language.

The voice input layer adds another dimension. Users can speak a three-word address into the app in over 35 languages, with regional variants supported (English has separate voice models for UK, US, Australian, Canadian, and Indian pronunciation). This isn’t a standard localisation task. It’s a speech recognition challenge that sits alongside the linguistic one, requiring each voice model to handle the specific phonetics and pronunciation patterns of that language or dialect.

What this shows: localisation at scale requires infrastructure. Spreadsheets work when you’re supporting four languages. At 60+, you need a TMS integrated with your design and development tools, a systematic onboarding process for new translators, and a way to provide visual context for strings that would otherwise be ambiguous.

Polarsteps: the market-by-market playbook

Polarsteps is a Dutch travel tracking app that lets users record their trips on a map, add photos and notes, and share the journey with friends and family. The app has over 19 million users. About a third of the entire Dutch population has a Polarsteps account.

Rather than localising into 20 languages at once and hoping for the best, Polarsteps took a market-by-market approach. They saturated the Netherlands first, then focused on France as their next priority market. In a 2025 interview, CEO Clare Jones described the logic: “France is our fastest-growing market. France was our main focus until we reached that growth trajectory. Now we’ve done that. And we learned a lot. So we’re going to other markets now.” We’ve been helping them localise into Spanish-speaking markets.

The interesting part isn’t the strategy itself (focus on one market at a time, learn, then expand), but why it matters for localisation specifically. Polarsteps discovered that each market needed more than language translation. Travel patterns differ. French users do more domestic travel than Dutch users. American users lean heavily on the planning features because they have less annual holiday and want to make every day count. These behavioural differences affect which features to emphasise in each market’s onboarding flow, which screenshots to use in the App Store listing, and which push notification copy will resonate.

Adapting to market-specific behaviour

Polarsteps follows the device language model: the app installs in whatever language the user’s phone is set to, if that language is supported. This is a common pattern for mobile apps and avoids the need for a separate in-app language selector. Their Google Play listing is fully localised in Spanish, French, and other supported languages, with locally adapted descriptions rather than direct translations.

The company’s revenue model (physical travel books generated from trip data) adds a layer that most SaaS products don’t face: the printed product itself needs localisation. Book layouts, text formatting, date representations, and even the paper size and printing specs may need to vary by market.

France now has over 3 million Polarsteps users. The company is currently applying what they learned in France to their next target markets, rather than trying to scale everywhere simultaneously.

What this shows: you don’t need to localise everywhere at once. Focusing deeply on one market, learning what works, and then applying those lessons to the next market can be more effective than spreading thin across many languages. It also shows that localisation isn’t just about the product: market-specific user behaviour should inform your ASO, your onboarding, and your feature emphasis.

Curve: when the concept itself doesn’t carry

Our client Curve is a London-based fintech that consolidates multiple payment cards into a single card and app. Users link their existing debit and credit cards to Curve, then use the Curve card (physical or digital) for all payments, switching between underlying cards through the app. The product is available in 31 European countries.

Curve is a useful case study because it exposes a localisation problem that most guides never mention. Most of the advice out there assumes that everything in your product is translatable. That if you get the words right, the feature will land. But with fintech products in particular, some features are built around financial behaviours that simply don’t exist in certain markets. The concept itself doesn’t carry, and no amount of linguistic accuracy will fix that.

Credit works differently in different countries

Take Spain. Credit cards there don’t work quite like they do in the UK or US. While Brits and Americans might carry balances and pay interest month after month, most Spaniards aim to clear their credit card debt in full each month to avoid charges. Some do choose to defer payments through fixed instalments, but that’s not the norm. Balance transfers aren’t heavily marketed, and Spanish banks don’t typically encourage moving balances around to reduce interest. The culture leans more towards debt avoidance than debt management. So a British fintech trying to promote a debt management feature in Spain might struggle to get traction, regardless of how well the copy was translated.

Rewards and cashback follow a similar pattern. In the UK and US, credit cards often come with bonuses or cashback offers that encourage moving purchases from one card to another. In Spain, while consumers do value rewards, they’re generally not as aggressively marketed, and people are less likely to chase points or cashback as a primary motivation. They tend to focus more on stability and predictability in their financial habits.

When a feature is untranslatable

Refinancing is another example. In France, credit cards function more like charge cards that get paid off in full each month, so refinancing isn’t relevant. In Germany, people are generally debt-averse, so moving balances between cards feels unnecessary. Even if a feature technically works in the localised app, the concept itself can feel completely foreign to the user.

This matters for Curve specifically because several of its core features were designed around British and American financial behaviour: card switching optimisation, cashback across multiple cards, “Go Back in Time” retroactive card changes. In markets where people actively juggle multiple cards, those features make immediate sense. In markets where the average person uses one debit card and pays everything off monthly, the value proposition itself needs rethinking, not just rewording. A perfectly translated onboarding screen explaining a feature that has no relevance to the user’s financial life is still going to produce low adoption.

This is why fintechs that hire non-specialist linguists sometimes end up scratching their heads over poor feature adoption in specific markets. They have the translations reviewed, and everything checks out linguistically. But the feature still underperforms. The translations were correct. The problem was upstream: the concept had no product-market fit in that locale.

Regulation and terminology add another layer

On top of the conceptual challenge, every European market comes with its own regulatory framework. GDPR applies across the EU, but national financial regulators layer on top: Germany’s BaFin, France’s AMF, Italy’s CONSOB. Each has specific requirements around disclosures, terms of service, and customer communication.

Payment terminology varies too. “Direct debit” in the UK is “Lastschrift” in Germany, “prélèvement” in France, and “domiciliación” in Spain. These aren’t interchangeable translations; each term carries specific legal and procedural connotations in its local banking system. Getting the terminology wrong in a fintech context doesn’t just confuse users. It can trigger compliance issues.

Curve’s community forums (dating back to 2018) show early user requests for additional language support. The product launched in 31 countries but initially with an English-only interface, relying on the fact that many Europeans speak English well enough to use a financial app. The localisation came later, driven by user demand and the recognition that “can use in English” and “trusts enough to link their bank cards” are two different thresholds. Trust in financial products is deeply connected to language, and users are more cautious about apps that handle their money than apps that track their travels.

What this shows: software localisation guides tend to treat the product’s features as a given and focus on how to translate them. But sometimes the harder question is whether a feature translates at all, in the conceptual sense. Fintech is the clearest example, but the principle applies to any product where user behaviour is culturally specific. If the underlying concept doesn’t resonate in the target market, perfect translation produces a perfectly worded feature that nobody uses.

REKKI: B2B vertical SaaS with industry-specific vocabulary

REKKI is a brand we worked with a few years ago – a restaurant supplier ordering app. Chefs and restaurant owners use it to order ingredients from their suppliers, replacing the traditional process of late-night phone calls, voicemails, and scribbled fax orders. The company was founded in London in 2016 and now has offices in London, New York, Amsterdam, and Lisbon. The team comprises over 70 people from 22 countries.

REKKI’s localisation challenge is different from a consumer app. The user base is professional kitchens, which means the vocabulary is highly specialised. Ingredient names, unit measurements, portion descriptions, and supplier terminology all vary by country and sometimes by region within a country. “Courgette” in the UK is “zucchini” in the US. “Aubergine” is “eggplant.” In a consumer recipe app, getting this wrong is mildly confusing. In a professional ordering app, it can mean receiving the wrong product and not being able to serve a dish. We’ve written separately about the complexities of culinary translation and what it actually involves beyond the linguistic layer.

The app and its Google Play listing are localised in Spanish, and the product handles orders from restaurants worldwide, though the marketplace (where chefs can browse and discover new suppliers) is currently UK-focused. The REKKI app itself works globally: a restaurant in Amsterdam can order from their Dutch suppliers through the same interface.

The glossary is the product

B2B vertical SaaS localisation has a specific quirk that horizontal SaaS doesn’t face: industry jargon often doesn’t translate cleanly between languages. Kitchen terminology has borrowed heavily from French in English-speaking countries (mise en place, sous vide, bain-marie), but when you localise the app into French, those terms aren’t special vocabulary anymore. They’re just ordinary words. The Italian version can’t assume the same French loan-words that English-speaking kitchens use. Each language version needs its own glossary built with input from people who actually work in kitchens in that country, not translators working from a generic dictionary.

REKKI’s multilingual team (22 nationalities) is itself an asset for localisation. Having native speakers of your target languages within the company means you have built-in reviewers who understand the domain, the product, and the cultural context. It’s a common pattern in startups: the early localisation often happens informally, with team members translating and reviewing strings for their own language, before the process is formalised with external translators and a TMS.

What this shows: B2B software localisation requires deep domain expertise. The translators (or reviewers) need to understand the industry vocabulary in the target market, not just the language. And for vertical SaaS products, the glossary is one of the most important localisation assets you’ll build.

Why localisation reduces churn in foreign markets

This is where the business case lives. Companies invest in localisation because it affects retention directly, particularly for SaaS and subscription-based mobile apps.

The language barrier is a churn accelerator

A CSA Research study surveying over 8,700 consumers across 29 countries found that 76% of online shoppers prefer to buy products with information in their native language, 40% will never purchase from websites in other languages, and 65% prefer content in their own language even if it’s poor quality.

For SaaS products, these preferences don’t just affect acquisition. They affect every interaction: logging in, understanding a new feature, reading a help article, contacting support. Each of these moments is an opportunity for the user to feel understood or to feel like the product wasn’t built for them.

What actually causes churn in foreign markets

Users in non-English markets don’t churn because they dislike the product. They churn because the experience doesn’t meet their expectations. Some common friction points:

Each of these problems is fixable. And each one, left unfixed, compounds. A user who encounters two or three of these issues in the first week is unlikely to renew.

The maths of churn vs localisation cost

There’s a tendency to think of localisation as a cost centre. It helps to reframe it in terms of what churn actually costs.

If your SaaS product charges €50/month and you’re losing 15% of users in a foreign market within the first 90 days due to experience issues that localisation would fix, that’s a straightforward calculation. For a cohort of 1,000 users, that’s 150 lost accounts and €7,500/month in recurring revenue gone. Over a year, that’s €90,000 from a single market and a single cohort.

The cost of localisation is a fraction of that. Which brings us to the question everyone asks early in the process.

Testing and QA

Localising the strings is only half the job. The other half is making sure the localised product actually works: visually, functionally, and linguistically.

Linguistic QA

This is the review of translated content in context. A string that reads perfectly in a translation editor can look wrong when it’s rendered in the actual UI. “Save” (as in “save a file”) and “save” (as in “save money”) might need different translations in the same product, but if the translator only sees the string without context, they’ll pick one and hope it’s right.

Linguistic QA catches these problems. It involves a native speaker reviewing the translated strings within the actual product (or in screenshots of the product), checking for accuracy, tone, consistency with the glossary, and cultural appropriateness. This is where a TMS with Figma integration earns its keep, because translators and reviewers can see exactly where each string appears.

Visual QA

Text that’s been translated correctly can still break the interface. Visual QA is the process of checking every screen in every target language for layout issues: truncated strings, overlapping elements, buttons that are too small for the translated label, text that overflows its container, and right-to-left rendering problems for languages like Arabic and Hebrew.

This needs to happen on actual devices (or device emulators) for mobile apps, and in actual browsers for web-based SaaS products. A string that fits on an iPhone 15 screen might not fit on an older device with a smaller display. A German label that works on Chrome might wrap incorrectly on Safari.

Functional QA

Functional QA checks that locale-specific features work correctly: date pickers showing the right format, currency symbols appearing in the right position, address forms accepting local formats, payment methods processing correctly, and sort orders respecting local alphabetical conventions (Swedish puts Ö after Z, not next to O).

This is often the most technically demanding QA layer because it involves testing the interaction between the localised UI and the underlying logic. A date displayed as 02/03/2026 needs to be unambiguous in every locale: is that 2 March or 3 February?

When to run QA

The temptation is to run all QA at the end, once all strings are translated. For a waterfall release, that works. For continuous localisation in an agile workflow, QA needs to be integrated into the sprint cycle. New or changed strings should be reviewed linguistically within the sprint, and visual/functional QA should happen before each release.

Some teams use pseudo-localisation during development as an early warning system. This replaces strings with artificially expanded text (adding extra characters to simulate German-length strings, for example) so developers can catch layout issues before real translations even begin.

How much software localisation costs

This is the question that comes up in every first conversation about localisation, and the honest answer is: it depends on at least half a dozen variables.

What drives the cost

The main factors are:

Number of strings. A simple mobile app might have 500-1,000 translatable strings. A complex SaaS product with a help centre, marketing pages, and email templates can have 10,000-50,000+. Translation is typically priced per word, so this is the single biggest cost driver.

Number of target languages. Each language multiplies the per-word cost. Localising into 5 languages costs roughly 5x what localising into 1 language costs, though there are some economies of scale with translation memory (strings that repeat across the product are stored and reused).

Language pair. Some languages cost more to translate than others. Japanese, Korean, Arabic, and Chinese typically cost more than Western European languages because the translator pool is smaller and the linguistic distance from English is greater.

Level of cultural adaptation. A straight translation costs less than a full cultural adaptation. If you need UX copy rewritten (not just translated) for each market, the cost goes up. If you need market-specific imagery, the cost goes up further.

Ongoing vs one-off. A one-time localisation of a stable product is a fixed project cost. Continuous localisation for a SaaS product that ships weekly is an ongoing expense. Most companies budget localisation as a percentage of their development spend.

Rough cost ranges

For a mid-sized SaaS product with around 5,000 source words of UI text:

These are ballpark figures. The actual cost for your product depends on the specifics. We break down the variables in more detail in our translation cost guide.

The more useful way to think about cost is in relation to the revenue opportunity. If a new market represents £500,000/year in potential revenue and the localisation cost is £10,000 per language, the ROI calculation is simple. The question isn’t “can we afford to localise?” It’s “can we afford not to?”

Rollout strategies

There’s no single correct way to take a software product into new markets. The right approach depends on your budget, your team’s capacity, how much of the product needs localising, and how much you already know about the target market.

In-region first

Start with one market. Localise fully for that market, launch, learn, iterate, then move to the next one. This is the approach Polarsteps took: saturate the Netherlands, then focus entirely on France, now expanding to other markets using what they learned.

It works well when you have limited localisation budget, or when you’re entering a market that’s culturally very different from your home market and you want to test assumptions before scaling. The downside is speed: you’re entering markets sequentially rather than simultaneously.

Go wide with minimum viable localisation (MVL)

MVL borrows from the MVP concept. You localise the minimum set of user-facing content needed to give users a functional experience in their language: core UI, onboarding, payment flow, and key help content. Everything else stays in English temporarily.

This is a pragmatic option for apps that want to establish presence in several markets quickly without committing to full localisation upfront. The risk is that users in those markets get a patchy experience, which brings us back to the churn question. MVL buys you time, but it shouldn’t be the permanent state.

Go deep

Full localisation across every touchpoint: UI, help content, marketing, ASO, lifecycle emails, push notifications, support. This is the right approach for markets where you’re serious about long-term growth and where the revenue opportunity justifies the investment.

what3words, supporting 60+ languages with voice input in 35+, is an example of going deep at scale. It required moving from spreadsheets to a full TMS with design tool integration, building systematic onboarding processes for new translators, and investing in infrastructure that makes each new language launch a five-to-six-week process rather than a months-long project.

Continuous localisation and agile workflows

If your development team ships updates in sprints, your localisation process needs to match that rhythm. This is what continuous localisation is for.

How it works

In a traditional localisation workflow, you finish building a feature, then hand the strings off for translation, wait for them to come back, integrate them, QA them, and ship. That cycle can take weeks. If you’re shipping features every one or two weeks, the lag becomes unmanageable.

Continuous localisation integrates translation directly into the development pipeline. New or changed strings are automatically flagged, sent to translators, and returned into the build. The product stays in a release-ready state in all supported languages at all times, rather than going through periodic “localisation sprints” that hold up the release.

What continuous localisation requires

Internationalised code: strings externalised into resource files, not hardcoded. (More on this here.)

A TMS that integrates with your development environment: tools like Phrase, Crowdin, or Lokalise connect directly to your repo and automate the string handoff. We’ve reviewed the main options in our TMS comparison guide.

Translators who understand the product: in a continuous workflow, translators are receiving strings with limited context, often out of order. They need to know the product well enough to make good decisions without seeing the full page every time. This is why what3words’ integration of Phrase with Figma was so valuable: translators could see context screenshots alongside every string.

QA integrated into the sprint cycle: linguistic QA and visual QA (checking that translated strings render correctly in the UI) need to happen before each release, not as an afterthought.

Is continuous localisation always the right approach?

For SaaS products with frequent releases and multiple supported languages, it’s essentially the only viable approach. For desktop software that ships major versions annually, a batch approach still works fine. Mobile apps sit somewhere in between: the update cadence is faster than desktop but often slower than SaaS, so a hybrid approach (continuous for core UI, batched for marketing content and help articles) can work well.

We have a more detailed piece on continuous localisation and how it fits into agile workflows if you want to go deeper on the operational side.

Where to start

If you’re looking at software localisation for the first time, the sequence that tends to work best is:

Audit your codebase for internationalisation readiness. If strings are hardcoded, if your layouts don’t accommodate text expansion, or if your app doesn’t support locale-based formatting, fix that first. Localising without internationalisation is like painting a house that hasn’t been plastered.

Pick your first market based on data, not instinct. Check your analytics for where international traffic is already coming from. Look at where your competitors are localised. Research the market size and who you’d be competing against. Statista and SimilarWeb are decent starting points for market sizing.

Decide what level of localisation the market warrants. Full localisation? MVL? Somewhere in between? This depends on the revenue opportunity, your budget, and how strategically important the market is.

Work with translators who know software. Software localisation involves terminology, UI constraints, character limits, and contextual translation (a button, a tooltip, and a help article all need different tones even if they reference the same feature). Generalist translators will produce technically accurate copy that feels off in context. You need people who’ve worked on software products before and understand the constraints of the medium. For B2B products like REKKI, you also need translators who understand the industry.

Set up before you translate

Build your glossary and style guide before you start translating. This is the single most overlooked step. A glossary defines how key terms should be translated consistently across the product. A style guide defines tone, formality level, and formatting conventions for each language. Without these, you’ll get inconsistent translations that need expensive rework.

Set up your localisation workflow before you start translating. Whether that’s integrating a TMS with your repo, establishing your QA process, or defining handoff procedures between developers and translators, getting the infrastructure right first saves you from reworking everything once you’re mid-project. what3words’ shift from Google Sheets to Phrase is a good example of what happens when a company outgrows its initial workflow and needs to invest in proper tooling.

If you’re unsure where to start or want help figuring out which markets and which approach make sense for your product, we’re here to talk it through.

Frequently asked questions about software localisation

What is software localisation? Software localisation is the process of adapting a software product so it works naturally for users in a specific language and region. It covers the user interface, on-screen text, date and currency formats, legal compliance, payment methods, and the overall user experience. Whether the product is a SaaS platform, a mobile app, or desktop software, the goal is to make the product feel like it was built for that market rather than ported into it.

What is the difference between software localisation and translation? Translation transfers meaning from one language to another. Localisation goes further by adapting the product culturally as well as linguistically. For a software product, that means reworking UX patterns, adjusting tone, aligning with local payment and regulatory expectations, and ensuring that layout and formatting hold up in the target language. A product can be accurately translated and still feel foreign to users if the localisation work hasn’t been done.

What is the difference between software localisation and internationalisation? Internationalisation (i18n) is the preparation work developers do to make a codebase ready for localisation: externalising strings, supporting multiple locales, handling text expansion, and building layouts flexible enough to accommodate different languages. Localisation is what happens after that foundation is in place: providing translated strings and adapting the product for specific markets. Skipping internationalisation makes localisation significantly harder and more expensive to do retroactively.

What does software localisation include in practice? At a minimum: UI strings and navigation, date and currency formats, legal and compliance content, and onboarding flows. For mobile apps, it also includes the App Store listing. For SaaS products, it typically extends to marketing pages, lifecycle emails, help content, and payment method integration. The full scope varies by product type and target market.

How does software localisation affect churn in foreign markets? Users in non-English markets don’t tend to churn because they dislike the product. They churn because the experience doesn’t meet their expectations. A CSA Research study of over 8,700 consumers found that 76% prefer to buy products with information in their native language, and 40% will never purchase from websites in other languages. Partially localised products (some screens in English, others in the local language) compound this by creating a patchwork experience that signals the product wasn’t made for them.

What is minimum viable localisation? Minimum viable localisation (MVL) borrows from the MVP concept: localise the minimum set of content needed to give users a functional experience in their language, covering the core UI, onboarding, payment flow, and key help content. Everything else stays in English temporarily. It’s useful for establishing presence in several markets quickly without committing to full localisation upfront, but it should be a starting point rather than a permanent state.

How much does software localisation cost? For a mid-sized SaaS product with around 5,000 source words, UI-only professional translation runs roughly £500 to £1,500 per language. Adding a help centre and marketing pages brings that to £2,000 to £6,000, and a full localisation with cultural adaptation, ASO, and QA can reach £5,000 to £15,000 or more. The more useful framing is the revenue opportunity in the market versus the localisation cost, since for most markets with real demand the investment pays back relatively quickly.

What is continuous localisation for software? Continuous localisation integrates translation directly into the development pipeline so that new or changed strings are automatically flagged and sent to translators, keeping the product in a release-ready state across all supported languages at all times. SaaS products that ship updates weekly or more often need this approach because batch localisation (translating everything once a quarter) inevitably falls behind the release cycle, leaving some markets on older versions with partially English interfaces.

---

Author: Maria Scheibengraf

Maria Scheibengraf is an award-winning marketer, multilingual SEO specialist, and English-to-Spanish translator specialised in software, including SaaS, martech, and fintech. She is the co-founder and Operations Manager of Crisol Translation Services and the author of The SEO Translation Bible.