Laurel es la plataforma de inteligencia del trabajo para servicios profesionales. Los despachos usan Laurel para automatizar el control del tiempo, entender qué impulsa la rentabilidad y demostrar el ROI de sus inversiones en IA. Hasta hace poco, el producto solo estaba disponible en inglés. Hoy se ofrece en más de una docena de idiomas —nórdicos, francés, neerlandés, portugués, español y coreano—, con mandarín, tailandés, árabe, japonés y vietnamita en preparación.

La integración de Laurel fue sencilla: la mayor parte del esfuerzo recayó de su lado, extrayendo y organizando las cadenas existentes para preparar la base de código. La alternativa de desarrollarlo internamente se estimó en entre cuatro y seis meses de trabajo de ingeniería, con mantenimiento continuo de forma indefinida. Vimos que el coste total de no comprar era aproximadamente 10 veces mayor que el de comprar, una vez tenidos en cuenta los acuerdos que se habrían retrasado. Ahora, añadir un nuevo idioma lleva un día: un product manager puede hacerlo por su cuenta. Esa frase habría sonado absurda hace dieciocho meses.

"Me encantó cómo Lingo.dev se implicó, entendió nuestros problemas y aportó soluciones. No tuvimos que montar infraestructura de localización: lo resolvieron a la perfección. El precio enterprise era justo y compartimos un canal de Slack con sus ingenieros. El tiempo de respuesta para los casos límite es de horas."

– Nick Bazley, Staff Product Manager, Laurel

¿Cuándo debería una empresa SaaS invertir en localización?#

Nick Bazley es Staff Product Manager en Laurel, donde lleva los últimos seis años liderando equipos de producto mientras la empresa escala su producto a nivel global. Llevaba alrededor de un año pensando en la localización antes de ponerla en marcha.

"Sabíamos que tendríamos que hacerlo en algún momento", dice Nick. "La cuestión era: ¿cuándo? Cada vez que hablábamos del tema, la conclusión era siempre la misma: va a ser un proyecto XXL, va a llevar una eternidad y no vamos a saber realmente cuál será la calidad del resultado."

Laurel estaba creciendo, pasando de clientes mid-market a grandes empresas globales. Empezó a repetirse un patrón: cerrar un cliente en una región, demostrar valor y, después, que ese cliente quisiera expandirse a otras regiones.

A medida que el equipo de ventas contrataba personal por toda Europa y customer success atendía solicitudes de expansión, Nick veía venir el problema.

"Cuando tuvimos que abordar este trabajo, éramos unas 50 personas. Asumir por nuestra cuenta la creación de infraestructura de localización habría sido pedir muchísimo: media empresa bloqueada durante meses, cuando aún teníamos muchas otras cosas que construir para nuestros clientes."

¿Por qué comprar infraestructura de localización en lugar de desarrollarla?#

Laurel se enfrentaba a dos opciones: comprar o desarrollar. Desarrollarlo probablemente iba a ser un esfuerzo de varios trimestres, con una estimación interna de proyecto XXL: entre cuatro y seis meses de trabajo de ingeniería. "No es una decisión inteligente asumir el coste, el tiempo y el esfuerzo de crear nuestra propia infraestructura de localización. La decisión sensata para el negocio, en la fase de crecimiento en la que estábamos, era comprar la mejor solución del mercado y centrarnos en desarrollar nuestra plataforma principal."

En este debate, los principales factores que inclinaron la balanza se redujeron a cuatro: velocidad de salida al mercado, escalabilidad tras el lanzamiento, personalización y calidad.

"No somos expertos en infraestructura de localización. No sabemos qué calidad vamos a obtener. ¿Por qué asumir ese riesgo cuando hay quien ha construido un negocio entero en torno a la ingeniería de localización?"

Cómo evaluar una plataforma de localización frente a un TMS tradicional#

Nick cartografió el mercado con una búsqueda rápida en Perplexity Pro, revisó los primeros resultados y encontró un TMS tradicional. Una búsqueda aparte en Google reveló algunas opciones más, y el Head of Engineering de Laurel se había topado por su cuenta con Lingo.dev.

Llevó a cabo evaluaciones en paralelo con ambos.

"A simple vista, ese TMS tradicional parecía una empresa muy pulida y sólida", dice Nick. "Pero cuando fuimos profundizando en lo que tenían y en lo que nosotros necesitábamos, solo había una opción si queríamos la velocidad y la calidad a las que aspirábamos."

"Lo que aprecié fue cómo Lingo.dev se implicó: entendió nuestros problemas, lo que intentábamos hacer, y aportó soluciones. El precio enterprise era justo. Y la promesa de velocidad y calidad fue el factor clave. Lo que más destacó fue el acceso. Estamos en un canal compartido de Slack con los ingenieros que realmente construyen la plataforma. Cuando nos encontramos con un caso límite, el tiempo de respuesta es de horas. Casi parece que formen parte de nuestra organización."

¿Qué precisión tiene la localización con IA para la terminología legal y contable?#

Los usuarios de Laurel son profesionales del ámbito legal y contable. Una interfaz en alemán que use la palabra equivocada para "billing rate" o "matter" no solo da mala imagen: socava la confianza en todo el producto. La terminología legal y contable tiene que ser exacta.

Nick probó la calidad con clientes reales. La primera tanda se envió a clientes nórdicos y a un cliente francés. El equipo nórdico no tuvo ningún comentario. El cliente francés, hablante nativo, detectó solo dos imprecisiones: el equipo las añadió de inmediato al glosario. Desde entonces, no ha habido problemas en neerlandés, portugués, español, etc.

Probamos la calidad en 12 idiomas con clientes nativos durante seis meses. Total de problemas terminológicos comunicados: dos, ambos resueltos el mismo día mediante incorporaciones al glosario. Resultó que el motor de localización, con un glosario configurado, producía una terminología legal más consistente que desarrollar la lógica de traducción desde cero, porque el motor aplica los términos en todos los pares de idiomas de forma simultánea, algo que un proceso manual no puede garantizar.

"Hace tiempo que no hemos tenido que volver al glosario para retocar nada", dice Nick.

¿Cuánto se tarda en añadir un nuevo idioma a un producto SaaS?#

Cuando un customer success manager detecta que un cliente necesita portugués en la interfaz, antes esa solicitud entraba en el roadmap, se priorizaba, esperaba a un sprint y tardaba semanas.

Ahora, Nick crea un ticket, toma como plantilla un ticket anterior de incorporación de idioma, orienta AI Tooling hacia él y espera. Después, la herramienta añade el idioma a la configuración, actualiza el selector de idioma y abre una PR. Un ingeniero revisa la PR y la publica; Lingo.dev se encarga de la localización continua en piloto automático.

"Un día es el proceso de principio a fin: desde redactar el ticket hasta que la PR está terminada. No significa que yo esté trabajando en ello un día entero. La mayor parte de ese tiempo estoy haciendo otras cosas."

Con herramientas de programación con IA y una infraestructura de localización de Lingo.dev, Nick puede añadir un idioma sin consumir capacidad de ingeniería.

"Con Lingo.dev, ahora cualquiera en la empresa puede añadir nuevos idiomas y ajustar nuestros motores de localización. Eso es bastante extraordinario."

¿Cómo afecta la velocidad de localización a la velocidad de cierre de acuerdos enterprise?#

El caso de negocio no va de ahorrar tiempo de ingeniería, aunque también lo hace. Va de asegurarnos de que podemos reaccionar rápido ante oportunidades de expansión cambiantes.

"Con clientes enterprise, la oportunidad de expansión puede aparecer muy rápido", dice Nick. "Nuestros clientes pueden ganar tracción en una nueva oficina y querer expandirse allí si somos capaces de entregar el producto en su idioma con rapidez. Tenemos que poder reaccionar a esa velocidad sin problema para seguir creciendo."

Laurel empezó con cinco idiomas nórdicos más francés para respaldar su primera expansión en Europa. Desde entonces, ventas y customer success han impulsado solicitudes de portugués, español y neerlandés, y ahora están en conversaciones sobre muchos más a medida que se expanden por oficinas de todo el mundo.

Hicimos el cálculo: en los seis meses posteriores a la integración, Laurel añadió siete idiomas en respuesta a solicitudes de expansión de clientes. Cada uno llevó menos de un día. Bajo el modelo de desarrollarlo por su cuenta, esos siete idiomas habrían consumido aproximadamente 28 sprints de ingeniería, una capacidad que se destinó en su lugar a funcionalidades clave del producto.

¿Deberías desarrollar o comprar infraestructura de localización?#

Cuando se le preguntó qué le diría a un VP Product de una empresa similar —B2B enterprise, usuarios profesionales, expansión global y un equipo de ingeniería con trabajo real de producto por hacer—, Nick no duda.

"Yo optaría por un proveedor al 100%."

Lo que subestimarían de desarrollarlo por su cuenta: "La complejidad y la calidad. No sabes cuál va a ser la calidad. ¿Por qué asumir ese riesgo?"

Lo que harían mal al elegir un proveedor: no entender con suficiente claridad su propio problema como para escoger el adecuado. "Entender de verdad el problema que estás resolviendo y elegir al proveedor adecuado para ese problema concreto: eso es fundamental."

Qué probar primero: "La velocidad y el tiempo de salida al mercado. Después, una vez completada la configuración inicial, la velocidad y la escalabilidad."

Lo que realmente cuesta esperar#

La configuración inicial recayó sobre todo en Laurel, preparando el stack tecnológico. Después de eso: un día por idioma, sin necesidad de sprint de ingeniería ni negociación en el roadmap.

La alternativa eran entre tres y cuatro meses de trabajo de ingeniería para desarrollarlo, mantenimiento continuo para siempre y una calidad que no podían garantizar en idiomas que nadie del equipo habla.

Nick lo resume así: "La infraestructura de localización no es un proyecto que terminas y dejas atrás. Es algo continuo: cada vez que escalas, cada vez que entras en un nuevo mercado, cada vez que añades una nueva funcionalidad. Tiene que ser fácil. No quiero seguir volviendo a ingeniería para pedir otro sprint que nos permita entregar todo lo que necesitamos."

Qué significa esto para los equipos de producto que se expanden a nuevos mercados#

La experiencia de Laurel refleja un patrón habitual en las empresas B2B SaaS con demanda internacional de grandes cuentas: la localización deja de ser una petición de funcionalidad y pasa a convertirse en un freno al crecimiento. La pregunta deja de ser "¿deberíamos localizar?" y pasa a ser "¿con qué rapidez podemos decir sí al próximo mercado?"

Tres factores marcaron el enfoque de Laurel: el equipo no podía permitirse dedicar capacidad de ingeniería a una infraestructura que no forma parte de su producto principal. La calidad de la terminología jurídica y contable tenía que ser verificable, no darse por supuesta.

El enfoque de ingeniería de localización trata la compatibilidad con idiomas como una capa de configuración, en lugar de como un proyecto de ingeniería. Un product manager puede añadir un idioma sin necesidad de un sprint, sin consumir capacidad de ingeniería y sin coordinarse con un proveedor de traducción. Para los equipos en los que la velocidad de expansión a nuevos mercados determina el crecimiento de los ingresos, ese cambio operativo marca la diferencia entre aprovechar una oportunidad y verla pasar.

Laurel desarrolla IA para profesionales del sector jurídico y contable. Lanzan su producto en más de una docena de idiomas y pueden añadir uno nuevo en un día. Su infraestructura de localización funciona con Lingo.dev.

Preguntas frecuentes#

¿Cuánto se tarda en añadir un nuevo idioma a un producto SaaS?

Laurel añade un nuevo idioma en aproximadamente un día, de principio a fin. Un product manager crea un ticket tomando como referencia una incorporación anterior de idioma, pone a trabajar sobre él a un agente de programación con IA y un ingeniero revisa la PR. Sin sprint dedicado, sin coordinación con proveedores. La alternativa anterior —crear internamente la infraestructura de localización— se estimó en entre cuatro y seis meses antes de poder lanzar un solo idioma.

¿Debería una startup crear o comprar infraestructura de localización?

Nick Bazley, Staff PM de Laurel, evaluó la opción de desarrollarlo internamente frente a comprarlo. Su conclusión fue: "No somos expertos en infraestructura de localización. No sabemos qué nivel de calidad vamos a obtener. ¿Por qué asumir ese riesgo cuando hay quien ha construido todo un negocio en torno a la ingeniería de localización?" La estimación de desarrollo interno era la de un proyecto XXL que consumiría a la mitad del equipo de ingeniería durante meses.

¿Qué nivel de precisión ofrece la localización con IA para la terminología profesional?

Laurel hizo pruebas en 12 idiomas con clientes nativos de los sectores jurídico y contable durante seis meses. Problemas terminológicos totales: dos, ambos resueltos el mismo día mediante incorporaciones al glosario. El motor de localización garantiza la coherencia del glosario en todos los pares de idiomas a la vez, algo que una implementación manual no puede asegurar a escala.

¿Cómo afecta la velocidad de localización a los ciclos de venta enterprise?

La experiencia de Laurel es clara: los clientes enterprise que solicitan compatibilidad con un nuevo idioma esperan una respuesta en cuestión de días, no de meses. Nick Bazley describe así esa dinámica: "La oportunidad no sigue ahí mucho tiempo. Si no podemos tenerlo listo en una semana, esa ventana puede cerrarse". Después de pasar a una infraestructura de localización, Laurel añadió siete idiomas en seis meses, cada uno en menos de un día.

¿Cómo se comparan los costes de crear frente a comprar en localización?

La comparación de Laurel fue clara: un breve periodo de integración y un coste recurrente por uso frente a entre cuatro y seis meses de tiempo de ingeniería para desarrollar la solución, además de mantenimiento indefinido y una calidad que no podían garantizar. Los siete idiomas añadidos en seis meses habrían consumido aproximadamente 28 sprints de ingeniería con el modelo de desarrollo interno, una capacidad que se destinó en su lugar a funcionalidades del producto principal.