Laurel ist die Work-Intelligence-Plattform für Professional Services. Unternehmen nutzen Laurel, um die Zeiterfassung zu automatisieren, Profitabilitätstreiber zu verstehen und den ROI ihrer KI-Investitionen nachzuweisen. Bis vor Kurzem war das Produkt nur auf Englisch verfügbar. Heute ist es in mehr als einem Dutzend Sprachen live – darunter nordische Sprachen, Französisch, Niederländisch, Portugiesisch, Spanisch und Koreanisch. Mandarin, Thai, Arabisch, Japanisch und Vietnamesisch stehen bereits in der Pipeline.

Die Integration bei Laurel war unkompliziert – der Großteil des Aufwands lag auf ihrer Seite: bestehende Strings zu extrahieren und zu strukturieren, um die Codebasis vorzubereiten. Die Alternative, selbst zu bauen, wurde auf vier bis sechs Monate Engineering-Zeit geschätzt, plus laufende Wartung auf unbestimmte Zeit. Wir kamen zu dem Schluss, dass die Gesamtkosten des Nicht-Kaufs etwa beim Zehnfachen der Kosten des Kaufs lagen, wenn man die Deals einrechnet, die sonst ins Stocken geraten wären. Heute dauert das Hinzufügen einer neuen Sprache einen Tag – und ein Product Manager kann das allein erledigen. Vor achtzehn Monaten wäre dieser Satz noch absurd gewesen.

„Ich war begeistert davon, wie Lingo.dev an die Sache herangegangen ist, unsere Probleme verstanden und Lösungen gefunden hat. Wir mussten keine Lokalisierungsinfrastruktur aufbauen – sie haben das perfekt gelöst. Die Enterprise-Preise waren fair, und wir sind in einem gemeinsamen Slack-Channel mit ihren Engineers. Bei Sonderfällen dauert die Reaktion nur ein paar Stunden.“

– Nick Bazley, Staff Product Manager, Laurel

Wann sollte ein SaaS-Unternehmen in Lokalisierung investieren?#

Nick Bazley ist Staff Product Manager bei Laurel. In den vergangenen sechs Jahren hat er dort Produktteams geführt, während das Unternehmen sein Produkt weltweit skaliert hat. Über Lokalisierung hatte er schon rund ein Jahr nachgedacht, bevor das Thema konkret wurde.

„Wir wussten, dass wir das irgendwann brauchen würden“, sagt Nick. „Die einzige Frage war: wann? Jedes Mal, wenn wir darüber gesprochen haben, kamen wir zum selben Schluss: Das wird ein XXL-Projekt, es wird ewig dauern, und wir werden die Qualität des Ergebnisses nie wirklich genau kennen.“

Laurel wuchs und entwickelte sich von Mid-Market-Kunden hin zu globalen Enterprise-Kunden. Dabei zeigte sich ein klares Muster: Ein Kunde wird in einer Region gewonnen, der Mehrwert wird bewiesen – und danach will derselbe Kunde in weitere Regionen expandieren.

Als das Sales-Team in ganz Europa neue Leute einstellte und Customer Success mit Expansionsanfragen konfrontiert war, konnte Nick das Problem bereits kommen sehen.

„Als wir an den Punkt kamen, diese Arbeit angehen zu müssen, waren wir ungefähr 50 Leute. Lokalisierungsinfrastruktur selbst aufzubauen, wäre eine enorme Belastung gewesen – monatelang wäre die halbe Mannschaft gebunden gewesen, obwohl wir noch so viel mehr für unsere Kunden bauen mussten.“

Warum Lokalisierungsinfrastruktur kaufen statt selbst bauen?#

Laurel stand vor zwei Optionen: kaufen oder selbst bauen. Der Eigenbau wäre sehr wahrscheinlich ein Projekt über mehrere Quartale geworden, intern als XXL-Projekt eingeschätzt – mit vier bis sechs Monaten Engineering-Zeit. „Es ist keine kluge Entscheidung, die Kosten, Zeit und Mühe auf uns zu nehmen, unsere eigene Lokalisierungsinfrastruktur aufzubauen. Für das Unternehmen in unserer damaligen Wachstumsphase war es die vernünftigste Entscheidung, die beste Lösung am Markt einzukaufen und uns stattdessen auf den Ausbau unserer Kernplattform zu konzentrieren.“

In dieser Diskussion kristallisierten sich vier ausschlaggebende Faktoren heraus: Time-to-Market, Skalierbarkeit nach dem Launch, Anpassbarkeit und Qualität.

„Wir sind keine Experten für Lokalisierungsinfrastruktur. Wir wissen nicht, wie gut die Qualität am Ende sein wird. Warum dieses Risiko eingehen, wenn jemand ein ganzes Unternehmen rund um Localization Engineering aufgebaut hat?“

Wie bewertet man eine Lokalisierungsplattform im Vergleich zu einem klassischen TMS?#

Nick verschaffte sich mit einer schnellen Suche in Perplexity Pro einen Überblick über den Markt, sichtete die Top-Ergebnisse und stieß auf ein klassisches TMS. Eine separate Google-Suche brachte noch ein paar weitere Optionen hervor, und Laurels Head of Engineering war unabhängig davon ebenfalls auf Lingo.dev gestoßen.

Er evaluierte beide parallel.

„Dieses klassische TMS wirkte auf den ersten Blick wie ein wirklich slickes, solides Unternehmen“, sagt Nick. „Aber als wir genauer hingeschaut haben – auf das, was sie anbieten, und auf das, was wir brauchten –, gab es mit Blick auf die Geschwindigkeit und Qualität, die wir erreichen wollten, nur eine richtige Wahl.“

„Was ich besonders geschätzt habe, war, wie Lingo.dev aufgetreten ist – sie haben unsere Probleme verstanden, was wir erreichen wollten, und dafür Lösungen gefunden. Die Enterprise-Preise waren fair. Und das Versprechen bei Geschwindigkeit und Qualität war der entscheidende Faktor. Besonders herausgestochen ist der direkte Zugang. Wir sind in einem gemeinsamen Slack-Channel mit den Engineers, die die Plattform tatsächlich bauen. Wenn wir auf einen Sonderfall stoßen, dauert die Reaktion nur Stunden. Es fühlt sich fast so an, als wären sie Teil unseres Teams.“

Wie präzise ist KI-Lokalisierung bei juristischer und buchhalterischer Terminologie?#

Die Nutzer von Laurel sind Fachleute aus Recht und Buchhaltung. Eine deutsche UI, die für „billing rate“ oder „matter“ das falsche Wort verwendet, sieht nicht nur schlecht aus – sie untergräbt das Vertrauen in das gesamte Produkt. Juristische und buchhalterische Terminologie muss exakt sitzen.

Nick testete die Qualität mit echten Kunden. Die erste Version ging an nordische Kunden und an einen französischen Kunden. Das nordische Team hatte keinerlei Feedback. Der französische Kunde, ein Muttersprachler, fand nur zwei Ungenauigkeiten – das Team ergänzte sie sofort im Glossar. Seitdem gab es in Niederländisch, Portugiesisch, Spanisch und weiteren Sprachen keine Probleme mehr.

Wir haben die Qualität über sechs Monate hinweg in 12 Sprachen mit muttersprachlichen Kunden getestet. Insgesamt gemeldete Terminologieprobleme: zwei, beide noch am selben Tag durch Ergänzungen im Glossar behoben. Es stellte sich heraus, dass die Lokalisierungs-Engine mit einem konfigurierten Glossar konsistentere juristische Terminologie lieferte, als es eine von Grund auf selbst gebaute Übersetzungslogik vermocht hätte – denn die Engine setzt Begriffe über alle Sprachpaare hinweg gleichzeitig durch, etwas, das ein manueller Prozess nicht garantieren kann.

„Wir mussten das Glossar schon seit geraumer Zeit nicht mehr anpassen“, sagt Nick.

Wie lange dauert es, einem SaaS-Produkt eine neue Sprache hinzuzufügen?#

Wenn ein Customer Success Manager meldet, dass ein Kunde Portugiesisch in der UI braucht, landete diese Anfrage früher auf der Roadmap, wurde priorisiert, wartete auf einen Sprint – und dauerte Wochen.

Heute erstellt Nick ein Ticket, verweist als Vorlage auf ein früheres Ticket zur Ergänzung einer Sprache, richtet AI Tooling darauf aus und wartet. Das Tooling ergänzt dann die Sprache in der Konfiguration, aktualisiert den Sprachumschalter und öffnet einen PR. Ein Engineer prüft den PR und bringt ihn live, Lingo.dev übernimmt die kontinuierliche Lokalisierung auf Autopilot.

„Ein Tag bedeutet End-to-End – vom Schreiben des Tickets bis zum fertigen PR. Das heißt nicht, dass ich einen ganzen Tag daran sitze. Die meiste Zeit mache ich in der Zwischenzeit andere Dinge.“

Mit KI-Coding-Tools und der Lokalisierungsinfrastruktur von Lingo.dev kann Nick eine neue Sprache hinzufügen, ohne Engineering-Kapazität zu beanspruchen.

„Mit Lingo.dev kann heute jeder im Unternehmen neue Sprachen hinzufügen und unsere Lokalisierungs-Engine feinjustieren. Das ist schon ziemlich bemerkenswert.“

Wie beeinflusst die Geschwindigkeit der Lokalisierung das Tempo von Enterprise-Deals?#

Im Business Case geht es nicht primär darum, Engineering-Zeit zu sparen – auch wenn genau das passiert. Es geht darum sicherzustellen, dass wir schnell auf neue Expansionschancen reagieren können.

„Bei Enterprise-Kunden können Expansionschancen sehr schnell entstehen“, sagt Nick. „Unsere Kunden gewinnen in einem neuen Büro erste Traktion und wollen dort weiter ausrollen, wenn wir das Produkt schnell in ihrer Sprache bereitstellen können. Wir müssen in genau diesem Tempo problemlos reagieren können, um unser Wachstum fortzusetzen.“

Laurel startete mit fünf nordischen Sprachen plus Französisch, um die erste Expansion in Europa zu unterstützen. Seitdem kamen über Sales und Customer Success Anfragen für Portugiesisch, Spanisch und Niederländisch hinzu – und inzwischen laufen Gespräche über viele weitere Sprachen, während die Expansion über globale Standorte hinweg voranschreitet.

Wir haben nachgezählt: In den sechs Monaten nach der Integration ergänzte Laurel sieben Sprachen als Reaktion auf Expansionsanfragen von Kunden. Jede einzelne dauerte weniger als einen Tag. Im Modell „selbst bauen“ hätten diese sieben Sprachen rund 28 Engineering-Sprints verschlungen – Kapazität, die stattdessen in Kernfunktionen des Produkts geflossen ist.

Sollten Sie Lokalisierungsinfrastruktur selbst bauen oder kaufen?#

Auf die Frage, was er einem VP Product in einem ähnlichen Unternehmen raten würde – Enterprise-B2B, professionelle Nutzer, globale Expansion, ein Engineering-Team mit echter Produktarbeit – zögert Nick keine Sekunde.

„Ich würde mich zu 100 % für einen Anbieter entscheiden.“

Was sie beim Selbstbau unterschätzen würden: „Die Komplexität und die Qualität. Man weiß nicht, wie die Qualität am Ende ausfällt. Warum dieses Risiko eingehen?“

Was sie bei der Wahl eines Anbieters falsch machen würden: das eigene Problem nicht klar genug zu verstehen, um den richtigen auszuwählen. „Das Problem, das man lösen will, wirklich zu verstehen und den richtigen Anbieter genau für dieses Problem auszuwählen – das ist entscheidend.“

Was man zuerst testen sollte: „Die Geschwindigkeit und die Time-to-Market. Und sobald das initiale Setup steht, sind es Geschwindigkeit und Skalierbarkeit.“

Was Warten tatsächlich kostet#

Das initiale Setup lag größtenteils auf Laurels Seite: den Tech-Stack vorzubereiten. Danach gilt: ein Tag pro Sprache, kein Engineering-Sprint nötig, keine Verhandlungen über die Roadmap.

Die Alternative waren drei bis vier Monate Engineering-Zeit für den Aufbau, laufende Wartung auf Dauer und eine Qualität, die sie in Sprachen, die niemand im Team spricht, nicht garantieren konnten.

Nick bringt es einfach auf den Punkt: „Lokalisierungsinfrastruktur ist kein Projekt, das man abschließt und dann abhakt. Sie ist fortlaufend relevant – jedes Mal, wenn man skaliert, jedes Mal, wenn man einen neuen Markt betritt, jedes Mal, wenn man ein neues Feature hinzufügt. Es muss einfach sein. Ich möchte nicht immer wieder zum Engineering-Team zurückgehen und um noch einen Sprint bitten müssen, um alles zu liefern, was wir brauchen.“

Was das für Produktteams bedeutet, die in neue Märkte expandieren#

Laurels Erfahrung steht exemplarisch für ein Muster, das sich in B2B-SaaS-Unternehmen mit internationaler Enterprise-Nachfrage zeigt: Lokalisierung wird vom Feature-Wunsch zum Wachstumshemmnis. Die Frage lautet nicht mehr „Sollten wir lokalisieren?“, sondern „Wie schnell können wir dem nächsten Markt ein Ja geben?“

Drei Faktoren prägten Laurels Ansatz: Das Team konnte es sich nicht leisten, Engineering-Kapazitäten in Infrastruktur zu stecken, die nicht zum Kernprodukt gehört. Und die Qualität juristischer und buchhalterischer Terminologie musste sich verlässlich prüfen lassen – nicht nur angenommen werden.

Der Localization-Engineering-Ansatz behandelt Sprachunterstützung als Konfigurationsebene statt als Engineering-Projekt. Ein Produktmanager kann eine Sprache hinzufügen – ohne Sprint, ohne Engineering-Kapazitäten und ohne Abstimmung mit einem Übersetzungsanbieter. Für Teams, bei denen die Geschwindigkeit der Marktexpansion direkt über das Umsatzwachstum entscheidet, macht dieser operative Wandel den Unterschied zwischen einer genutzten Chance und einer verpassten Gelegenheit.

Laurel entwickelt KI für Fachkräfte aus Recht und Buchhaltung. Das Unternehmen stellt sein Produkt in über einem Dutzend Sprachen bereit – und kann eine neue Sprache innerhalb eines Tages hinzufügen. Die Lokalisierungsinfrastruktur läuft auf Lingo.dev.

Häufig gestellte Fragen#

Wie lange dauert es, einem SaaS-Produkt eine neue Sprache hinzuzufügen?

Laurel fügt eine neue Sprache end-to-end in etwa einem Tag hinzu. Ein Produktmanager erstellt ein Ticket mit Verweis auf eine frühere Spracherweiterung, setzt einen KI-Coding-Agenten darauf an, und ein Engineer prüft den PR. Kein dedizierter Sprint, keine Abstimmung mit Anbietern. Die frühere Alternative – die Lokalisierungsinfrastruktur intern aufzubauen – wurde auf vier bis sechs Monate geschätzt, bevor überhaupt eine Sprache live gehen konnte.

Sollte ein Startup Lokalisierungsinfrastruktur selbst entwickeln oder einkaufen?

Laurels Staff PM Nick Bazley verglich Eigenentwicklung und Zukauf. Sein Fazit: „Wir sind nicht die Experten für Lokalisierungsinfrastruktur. Wir wissen nicht, wie die Qualität ausfallen wird. Warum dieses Risiko eingehen, wenn jemand ein ganzes Unternehmen rund um Localization Engineering aufgebaut hat?“ Die Schätzung für die Eigenentwicklung: ein XXL-Projekt, das monatelang die Hälfte des Engineering-Teams gebunden hätte.

Wie präzise ist KI-Lokalisierung bei fachspezifischer Terminologie?

Laurel testete über sechs Monate hinweg in 12 Sprachen mit muttersprachlichen Kunden aus Recht und Buchhaltung. Gesamtzahl der Terminologieprobleme: zwei – beide noch am selben Tag durch Ergänzungen im Glossar behoben. Die Lokalisierungs-Engine stellt Glossarkonsistenz über alle Sprachpaare hinweg gleichzeitig sicher – etwas, das ein manueller Eigenbau in diesem Maßstab nicht garantieren kann.

Wie beeinflusst die Lokalisierungsgeschwindigkeit Enterprise-Vertriebszyklen?

Laurels Erfahrung: Enterprise-Kunden, die Unterstützung für eine neue Sprache anfragen, erwarten eine Antwort innerhalb von Tagen, nicht Monaten. Nick Bazley beschreibt die Dynamik so: „Die Gelegenheit bleibt nicht lange bestehen. Wenn wir es nicht innerhalb einer Woche umsetzen können, könnte sich das Zeitfenster schließen.“ Nach dem Wechsel auf Lokalisierungsinfrastruktur fügte Laurel in sechs Monaten sieben Sprachen hinzu – jede in weniger als einem Tag.

Wie sieht der Kostenvergleich zwischen Eigenentwicklung und Zukauf bei Lokalisierung aus?

Laurels Vergleich: eine kurze Integrationsphase und laufende nutzungsabhängige Kosten gegenüber vier bis sechs Monaten Engineering-Zeit für den Aufbau, plus unbefristete Wartung, plus eine Qualität, die sie nicht garantieren konnten. Die sieben in sechs Monaten hinzugefügten Sprachen hätten im Eigenentwicklungsmodell ungefähr 28 Engineering-Sprints verschlungen – Kapazitäten, die stattdessen in Kernprodukt-Features flossen.