How to Localize a SaaS App Without a Localization Team

You're a startup with 5-15 engineers. Your product works. Users are signing up. Now you're seeing demand from non-English markets — Germany, Japan, Brazil, France. Your options seem to be: hire a localization team, or ignore international users.

There's a third option: automate it.

Here's a practical playbook for localizing a SaaS app when you don't have a localization team, a translation budget, or time to build a custom pipeline.

Step 1: Externalize Your Strings

If your app has hardcoded English strings scattered across components, step one is pulling them out into a structured format. This is non-negotiable — you can't translate what you can't find.

// Before: hardcoded strings everywhere
function SettingsPage() {
  return (
    <div>
      <h1>Settings</h1>
      <p>Manage your account preferences.</p>
      <button>Save changes</button>
    </div>
  );
}
// After: externalized strings
function SettingsPage() {
  const t = useTranslations("settings");
  return (
    <div>
      <h1>{t("title")}</h1>
      <p>{t("description")}</p>
      <button>{t("save")}</button>
    </div>
  );
}

// messages/en.json
{
  "settings": {
    "title": "Settings",
    "description": "Manage your account preferences.",
    "save": "Save changes"
  }
}

For an existing app with 200+ components, this is a tedious afternoon. But it's a one-time cost. Every new feature from now on uses the translation function.

Tip: Don't try to externalize everything at once. Start with user-facing pages (landing, settings, billing). Leave admin panels and developer tools for later.

Step 2: Pick Your Languages

Don't translate into 20 languages on day one. Pick 3-5 based on data:

Check your analytics. Where are your users? What Accept-Language headers are most common?

Check your support tickets. Are non-English users writing to you in their language?

Check your competitors. Which languages do they support?

A common starting set for B2B SaaS: English, German, French, Spanish, Japanese. This covers Western Europe, Latin America, and Japan — three of the largest software markets.

Step 3: Automate Translation

Here's the key insight: for a SaaS UI, machine translation is good enough for launch. You can refine later.

Your UI strings are short, contextual, and repetitive. "Save," "Cancel," "Delete," "Settings," "Your account" — these translate well with any modern translation API. The edge cases (marketing copy, legal text) can be hand-reviewed later.

Set up automated translation in your CI pipeline:

# .github/workflows/translate.yml
name: Translate
on:
  push:
    branches: [main]
    paths: ["messages/en.json"]
jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      
uses: actions/checkout@v4
      
uses: actions/setup-node@v4
        with:
          node-version: 20
      
run: npm ci
      
run: node scripts/translate.js
        env:
          AUTO18N_API_KEY: ${{ secrets.AUTO18N_API_KEY }}
      
name: Commit translations
        run: |
          git config user.name "i18n bot"
          git config user.email "bot@example.com"
          git add messages/
          git diff --cached --quiet || git commit -m "chore: update translations"
          git push

The translation script detects new or changed keys in en.json and translates them into your target languages. On every push, your locale files stay in sync automatically.

Using a service like auto18n here makes sense because it caches translations — the same "Save changes" string only gets translated once, ever. Subsequent CI runs are instant for unchanged strings.

Step 4: Handle What Machines Get Wrong

Machine translation isn't perfect. Here's what to watch for:

Formal vs. informal tone

In German, French, and Japanese, the level of formality matters. Machine translation might produce a mix of formal and informal. Decide on your tone (most SaaS products use informal) and configure it.

With LLM-based translation, you can specify context:

{
  "text": "Check your inbox for a confirmation email.",
  "to": "de",
  "context": "SaaS app notification, use informal 'du' form"
}

String length

German strings are typically 30% longer than English. Japanese strings are often shorter. This affects UI layout. Plan for it:

/ Allow buttons to expand for longer translations /
.btn {
  white-space: nowrap;
  padding: 0.5rem 1rem;
  / Don't set a fixed width /
}

Pluralization

English has two plural forms (1 item, 2 items). Other languages have more. Arabic has six. Russian has three. Use your i18n library's plural support:

{
  "projects": "{count, plural, one {# project} other {# projects}}"
}

Context-dependent strings

"Close" can mean "shut" (a modal) or "nearby." "Post" can be a noun or a verb. The translation API doesn't know which you mean without context. Add context to ambiguous strings or use descriptive keys:

{
  "modal.close": "Close",
  "location.close": "Close by",
  "blog.post.verb": "Post",
  "blog.post.noun": "Post"
}

Step 5: Locale Routing

Users need to see your app in their language. Options:

URL prefix: /en/dashboard, /de/dashboard. Best for SEO. Easy to share locale-specific links.

Cookie/header detection: Detect from Accept-Language header on first visit, save preference in a cookie. Better UX for app-like products where SEO doesn't matter.

Both: Detect on first visit, redirect to the prefixed URL. This is what most SaaS apps do.

If you're on Next.js, see the next-intl middleware setup. If you're on a SPA (Vite, CRA), use your router's path params.

Step 6: The Feedback Loop

After launch, you need a way for users to report bad translations. The simplest approach:

Add a "Suggest better translation" link in your app footer

Link it to a form or Slack channel

Review feedback weekly and update translations manually

Don't over-engineer this. A Google Form works fine for the first 6 months.

For high-visibility strings (pricing page, marketing pages, onboarding flow), get professional review before launch. For everything else, machine translation with a feedback loop is fine.

What This Costs

For a typical SaaS app with 500 translatable strings across 5 languages:

• Translation API cost: ~$5-15 one-time, then pennies per month for new strings
• CI pipeline: Free (GitHub Actions free tier)
• Engineering time: 1-2 days initial setup, 15 minutes per sprint for maintenance
• Professional review of key pages: $200-500 one-time per language

Total first-month cost: under $1,000. Ongoing cost: nearly zero.

Compare that to a localization team: $5,000-15,000/month for a localization manager + translator access.

The Timeline

• Week 1: Externalize strings in your main pages. Set up i18n library.
• Week 2: Write translation script. Set up CI pipeline. Translate into first 2 languages.
• Week 3: Add locale routing. Test with native speakers on your team (or friends, or Twitter).
• Week 4: Launch. Add feedback mechanism. Monitor for issues.

Four weeks from "English only" to "5 languages." No localization team required.

When You Will Need a Localization Team

This scrappy approach works until:

• You have 50+ pages of marketing content that needs to sound polished
• You're entering regulated markets (medical, financial) where translation accuracy is legally required
• Your support volume in non-English languages exceeds what your team can handle
• You need cultural adaptation (not just translation) — different imagery, different messaging, different feature emphasis per market

Until then, automate, iterate, and ship. Perfect is the enemy of localized.