A Laurel é a plataforma de work intelligence para serviços profissionais. As empresas usam a Laurel para automatizar o registo de horas, perceber o que está a impulsionar a rentabilidade e provar o ROI dos seus investimentos em IA. Até há pouco tempo, o produto só estava disponível em inglês. Hoje, está disponível em mais de uma dúzia de idiomas — idiomas nórdicos, francês, neerlandês, português, espanhol, 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, a extrair e organizar strings já existentes para preparar a base de código. A alternativa de desenvolver internamente estava estimada em quatro a seis meses de tempo de engenharia, com manutenção contínua por tempo indeterminado. Concluímos que o custo total de não comprar era cerca de 10x superior ao de comprar, quando se contabilizavam os negócios que teriam ficado pelo caminho. Agora, adicionar um novo idioma demora um dia — e um product manager consegue fazê-lo sozinho. Há dezoito meses, esta frase teria soado absurda.

"Adorei a forma como a Lingo.dev entrou, percebeu os nossos problemas e apresentou soluções. Não precisámos de criar infraestrutura de localização — resolveram isso na perfeição. O preço enterprise era justo e estamos num canal partilhado de Slack com os engenheiros deles. O tempo de resposta para casos limite mede-se em horas."

– Nick Bazley, Staff Product Manager, Laurel

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

Nick Bazley é Staff Product Manager na Laurel, onde passou os últimos seis anos a liderar equipas de produto à medida que a empresa escalava o produto a nível global. Andou a pensar na localização durante cerca de um ano antes de ela avançar.

"Sabíamos que íamos precisar de fazer isto a certa altura", diz Nick. "A questão era: quando? Sempre que falávamos sobre isso, a conclusão era sempre a mesma: vai ser um projeto XXL, vai demorar imenso tempo e não vamos saber ao certo qual será a qualidade do resultado."

A Laurel estava a crescer, a expandir-se de clientes mid-market para empresas globais. E surgiu um padrão: fechavam com um cliente numa região, provavam valor e, depois, esse cliente queria expandir-se para outras regiões.

À medida que a equipa de vendas reforçava a contratação por toda a Europa e a equipa de customer success recebia pedidos de expansão, Nick percebia o problema a aproximar-se.

"Na altura em que precisávamos de fazer este trabalho, éramos cerca de 50 pessoas. Assumir nós próprios a criação da infraestrutura de localização teria sido um enorme pedido — metade da equipa ocupada durante meses, quando havia muito mais para desenvolver para os nossos clientes."

Porquê comprar infraestrutura de localização em vez de a desenvolver internamente?#

A Laurel estava perante duas opções: comprar ou desenvolver. Desenvolver seria, muito provavelmente, um esforço de vários trimestres, com a estimativa interna a apontar para um projeto XXL — quatro a seis meses de tempo de engenharia. "Não é uma decisão inteligente assumir o custo, o tempo e o esforço de desenvolver a nossa própria infraestrutura de localização. A escolha sensata para o negócio, na fase de crescimento em que estávamos, era comprar a melhor solução do mercado e focarmo-nos antes na nossa plataforma principal."

Nesta discussão, os principais fatores que fizeram pender a decisão resumiram-se a quatro pontos: rapidez de entrada no mercado, escalabilidade após o lançamento, personalização e qualidade.

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

Como avaliar uma plataforma de localização face a um TMS legacy#

Nick mapeou o mercado com uma pesquisa rápida no Perplexity Pro, analisou os principais resultados e encontrou um TMS legacy. Uma pesquisa separada no Google revelou mais algumas opções, e o Head of Engineering da Laurel já tinha encontrado a Lingo.dev de forma independente.

Fez avaliações em paralelo com ambos.

"À superfície, esse TMS legacy parecia um negócio muito polido e sólido", diz Nick. "Mas, quando fomos mais a fundo no que eles tinham e no que nós precisávamos, para a rapidez e a qualidade que procurávamos só havia uma escolha."

"O que apreciei foi a forma como a Lingo.dev entrou — percebeu os nossos problemas, o que estávamos a tentar fazer, e apresentou soluções. O preço enterprise era justo. E a promessa de rapidez e qualidade foi o principal fator de decisão. O que mais se destacou foi o acesso. Estamos num canal partilhado de Slack com os engenheiros que realmente constroem a plataforma. Quando nos deparamos com um caso limite, o tempo de resposta mede-se em horas. Quase parece que fazem parte da nossa organização."

Quão precisa é a localização com IA para terminologia jurídica e contabilística?#

Os utilizadores da Laurel são profissionais das áreas jurídica e contabilística. Uma interface em alemão que use a palavra errada para "billing rate" ou "matter" não só causa má impressão, como compromete a confiança em todo o produto. A terminologia jurídica e contabilística tem de ser exata.

Nick testou a qualidade com clientes reais. A primeira versão foi para clientes nórdicos e para um cliente francês. A equipa nórdica não deu qualquer feedback. O cliente francês, falante nativo, detetou apenas duas imprecisões: a equipa adicionou-as imediatamente ao glossário. Desde então, não houve problemas em neerlandês, português, espanhol, etc.

Testámos a qualidade em 12 idiomas com clientes nativos ao longo de seis meses. Total de problemas terminológicos reportados: dois, ambos resolvidos no próprio dia através de adições ao glossário. Acabou por se verificar que o motor de localização com um glossário configurado produzia uma terminologia jurídica mais consistente do que desenvolver lógica de tradução de raiz — porque o motor aplica os termos em todos os pares de idiomas em simultâneo, algo que um processo manual não consegue garantir.

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

Quanto tempo demora 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 costumava entrar no roadmap, ser priorizado, esperar por um sprint e demorar semanas.

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

"Um dia é o processo do início ao fim — desde escrever o ticket até o PR ficar concluído. Não significa que eu esteja a trabalhar nisso durante um dia inteiro. Na maior parte desse tempo, estou a fazer 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 capacidade de engenharia.

"Com a Lingo.dev, qualquer pessoa na empresa pode agora adicionar novos idiomas e afinar os nossos motores de localização. Isso é bastante notável."

Como é que a velocidade da localização afeta a velocidade dos negócios enterprise?#

O argumento de negócio não tem a ver com poupar tempo de engenharia — embora também o faça. Tem a ver com garantir que conseguimos reagir rapidamente à evolução das oportunidades de expansão.

"Com clientes enterprise, a oportunidade de expansão pode surgir rapidamente", diz Nick. "Os nossos clientes ganham tração num novo escritório e querem expandir-se nesse mercado se conseguirmos disponibilizar rapidamente o produto no idioma deles. Precisamos de conseguir reagir a essa velocidade sem qualquer problema para continuarmos a crescer."

A Laurel começou com cinco idiomas nórdicos mais francês para apoiar a sua primeira expansão europeia. Desde então, as equipas de vendas e de customer success geraram pedidos para português, espanhol e neerlandês — e agora estão em conversações sobre muitos mais, à medida que a empresa se expande por escritórios em todo o mundo.

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 demorou menos de um dia. No modelo de desenvolvimento interno, esses sete idiomas teriam consumido aproximadamente 28 sprints de engenharia — capacidade que foi, em vez disso, canalizada para funcionalidades core do produto.

Deve desenvolver ou comprar infraestrutura de localização?#

Quando lhe perguntam o que diria a um VP of Product de uma empresa semelhante — B2B enterprise, utilizadores profissionais, expansão global, equipa de engenharia com trabalho real de produto para fazer — Nick não hesita.

"Eu escolheria um fornecedor, sem qualquer dúvida."

Aquilo que subestimariam ao desenvolver internamente: "A complexidade e a qualidade. Não sabes qual vai ser a qualidade. Porque haverias de correr esse risco?"

Aquilo em que se enganariam ao escolher um fornecedor: não compreender suficientemente bem o seu próprio problema para escolher o certo. "Compreender verdadeiramente o problema que estás a resolver e escolher o fornecedor certo para esse problema específico — isso é crítico."

O que testar primeiro: "A rapidez e o time to market. Depois, assim que tiveres concluído a configuração inicial, é a rapidez e a escalabilidade."

Quanto custa realmente esperar#

A configuração inicial ficou, na sua maioria, do lado da Laurel, ao preparar a stack tecnológica. Depois disso: um dia por idioma, sem necessidade de sprint de engenharia, sem negociação de roadmap.

A alternativa era três a quatro meses de tempo de engenharia para desenvolver, manutenção contínua para sempre e uma qualidade que não conseguiam garantir em idiomas que ninguém na equipa fala.

Nick resume de forma simples: "A infraestrutura de localização não é um projeto que se conclui e depois se esquece. É contínua — sempre que se escala, sempre que se entra num novo mercado, sempre que se adiciona uma nova funcionalidade. Tem de ser fácil. Não quero estar sempre a voltar à engenharia para pedir mais um sprint para entregar tudo o que precisamos."

O que isto significa para equipas de produto em expansão para novos mercados#

A experiência da Laurel reflete um padrão comum nas empresas B2B SaaS com procura internacional por parte de grandes empresas: a localização deixa de ser um pedido de funcionalidade e passa a ser um travão ao 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 equipa não podia dar-se ao luxo de alocar capacidade de engenharia a uma infraestrutura que não faz parte do seu produto principal. A qualidade da terminologia jurídica e contabilística tinha de ser verificável, não presumida.

A abordagem de engenharia de localização trata o suporte de idiomas como uma camada de configuração, e não como um projeto de engenharia. Um gestor de produto pode adicionar um idioma sem sprint, sem capacidade de engenharia e sem ter de coordenar com um fornecedor de tradução. Para equipas em que a velocidade de expansão para novos mercados determina o crescimento da receita, esta 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 contabilística. Disponibiliza o seu produto em mais de uma dúzia de idiomas — e consegue acrescentar um novo num só dia. A sua infraestrutura de localização funciona com a Lingo.dev.

Perguntas frequentes#

Quanto tempo demora a adicionar um novo idioma a um produto SaaS?

A Laurel adiciona um novo idioma em aproximadamente um dia, de ponta a ponta. Um gestor de produto cria um ticket com referência a uma adição anterior de idioma, indica-o a um agente de programação com IA, e um engenheiro faz a revisão do PR. Sem sprint dedicado, sem coordenação com fornecedores. A alternativa anterior — criar internamente a infraestrutura de localização — estava estimada em quatro a seis meses antes de ser possível lançar qualquer idioma.

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

Nick Bazley, Staff PM da Laurel, avaliou a opção de desenvolver internamente face à compra. A sua conclusão: "Não somos especialistas em infraestrutura de localização. Não sabemos qual vai ser a qualidade. Porque haveríamos de correr esse risco quando alguém construiu um negócio inteiro em torno da engenharia de localização?" A estimativa para o desenvolvimento interno apontava para um projeto XXL que consumiria metade da equipa de engenharia durante meses.

Qual é a precisão da localização com IA para terminologia profissional?

A Laurel testou em 12 idiomas com clientes nativos das áreas jurídica e contabilística ao longo de seis meses. Total de problemas de terminologia: dois, ambos resolvidos no próprio dia através de adições ao glossário. O motor de localização garante consistência do glossário em todos os pares de idiomas em simultâneo — algo que um desenvolvimento manual não consegue assegurar à escala.

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

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

Como se comparam os custos de criar vs. comprar infraestrutura de localização?

A comparação da Laurel: um curto período de integração e um custo contínuo por consumo, versus quatro a seis meses de tempo de engenharia para desenvolver, mais manutenção por tempo indeterminado, mais uma qualidade que não conseguiam garantir. Os sete idiomas adicionados em seis meses teriam consumido aproximadamente 28 sprints de engenharia no modelo de desenvolvimento interno — capacidade que acabou por ser canalizada para funcionalidades do produto principal.