A Laurel é a plataforma de inteligência do trabalho para serviços profissionais. Empresas usam a Laurel para automatizar o controle de horas, entender o que impulsiona a lucratividade e comprovar o ROI dos seus investimentos em IA. Até pouco tempo atrás, o produto existia só em inglês. Hoje, já está disponível em mais de uma dúzia de idiomas — idiomas nórdicos, francês, holandês, português, espanhol e coreano — com mandarim, tailandês, árabe, japonês e vietnamita no pipeline.

A integração da Laurel foi simples — a maior parte do esforço ficou do lado deles, extraindo e organizando as strings existentes para preparar a base de código. A alternativa de fazer o build internamente foi estimada em quatro a seis meses de engenharia, com manutenção contínua por tempo indefinido. Descobrimos que o custo total de não comprar era cerca de 10x maior do que o de comprar, considerando os contratos que poderiam escorregar. Agora, adicionar um novo idioma leva um dia — um product manager consegue fazer isso sozinho. Essa frase teria soado absurda dezoito meses atrás.

"Adorei a forma como a Lingo.dev chegou junto, entendeu nossos problemas e trouxe soluções. Não precisávamos construir uma infraestrutura de localização — eles resolveram isso perfeitamente. O preço enterprise foi justo, e estamos em um canal compartilhado no Slack com os engenheiros deles. O retorno para edge cases acontece em horas."

— Nick Bazley, Staff Product Manager, Laurel

Quando uma empresa SaaS deve investir em localização?#

Nick Bazley é Staff Product Manager na Laurel, onde passou os últimos seis anos liderando equipes de produto enquanto a empresa expandia seu produto globalmente. Ele já vinha pensando em localização havia cerca de um ano antes de isso acontecer.

"Sabíamos que, em algum momento, precisaríamos fazer isso", diz Nick. "A questão era: quando? Sempre que falávamos sobre isso, a conclusão era a mesma: vai ser um projeto XXL, vai demorar uma eternidade, e não vamos saber ao certo qual será a qualidade da entrega."

A Laurel estava crescendo, expandindo de clientes mid-market para empresas globais. E um padrão começou a se repetir: fechar com um cliente em uma região, provar valor e, depois, ver esse cliente querer expandir para outras regiões.

À medida que a equipe de vendas contratava pessoas pela Europa e customer success recebia pedidos de expansão, Nick já conseguia ver o problema se aproximando.

"Na época em que precisávamos fazer esse trabalho, éramos cerca de 50 pessoas. Assumir a construção da infraestrutura de localização por conta própria teria sido pedir demais — metade da equipe presa nisso por meses, quando ainda havia muita coisa que precisávamos construir para os nossos clientes."

Por que comprar infraestrutura de localização em vez de construir?#

A Laurel se viu diante de duas opções: comprar ou construir. Construir provavelmente exigiria um esforço de vários trimestres, com a estimativa interna classificando isso como um projeto XXL — de quatro a seis meses de engenharia. "Não é uma decisão inteligente assumir o custo, o tempo e o esforço de construir nossa própria infraestrutura de localização. A escolha mais sensata para o negócio, no estágio de crescimento em que estávamos, era comprar a melhor solução do mercado e focar na construção da nossa plataforma principal."

Nessa discussão, a decisão acabou girando em torno de quatro fatores principais: velocidade para chegar ao mercado, escalabilidade após o lançamento, customização e qualidade.

"Não somos especialistas em infraestrutura de localização. Não sabemos qual vai ser a qualidade. Então por que correr esse risco quando já existe quem tenha construído um negócio inteiro em torno da engenharia de localização?"

Como avaliar uma plataforma de localização versus um TMS legado#

Nick mapeou o mercado com uma busca rápida no Perplexity Pro, analisou os principais resultados e encontrou um TMS legado. Em uma busca separada no Google, apareceram mais algumas opções, e o Head of Engineering da Laurel encontrou a Lingo.dev de forma independente.

Ele conduziu avaliações em paralelo com os dois.

"Aquele TMS legado, à primeira vista, parecia um negócio muito bem-acabado e sólido", diz Nick. "Mas, quando fomos além da superfície do que eles ofereciam e do que a gente precisava, ficou claro que só havia uma escolha para a velocidade e a qualidade que buscávamos."

"O que eu gostei foi a forma como a Lingo.dev chegou junto — entendeu nossos problemas, o que estávamos tentando fazer e trouxe soluções. O preço enterprise foi justo. E a promessa de velocidade e qualidade foi o principal fator decisivo. O que mais se destacou foi o acesso. Estamos em um canal compartilhado no Slack com os engenheiros que realmente constroem a plataforma. Quando esbarramos em um edge case, o retorno vem em horas. Quase parece que eles fazem parte da nossa equipe."

Quão precisa é a localização com IA para terminologia jurídica e contábil?#

Os usuários da Laurel são profissionais das áreas jurídica e contábil. Uma interface em alemão com a palavra errada para "billing rate" ou "matter" não só passa uma má impressão — ela compromete a confiança no produto inteiro. A terminologia jurídica e contábil precisa ser exata.

Nick testou a qualidade com clientes reais. A primeira leva foi para clientes nórdicos e um cliente francês. A equipe nórdica não teve nenhum feedback. Já o cliente francês, falante nativo, apontou apenas duas imprecisões: a equipe adicionou tudo ao glossário no mesmo instante. Desde então, não houve problemas em holandês, português, espanhol etc.

Testamos a qualidade em 12 idiomas com clientes nativos ao longo de seis meses. Total de problemas terminológicos reportados: dois, ambos resolvidos no mesmo dia por meio de adições ao glossário. No fim, o engine de localização com um glossário configurado produziu uma terminologia jurídica mais consistente do que produziria um build da lógica de tradução do zero — porque o engine aplica os termos em todos os pares de idiomas ao mesmo tempo, algo que um processo manual não consegue garantir.

"Já faz um tempo que não precisamos voltar ao glossário para ajustar nada", diz Nick.

Quanto tempo leva para adicionar um novo idioma a um produto SaaS?#

Quando um customer success manager sinaliza que um cliente precisa de português na interface, esse pedido antes entrava no roadmap, era priorizado, esperava uma sprint e levava semanas.

Agora, Nick cria um ticket, usa um ticket anterior de adição de idioma como modelo, aponta o AI Tooling para ele e espera. A ferramenta então adiciona o idioma à config, atualiza o seletor de idiomas e abre um PR. Um engenheiro faz a revisão do PR, ele é publicado, e a Lingo.dev cuida da localização contínua no piloto automático.

"Um dia é o tempo end-to-end — desde escrever o ticket até o PR ficar pronto. Não significa que eu esteja trabalhando nisso por um dia inteiro. Na maior parte do tempo, estou fazendo outras coisas."

Com ferramentas de programação com IA e a infraestrutura de localização da Lingo.dev, Nick consegue adicionar um idioma sem consumir bandwidth de engenharia.

"Com a Lingo.dev, qualquer pessoa na empresa consegue adicionar novos idiomas agora e ajustar nossos engines de localização. Isso é realmente impressionante."

Como a velocidade da localização afeta a velocidade de fechamento de contratos enterprise?#

O business case não é sobre economizar tempo de engenharia — embora faça isso. É sobre garantir que possamos reagir rapidamente a oportunidades de expansão em constante evolução.

"Com clientes enterprise, a oportunidade de expansão pode surgir muito rápido", diz Nick. "Nossos clientes ganham tração em um novo escritório e querem expandir ali se conseguirmos disponibilizar o produto no idioma deles rapidamente. Precisamos conseguir responder nessa velocidade, sem problema nenhum, para continuar crescendo."

A Laurel começou com cinco idiomas nórdicos mais francês para apoiar sua primeira expansão na Europa. Desde então, vendas e customer success passaram a puxar pedidos de português, espanhol e holandês — e agora eles já estão em conversas sobre muitos outros à medida que se expandem por escritórios globais.

Nós fizemos as contas: nos seis meses após a integração, a Laurel adicionou sete idiomas em resposta a pedidos de expansão de clientes. Cada um levou menos de um dia. No modelo de fazer tudo internamente, esses sete idiomas teriam consumido aproximadamente 28 sprints de engenharia — capacidade que, em vez disso, foi direcionada para funcionalidades centrais do produto.

Vale mais a pena construir ou comprar infraestrutura de localização?#

Quando perguntam a Nick o que ele diria a um VP de Produto em uma empresa parecida — enterprise B2B, usuários profissionais, expansão global, equipe de engenharia com trabalho real de produto para fazer — ele não hesita.

"Eu iria com um fornecedor, sem pensar duas vezes."

O que essas empresas tendem a subestimar ao construir por conta própria: "A complexidade e a qualidade. Você não sabe qual vai ser a qualidade. Então por que correr esse risco?"

O que elas tendem a errar ao escolher um fornecedor: não entender com clareza suficiente o próprio problema para escolher o parceiro certo. "Entender de verdade o problema que você está resolvendo e escolher o fornecedor certo para aquele problema específico — isso é fundamental."

O que testar primeiro: "A velocidade e o tempo de entrada no mercado. Depois que a configuração inicial estiver feita, passam a ser a velocidade e a escalabilidade."

Quanto realmente custa esperar#

A configuração inicial ficou majoritariamente do lado da Laurel, preparando a stack de tecnologia. Depois disso: um dia por idioma, sem precisar de sprint de engenharia, sem negociação de roadmap.

A alternativa era de três a quatro meses de engenharia para fazer o build, manutenção contínua para sempre e uma qualidade que eles não conseguiriam garantir em idiomas que ninguém da equipe fala.

Nick resume de forma simples: "Infraestrutura de localização não é um projeto que termina e pronto. É algo contínuo — toda vez que você escala, toda vez que entra em um novo mercado, toda vez que adiciona uma nova funcionalidade. Isso precisa ser fácil. Não quero ficar voltando para a engenharia pedindo mais uma sprint para entregar tudo de que precisamos."

O que isso significa para equipes de produto que estão se expandindo para novos mercados#

A experiência da Laurel reflete um padrão comum em empresas B2B SaaS com demanda internacional de grandes contas: localização deixa de ser um pedido de funcionalidade e passa a ser um limitador de crescimento. A pergunta deixa de ser "devemos localizar?" e passa a ser "com que rapidez conseguimos dizer sim ao próximo mercado?"

Três fatores definiram a abordagem da Laurel: a equipe não podia se dar ao luxo de dedicar capacidade de engenharia a uma infraestrutura que não faz parte do seu produto principal. A qualidade da terminologia jurídica e contábil precisava ser verificável, não presumida.

A abordagem de engenharia de localização trata o suporte a idiomas como uma camada de configuração, e não como um projeto de engenharia. Um gerente de produto pode adicionar um idioma sem precisar de sprint, sem consumir banda da engenharia e sem coordenar com um fornecedor de tradução. Para equipes em que a velocidade de expansão para novos mercados determina o crescimento da receita, essa mudança operacional é a diferença entre aproveitar uma oportunidade e vê-la escapar.

A Laurel desenvolve IA para profissionais das áreas jurídica e contábil. Seu produto já está disponível em mais de uma dúzia de idiomas — e um novo idioma pode ser adicionado em um dia. Sua infraestrutura de localização roda com a Lingo.dev.

Perguntas frequentes#

Quanto tempo leva para adicionar um novo idioma a um produto SaaS?

A Laurel adiciona um novo idioma em aproximadamente um dia, de ponta a ponta. Um gerente de produto cria um ticket com base em uma adição anterior de idioma, aponta um agente de programação com IA para essa tarefa, e um engenheiro faz a revisão do PR. Sem sprint dedicado, sem coordenação com fornecedor. A alternativa anterior — construir a infraestrutura de localização internamente — foi estimada em quatro a seis meses antes que qualquer idioma pudesse ser lançado.

Uma startup deve construir ou comprar infraestrutura de localização?

Nick Bazley, Staff PM da Laurel, avaliou desenvolver internamente versus comprar. Sua conclusão: "Não somos especialistas em infraestrutura de localização. Não sabemos qual vai ser a qualidade. Por que correr esse risco quando alguém construiu um negócio inteiro em torno da engenharia de localização?" A estimativa de desenvolvimento era de um projeto XXL, que consumiria metade da equipe de engenharia por meses.

Quão precisa é a localização com IA para terminologia profissional?

A Laurel testou em 12 idiomas com clientes nativos das áreas jurídica e contábil ao longo de seis meses. Total de problemas de terminologia: dois — ambos resolvidos no mesmo dia com adições ao glossário. O engine de localização garante consistência de glossário em todos os pares de idiomas ao mesmo tempo — algo que uma implementação manual não consegue assegurar em escala.

Como a velocidade da localização afeta os ciclos de vendas enterprise?

A experiência da Laurel é clara: clientes enterprise que pedem suporte a novos idiomas esperam uma resposta em dias, não meses. Nick Bazley descreve a dinâmica: "A oportunidade não fica aberta por muito tempo. Se não conseguirmos resolver isso em uma semana, a janela pode se fechar." Depois de adotar uma infraestrutura de localização, a Laurel adicionou sete idiomas em seis meses — cada um em menos de um dia.

Qual é a comparação de custo entre construir e comprar localização?

A comparação da Laurel: um curto período de integração e um custo recorrente por consumo versus quatro a seis meses de tempo de engenharia para desenvolver, além de manutenção por tempo indeterminado e de uma qualidade que eles não podiam garantir. Os sete idiomas adicionados em seis meses teriam consumido aproximadamente 28 sprints de engenharia no modelo de desenvolvimento interno — capacidade que, em vez disso, foi direcionada para funcionalidades do produto principal.