Scribe makes email signatures simple and measurable: a company rolls out consistent, on-brand signatures company-wide, with no per-employee setup, and turns the signature into a measurable revenue channel. The company is five years old and carries strong product-market fit. During a full product rebuild, Scribe shipped its entire product and documentation in 16 languages. The integration took less than a day; from there, two founders ran the localization themselves, with no hire and no agency. They configured the engine – glossary, brand voice, per-locale instructions, and AI quality scoring on every translation – by iterating with Claude through Lingo.dev's MCP server.

"Lingo.dev gave us a localization engine we run from an API, an MCP, and a CLI, right inside our own stack. For an engineering-first team, it's a no-brainer."

Clément Champau, CEO and Co-Founder, Scribe

Why localize now, after five years#

AI made localization practical for a two-person team, and the timing aligned with a full product rebuild – new UI, new UX, and a natural moment to announce 16 languages. After five years, Scribe had reached strong product-market fit and a stable UI, so retranslation would not break on constant interface churn.

The market pulled in the same direction. Some enterprise buyers are still digitalizing rather than adopting AI, and in several markets a product that does not speak the local language is friction in the sales process. Scribe started where the revenue was: French, including Francophone Africa; Spanish, LatAm-first; and English. Those three cover most of the Western world plus Latin America. From there it moved to the highest-GDP markets – Switzerland, Norway, Sweden. "Highest GDP in Europe, highest GDP in the world," Clément said.

Why an engineering-first platform was the deciding factor#

Clément found Lingo.dev through the Y Combinator directory; he watches for new YC tools and adopts early. What decided it was where the platform sat in the stack. Lingo.dev is a localization engineering platform: a configurable localization engine – glossary, brand voice, per-locale instructions, and AI quality scoring that independently grades the output – driven by an API, an MCP server, and a CLI. It runs at the first layer of the development process, the same way a team runs the rest of its infrastructure.

"We wanted something at the very first layer of the development process. You need an API, you need an MCP – and once you have that, we can plug that kind of Lego into our agent workflow very easily."

Gil, Scribe's co-founder and CTO, read the API documentation, judged it sound, and integrated everything in under a day.

"I sent it to Gil. He read the API docs, said it looked legit, and in under a day he had implemented everything."

How the CEO configured the entire engine through the MCP#

After the one-day integration, Clément configured the entire engine himself – brand voice, glossary, and per-locale instructions – through Lingo.dev's MCP server, despite not being a developer. The finished configuration was substantial: 16 brand voices, 133 instructions, and 644 glossary terms.

The loop was concrete. He ran one language, opened the app, took screenshots, and sent them back through the MCP: here it broke the call to action, here it broke the UI. Claude adjusted the three levers – glossary, instructions, brand voice – until the output held. Then he ran the full translation and rolled out the rest.

"I would run one language, look at the app, take screenshots, and send them back through the MCP – here it broke the CTA, here it broke the UI – and Claude would adapt the glossary, the instructions, and the brand voice until it was right."

The agent took initiative inside the same workflow. While optimizing SEO on the rebuilt homepage, Claude flagged that Google was treating the localized pages as fallbacks of the English page rather than independent locale targets. Because it had MCP access to the engine, it re-ran the Lingo.dev sync to correct it.

How do you validate translation quality in languages you don't speak?#

The engine measures its own output. Across Scribe's runs, AI quality scoring averaged about 87 out of 100, with roughly 96 percent of scored translations at 70 or above – a quality signal in 16 languages that two founders do not personally read.

Scribe ships at roughly 95 percent and treats human post-editing as the path to close the final gap as it scales. The reasoning is straightforward: a product that solves a real problem does not lose the user to a translation that is not perfectly polished.

"Even at 95 percent it is good enough. If you are solving a real problem and the user wants the solution, a translation that is not perfect will not stop them from using the product."

Should you build or buy localization?#

Clément recommended Lingo.dev to one of his investors, a CTO who had already built localization in-house. The reaction settled the build-versus-buy question.

"I recommended Lingo.dev to one of our investors, who is also a CTO. He had built localization in-house, and his reaction was: this is exactly what we should have used. If I had known, I would have invested in them."

The cost that surprised Scribe was not the initial build. It was the maintenance – the edge cases that never stop arriving, and the ongoing decision-making about how to improve the system.

"Nothing is easy. Once you start handling all the edge cases – and they never stop coming – it takes real time to maintain. It is better to plug in something engineering-first and know there is a team working on it around the clock."

With AI executing the work, the value moves to whoever designs the system. The localization engine – glossary, brand voice, instructions, and AI quality scoring – is an architecture an in-house team building under deadline is unlikely to design as well.

The billing friction, and the fix#

Early on, cost visibility was thin. Clément had to launch a run and refresh the interface to confirm the credits would not run out mid-run; when they did, the run stopped and he restarted it. He raised it, and the fixes shipped the same week: a pre-run cost estimate and an auto-top-up usage indicator.

"Now I can see how long a run takes and what it will cost before I start it. Before, I had to launch a run and keep refreshing to make sure the credits did not run out, because when they did, everything stopped and we had to restart."

The change let him project the output in advance – runtime and cost known before a run begins. The contrast he drew was between filing a request and waiting, and seeing the requested change ship within the week. "Congrats on the fast iteration loop," he said.

Where it stands now#

Scribe runs four apps – web app, desktop app, and others – plus its documentation, all from English, all through a single localization engine. Autosync is off for now; Gil triggers runs manually after major pushes, a habit carried over from an early credit issue and reinforced by how few changes followed the big release. The plan is to turn autosync on once everything is fully stable, so that a single push deploys to every app and the docs.

The MCP server is one of three ways into the platform, alongside the API and the CLI. Most MCPs are read-only or limited by context; Lingo.dev's let a non-developer configure the entire localization engine, which freed Gil to move on after the one-day setup.

"I didn't even spend so much time in the interface, but it did it well."

The engine handled the translation; Clément handled the configuration.

What this means for small teams localizing software#

Scribe's rollout points to a pattern beyond email signatures. For an engineering-first team, localization has shifted from a labor problem to a system-design problem. The translation is handled by models; the work that remains is configuring the engine that governs them – the glossary, the brand voice, the per-locale instructions, and the AI quality scoring that grades the output.

That shift changes the build-versus-buy math. The expensive part of in-house localization was never the first version – it was the maintenance: the edge cases, the model changes, and the per-locale rules that accumulate over time. A localization engineering platform absorbs that, which is why a two-person team can run 16 languages without a dedicated localization hire.

Three conditions make it generalize to other teams. Source content lives in version control. The engine is driven by an API, a CLI, and an MCP server, so it plugs into the workflow a team already runs. And AI quality scoring makes output measurable in languages no one on the team speaks – the difference between trusting a translation and verifying one.

In their words#

"With AI executing so well, the value is on the architect's side now – the best system designer wins. If I had built it myself, I would not have designed as good a system."

"I recommended Lingo.dev to one of our investors, who is also a CTO. He had built localization in-house, and his reaction was: this is exactly what we should have used. If I had known, I would have invested in them."

"Run one language for the market you want to open. Implement it, test the MCP – it does the job itself. The aha moment is really the MCP."

Clément Champau, CEO and Co-Founder, Scribe

Scribe is the email-signature platform thousands of companies use to roll out consistent, on-brand signatures company-wide, with no per-employee setup, and turn them into a measurable revenue channel. Two founders run its product and documentation in 16 languages, configured as a single localization engine they operate like the rest of their infrastructure. Their localization runs on Lingo.dev.

Frequently asked questions#

How long does it take to integrate a localization engine?

Under a day. Scribe's CTO read the API documentation, judged it sound, and wired the Lingo.dev API into the existing agent workflow in less than a day. Configuration of the engine – glossary, brand voice, and per-locale instructions – then happened separately, driven by the CEO through the MCP server.

Can a non-developer configure a localization engine?

Yes. After the one-day integration, Scribe's CEO – technical but not a developer – configured the entire engine himself through Lingo.dev's MCP server: running one language, reviewing the app, and having Claude adjust the glossary, instructions, and brand voice until the output held. The finished configuration ran to 16 brand voices, 133 instructions, and 644 glossary terms.

How do you validate translation quality in languages you don't speak?

Scribe relies on AI quality scoring: every translation is graded by a model independent of the one that produced it. Across Scribe's runs the average score was about 87 out of 100, with roughly 96 percent of translations scoring 70 or above. That gives a two-person team a measurable quality signal in 16 languages they do not personally read, with human post-editing reserved to close the final gap.

Should you build or buy localization?

Scribe is two technical founders who could have built localization in-house. They chose a platform after weighing the maintenance, not the initial build. One of their investors, a CTO who had built it in-house, put it plainly: this is exactly what we should have used. The cost that compounds is the edge cases and per-locale rules over time, not the first version.

What does a localization engineer actually do?

Less translating, more configuring. At Scribe the work was setting up the engine – glossary, brand voice, per-locale instructions – and tuning it against AI quality scores, rather than managing translators or files. The role looks closer to platform engineering than to vendor coordination: you design and operate the system that produces translations, instead of managing the people who produce them.

What would you tell a peer evaluating it?

"Run one language for the market you want to open. Implement it, test the MCP – it does the job itself. The aha moment is really the MCP."