- Lago, con sede en París, anunció junto con su lanzamiento oficial que se convirtió en una plataforma de facturación open source para desarrolladores y que recaudó alrededor de 22 millones de dólares ($22m) en dos rondas
- La más reciente, una Series A de 15 millones de dólares, fue liderada por FirstMark, mientras que la semilla previa de 7 millones de dólares fue liderada por SignalFire, con participación de Y Combinator, New Wave, Script e inversionistas ángeles
- El equipo, que originalmente quería crear un “Zapier” para equipos de marketing, pivotó hacia una plataforma de facturación después de que una publicación en Hacker News sobre problemas de facturación para desarrolladores generara una gran respuesta
- Mistral.ai, Together.ai y Juni se sumaron como clientes iniciales en la beta privada, y Lago apunta a startups que manejan modelos de precios por suscripción, por uso e híbridos
- En un mercado donde ya están Stripe, Adyen, Salesforce, Zoho y Paddle, Lago apuesta por la escalabilidad y la implementación de facturación personalizada como diferenciadores
Lanzamiento oficial y estructura de la inversión
- La startup Lago, con sede en París, anunció el lanzamiento oficial de su plataforma de facturación open source junto con una recaudación total de 22 millones de dólares
- La inversión se compone de dos rondas
- La más reciente, una Series A de 15 millones de dólares, fue liderada por FirstMark
- La anterior, una ronda semilla de 7 millones de dólares, fue liderada por SignalFire
- Y Combinator, New Wave y Script también participaron como inversionistas
- Entre los inversionistas individuales están Meghan Gill, responsable de monetización en MongoDB; Romain Huet, ex Stripe y actual responsable de relaciones con desarrolladores en OpenAI; y Clément Delangue, CEO de Hugging Face
- Según una fuente, la valoración de Lago ronda los 100 millones de dólares
Beta privada y primeros clientes
- Antes del lanzamiento oficial, Lago operó en beta privada
- Entre sus primeros clientes hay startups como Mistral.ai, Together.ai y Juni
- Su enfoque es ayudar a que los desarrolladores ajusten directamente el sistema de facturación según las necesidades de cada nuevo servicio
- También permite medir datos de uso para gestionar suscripciones u otros esquemas de precios
De herramienta de marketing a plataforma de facturación
- Lago no nació como una empresa que quisiera construir una plataforma de facturación desde el principio
- Sus cofundadores, Anh-Tho Chuong y Raffi Sarkissian, fundaron la empresa tras trabajar en Qonto y se unieron a la cohorte de Y Combinator Summer 2021
- Cuando ingresaron a YC todavía no tenían producto, y luego eligieron la idea de un “Zapier” para equipos de marketing
- En un mercado de tecnología de marketing altamente competitivo, ese producto inicial casi no logró tracción
- Para llamar la atención, Sarkissian publicó en Hacker News un texto sobre los problemas de facturación para desarrolladores
- El título era “Billing systems are a nightmare for engineers”
- El tema conectaba con su experiencia construyendo en Qonto un producto para resolver problemas de facturación
- Como muchos usuarios compartieron sus propios problemas de facturación, Lago cambió de rumbo para enfocarse en resolver la facturación para desarrolladores
Estrategia open source para apuntar a la facturación compleja
- Consideran que ya existen muchas soluciones para precios y facturación simples, pero que no hay respuestas suficientes para la facturación compleja
- Las empresas que crean productos basados en IA siguen buscando modelos de negocio viables, y muchas evalúan un enfoque híbrido que combine suscripciones de tarifa fija con precios basados en uso
- Ese enfoque requiere herramientas que se integren con los productos que construyen los desarrolladores y que puedan identificar y aplicar datos de uso
- Muchas empresas, como Qonto, terminan construyendo su propio sistema de facturación, pero a los ingenieros no les gusta hacerlo y además es costoso contratar ingenieros dedicados solo a eso
- Timothée Lacroix, cofundador y CTO de Mistral.ai, dijo que eligieron Lago por su confianza en el ecosistema open source, y que gracias a Lago pudieron seguir el ritmo de sus lanzamientos y concentrarse en su trabajo principal
Competencia y próximas áreas de expansión
- En el mercado de la facturación ya existen soluciones de grandes empresas tecnológicas como Stripe, Adyen, Salesforce, Zoho y Paddle
- También hay proveedores previos que adoptaron un enfoque open source
- FOSSBilling
- ChargeBee
- Kill Bill
- jBilling de AppDirect
- Open Source Billing
- Lago considera que incluso en un mercado muy competido todavía hay espacio en escalabilidad y en la implementación de facturación adaptada a cada startup
- A futuro, mientras amplía su negocio actual, evalúa dos áreas
- Analítica de datos conectada con su idea original de marketing: ofrecer información sobre qué consumen y pagan los clientes, y cómo son sus patrones de pago
- El área de pagos, que es el lado opuesto de la facturación
- Es poco probable que construya su propio stack de pagos; en cambio, es más probable que se enfoque en la orquestación de pagos, de modo que los usuarios puedan usar las herramientas de pago que quieran e integrarlas bien con la plataforma de facturación
2 comentarios
Lago se esforzó muchísimo en compararse con Stripe... y, como era de esperarse, recibió mucha inversión.
También publicaron artículos como El precio real de Stripe: guía introductoria.
Pero que una API de facturación sea open source sí se siente como algo que no termina de encajar.
Opiniones en Hacker News
Intenté usarlo para un nuevo producto SaaS, pero me sorprendió que los planes empezaran en US$3,000 al mes
Parece que van en la dirección contraria. Los equipos pequeños como el mío no quieren self-hosting; quieren una solución administrada. Las empresas grandes, por su escala, más bien sí tienen capacidad para hacer self-hosting
Después de unos años, cuando el volumen de transacciones creció, queríamos renegociar el contrato. Si en ese momento hubiéramos podido reintegrarnos con Lago, habría sido una carta de negociación al renovar el contrato con Stripe. Pagábamos US$30k al mes en comisiones de Stripe, así que una alternativa de US$3k al mes podría haber valido mucho la pena. Nuestro caso era un poco distinto porque era retail y no facturación SaaS, pero veo situaciones en las que tiene sentido financiero
Hablamos con unas 5 empresas de API de facturación basada en uso, y en la práctica casi nadie estaba interesado en el mercado de menos de US$1,000 al mes, donde estaremos durante nuestra etapa de crecimiento del próximo año. Además, Lago y otros proveedores anuncian “sin revenue share”, pero siempre cotizan como porcentaje de los ingresos. Técnicamente no es revenue share, pero el costo sube casi linealmente con los ingresos
Si la estrategia de precios consiste en evitar clientes pequeños, con alto costo de soporte y baja rentabilidad, dejar que Stripe pierda dinero con ellos y luego quedarse solo con los buenos clientes que ya crecieron dentro de Stripe, es inteligente
Creo que venderles a desarrolladores será difícil. Los desarrolladores no gastan dinero y prefieren construirlo ellos mismos aunque el costo de oportunidad sea 10 veces mayor
Y en cuanto intenten monetizar de cualquier forma, habrá una salida masiva por sentirse “traicionados”, como pasó con Redis. Lo sé porque yo también soy ese tipo de desarrollador
Necesitaba sí o sí un portal de clientes, pero era una función premium, y el plan premium tenía un mínimo de US$1,500 al mes. Con mis ingresos era difícil justificarlo. Dicho eso, Lago evita deliberadamente cobrar un porcentaje de los ingresos, así que no le queda otra que cobrar una tarifa base alta. Stripe Billing cobra por porcentaje, y si tu negocio está creciendo, que la factura de Stripe supere los US$1.5k es cuestión de tiempo
También evalué la facturación basada en uso de Stripe Billing, pero no cumplía mis requisitos. Uso Stripe Billing para la facturación de tarifa fija
El requisito exacto es que quiero vender créditos de API prepagados incluidos en una suscripción. Por ejemplo, si un usuario se suscribe a US$10 de créditos mensuales, primero paga US$10 y luego usa esa cantidad de créditos. Stripe Billing no admite cobro por adelantado en la facturación basada en uso; solo cobra al final del periodo de facturación. Algunos usuarios abusaban del sistema cancelando y no pagando, así que no me sirve. Recuerdo que Lago sí admitía cobro por adelantado
También quería poder mezclar libremente créditos de suscripción y créditos prepagados. Cuando un usuario supera su cuota mensual, prefiere una recarga única antes que subir al plan más caro. También hay que controlar qué créditos se consumen primero, y tanto Stripe Billing como Lago tenían problemas en este punto
Además quería admitir la mayor cantidad posible de métodos de pago, especialmente billeteras chinas como Alipay y WeChat para créditos prepagados. Lago no tenía planes de implementarlo, y hasta consideré a medias implementarlo yo mismo dentro de Lago. En B2B puede que WeChat y Alipay no sean tan importantes
También me gusta el código con pruebas de regresión muy exhaustivas, y en ese aspecto Stripe Billing está muy por delante de Lago gracias a su función de relojes de prueba. Lago no tiene una función para adelantar el tiempo al probar el ciclo de vida de una suscripción. Si confías en el producto, quizá sea menos importante, porque esperas recibir los callbacks correctos en el momento adecuado
Aun así, vi que los desarrolladores de Lago en Slack se tomaban el tiempo de responder incluso preguntas técnicas muy profundas. Si estuviera operando una startup B2B, especialmente en un momento en que se ven muchos casos de suspensión de cuentas de Stripe, creo que habría intentado adaptar Lago como fuera
Y creo que esa es la hipótesis central de Lago. Los desarrolladores quieren software de facturación open source que puedan modificar ellos mismos si hace falta, en lugar de depender de un proveedor propietario como Stripe. No es una idea tan descabellada
Como dice el comentario vecino, pago con gusto por cosas que generan valor y me ahorran tiempo. Para empezar, nunca se me ocurrió construir mi propio sistema de facturación
Puede que, por estar viejo, mi sentido de lo que significa el código abierto ya no se adapte a los cambios de la realidad, pero cuando veo código abierto e “inversión de $22M” en la misma oración, de inmediato pienso: “¿código abierto? sí, claro”
He visto mucho ese sentimiento, incluso en veteranos del código abierto como Rich Harris. Irónicamente, ahora él recibe su sueldo de dinero de VC. Por un lado, también me dan ganas de quejarme y decir que la gente debería crear software abierto solo por el placer de crear y compartir. Pero vivir en el mundo real cuesta mucho dinero, y esperar que alguien haga por las noches y fines de semana un software que yo uso de forma útil y del que quizá incluso obtengo ingresos, para recibir solo estrellas en GitHub, me parece improductivo e injusto
En el contexto de Lago, no veo muy bien el beneficio del código abierto más allá de la promoción y la buena voluntad de los desarrolladores. Hoy, hacerlo como código abierto te deja entre la espada y la pared, y si este es el futuro que trae una vida útil más larga y más soporte, creo que no queda más que aceptarlo
Cuando el código abierto comenzó a mediados de los años 70, el espíritu era compartir software gratis. El dinero venía en forma de subsidios de investigación universitarios o corporativos, y no había modelo de negocio. En 1998, con RedHat, MySQL y otros que pusieron soporte y servicios pagos encima del software libre, el dinero empezó a entrar en serio. Desde mediados de los 2000, por el cloud computing, la idea de ganar dinero con código abierto se volvió común. En SaaS, los usuarios no saben o no les importa si por dentro es código abierto o software propietario, así que el código abierto pasó a jugar en la misma cancha
Hay varias razones por las que a los VC les gusta el código abierto. Soy inversionista con origen como ingeniero de machine learning y, en lo personal, también tengo nostalgia por haber usado excelente software abierto como spaCy en la universidad, y comparto valores como comunidad, transparencia y retribución. Al mismo tiempo, el trabajo de un VC es ganar dinero
Las empresas de código cerrado gastan mucho dinero en ventas y marketing. A los desarrolladores normalmente no les gusta que les vendan; tienen que elegir por sí mismos más que ser convencidos. Si una empresa se gana el corazón de los desarrolladores, el software entra en la etapa de evaluación de compra sin tener que gastar millones de dólares en ventas y marketing, por lo que el modelo de negocio es más eficiente. También tiene defensas más fuertes. Una gran empresa puede gastar fortunas en vendedores de traje para vender un producto, pero no puede comprar el amor de los desarrolladores. Para eso se necesita una gran experiencia de desarrollo y buenas relaciones con desarrolladores
Pero ganar dinero con código abierto es mucho más difícil que con SaaS. En SaaS se habla de encaje producto-mercado. Si encuentras al menos 5 clientes que lo usan de la misma manera, compran de la misma manera y obtienen el mismo valor, generas previsibilidad, los VC ponen dinero y escalas ventas. En código abierto, este problema se multiplica por 3. El encaje proyecto-comunidad se mira con GitHub Stars; el encaje producto-mercado, con descargas; y el encaje valor-mercado, con ingresos. Además, el comprador puede ser distinto del desarrollador o del usuario. La mayoría de los grandes productos de código abierto fallan en el encaje valor-mercado
La mayoría de los fundadores de empresas de código abierto fracasan al capturar valor. Porque es demasiado difícil, o porque postergan la monetización por la sensación de que el código abierto debe ser “software gratis”. Y cuando empiezan a monetizar, ya es demasiado tarde. Si durante años recibiste la leche gratis, ¿comprarías la vaca? Otra razón es que no saben cómo hacerlo. Las formas típicas de ganar dinero con código abierto son vender soporte y servicios, open core con funciones propietarias, y SaaS que vende hosting y herramientas. Ejemplos: RedHat, Confluent, Elastic y Databricks
Simplificando a partir de empresas de código abierto exitosas, la versión gratuita debe tener todo lo necesario para que un desarrollador individual termine su trabajo. El producto pago debe ofrecer funciones adicionales necesarias para que un equipo termine su trabajo
Me gusta el código abierto, y me da pena ver a fundadores muy inteligentes y a muchísimos colaboradores ponerle pasión a algo que luego no escala y no recibe recompensa. La comercialización ayuda con eso, pero es realmente difícil. Quienes contribuyen y crean código abierto valoran la comunidad y quieren dar gratis, así que la idea misma de ganar dinero les resulta incómoda. Cuando algo incomoda, la gente vuelve a lo conocido, y para la mayoría de los ingenieros eso es programar. Así terminamos con excelente software de código abierto lleno de funciones geniales y con fundadores que postergaron la monetización demasiado tiempo. En algún momento se cruza un punto sin retorno, otra empresa prometedora muere y, por más genial que sea el producto, los inversionistas no invierten si no pueden recuperar su dinero
Si de todos modos hay que pagar comisiones de procesamiento, ¿cuál es la ventaja aquí?
Si tienes que mantener tu propio stack de pagos y cumplimiento PCI, parece que sería una distracción enorme
Es difícil llevar el control de pagos recurrentes, facturas, cambios de plan prorrateados y casos límite de facturación por uso. Y la API de Stripe Billing tampoco es muy elegante en muchos casos. Se agradece que aparezca una nueva capa en esta área
Como referencia, fundé Very Good Security y fui su CEO durante 8 años
De forma similar, existe el open source https://hyperswitch.io escrito en Rust.
Lago está escrito en Ruby, y también encontré algunos otros sistemas de facturación open source escritos en Java. ¿Alguien conoce alguno hecho en Node.js?
Paris parece ser un lugar realmente caliente para generar nuevas startups fintech
En cambio, también hay contraejemplos en France que surgieron con excelentes intenciones. Por ejemplo, Semmle [1] fue adquirida por GitHub para análisis estático de repositorios. Inria [2] también es excelente, pero el problema no es la investigación, sino cómo competir a nivel de negocio con empresas al estilo estadounidense.
[1] https://en.wikipedia.org/wiki/Semmle
[2] https://www.inria.fr/en
Están usando un meme de Drake en el README de GitHub
https://github.com/getlago/lago
https://imgur.com/a/gsrhUXm
No esperaba ver la memificación de la documentación técnica… Dios mío
¿Alguien conoce una alternativa real a Stripe Payments? Stripe no quiere trabajar con nosotros y solo quiere trabajar con competidores de código cerrado, así que estamos atados a PayPal
Para que conste, trabajo ahí
Esto no es una alternativa a Stripe
Facturación, facturas, pagos, permisos y suscripciones son cosas distintas
Es decir, queremos ofrecer una alternativa abierta para todo RevOps. En lugar de entrar en un ecosistema de código cerrado como Stripe, buscamos que se pueda crear un stack personalizado y, con un enfoque de “combinación de las mejores herramientas”, conectar herramientas de larga cola, casos de uso y sistemas propios. Stripe tiene 21 productos, y muchos fundadores no saben bien que no usan solo “Stripe payments”, sino entre 3 y 6 de esos productos, y que cada uno normalmente se lleva una parte de los ingresos
Levantó 15M en una Series A y, aunque la valuación no se anunció, se rumorea que fue de 100M.
Según Crunchbase, 7M correspondían a la ronda semilla recibida en 2023. Por el último párrafo del artículo enlazado, parece que no intentan reemplazar todo Stripe. En cualquier caso, es interesante como historia de un pivote exitoso de startup que empezó con una publicación entusiasta en HN