How to Localize a B2B SaaS App in Under 30 Days

Your CEO closed a strategic deal in Germany. The customer wants the product in German by end of quarter. That is 30 days. Nobody on your team has localized a product before.

Here is the exact plan. Not the "how to think about localization" plan. The one with dates.

What do you commit to before the 30 days start?

You do not commit to a fully localized app. You commit to a fully localized path from signup to activation to renewal, in the target language, that the customer's users can actually complete.

The scope decision is the difference between a real 30-day launch and a slipped one.

• In scope. Signup, onboarding, billing, the top 3 workflows in your product, all error states, transactional emails.
• Out of scope. Admin settings, help center, marketing site, blog, changelog, second-tier workflows, customer-visible strings gated behind feature flags nobody in the target region has.

Write this down. Get the CEO to sign the scope. Then start the timer.

Week one: what does the inventory phase look like?

The goal of week one is a complete, versioned string inventory for the in-scope surfaces, in a format the pipeline can read.

• Day 1 to 2. Audit the codebase for hardcoded strings in the in-scope files. If you already use a string catalog, skip. If not, budget the whole week for extraction and this whole playbook is running two weeks late.
• Day 3 to 4. Consolidate strings into one file per surface, in the platform-native format. Add descriptions and screenshots for anything ambiguous. Remove dead keys.
• Day 5. Set up the sync between your repo and a translation service. Push the source strings. Confirm they parse without errors on the other side.

At the end of week one, you have a file called de.json (or the equivalent for your stack) with the same key set as en.json, all values empty, ready to be filled.

Week two: what does the drafting phase look like?

The goal of week two is machine translation drafts for every in-scope string, reviewed by a human for tier-1 surfaces, in place in the repo.

• Day 6. Run MT drafts for every string. Modern MT with your glossary and tone rules produces usable output in minutes.
• Day 7. Human reviewer starts on billing, onboarding, and error strings. These get full review. Everything else stays as MT with a spot-check plan.
• Day 8 to 10. Reviewer works through tier-1 surfaces. Engineering wires up the UI to render German locale, using the partial translations that exist so far. Bugs get filed against the drafts, not against the reviewer.

Do not wait for the reviewer to finish before wiring up the UI. Ship a broken locale internally first. The UI bugs surface faster when everyone can see the German build.

Week three: what does the QA phase look like?

The goal of week three is passing every CI check, on the release branch, with the German locale enabled.

• Day 11. Reviewer completes tier-1 surfaces. Full human coverage on billing, onboarding, errors, and legal.
• Day 12 to 14. CI checks turn on: completeness, placeholder integrity, plural coverage, layout overflow at 320px, 768px, and 1280px, glossary compliance. Every failure is a fix.
• Day 15 to 17. Manual QA in-app by a native German speaker who is not the reviewer. New pair of eyes catches what the pipeline misses.

The layout QA is where teams lose a day they did not budget. German is 30 percent longer than English on average. Buttons overflow. Modal titles wrap awkwardly. Nav items break the grid. Fix at the CSS level with responsive rules, not by editing translations.

Week four: what does the launch phase look like?

The goal of week four is turning German on for paying customers and handling the first support tickets.

• Day 18 to 20. Beta cohort of internal users and the strategic customer. Every visible string change flags in a shared channel. Every complaint becomes a ticket, not a Slack thread that vanishes.
• Day 21 to 24. Over-the-air push cycle. Fixes to the top 10 issues from the beta ship without a new build. Reviewer works the fix queue in parallel with engineering.
• Day 25 to 28. Locale switcher becomes visible to all users in target region. Monitor CS ticket volume, self-serve upgrade conversion, and time-to-activation in the new locale.
• Day 29 to 30. Retrospective. What broke. What surprised you. Which decisions in week one you should keep for language two.

If you get to day 30 with the light green, language two starts at day 31 with the pipeline already built.

What tooling do you need in place?

The tooling stack is smaller than most teams assume.

The one line item most teams skip is monitoring. Without it, you cannot tell whether the launch worked. Ship it with the launch, not after.

What are the most common reasons the 30 days slip?

Five patterns account for almost every slip. Watch for them.

1. Scope creep in week one. Someone argues that the help center "should really be included". Reject. Ship the launch. Do the help center in month two.
2. Hardcoded strings discovered in week three. A screen you did not audit was rendering English constants inline. Add a lint rule for this now, not next quarter.
3. Reviewer capacity underestimated. A single reviewer processes roughly 300 to 500 strings per day at review-quality pace. If your inventory is 1500 strings, you need three reviewer-days minimum, and probably five for iteration.
4. Layout QA left to the last week. You find button overflow on day 25. Better to find it on day 15. Turn on pseudo-locale rendering in week one for early signal.
5. Currency and payment integration bundled in. If you also need to accept euros, that is a separate 30-day project on the finance side. Do not blend them.

The mistake to avoid

Most teams treat a 30-day localization as impossible because they are trying to translate 5000 strings. It is not impossible. It is impossible for the whole app in 30 days, entirely possible for the flows that convert paying customers. Cut the scope in week one, ship the pipeline that lets you extend coverage over-the-air, and treat the launch as the beginning of continuous localization rather than the end of a one-time project. Language two lands in half the time. Language three lands in a week.