If a real share of your visitors or signups already use your product in a language you don't support, translating the parts that get a new user to their first result is often one of the cheapest growth moves a small product has. You don't need to translate everything. You need one language, picked from evidence, with the landing page, signup, first-run screens and core emails done well, on URLs search engines can read.
This guide is for solo makers and tiny teams whose product is English-only and who keep seeing one other language show up in analytics, support emails or replies. It ends with a 14-day sprint, common traps and a short FAQ.
One honest warning: a second language is a second product surface. Every new feature, email and error message now needs two versions. That's fine if the demand is real and a slow drain if it isn't, so start by checking.
When is localization worth it for a small product?
It's worth it when people who speak another language are already trying to use your product and getting stuck, not when a market just looks big on paper. A big market where nobody knows you is a distribution problem a translation won't fix.
Look for signals you can count:
Browser language in your analytics. Country tells you where someone is. Language tells you what they read. Google Analytics 4, for example, has a Language dimension that records the language of a user's browser or device, so you can see signups by language, not just by country.
Search queries from one country. The Search Console performance report can group clicks and impressions by country. If one non-English country keeps showing up with English queries, many of those people are probably searching in a second language and finding you anyway.
Support emails in another language. Even two or three a month matter, because most people who struggle never write at all.
Signups who stall early. If speakers of that language sign up at a fair rate but finish setup less often than English speakers, language friction is worth testing.
Direct asks. "Is a German version coming?" from paying users is the strongest signal.
If none of these show up, park it. Come back when one language keeps appearing on its own.
How do you pick the one language to start with?
Pick the language where you already have the most stuck demand and can get a native speaker to review the work. Two languages at once doubles the review work before you know whether the first pays off.
Score each candidate from 1 to 3 on five questions:
Existing demand: how many signups, visits or emails already come from speakers of this language?
Buyer fit: do the people in that market have the problem your product solves, and do they pay for tools like yours?
Competition in that language: are the tools your buyers compare you to already localized, or would you be one of the few options in their language?
Review access: do you know a customer, friend or freelancer who speaks it natively and understands your field?
Support load: can you answer questions in that language, even slowly with help, without breaking your week?
Add the scores. The highest total wins, but a 1 on review access should knock a language out for now.
What should you translate first, and what can wait?
Translate the path from first visit to first result, and nothing else in round one. That path is usually short, and it's where language friction costs you the most.
Round one, in this order:
Landing page. Translate the positioning, not just the words. If you've written a one-page positioning brief before rewriting your homepage, hand it to your reviewer first so the translated headline carries the same promise, not a literal word swap.
Pricing page. Plan names, what's included, limits and the billing period. Keep your existing prices for now and say clearly which currency they're in.
Signup and login. Form labels, validation errors, the button text and the terms line.
First-run screens. Whatever a new user sees before their first real result: setup steps, empty screens, tooltips and the main buttons.
Core emails. Verification, password reset, welcome and receipts. They're easy to forget because they live outside the app. Check they land in the inbox too; it's worth reading why your password reset email might be sitting in spam before you translate copy nobody receives.
Things that can wait for round two or forever:
Your blog archive. Write new pieces for the new market later if it works.
Settings screens and admin areas few people open.
Your full help center. Translate only the two or three pages new users open most.
Finish each screen fully before moving on. A German page with an English error message in the middle tells the reader you stopped caring halfway.
How do you prepare your app for a second language?
Move every user-facing string out of your code into translation files, and stop building sentences by gluing pieces together. That one change makes everything after it cheaper, including a third language if it comes.
The main jobs, in rough order:
Extract strings. Every button, label, error and email line gets a key, like signup.button, with one file per language. Use the i18n library your framework's docs point to.
Use whole sentences with placeholders. "You have {count} projects" translates. "You have " + count + " projects" often doesn't, because word order changes between languages.
Handle plurals properly. English has two plural forms for counts (1 project, 2 projects). Other languages don't follow that pattern. MDN's page on Intl.PluralRules notes that Chinese has one form and Arabic has six. Use your library's plural support or the Intl APIs, not an if statement for 1.
Leave room for longer text. The W3C's article on text size in translation explains that text translated from English usually gets longer, short strings grow the most, and languages like German build long compound words that won't wrap neatly. Tight buttons and tabs break first.
Format dates, numbers and times by locale. 03/04 means different days in different countries, and decimal separators differ too. Let the Intl APIs or your library format them from the user's locale.
Store the user's language on the account, so emails go out in the right language too.
Before real translations arrive, duplicate your English file, pad every string by half again, click through the activation path and fix whatever overflows. It's a boring hour that saves a lot of ugly screenshots later.
How do you translate without it sounding like a machine wrote it?
Use machine translation for the first draft if you like, then have a native speaker who knows your field review every string in context before it goes live.
A process that works at small scale:
Write a short glossary first. Ten to twenty terms: key nouns, plan names and words you never translate, like the product name. It stops "project" becoming three different words on three screens.
Draft the strings. Machine translation or a freelancer, either is fine for a draft.
Review in context, not in a spreadsheet. Give your reviewer a staging link or screenshots of every screen. A string like "Open" can mean a verb or a status, and only the screen tells you which.
Pick a tone on purpose. Some languages have formal and informal "you". Ask your reviewer which one your buyers expect from a tool like yours, then keep it consistent everywhere.
Read the landing page out loud together. A short call catches stiff phrases a written review misses.
Pay your reviewer, or trade something real like a free year if they're a customer. And don't skip the human pass: Google's spam policies list scraping content and turning it into many pages through automated transformations, translation included, with little value for users, as one form of scaled content abuse. Carefully reviewed product pages aren't that, but bulk machine output you never read drifts toward it.
How should you set up URLs so search engines show the right language?
Give each language its own URL, link the versions to each other with hreflang, and let people switch language themselves instead of redirecting them. That's the short version of what Google's guide to managing multi-regional and multilingual sites recommends.
The details that matter for a small product:
Use separate URLs, not cookies or browser settings. Google notes its crawler usually comes from the US and sends requests without an Accept-Language header, so content swapped by browser language may never be seen. A subdirectory like yourproduct.com/de/ is usually easiest; Google's comparison lists subdirectories as easy to set up and low maintenance, and URL parameters like ?lang=de as not recommended.
Add hreflang annotations. Google's page on telling Google about localized versions of your page covers three equal methods: HTML link tags, HTTP headers or your sitemap. Pick one. Each version must list itself and every other version, with full https URLs, and if two pages don't point to each other the tags are ignored. Add an x-default for visitors whose language you don't support.
Use valid codes. hreflang takes a language code, optionally followed by a region, such as de or de-AT. You can't use a country code alone, and Google says codes like UK or EU have no effect. Use GB for the United Kingdom.
Keep one language per page. Google works out a page's language from its visible content, not the lang attribute or the URL, and advises against side-by-side translations. So translate the navigation and footer too, not just the body.
Don't auto-redirect. Google advises against redirecting people based on what you think their language is, and against adapting content by IP address. Put a language switcher on every page instead.
Label the switcher with each language's own name, like "Deutsch" or "Español", rather than flags. A flag stands for a country, and many languages are spoken in several.
How do you get your first users in the new language?
Start with the people who already found you, then go where speakers of that language talk about your problem. A translated page with no new distribution mostly helps visitors you already had.
Tell existing users first. Email signups and customers whose browser language matches, in that language, say what's now translated and ask for one honest reaction. Some will send fixes your reviewer missed.
Research words, don't translate keywords. People may search with a local term, an English loanword or a different phrase entirely. Check autocomplete in that language and your Search Console queries for that country before writing titles.
Join a few local communities. Forums, groups and subreddits in that language where your buyers ask for help. Answer questions for a couple of weeks before you mention your product, same as you would in English.
Update every listing you control. Marketplace pages, app store descriptions and launch-site profiles often support more than one language. A translated listing is cheap and visible.
How do you know if the new language is working?
Compare the new language's activation and paid conversion against your English baseline over the same weeks, not just its traffic. More German speakers reaching their first result is the point.
Track a small set of numbers weekly, split by language:
Visits to the localized pages
Signups whose account language is the new one
Share of those signups who reach your activation event
Paid conversions from that group
Support messages in that language, and how long they take you
If you don't have an activation event defined yet, do that first; this guide to tracking the product metrics that matter before your first 100 users covers how to pick one and read tiny numbers honestly. A handful of users can swing a percentage a lot, so keep raw counts next to every rate.
Set a review date about eight weeks after launch. Then make one of three calls: keep it and translate round two, keep it as is, or roll it back and redirect the localized URLs to their English versions. Rolling back is a fine outcome too.
What does this look like for a tiny product? (invented example)
Everything in this example, including the product and the numbers, is invented to show the steps.
Stavewise is a small tool for community choir directors to share rehearsal tracks and track attendance. Its founder, Mara, noticed that over 90 days, 64 of her 410 signups had a German browser language, the biggest group after English. Only 11 of those 64 finished setting up their first choir, against roughly a third of English signups. Two paying directors had asked about a German version.
She scored German, Dutch and Spanish. German won on demand and review access: a paying customer who runs a choir in Austria offered to review in exchange for a free year.
Round one took about three weeks of evenings: a 14-term glossary (her reviewer said directors say "track" in English, so it stayed), the landing and pricing pages under /de/, signup, four first-run screens, and the verification, reset and welcome emails, with hreflang in her sitemap. She emailed the 64 German-browser signups in German and posted in two German-language choir forums where she'd been helping for a month.
Eight weeks later, 23 of 52 new German-language signups had set up a choir. That's too few to call a trend, but it beat the old rate, German support emails stayed at a couple a week, and three new directors paid. She kept German, planned round two for settings, and left Dutch for later.
What does a 14-day localization sprint look like?
Two weeks is enough for round one if you keep the scope to the activation path, even working part days.
Days 1 to 2: check and choose
Pull 90 days of signups by browser language and search clicks by country.
Score your top two or three candidate languages and pick one.
Line up a native reviewer and agree on payment or a trade.
Days 3 to 5: prepare the code
Extract strings on the activation path into translation files.
Fix glued sentences, plurals, and date and number formatting.
Run the padded fake-language test and fix overflowing buttons.
Days 6 to 9: translate and review
Agree the glossary and the formal or informal tone with your reviewer.
Draft every string, then review each screen on staging.
Translate the core emails and test them in a real inbox.
Days 10 to 12: URLs and search
Publish under /xx/ with a language switcher on every page.
Add hreflang with return links and an x-default, then submit the sitemap.
Write the localized page titles and descriptions from real local search terms.
Days 13 to 14: tell people and start measuring
Email matching users in their language and ask for one reaction.
Update listings you control and post in one or two communities where you already help.
Add language as a column in your weekly numbers and put the eight-week review in your calendar.
What traps waste the most time?
Shipping without a native review. Machine drafts are a starting point. Unreviewed copy on your pricing page is a trust problem.
Auto-redirecting by IP or browser. It annoys travellers and bilingual users and can hide versions from search engines.
Forgetting emails and errors. An English reset email after a German signup feels half-done.
Translated keywords nobody searches. Research the words people actually type in that language.
No owner for new strings. Every feature you ship now needs translation. Add "strings translated?" to your release checklist, or the new language will slowly fill up with English.
Adding a second language before judging the first. Wait for the eight-week review.
Frequently asked questions
Is machine translation good enough on its own?
For a first draft, often yes. For anything a buyer reads before paying, have a native speaker review it in context to catch wrong terms, the wrong tone and phrases nobody would actually say.
Should I use a subdirectory, subdomain or a separate domain?
For most small products, a subdirectory like /de/ is the simplest. Google's comparison lists it as easy to set up and low maintenance on one host. Country domains give a clearer country signal but cost more and need more setup, and they only target one country.
What if I can't offer support in that language?
Say so on the contact page, for example that replies may come in English or with help from translation. An honest note beats a promise you can't keep.
If you've just localized your product and want early feedback from people who aren't your usual crowd, you can put it in front of other builders on MakerHunt, where makers launch, compare notes and find their first users.