Laurel es la plataforma de inteligencia del trabajo para servicios profesionales. Las firmas usan Laurel para automatizar el registro de 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 está disponible en más de una docena de idiomas —idiomas nórdicos, francés, neerlandés, portugués, español y coreano—, con mandarín, tailandés, árabe, japonés y vietnamita en camino.

La integración de Laurel fue sencilla: la mayor parte del esfuerzo estuvo de su lado, extrayendo y organizando strings existentes para preparar la base de código. La alternativa de desarrollarlo internamente se estimó en cuatro a seis meses de trabajo de ingeniería, con mantenimiento continuo de forma indefinida. Descubrimos que el costo total de no comprar era aproximadamente 10 veces mayor que el de comprar, una vez que se tenían en cuenta los acuerdos que se habrían caído. Ahora, sumar un nuevo idioma toma 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 involucró, entendió nuestros problemas y propuso soluciones. No tuvimos que construir infraestructura de localización: ellos lo resolvieron a la perfección. El precio enterprise fue justo, y tenemos un canal compartido en Slack con sus ingenieros. La respuesta a los casos límite llega en cuestión 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 ha pasado 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 que se concretara.

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

Laurel estaba creciendo y expandiéndose de clientes mid-market a empresas globales. Empezó a repetirse un patrón: cerraban con un cliente en una región, demostraban valor y luego ese cliente quería expandirse a otras regiones.

A medida que el equipo de ventas incorporaba gente en toda Europa y customer success recibía solicitudes de expansión, Nick veía venir el problema.

"En el momento en que necesitábamos hacer este trabajo, éramos unas 50 personas. Encargarnos nosotros mismos de construir infraestructura de localización habría sido muchísimo pedir: medio equipo ocupado durante meses, cuando todavía había muchas otras cosas que necesitábamos construir para nuestros clientes."

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

Laurel se enfrentaba a dos opciones: comprar o construir. Construir probablemente iba a implicar 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 costo, el tiempo y el esfuerzo de construir nuestra propia infraestructura de localización. La decisión más sensata para el negocio, en la etapa de crecimiento en la que estábamos, era comprar la mejor solución del mercado y enfocarnos en construir nuestra plataforma principal."

En esta discusión, los principales factores que inclinaron la balanza se redujeron a cuatro cosas: velocidad de salida al mercado, escalabilidad después del lanzamiento, personalización y calidad.

"No somos expertos en infraestructura de localización. No sabemos cómo va a ser la calidad. ¿Por qué asumir ese riesgo cuando hay alguien que ha construido todo un negocio alrededor de la ingeniería de localización?"

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

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

Hizo evaluaciones en paralelo con ambos.

"Ese TMS legacy, a simple vista, parecía un negocio realmente pulido y sólido", dice Nick. "Pero cuando profundizamos en lo que tenían y en lo que nosotros necesitábamos, para la velocidad y la calidad a las que aspirábamos solo había una opción."

"Lo que valoré fue cómo Lingo.dev se involucró: entendió nuestros problemas, lo que intentábamos hacer y propuso soluciones. El precio enterprise fue justo. Y la promesa de velocidad y calidad fue el principal factor decisivo. Lo que más destacó fue el acceso. Tenemos un canal compartido en Slack con los ingenieros que realmente construyen la plataforma. Cuando nos topamos con un caso límite, la respuesta llega en horas. Casi se siente como si fueran parte de nuestra organización."

¿Qué tan precisa es la localización con IA para la terminología legal y contable?#

Los usuarios de Laurel son profesionales de los sectores legal y contable. Una interfaz en alemán que use la palabra incorrecta para "billing rate" o "matter" no solo se ve mal: 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 versión 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 inexactitudes: el equipo las agregó 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 de terminología reportados: dos, ambos resueltos el mismo día mediante adiciones al glosario. Resultó que el motor de localización con un glosario configurado producía una terminología legal más consistente que construir la lógica de traducción desde cero, porque el motor aplica los términos en cada par 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 ajustar nada", dice Nick.

¿Cuánto tiempo lleva sumar un nuevo idioma a un producto SaaS?#

Cuando un customer success manager señala que un cliente necesita portugués en la interfaz, esa solicitud antes iba al roadmap, se priorizaba, esperaba un sprint y tardaba semanas.

Ahora, Nick crea un ticket, toma como plantilla un ticket anterior de incorporación de idioma, apunta AI Tooling a eso y espera. La herramienta luego agrega el idioma a la configuración, actualiza el selector de idiomas y abre un PR. Un ingeniero revisa el PR, lo publica y Lingo.dev se encarga de la localización continua en piloto automático.

"Un día es de punta a punta: desde redactar el ticket hasta que el PR queda terminado. No significa que yo esté trabajando en eso durante 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 sumar un idioma sin consumir capacidad de ingeniería.

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

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

El caso de negocio no pasa por ahorrar tiempo de ingeniería, aunque sin duda también lo hace. Se trata de asegurarnos de poder reaccionar rápido ante oportunidades de expansión que evolucionan constantemente.

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

Laurel comenzó 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 a oficinas globales.

Hicimos la cuenta: en los seis meses posteriores a la integración, Laurel sumó siete idiomas en respuesta a solicitudes de expansión de clientes. Cada uno tomó menos de un día. Bajo el modelo de construirlo internamente, esos siete idiomas habrían consumido aproximadamente 28 sprints de ingeniería, capacidad que en cambio se destinó a funcionalidades clave del producto.

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

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

"Yo 100% elegiría un proveedor."

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

Lo que podrían hacer mal al elegir un proveedor: no entender con suficiente claridad su propio problema como para elegir el correcto. "Entender de verdad el problema que estás resolviendo y elegir al proveedor adecuado para ese problema específico: eso es crítico."

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

Lo que realmente cuesta esperar#

La configuración inicial estuvo mayormente del lado de Laurel, dejando listo el stack tecnológico. Después de eso: un día por idioma, sin necesidad de un sprint de ingeniería ni negociaciones de roadmap.

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

Nick lo resume de forma simple: "La infraestructura de localización no es un proyecto que se termina y del que luego te olvidas. Es algo continuo: cada vez que escalas, cada vez que entras a un nuevo mercado, cada vez que sumas una nueva funcionalidad. Tiene que ser fácil. No quiero seguir volviendo a ingeniería a pedir otro sprint para entregar todo lo que necesitamos."

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

La experiencia de Laurel refleja un patrón común entre las empresas B2B SaaS con demanda internacional del segmento enterprise: la localización deja de ser una solicitud de funcionalidad y se convierte en una limitación para el crecimiento. La pregunta ya no es "¿deberíamos localizar?", sino "¿qué tan rápido podemos decirle que sí al siguiente mercado?"

Tres factores definieron el enfoque de Laurel: el equipo no podía darse el lujo de destinar capacidad de ingeniería a una infraestructura que no forma parte de su producto principal. Y la calidad de la terminología legal y contable tenía que poder comprobarse, no asumirse.

El enfoque de ingeniería de localización trata el soporte de idiomas como una capa de configuración, no como un proyecto de ingeniería. Un gerente de producto puede agregar un idioma sin dedicar un sprint, sin consumir capacidad de ingeniería y sin coordinarse con un proveedor de traducción. Para los equipos donde la velocidad de expansión a nuevos mercados define el crecimiento de los ingresos, ese cambio operativo marca la diferencia entre capitalizar una oportunidad y verla cerrarse.

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

Preguntas frecuentes#

¿Cuánto tiempo toma agregar un nuevo idioma a un producto SaaS?

Laurel agrega un nuevo idioma en aproximadamente un día, de punta a punta. Un gerente de producto crea un ticket con referencia a una incorporación previa de idioma, apunta a eso a un agente de programación con IA y un ingeniero revisa el PR. Sin sprint dedicado, sin coordinación con proveedores. La alternativa anterior —crear infraestructura de localización internamente— se estimaba en cuatro a seis meses antes de poder lanzar cualquier idioma.

¿Una startup debería desarrollar o comprar infraestructura de localización?

Nick Bazley, Staff PM de Laurel, evaluó la opción de desarrollar internamente frente a comprar. Su conclusión: "No somos expertos en infraestructura de localización. No sabemos cómo va a ser la calidad. ¿Por qué asumir ese riesgo cuando alguien ya construyó todo un negocio alrededor de la ingeniería de localización?" La estimación de desarrollo era un proyecto XXL que consumiría a la mitad del equipo de ingeniería durante meses.

¿Qué tan precisa es la localización con IA para la terminología profesional?

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

¿Cómo influye la velocidad de localización en los ciclos de venta enterprise?

La experiencia de Laurel es clara: los clientes enterprise que solicitan soporte para nuevos idiomas esperan una respuesta en cuestión de días, no de meses. Nick Bazley describe la dinámica así: "La oportunidad no sigue ahí por mucho tiempo. Si no podemos resolverlo en una semana, esa ventana puede cerrarse". Después de cambiar a infraestructura de localización, Laurel agregó siete idiomas en seis meses, cada uno en menos de un día.

¿Cómo se comparan los costos de desarrollar vs. comprar localización?

La comparación de Laurel: un periodo breve de integración y un costo continuo por uso frente a cuatro a seis meses de tiempo de ingeniería para desarrollar, más mantenimiento indefinido y una calidad que no podían garantizar. Los siete idiomas agregados en seis meses habrían consumido aproximadamente 28 sprints de ingeniería bajo el modelo de desarrollo, capacidad que en su lugar se destinó a funciones clave del producto.