Scribe macht E-Mail-Signaturen einfach und messbar: Unternehmen rollen unternehmensweit konsistente, markengerechte Signaturen aus, ohne Setup pro Mitarbeitenden, und machen die Signatur zu einem messbaren Umsatzkanal. Das Unternehmen ist fünf Jahre alt und hat einen starken Product-Market-Fit. Im Zuge eines kompletten Produkt-Rebuilds hat Scribe sein gesamtes Produkt und die komplette Dokumentation in 16 Sprachen veröffentlicht. Die Integration dauerte weniger als einen Tag; danach haben die beiden Gründer die Lokalisierung selbst gesteuert, ohne Neueinstellung und ohne Agentur. Sie konfigurierten die Engine – Glossar, Markenstimme, Anweisungen pro Sprache und KI-Qualitätsbewertung für jede Übersetzung – iterativ mit Claude über den MCP-Server von Lingo.dev.

"Lingo.dev hat uns eine Lokalisierungs-Engine gegeben, die wir per API, MCP und CLI direkt in unserem eigenen Stack betreiben. Für ein Engineering-first-Team ist das ein No-Brainer."

Clément Champau, CEO und Mitgründer, Scribe

Warum jetzt lokalisieren – nach fünf Jahren#

KI hat Lokalisierung für ein Zwei-Personen-Team praktikabel gemacht, und das Timing passte perfekt zu einem kompletten Produkt-Rebuild – neue UI, neue UX und ein idealer Moment, 16 Sprachen anzukündigen. Nach fünf Jahren hatte Scribe einen starken Product-Market-Fit und eine stabile UI erreicht, sodass Neuübersetzungen nicht an ständig wechselnden Interfaces scheitern würden.

Auch der Markt zog in dieselbe Richtung. Einige Enterprise-Käufer digitalisieren noch, statt bereits KI einzuführen, und in mehreren Märkten ist ein Produkt, das die lokale Sprache nicht spricht, ein Reibungspunkt im Vertriebsprozess. Scribe startete dort, wo der Umsatz lag: mit Französisch, einschließlich frankophonem Afrika, Spanisch mit Fokus auf Lateinamerika und Englisch. Diese drei decken den Großteil der westlichen Welt plus Lateinamerika ab. Danach ging es in die Märkte mit dem höchsten BIP – Schweiz, Norwegen, Schweden. "Höchstes BIP in Europa, höchstes BIP der Welt", sagte Clément.

Warum eine Engineering-first-Plattform den Ausschlag gab#

Clément entdeckte Lingo.dev im Y Combinator Directory; er hält gezielt Ausschau nach neuen YC-Tools und setzt sie früh ein. Ausschlaggebend war, wo die Plattform im Stack sitzt. Lingo.dev ist eine Plattform für Localization Engineering: eine konfigurierbare Lokalisierungs-Engine – mit Glossar, Markenstimme, Anweisungen pro Sprache und KI-Qualitätsbewertung, die das Ergebnis unabhängig bewertet – gesteuert über API, MCP-Server und CLI. Sie läuft auf der ersten Ebene des Entwicklungsprozesses, genau dort, wo Teams auch den Rest ihrer Infrastruktur betreiben.

"Wir wollten etwas direkt auf der allerersten Ebene des Entwicklungsprozesses. Du brauchst eine API, du brauchst ein MCP – und wenn das da ist, können wir so eine Art Lego ganz leicht in unseren Agenten-Workflow einstecken."

Gil, Scribes Mitgründer und CTO, las die API-Dokumentation, befand sie für solide und integrierte alles in weniger als einem Tag.

"Ich habe es Gil geschickt. Er hat die API-Doku gelesen, meinte, das sieht solide aus, und in weniger als einem Tag hatte er alles implementiert."

Wie der CEO die gesamte Engine über das MCP konfiguriert hat#

Nach der eintägigen Integration konfigurierte Clément die gesamte Engine selbst – Markenstimme, Glossar und Anweisungen pro Sprache – über den MCP-Server von Lingo.dev, obwohl er kein Entwickler ist. Die fertige Konfiguration war beachtlich: 16 Markenstimmen, 133 Anweisungen und 644 Glossarbegriffe.

Der Ablauf war ganz konkret. Er ließ eine Sprache laufen, öffnete die App, machte Screenshots und schickte sie über das MCP zurück: Hier wurde der Call-to-Action beschädigt, hier die UI. Claude justierte die drei Hebel – Glossar, Anweisungen, Markenstimme – so lange nach, bis das Ergebnis stimmte. Dann ließ er die vollständige Übersetzung laufen und rollte den Rest aus.

"Ich habe eine Sprache laufen lassen, mir die App angesehen, Screenshots gemacht und sie über das MCP zurückgeschickt – hier hat es den CTA beschädigt, hier die UI – und Claude hat Glossar, Anweisungen und Markenstimme so lange angepasst, bis es richtig war."

Der Agent übernahm innerhalb desselben Workflows auch selbst Initiative. Während der SEO-Optimierung der neu aufgebauten Homepage wies Claude darauf hin, dass Google die lokalisierten Seiten als Fallbacks der englischen Seite behandelte statt als eigenständige Sprachziele. Weil er per MCP Zugriff auf die Engine hatte, stieß er den Lingo.dev-Sync erneut an, um das zu korrigieren.

Wie validiert man Übersetzungsqualität in Sprachen, die man nicht spricht?#

Die Engine misst die Qualität ihrer eigenen Ausgabe. Über Scribes Runs hinweg lag die durchschnittliche KI-Qualitätsbewertung bei etwa 87 von 100, wobei rund 96 Prozent der bewerteten Übersetzungen 70 oder mehr erreichten – ein Qualitätssignal in 16 Sprachen, die die beiden Gründer selbst nicht lesen.

Scribe veröffentlicht bei rund 95 Prozent und sieht menschliches Post-Editing als den Weg, die letzte Lücke mit zunehmender Skalierung zu schließen. Die Logik dahinter ist einfach: Ein Produkt, das ein echtes Problem löst, verliert Nutzende nicht wegen einer Übersetzung, die noch nicht perfekt poliert ist.

"Selbst bei 95 Prozent ist es gut genug. Wenn du ein echtes Problem löst und der Nutzer die Lösung will, wird ihn eine Übersetzung, die nicht perfekt ist, nicht davon abhalten, das Produkt zu nutzen."

Lokalisierung selbst bauen oder einkaufen?#

Clément empfahl Lingo.dev einem seiner Investoren, einem CTO, der Lokalisierung bereits inhouse aufgebaut hatte. Die Reaktion beantwortete die Build-versus-Buy-Frage endgültig.

"Ich habe Lingo.dev einem unserer Investoren empfohlen, der auch CTO ist. Er hatte Lokalisierung inhouse aufgebaut, und seine Reaktion war: Genau das hätten wir nutzen sollen. Wenn ich das gewusst hätte, hätte ich in sie investiert."

Die Kosten, die Scribe überrascht haben, lagen nicht im initialen Aufbau. Es war die Wartung – die Edge Cases, die unaufhörlich auftauchen, und die laufenden Entscheidungen darüber, wie sich das System weiter verbessern lässt.

"Nichts ist einfach. Sobald man anfängt, all diese Edge Cases zu behandeln – und sie hören nie auf –, kostet die Wartung echte Zeit. Es ist besser, etwas Engineering-first anzudocken und zu wissen, dass ein Team rund um die Uhr daran arbeitet."

Wenn KI die Arbeit ausführt, verschiebt sich der Wert dorthin, wo das System entworfen wird. Die Lokalisierungs-Engine – Glossar, Markenstimme, Anweisungen und KI-Qualitätsbewertung – ist eine Architektur, die ein internes Team unter Zeitdruck wahrscheinlich nicht so gut designen würde.

Reibung bei der Abrechnung – und die Lösung#

Am Anfang war die Kostentransparenz begrenzt. Clément musste einen Run starten und die Oberfläche aktualisieren, um sicherzugehen, dass die Credits nicht mitten im Run ausgehen; wenn sie ausgingen, stoppte der Run und er musste ihn neu starten. Er sprach das an, und die Verbesserungen wurden noch in derselben Woche ausgerollt: eine Kostenschätzung vor dem Run und ein Nutzungsindikator mit Auto-Top-up.

"Jetzt kann ich sehen, wie lange ein Run dauert und was er kosten wird, bevor ich ihn starte. Früher musste ich einen Run starten und ständig aktualisieren, um sicherzugehen, dass die Credits nicht ausgehen, denn wenn sie weg waren, stoppte alles und wir mussten neu starten."

Die Änderung machte die Ergebnisse im Voraus planbar – Laufzeit und Kosten sind bekannt, bevor ein Run beginnt. Den Kontrast beschrieb er so: statt eine Anfrage einzureichen und zu warten, sah er die gewünschte Änderung innerhalb derselben Woche live gehen. "Glückwunsch zur schnellen Iterationsschleife", sagte er.

Wo es heute steht#

Scribe betreibt vier Apps – Web-App, Desktop-App und weitere – plus die eigene Dokumentation, alles ausgehend von Englisch, alles über eine einzige Lokalisierungs-Engine. Autosync ist vorerst deaktiviert; Gil stößt Runs nach größeren Pushes manuell an – eine Gewohnheit aus einem frühen Credit-Problem, verstärkt dadurch, dass nach dem großen Release nur wenige Änderungen folgten. Der Plan ist, Autosync einzuschalten, sobald alles vollständig stabil ist, sodass ein einzelner Push in jede App und die Doku ausgerollt wird.

Der MCP-Server ist einer von drei Zugängen zur Plattform – neben API und CLI. Die meisten MCPs sind read-only oder durch Kontext begrenzt; der von Lingo.dev ermöglicht es auch Nicht-Entwicklern, die gesamte Lokalisierungs-Engine zu konfigurieren. So konnte Gil nach dem eintägigen Setup direkt weitermachen.

"Ich habe gar nicht so viel Zeit in der Oberfläche verbracht, aber sie hat es gut gemacht."

Die Engine übernahm die Übersetzung, Clément die Konfiguration.

Was das für kleine Teams bedeutet, die Software lokalisieren#

Scribes Rollout deutet auf ein Muster hin, das weit über E-Mail-Signaturen hinausgeht. Für ein Engineering-first-Team hat sich Lokalisierung von einem Arbeitsproblem zu einem Systemdesign-Problem verschoben. Die Übersetzung übernehmen Modelle; die verbleibende Arbeit besteht darin, die Engine zu konfigurieren, die sie steuert – mit Glossar, Markenstimme, Anweisungen pro Sprache und KI-Qualitätsbewertung, die das Ergebnis bewertet.

Dieser Wandel verändert die Build-versus-Buy-Rechnung. Der teure Teil von inhouse aufgebauter Lokalisierung war nie die erste Version – sondern die Wartung: Edge Cases, Modelländerungen und die sprachspezifischen Regeln, die sich mit der Zeit ansammeln. Eine Plattform für Lokalisierungs-Engineering fängt all das ab. Genau deshalb kann ein Zwei-Personen-Team 16 Sprachen ohne dedizierte Lokalisierungsrolle betreiben.

Drei Bedingungen machen das auf andere Teams übertragbar. Der Quellcontent liegt in der Versionskontrolle. Die Engine wird über API, CLI und MCP-Server gesteuert und fügt sich damit nahtlos in den Workflow ein, den ein Team ohnehin schon nutzt. Und KI-Qualitätsbewertung macht Ergebnisse in Sprachen messbar, die niemand im Team spricht – der Unterschied zwischen blindem Vertrauen in eine Übersetzung und ihrer Verifizierung.

In ihren eigenen Worten#

"Weil KI inzwischen so gut ausführt, liegt der Wert jetzt auf der Seite des Architekten – der beste Systemdesigner gewinnt. Hätte ich es selbst gebaut, hätte ich kein so gutes System entworfen."

"Ich habe Lingo.dev einem unserer Investoren empfohlen, der auch CTO ist. Er hatte Lokalisierung inhouse aufgebaut, und seine Reaktion war: Genau das hätten wir nutzen sollen. Wenn ich das gewusst hätte, hätte ich in sie investiert."

"Lass eine Sprache für den Markt laufen, den du erschließen willst. Implementiere es, teste das MCP – es erledigt den Job von selbst. Der eigentliche Aha-Moment ist das MCP."

Clément Champau, CEO und Mitgründer, Scribe

Scribe ist die E-Mail-Signatur-Plattform, mit der Tausende Unternehmen unternehmensweit einheitliche, markengerechte Signaturen ausrollen – ohne Setup pro Mitarbeiter – und daraus einen messbaren Umsatzkanal machen. Zwei Gründer betreiben Produkt und Dokumentation in 16 Sprachen, konfiguriert als eine einzige Lokalisierungs-Engine, die sie wie den Rest ihrer Infrastruktur betreiben. Ihre Lokalisierung läuft auf Lingo.dev.

Häufig gestellte Fragen#

Wie lange dauert es, eine Lokalisierungs-Engine zu integrieren?

Weniger als einen Tag. Der CTO von Scribe las die API-Dokumentation, befand sie für überzeugend und band die Lingo.dev API in weniger als einem Tag in den bestehenden Agenten-Workflow ein. Die Konfiguration der Engine – Glossar, Markenstimme und Anweisungen pro Sprache – erfolgte anschließend separat, gesteuert vom CEO über den MCP-Server.

Kann auch jemand ohne Entwicklerhintergrund eine Lokalisierungs-Engine konfigurieren?

Ja. Nach der eintägigen Integration konfigurierte der CEO von Scribe – technisch versiert, aber kein Entwickler – die komplette Engine selbst über den MCP-Server von Lingo.dev: Er ließ eine Sprache laufen, prüfte die App und ließ Claude Glossar, Anweisungen und Markenstimme so lange anpassen, bis die Ergebnisse stimmten. Die fertige Konfiguration umfasste 16 Markenstimmen, 133 Anweisungen und 644 Glossarbegriffe.

Wie validiert man Übersetzungsqualität in Sprachen, die man nicht spricht?

Scribe setzt auf KI-Qualitätsbewertungen: Jede Übersetzung wird von einem Modell bewertet, das unabhängig von dem Modell ist, das sie erzeugt hat. Über alle Durchläufe hinweg lag der Durchschnittswert bei etwa 87 von 100, und rund 96 Prozent der Übersetzungen erreichten 70 Punkte oder mehr. So erhält ein Zwei-Personen-Team ein messbares Qualitätssignal in 16 Sprachen, die es selbst nicht lesen kann, während menschliches Post-Editing den letzten Feinschliff übernimmt.

Sollte man Lokalisierung selbst bauen oder kaufen?

Scribe besteht aus zwei technischen Gründern, die Lokalisierung auch intern hätten aufbauen können. Sie entschieden sich für eine Plattform, nachdem sie nicht den initialen Build, sondern den laufenden Wartungsaufwand abgewogen hatten. Einer ihrer Investoren, ein CTO, der genau das intern gebaut hatte, brachte es auf den Punkt: Genau das hätten wir nutzen sollen. Die Kosten, die sich mit der Zeit summieren, entstehen durch Sonderfälle und sprachspezifische Regeln – nicht durch die erste Version.

Was macht ein Localization Engineer eigentlich?

Weniger übersetzen, mehr konfigurieren. Bei Scribe ging es darum, die Engine einzurichten – Glossar, Markenstimme, Anweisungen pro Sprache – und sie anhand von KI-Qualitätswerten zu optimieren, statt Übersetzer oder Dateien zu verwalten. Die Rolle ist näher am Platform Engineering als an der Koordination von Dienstleistern: Man entwirft und betreibt das System, das Übersetzungen erzeugt, statt die Menschen zu steuern, die sie erstellen.

Was würdest du einem Kollegen sagen, der das gerade evaluiert?

"Startet mit einer Sprache für den Markt, den ihr erschließen wollt. Setzt es auf, testet das MCP – es macht den Job praktisch von selbst. Der eigentliche Aha-Moment ist das MCP."