¿Cómo hemos comprado una empresa? | Podcast de itnig

Hoy se anuncia que Factorial ha adquirido Yepcode. Miguel, ¿cómo se compra una empresa? Lo primero que me dijo Bernat: «Oye, Miguel, tú lo lideras». «Adelante». «Tú te encargas». «Espabílate». Exacto. Que pase. Nosotros tenemos un problema: cada vez más clientes, más países, más soluciones con las que se quieren integrar y no nos da la vida. Y ahí dices: «Bueno, voy a probar si pongo Yepcode».

¿Por qué comprar la empresa? ¿Por qué no somos simplemente clientes de Yepcode? No solo queremos el software, queremos al equipo en sí mismo. Para ellos también era la oportunidad de que su solución tenga el impacto que le puede dar Factorial. Una integración era un parto y me acuerdo de la cantidad de discusiones y roadmaps y priorizaciones y recursos a de repente que salgan como churros.

Tardábamos meses, hemos pasado a hacerlo en semanas y queremos avanzar más. En Yepcode tenemos nuestro propio agente. Le puedes dar un-unas especificaciones, un selectivo, y que ya se quede ejecutándose. Esa es la visión hacia donde vamos, que las integraciones casi se puedan construir on the fly con las especificaciones, ¿no? La otra noticia, quizá más importante todavía, es que Factorial abre una oficina en Coruña.

Espero que se vea con buenos ojos que aterriza un unicornio en Coruña. Ahora viene lo más difícil, ¿eh? Que las compras de compañía no acaban el día que, que se firma el contrato, sino que empiezan. Bienvenido a las historias de startups de Itnig. Bienvenidos una semana más al pódcast de Itnig. Hoy estamos con Miguel García.

¿Qué tal, Miguel? Muy bien. Y con Marcos Muiño. ¿Qué tal, Marcos?

Muy bien. Encantado de estar aquí, Jordi.

Bienvenidos. Miguel ya ha estado por el pódcast, VP Ingeniería en Factorial, y Marcos es fundador y CEO de Yepcode.

Mhm.

Hasta hace poco.

Sí.

Eh, Marcos, eh, empezamos con la noticia y luego vamos un poquito para atrás. Eh, hoy se anuncia que Factorial ha adquirido Yepcode, la empresa que Marcos cofundó hace un montón de años y que ahora nos contará. Em, explícanos qué es Yepcode y de dónde sale.

Bueno, Yepcode es una plataforma para desarrolladores para agilizar el, la, el desarrollo, creación de, de integraciones y automatizaciones, ¿no? Y en los últimos meses, eh, sacando el máximo partido a todo lo que hay alrededor de la IA, ¿no? Con, con todas estas capacidades de generación de código. Y proporciona una infraestructura donde estas integraciones se pueden ejecutar de una forma segura y escalable, ¿no?

Y nace de una empresa anterior que yo también había cofundado con mis dos socios, una empresa de servicios de desarrollo, y nace como un proyecto interno que se acaba convirtiendo en una compañía y que ya hace unos años yo me he movido a estar full time empujando Yepcode como modelo startup, separado de la línea de servicios de desarrollo y, y que finalmente, pues ha encontrado un, un nuevo ecosistema donde integrarse, ¿no?

O sea, para entenderlo, em, vosotros hacíais software para corporaciones, para empresas que os contrataban, ¿no? A vuestra consultoría de, de ingeniería y de programación, y veíais que mucho del trabajo que hacíais eran integraciones. Y es un palo hacer integraciones, ¿no? Tiene como mucha complejidad, muchos problemas que son parecidos, pero diferentes, y decidís hacer una plataforma para ser más ágiles haciendo estas integraciones.

Sí, efectivamente. Veíamos que muchas veces estos proyectos, eh, en cuanto a lógica de negocio no eran supercomplicados, pero sí que había un trade off de, eh: hay que arrancar un proyecto de cero, hay que desplegarlo, gestión de credenciales, auditoría, logs, scheduling, webhooks, todo esto. Y decíamos: «Jo, estamos perdiendo tiempo en hacer todo esto que, eh, podría venir out of the box, ¿no?».

Sí que hay alternativas, ¿no? Como se llama-

Iba a preguntar.

Va.

Existen, eh, los Zapiers, los If This Then That.

Ya.

Los Mulesoft, ¿no? Los Workatos. O sea, hay varias plataformas más o menos que permiten conectar un software con otro.

Sí.

¿Por qué no servían estas?

Y, y cubren parte de esta problemática, pero un enfoque no-code, ¿no? Y donde tienes que acabar resolviendo estas integraciones, pues con drag and drop, ¿no? Y nosotros, siendo-

Se estaban limitadas por el interfaz que ofrecían.

Sí, son-- yo creo que más que ser competidores de las soluciones no-code. De hecho, nuestro nombre lo dice, ¿no? Yepcode es, eh-

Sí, sí.

...going against the no-code stream, ¿no? Y, y lo que queríamos era dotar a los developers de toda esa, de todo ese pain, pero permitiéndoles seguir escribiendo código, JavaScript o Python, utilizando cualquier librería de npm, pip, lo que necesiten, y que se pudieran centrar en sacar adelante las integraciones de la forma más ágil posible, ¿no?

Voy a hacer una comparación muy, muy bruta quizá, pero es como cuando querías integrar pagos, podías meter PayPal, que era un botón en la web, pero cero control del proceso de billing, o Stripe, ¿no? Que te da un SDK, te da una librería que tú puedes integrar en tu backoffice de manera totalmente transparente para el usuario. Un poco a saco, pero ¿me la compras?

Sí, yo, yo creo que sí, ¿no? Esa, esa experiencia, eh, out of the box de, de PayPal, pero si quieres más control, si quieres-- incluso si nos vamos a integraciones, eh, cuando la complejidad se empieza a incrementar, las soluciones no-code, tengo-- he visto pantallas de cajitas y muchísimas cajitas, ¿no? Que, que eso acaba siendo complicado de mantener-

Sí.

...de evolucionar. También hay un altísimo vendor lock-in, ¿no? Con-- cuando desarrollas con esa-- con ese tipo de soluciones.

O sea, quieres decir que metes mucho código, inviertes mucho en, en un partner o en una integración en concreto.

Sí, cuando realmente sí lo puedes hacer con JavaScript o Python, pues las empresas están más abiertas a explorar estas soluciones y sacar partido de, de lo que ofrecemos, ¿no?

Este pódcast es posible gracias a nuestro sponsor MyTraffic. Si te dedicas al real estate o eres un franquiciado, o te dedicas al retail y estás pensando en qué zona invertir para crear tu primer local, te recomiendo

Miguel, aquí el que compra YepCode eres tú. ¿No? Paga Factorial, vamos a decir, pero el que levanta la mano y dice: "Oye, esto, eh... lo necesitamos en Factorial", ¿no? Eh, ¿de, de dónde sale? Eh, aparte de que sois todos gallegos, pero, pero aparte de ser gallegos, ¿por qué-- cómo llegas tú a, a, a YepCode y a la conclusión de que Factorial debería adquirir YepCode?

O sea, nosotros ya hace tiempo que, que hemos detectado, ¿no? Una, una necesidad que es evolucionar nuestra capa de integraciones. La realidad es que hasta el día de hoy, bueno, ya hace unos meses, ¿no? Teníamos toda la integración, eh... digamos, integrada en el monolito, ¿no? Al final es u-única pieza de software, por simplificarlo.

Y, mmm, a medida que vamos creciendo y las integraciones se hacen más necesarias, más complejas-

Mhm.

Y además con más personas involucradas, ya no solo desarrollo interno, los partners, los clientes, necesitamos una plataforma más ágil y desacoplada de lo que es nuestro desarrollo principal, el ciclo de vida principal, ¿no? Entonces, ahí hay tres sabores-

¿Por qué? ¿Por qué necesitamos una plataforma más desacoplada en nuestro desarrollo?

Por una parte, eh... necesitamos que-- déjame explicarte el, el proceso-

Vale.

Y entonces lo vamos a entender mejor, ¿no? Eh, vemos hay tres tipos de servicios de este tipo: los Zapier, que son los low-code, no tienes que hacer nada, simplemente es lo que dices tú, estás completamente, eh... bueno, pues es locking a lo que te ofrece el co-el componente. Después tenemos los, los servicios tipo Fivetran, que están-- son ETL muy orientadas a procesador de datos, generalmente con cajitas, ese tipo de cosas.

Tenemos los Mulesoft o los Oracle de toda la vida, que son muy caros y con cierta complejidad. Y después hay otras plataformas de nueva generación como YepCode, ¿no? Que están ahí en el medio de ese mundo, te ofrecen toda la capacidad y esa es también esa posibilidad de tú poder, eh, customizar esos procesos con un lenguaje muy simplificado, que es Python o TypeScript, ¿no?

Que es lo que además en Factorial utilizamos, en-- co-concretamente, TypeScript, nuestros desa-desarrolladores están supercómodos con eso. Entonces, eh, el porqué necesitamos algo desacoplado. Primero, porque, eh... nosotros en Factorial tenemos una serie de procesos de negocio que requieren integración con terceros, por ejemplo, expenses, integración con ERP, la actualización de los empleados, eh, pues con los sistemas de nóminas, etcétera, ¿no?

Eh, piensa que el core de estos procesos siempre es el mismo, ¿no? Hay un blueprint del proceso de negocio, es lo que tenemos en el monolito, lo podemos tener una librería, y después hay una serie de capacidades que es la personalización de esos componentes, que, eh, por dos tipos de necesidades. Una, por la agilidad. Desarrollar en el monolito siempre es mucho más pesado, mucho más lento. Desarrollar una, en una plataforma desacoplada en el que cada proceso está aislado del siguiente, ¿no?

Imagínate que vienen dos compañías que se-

Estás hablando de microservicios.

No tiene por qué ser microservicios-

Medio servicios.

Pero bueno, sí, me-medio, en esa línea, ¿no? O sea, vienen dos compañías, dos grandes compañías, dos enterprises, con dos necesidades de integración completamente distintas, pero el mismo proceso de negocio. Entonces, Factorial proporciona el blueprint-

Mmm.

Pro-proporciona el SDK, lo que tú comentabas antes, que es lo que te permite out of the box, y además te da un entorno en el que tú puedes hacer esas integraciones sin impactar a nuestro core.

Con lo cual no hay, vamos a decir, líneas de código dentro del core de Factorial que tengan que ver con una integración concreto muy específica. Esto está en una capa de abstracción un poquito más alta que es YepCode.

Exacto.

¿Y tú cómo descubres YepCode?

O sea, lo ye-- lo descubro-- bueno, primero, eh... o sea, yo he trabajado unos años en... Soy gallego. Segundo, he trabajado unos años en, en Inditex, unos cuantos. Eh... la empre-la empresa inicial antes de YepCode, que era Trileuko, ¿no? Es una empresa superconocilla-- conocida. Ellos son muy conocidos en el sector allí en, en Coruña, por, por lo bien que hacían su trabajo, la calidad, etcétera.

Tenemos amigos en común y ya en otras experiencias ya habíamos eva-- yo ya había evaluado YepCode, ¿no? Porque, eh... pues es muy parecido a Airwave, en cierta manera. Siempre hay esta necesidad en cualquier, cualquier solución, siempre tiene una necesidad de, de integración. Entonces, ya, ya lo tenía en, en el radar. Y después, eh, Marcos también tiene esa, ese espíritu emprendedor que tú también conoces perfectamente.

Es, o sea, una persona muy persistente, que es superpositivo eso, ¿no? Cuando alguien constantemente, ¿no? Tiene esa-- él sabe que tiene valor que aportar y al final acabas escuchando y das una oportunidad, ¿no? O sea, teníamos la necesidad-

Él te quería vender, o sea, pa que Factorial fuera cliente de la plataforma YepCode.

Efectivamente.

Y te, y te dio por saco hasta que le hiciste caso.

Hasta que le dimos una oportunidad.

¿Cuántas veces? Que eso a veces hemos hablado aquí de la perseverancia.

Es que no fue el primero en Factorial, ya hace años le...

A mí, a mí me escribiste también, eh...

Es que yo a Marcel estuvimos-

A Marcel, otro gallego, medio gallego.

Estuvimos hablando con ellos. De hecho, hicimos mogollón de recipes, de: "Oye, con esto a Factorial, con esto tal".

O sea, proactivamente tú venías con: "Mira qué puedo hacer para Factorial".

Correcto, sí.

Ya prehecho, ¿no? O sea, precocinado.

Sí, mmm, no es que quisiésemos vender servicios de desarrollo, porque no es el modelo de negocio de Factorial, sí que lo era del anterior, pero-

La plataforma.

Pero queríamos-- creíamos que la plataforma os podía aportar mucho valor en, en eso, en ser más ágiles, ¿no? Mmm.

Y nosotros empezamos siendo clientes de YepCode.

Exacto.

¿No? O sea, tú decides, ves que nosotros tenemos un, un problema, que es que, bueno, más-- cada vez más clientes, más países, más soluciones con las que se quieren integrar y no nos da la vida.

Efectivamente.

Más todos los retos que has dicho, ¿no? Que si lo hiciéramos todo a medida en el monolito, nos, nos vamos a cargar, tal. Y ahí dices, bueno, voy a probar si, si pongo YepCode y nuestros partners y nuestros clientes pueden hacer sus integraciones directamente y funciona esto.

Funciona.

¿Cuándo pasa esto?

Pues esto creo que hace aproximadamente un año, un poco menos de un año, comenzamos con, con partners, con el equipo de Marcel, que Marcel también creo que es más insistente que Marcos, ¿no? En la necesidad que tiene Factorial. Y entonces vimos la oportunidad de hacer toda inte-- todas las integraciones, pues con Microsoft, con Pilot Team, también Slack, eh, a través de esta de plataforma, ¿no?

Y, y eso empezó a funcionar muy bien. Y entonces generamos un nuevo caso de uso, otra necesidad en Fac-en Factorial, que era el, el equipo de, de Xavi Vigili con, con Albert, que también tenían que hacer desarrollos a medida de estas customizaciones-

Este es el equipo para la audiencia que no conozca nuestro equipo entero. Es el equipo de customer experience-

Ya

...que es el equipo que trabaja con los clientes que ya tenemos en Factorial y que dicen: "Vale, esto va muy bien, pero yo tengo este otro sistema que lo quiero integrar, ayudadme".

Exacto.

Y el equipo de customer experience dice: "Oye, ¿quieres que-- qué quieres que haga? No te voy a hacer una integración yo. No me dedico a esto", ¿no?

Efectivamente.

Y tú dices: "Cuidado".

Ahí ya decimos-- o sea, a mí en el fondo la, la arquitectura, porque yo he venido aquí y nos explican la arquitectura del producto, siempre me ha gustado, creo que tiene unos fundamentos muy buenos, pero a ve-- después había que mostrarlo, ¿sabes? Eh, y entonces, estos dos signos dijimos: "Ostras, estas dos señales son potentes, son buenas", ¿no? Entonces, ya con nuestro equipo de, de integraciones de API Marketplace, que gestiona Antonio dentro de producto, eh, pues estuvimos haciendo ya más, pues un proceso más de análisis más profundo, ver cómo podíamos evolucionar todo el desarrollo agéntico.

Y ahí fue cuando vimos la oportunidad y empezamos a hablar de esta, de esta opción.

Y antes de, de volver a Marcos, ¿por qué comprar la empresa? ¿Por qué no somos simplemente clientes de YepCode y pagamos el fee de la plataforma?

O sea, primero, porque creo que, eh, la plataforma en sí es una parte core para Factorial en nuestra evolución. Y segundo, por el talento del equipo, ¿no? O sea, no solo queremos el software, queremos al equipo en sí mismo. Y yo no veo la forma de, de generar ese engage, que tú sabes que es fundamental, y yo también creo en el equipo, este sentimiento de estar todos en, eh, bueno, pues en el barco, en el sentimiento ese Factorial, si no formas parte de Factorial en sí mismo.

Y además creo que para ellos también, que lo hemos hablado muchas veces en todo este proceso, eh, para ellos también era la oportunidad de que su solución, en la que ellos han creído, han invertido tanto tiempo, tenga el impacto que le puede dar Factorial, ¿no? Y que vean reconocido también todo ese trabajo que habéis hecho, pero en el impacto en los clientes.

Ya mucha gente que, que, que la va a usar ahora esta plataforma, ¿no? Y oye, Marcos, para, para el que se ha perdido de la audiencia, ¿vale? Que dice: "Integraciones, más o menos me suena". Pon ejemplos de qué integraciones permite hacer YepCode y, y cómo es el producto, qué se ve y qué se toca del producto.

Vale, muy bien. Pues podría coger, por ejemplo, uno, cómo lo está utilizando uno de vuestros equipos, ¿no? El equipo de forward deploy engineers para un caso muy concreto, ¿no? Hay, hay un cliente que, que tiene una plataforma de, de no sé si es de fichaje de entradas de alguna forma, ¿no? Que deja la información en, en algún sitio, eh, y está el API de Factorial, ¿no?

Pues, eh, en lugar de extender el monolito, lo que se ha hecho es simplemente entras en una... YepCode es un SaaS, ¿no? Entras y desde un navegador, pues ya ves un editor de código, ¿no? Donde tú puedes empezar a escribir el código. También hemos incorporado en los últimos meses un agente que conoce todas las-- tiene todas las skills de cómo se escribe código de YepCode, que no hay un vendor lock-in superalto, pero sí que hay cierta sintaxis de-- para leer los parámetros de entradas, scheduling, todo esto, ¿no?

Y entonces, pues tú entras ahí y desde un navegador puedes estar subiendo el código. También puedes trabajar en, en local con Cloud Code, con Open Code, con lo que quieras, porque tenemos un CLI que te permite descargarte-

CLI es un command line interface, ¿no? Que es, eh, básicamente una herramienta de terminal, para la gente que nos ote-- que nos escucha, que te permite hablar con el API de YepCode, ¿no? Hablar con el servicio de YepCode desde tu ordenador local-

Exacto

...desde tu terminal, que es lo que usan los programadores.

Los desarrollos normalmente no se quieren salir mucho de su...

No, no les saques de la terminal.

Sí, entonces, permit-- decimos: "No pasa nada". Permitimos clonar tu workspace a tu máquina local, desarrollas ahí con las in-- con los procesos de YepCode. Cuando estás cómodo, pues haces un push a la nube de YepCode. Es un enfoque similar a Git para, para ese intercambio de, de esos ficheros.

Pero va directamente a-- o sea, es CLI, o sea, es YepCode Push-

Sí

...no es Git Push.

No, es también, también algo positivo, porque no le vas a vender de muy buena gana a un developer si no puede tener el código en su repo de Git con YepCode también-

Él puede tener igualmente su repo de Git mientras lo empuja en YepCode.

Y después inc-- tenemos cosas más avanzadas como GitHub Actions para promocionar entre entornos, etcétera, ¿no? Entonces, desarrollas el código, lo subes y ya se queda en la plataforma de YepCode, que puede estar recibiendo ya un webhook. Y por ejemplo, este cliente de, de Factorial, pues enganchó un webhook desde el sistema origen y cada tracking, pues invoca un proceso de YepCode.

Y ahí está la lógica de hablar con el API de Factorial, con los tokens de autenticación, todo correctamente securizado, ¿no? Y sube la información a Factorial. Este es un caso, una integración one-on-one, pero estamos evolucionando, eh, mucho el, el actual framework de integraciones que, que Factorial tiene, que está muy bien, pero tenía un, un hándicap, que es que ahora mismo Factorial ya permite detectar cuando hay cambios en ciertas entidades y que son-- es necesario sincronizarlos, ¿no?

Incluso instalar esta, eh: integraciones. Pero ahora mismo la lógica corre dentro del monolito. O se le dice al partner: "Dame el webhook en tu infraestructura a donde quieres que te lleguen los eventos con la información que hay que sincronizar". Y estabais dejando al partner, pues que se montase su servidor, lo que fuera-

O sea, le estamos dando un problema al partner de tener que recibir esa información como pudiera y a veces, pues quizá no tenía la infraestructura para hacer-- era, era un problema.

Era un problema, ¿no? Y, y ahora lo que se va a hacer es dar una solución que out of the box, este framework de integraciones con este SDK ya va a dar también este entorno de trabajo para el equipo interno de Factorial que esté desarrollando interac-- integraciones o un partner que venga a desarrollar integraciones. Y no solamente hablaremos de que una persona lo esté desarrollando, ¿no?

Porque con las capacidades agénticas que hay, incluso en YepCode tenemos, como decía, nuestro propio agente, le puedes dar un-unas especificaciones, un spec driven, y puede llegar a implementar la lógica de esa integración y que ya se quede ejecutándose en, en YepCode, ¿no? Esa es la visión hacia donde, hacia donde vamos, que las integraciones casi se puedan construir on the fly con las especificaciones, ¿no?

Y ahora que está de moda incluso habla-hablando, ¿no? Eh, whispering, que... Bueno, es igual. Eh, para entenderlo, lo que si alguien, mmm, le cuesta imaginárselo, tú me estás diciendo que hay una especie de Zapier con un Lowable totalmente integrado, con lo cual el Zapier, en lugar de ser clic, clic, clic, es código, pero el código, si quieres, se escribe solo.

Se escribe solo.

Eh, hablando en un chat, eh, como harías con Lowable o con cualquier de las herramientas, ¿no? GitHub Copilot, etcétera, etcétera. Y esto controla infraestructura y todo el contexto y conocimiento de, de integraciones.

Mhm.

Em, en el caso de, ¿no? Ahora, que YepCode forma parte de Factorial, ¿este producto se sigue llamando YepCode?

Mmm, de momento sigue existiendo la web y, y de hecho, pues en el acuerdo que, que hemos cerrado, sí que vamos a seguir dando servicio a, a algunos clientes que, que teníamos, ¿no? Eh, pero la marca pasará a ser de Factorial y, y eventualmente, pues sí que, mmm, bueno, ya no se comercializará a más usuarios, ¿no? Pero sí que queremos, eh, seguir, eh, bueno, mmm, que, que la gente que ha confiado en nosotros en estos años-

Sí, sí, no dejamos a nadie tirado.

Claro.

No dejamos a nadie tirado.

Y, y además, será la forma más rápida de que nosotros pudiésemos pasar a estar full focus en, en Factorial. Ahí sí que agradezco que haya habido esa flexibilidad para la gente que ha confiado en nosotros que pueda seguir utilizando la plataforma.

¿Y quién va a usar YepCode? ¿Qué usuario interactuará con YepCode? Obviamente, hay una parte que es nuestro equipo, el equipo de Factorial, los que decía antes Miguel, ¿no? El equipo de clientes, el equipo de partners, tal. Pero fuera del equipo de Factorial, ¿quién interactuará con la plataforma de YepCode?

Pues partners que ahora mismo están desarrollando integraciones, ¿no?

O sea, no el equipo de partners, sino los partners.

Los-- sí, las empresas de-- que, que crean integraciones, pues lo harán en este, en este entorno. Y eventualmente, yo creo que podremos llegar a que... Es decir, la, la, los clientes finales de Factorial no van a entrar a la plataforma de YepCode, sí que va-van a ver lo que ya ha integrado en el-- e-en Factorial con, con esa visibilidad, ese feedback de qué está sucediendo por debajo y verán las entidades si ya están sincronizadas, si hay algo pendiente de sincronizar.

No van a entrar a la herramienta.

O sea, verán como un resumen de lo que está pasando en YepCode en la interfaz de Factorial-

Correcto

...sin tener que entrar en la herramienta entera de, de YepCode.

Sí que, eh, cubrirán ciertos flujos. Por ejemplo, queremos que las integraciones sean self-service, ¿no? Que tú quieras conectar con un sistema y lances un wizard, te pida, pues las credenciales de autenticación en ese otro sistema. Si hay que configurar algún mapping, pues que se haga. Eso se persistirá para que esté disponible para que los procesos de YepCode puedan hacer su, su trabajo, ¿no?

Y, y se pueda implementar, pero no, no entrarán ahí. Y-- pero eventualmente, yo creo que incluso usuarios, eh, finales que, que tengan cierto conocimiento podrán acabar haciendo sus integraciones con este enfoque AI first, ¿no? Eh, tendrá que ser: "Pues oye, yo tengo mi, mi herramienta, mi RP in-house, y sí que tengo esta API, pero es algo interno y, y tengo capacidades de, de desarrollo.

Factorial me permite hacerlo, pues lo, lo puedo hacer yo también", ¿no?

Hay algún caso ya de... O sea, es cierto que el cliente final, el usuario final, la persona de, de, de people, ¿no? De, de, de HR, pues, mmm, pues no se va a poner a hacer un desarrollo, aunque sea en lenguaje natural, ¿no? Eh, pero hay ciertas integraciones, como, pues la típica de los ficheros que exportamos, que es, al final es una integración, pues muy típica, porque hay un montón de sistemas de payroll, por ejemplo, antiguos.

Eso ya sabes que está muy fragmentado, que no tienen APIs. Esa es la realidad. Esos sistemas no funcionan con APIs. Eh, esas capacidades de poder personalizar esas extracciones, que al final son transformaciones de datos, no dejan de ser otra integración. Esa sí se la vamos a permitir hacer a los usuarios finales, porque requiere más lógica de negocio, que es lo que ellos saben a final-

Que es mapear los campos y definir-

De hecho, ya lo están haciendo en muchos casos, ¿no? Se descargan el export, lo pasan a su Excel. Efectivamente.

Lo hacen a mano.

O sea, la transforma-- el ETL que decías tú antes-

Exacto

...es alguien que se descarga un fichero, lo manipula.

Exacto.

Esperemos que lo haga bien y lo importa en otro sistema que se hizo en los 70.

Eso, ese, este, eso este año, eh, ya va a estar disponible para el usuario final, ¿no? A día de hoy, ya tene-- ya hemos, eh, ten-- ya tenemos ese desarrollo basado en especificaciones, eh, bueno, que hemos presentado en las últimas product reviews, que eso sí que ya la audiencia sabe lo que es una product review de Factorial, ¿no? Em, en la que, pues requiere que el equipo de desarrollo de ingeniería tarde unos minutos, una hora en hacer ese export, que es lo que hemos estado testeando durante este quarter.

Ha funcionado bastante bien y ahora va-vamos a empezar a liberarlo primeramente a nuestro equipo de forward deploy engineering y finalmente a que el usuario final pueda custom-customizarse e-ese tipo de, de desarrollo. Y en el caso de, de estas integraciones más complejas, pues la idea es que ya este año las-- los clientes finales, con su equipo técnico, nuestro forward deploy engineering o los partners, pues con una especificación, ya desarrollen, eh, de forma automática o semi asistida, eh, esa integración.

Y estamos muy cerca ya de, de ese punto.

Entonces, de ca-- al cliente de Factorial, eh, lo que le va a cambiar es, eh, lo que has dicho tú ahora, ¿no? Podrá integrarse, eh, con cosas custom utilizando la tecnología de, de YepCode, pero sobre todo verá la velocidad de potenciales integraciones disponibles en Factorial explotar.

Totalmente.

Porque ahora una integración era un parto, y me acuerdo de la cantidad de discusiones y roadmaps y priorizaciones y recursos, y cuesta mucho, a de repente que salgan como churros.

Exacto. Es que hemos pasado de un enfoque más, el típico enfoque de proyecto, ¿no?

Sí.

Vamos a hacer, eh, la integración con-- y tardábamos meses. Hemos pasado a hacerlo en semanas y queremos avanzar más. De hecho, a día de hoy, el problema no es el desarrollo de la integración. El problema es la especificación, porque en muchos casos, aunque nosotros tengamos esta parte del blueprint, no tenemos el del sistema con el que nos integramos. Entonces, ese discovery

Pues ese discovery es lo que nos bloquea, lo que todavía nos está generando, pues, mmm, tardar semanas en hacer las integraciones.

Ahora, yo soy ingeniero también, pero te hago el challenge, ¿eh? Porque el ingeniero siempre dice: "No, no, el problema no es, eh, construir el código, es que el spec está mal, es que la especificación está mal", ¿no? Y luego el de producto dice: "No, no, si está clarísimo, pero el programador tarda mucho, no se entera, tal". Entonces, bueno, eh, es cierto que en integraciones no es rocket science si sabes lo que tienes que hacer.

Exacto.

El problema es que saber lo que tienes que hacer es muy complejo.

Es complejo y forma parte también de los ingenieros, porque los ingenieros somos los que luego cuentan las APIs.

Correcto.

Y, y demás.

Sobre todo en este mundo de las especificaciones ingenieril, digamos, es mucho más técnica.

Exacto.

Eh...

Otra cosa que mejoramos, eh, que creo que también es superimportante, porque ha sido una mejora en los últimos años y ahora, eh, pues en los últimos meses, y, y lo vamos a potenciar más, eh, va a ayudar mucho a nuestros partners. Es que antes, cuando un partner, hasta hace poco, cuando un partner hacía un conector de integración, digamos que todo ese flujo de integración, que es un proceso de negocio, corría fuera de Factorial y nuestros usuarios estaban como, como ciegos, ¿no?

O sea, sabían que pasaban cosas, pero no lo podían ver de, de...

O sea, esa integración era un poco un parche.

Era un parche. Bueno-

Que estaba por ahí.

Es la típica inteo-integración de toda la vida, ¿no?

Sí, se, se han hecho así siempre-

Siempre

...casi todas.

Ahora-

Y falla.

Falla.

Y nadie sabe por qué.

Y nadie sabe-- exacto.

Ni dónde está.

Exacto.

Qué ha pasado, ¿no? Es como: ¿dónde está el servidor para darle con el botón? Porque literalmente puede ser que esté en un, en un armario.

Y para nosotros también es algo, eh, complicado de poder dar soporte, porque no corre en nuestra plataforma, no es una plataforma conocida, muchas veces en un lenguaje que no-- del que nosotros no tenemos expertise, por mucho que haya IA y demás. Y, y con este modelo evolucionamos un poco. Cualquier integración va a estar preintegrada ya en Factorial. El usuario, eh, pues en la típica, eh, sincronización que tenemos con A3, por ejemplo, de los empleados.

Si mañana viene un cliente y quiere integrarlo con otro, eh, sistema, pues en el mismo botón que hoy pone, eh, A3 con una serie de, de información, pues a él le aparecerá el nombre de su sistema de forma automática. Y esa capacidad de integración dentro de Factorial para nuestro-- la-- para la experiencia de sus usuarios es increíble.

Y, Miguel, ¿qué valor tiene para ti, para nosotros, las integraciones que ya estaban hechas en YepCode? O sea, el catálogo, ¿no? El back catalog, lo que, lo que ya se ha hecho porque algún cliente se lo ha pedido, porque lo han hecho ellos proactivamente, versus la capacidad de hacer integraciones en minutos, eh, long tail.

Emm, bue-- no acabo de entender la pregunta, Jordi.

YepCode viene con integraciones hechas.

Ah, con los conectores.

Viene con un catálogo de conectores hechos.

Mmm, realmente, eh...

Algunos sí.

A-algunas sí que ya, ya las hemos implementado, pero da el-- los foundations para construirlas, ¿no? Pero no es que otros-

Son las recetas estas que decías tú antes al final.

Esa-- sí, tenemos templates, pero acaba siendo código. Es decir, no hay una-- no hay cajas de un vendor concreto en YepCode. Hay la posibilidad de conectarte, pues si ofrece-- Shopify ofrece un SDK, pues puedes utilizarlo en YepCode. Muy straightforward, no, no hay que hacer, eh, ningún despliegue ni nada, ¿no? Eh, pero la idea es ese enfoque developer first, que también es lo que mejor encaja hoy en día con los agentes, ¿no?

Vale, ahora entraremos en el futuro de las integraciones.

O sea, no tiene-- o sea, yo no veo mucho valor en el conector pre-preconstruido. Veo mucho más valor en cómo está estructurada la plataforma de YepCode con toda la capacidad para tener, eh, esta parte de los, de los blueprints, de los SDK compartidos, ¿no? Como una librería, entornos aislados, todo securizado, eh, la capacidad de poder desarrollar, bueno, eso que vamos a comentar de, de los agentes de forma mucho más rápida.

Ahí es donde está el valor.

Esa es la gran diferencia con el Zapier.

Mhm.

Que su claim es 850.000 integraciones. Y tú dices: "Es que las que tengo me dan igual".

Pero hasta-

Que te la vuelvo a hacer.

Sí, hasta están-- yo creo que están pivotando algo. Bueno, como curiosidad, el CEO de Zapier, Wade Foster, un día me contactó por LinkedIn cuando no sé dónde nos vio. "Oye, a ver qué hacéis", tal. Y estuvimos charlando, ¿no? Y, y yo creo que, que están explorando. Date cuenta que con los agentes, bueno, igual ya estamos saltando al futuro.

No, no, no vamos ahí. Vamos a, vamos a las interacciones en el mundo de los agentes.

Ahora Zapier ya tiene su chat de: "Hazme esta integración". ¿Y qué más te da si hay un chat que te acabe transformando ese prompt en cajitas de Zapier, que, que te lo acabe transformando en código que resuelve el mismo problema, no?

Pero ¿le puedes pedir que te haga una integración con el RP obscuro que solo se usa en un pueblo de Galicia?

Tienes-

O solo le puedes decir: "Haz una integración con HubSpot o con Shopify"?

Tienes que tener la documentación, pero toda la gente, si hay un PDF con, con la documentación, se lo puedes adjuntar al agente y que lo tenga en su cuenta.

En Zapier, ¿eh?

Ah, en Zapier-

No.

No, no, en Zapier no porque-

En Zapier solo si existe el conector.

Sí, tiene un con-conector genéricos.

En YepCode sí, claro, de esto estamos hablando.

Claro, sí. En, en Zapier hay conectores genéricos de llamadas, lo que sea, pero-

O sea, tú puedes hacer-- puedes usar el chat, pero el chat es un poco tonto entre comillas, porque lo único que hace es utilizar las conexiones que ya están hechas. Eh, vale. Entonces, hay un, hay un debate desde hace un año, eh, que tengo yo solo, que si el MCP es una parida, eh, o es-- o lo cambia todo, ¿vale?

Porque las APIs, que al final la API es, em, eh, el interfaz programable para aplicaciones, ¿no? Son las iniciales en inglés, que es como un software habla con otro software. Esto es viejo. Ya las APIs REST, las APIs HTTP, ¿no? Incluso XML, ya llevamos muchos años donde las APIs son una cosa que todo el mundo tiene, todo el mundo utiliza y funcionan muy bien y permiten hacer lo que, lo que quieras.

Y de repente se pone de moda el MCP. Eh, ¿hace falta el MCP? ¿Creéis que hace falta el MCP o ya estábamos la mar de tranquilos con las APIs? A ver, ¿qué es el MCP? ¿Qué es el MCP en 10 segundos?

MCP es un protocolo que al final es una nueva forma de definir una API con una serie de, de, de reglas para que los agentes hablen-- se comuniquen entre sí, ¿no? Al final es más contexto, más definición de las reglas, cuál es el propósito de, de las tools, cuál es el propósito de cada una de las cosas.

¿Pero esto no es lo mismo que la documentación de una API?

Claro. O sea, en teoría debería estar optimizado para que los agentes hablen entre ellos, ¿no? Pero hoy día la comunidad está totalmente dividida O sea, que el MCP es el futuro, mmm, no hay consenso. Cada día hay más, eh, debate sobre el tema, ¿no? Y sobre todo porque, eh, creo que los, eh, los modelos han mejorado tanto-

Sí

...que-- es que esta es una de las corrientes, ¿no? Los modelos mejoran tanto que ya solo con-- teniendo me-metainformación suficiente en las APIs son capaces-- ¿no? Ahora, después, ahora viene la contrapartida, ¿no? Con el incremento de los costes. Vas a ver las últimas semanas. Eh, bueno, pues ahora viene más el-- la, más la optimización, no tanto reasoning, no tanta potencia.

Entonces, otra vez, el metadato bien estructurado vuelve a ser relevante. Esto es que cambia cada mes.

¿Pero a ti te hace falta un MCP, Miguel?

No, no.

¿Tú crees que hacen falta, Marcos, los MCPs?

Eh, a, a ver, yo creo que hay que ver cómo se utiliza, ¿no? Porque lo que no me tiene ningún sentido es hacer un MCP que exponga literalmente lo que expone un API, ¿no? Porque una API está desnormalizada, ¿no? Y-

¿Qué significa esto?

Que, que hay un método para cada cosa, ¿no? Y por ejemplo, si tú quieres, en Factorial, quieres crear un time off, antes de poder invocar al método de crear un time off del API, tienes que tener un método que te vuelva los tipos de time off que hay, ¿no? No tiene sentido crear un MC-MCP que exponga: "Dame los tipos de time off, eh, déjame crear un, un time off".

¿Por qué? Para hacer una, una operación, ya le hacen falta dos invocaciones en el MCP, ¿no?

Con lo cual pierdes tiempo, cuesta dinero.

Lo que puede tener sentido es, mmm, vamos a crear casos de uso más complejos que el API no soporta, mmm, end-to-end, ¿no? Y los exponemos como tools.

¿Esto no era GraphQL?

No.

Este, esto es los, los API gateway, ¿no? Estamos hablando de-

Sí, pero, pero-

...de que GraphQL también empieza un poco la misma premisa, ¿no? Sobre todo con el, con el auge de mobile.

Bueno, pero te-- eh, GraphQL estamos orientados al tema de las mutations, pero sobre todo a poder explorar, eh, la información de tus aplicaciones de una forma más SQL estándar, ¿no? Con la que necesites.

La que necesites.

Que sea una microservición.

No, no como tú has diseñado las API calls, sino como yo la necesito. Claro, en el caso de las APIs, si comparas GraphQL con API REST, ¿no? API REST te, te ofrece un recurso y tú solo consultas ese, ese recurso, aunque hay empresas que han extendido esto, han creado un modelo sobre API que te permiten proyectar y demás, ¿no? Pero bueno, el estándar. Y GraphQL realmente, eh, te permite hacer todas estas relaciones, la proyección.

Oye, quiero consultar empleados, pero también con equipos y además solo quiero que me muestre el nombre del empleado y el nombre del equipo. Ese tipo de cosas, agregaciones, te da muchísimo más potencia. Pero también te digo que GraphQL tuvo un auge y a día de hoy está superestancado el crecimiento, ¿no? Porque-

Ya no, ya no mola GraphQL.

Como toda tecnología, ¿no? Coge un pico y, y después, pues cada o-- cada tecnología tiene un uso, ¿no? Entonces, en MCP sí que lo veo un poco esa-- como tú estabas comentando, esa agregación, ese API gateway que te expone más procesos de negocio, no tanto recurso.

Sí, y yo creo que el, el beneficio que puede tener es, mmm, que ha sido un estándar para comunicar. Pero yo cuando salió MCP dije: "Pero esto, ya hay APIs", ¿no? Eh, volviendo a-atrás, ¿no? L-Lo que creo que, eh, cada vez puede tener menos sentido, eh, para MCP es, eh, cómo decir, los modelos tienen cada vez más capacidades de generación de código, ¿no?

Y tú le puedes dar una especificación de una API y te puede generar un script que sí que te cubre ese caso de uso end-to-end, ¿no? Pero necesitas un entorno donde ejecutar de forma segura código que te ha generado un LLM que no puedes confiar ni tirar en tu servidor porque no sabes lo que va a hacer, ¿no? Y eso es una de las cosas que resolvemos en Jet Code, ¿no?

En Jet Code, cada ejecución estamos dejando que cualquier persona entre a una plataforma, escriba el código que quiera. Es decir, eso tiene que estar blindado, ¿no? Y entonces es algo que también permite Jet Code, ¿no? De, eh, recibir código y ejecutarlo en entornos seguros. Y ahí sí que ese código que te ha generado el LLM lo puedes ejecutar. Sí que le puedes proporcionar las credenciales, no en el código, porque no le deberías dar acceso a, al LLM, a tus credenciales, pero Jet Code te da la facilidad de definir esas credenciales que están a disposición del código.

Y entonces eso sí que se permite. Y, y así sí que se resuelven estos casos de uso end-to-end con-- de hecho, hemos hecho algún vídeo de demo ya hace tiempo, antes de ser incluso proveedores de, de Factorial, de: "Oye, agente, dame-- dime las vacaciones que le quedan a esta persona, este es el API de Factorial, y en tu cuenta de Jet Code ya tienes un API key", no le dices el valor.

Y el LLM generaba un script que atacaba a distintas, eh, métodos del API de Factorial y daba el resultado, ¿no? Y todo eso on the fly.

Yo, mi opinión es que si la única razón por la cual MCP, el concepto, porque para mí, que es un estándar, y es que ni siquiera lo compro, que es un estándar, porque al final es, es un estándar muy, muy, muy tonto.

Y nació muy malparido, que cuando-

Sí, que sacaron primera versión pensando que no tal y...

Pero que dice que hay muchos estándares de documentación de APIs que ya nos valían. O sea, yo creo que el estándar de MCP no nos trae nada que no tuviéramos ya antes. L-La única razón por la que creo que ha triunfado el estándar de MCP es que como MCP ha nacido para agentes, si tu empresa tiene un MCP, estás diciendo que tu empresa es AI. Entonces, todo el mundo ha hecho un MCP solo para poder decir que es AI, cuando en realidad, si todos se hubieran de-- puesto de acuerdo diciendo: "No, lo que tenemos que hacer es arreglar nuestra API para que sea un poquito más use case driven y que, y que traduzca mejor a la acción, ¿no?

Al tool calling y el tipo de acción or de data retrieval que quiera hacer el usuario del agente", ya estaba. No hacía falta llamarle nada. Pero bueno, es igual, es un poco...

O sea, en algún momento yo creo que sí, que no sé si será MCP o será otra cosa, porque no, no es solo el estándar, ¿no? O sea, si utilizamos, eh, REST, eh, pues digamos que la especificación estándar es Open API, pero el protocolo es HTTP, ¿no? En MCP, pues al final es un protocolo para agentes. Creo que cada vez tendrá más sentido, porque creo que además es que la eficiencia va a ser más relevante cada, cada día, ¿no?

Yo no sé si va a ser, si va a ser en MCP, pero que hay que seguir evolucionando, eh, esas capacidades de integración en términos de performance, especificación y demás, para que los modelos y los agentes sean más performantes

Gaste menos token y, eh, piense menos. Eso seguro que hay mucho camino por delante.

Mhm.

Marcos, uno de los debates que también está habiendo últimamente es si las empresas, los proveedores de software, sobre todo de system of record, ¿no? Y ahora se llama también system of execution. Está muy de moda esto para la gente. Se quiere salvar del SaaSpocalypse, ¿no? Y dice: "El SaaS ha muerto, pero yo no", por, por estas razones que lo hemos hablado mil veces. Eh, hay empresas que están empezando a recortar acceso a sus APIs y otras que están haciendo lo contrario, ¿no?

Que, que dicen: "No, no, yo ahora soy solo una base de datos, soy..." Incluso algunas grandes empresas de SaaS están diciendo: "Yo soy headless. Mi, mi SaaS-- yo era SaaS y ahora soy headless". Con lo cual están diciendo: "Soy un modelo de datos con APIs y MCPs". ¿Vosotros habéis visto, consumiendo muchas APIs o ayudando a vuestros, eh, eh, clientes a consumir muchas APIs, eh, una dirección o la otra?

¿O es todo lo mismo que era hace un año o dos?

Mmm, yo creo que la, la potencialidad está ahí, ¿no? Y en-- y de hecho, eh, eh, mismamente en Factorial, ¿no? Que estamos hablando con Microsoft y cómo están haciendo cosas alrededor de Copilot, de WorkIQ y tal. En alguna reunión salió la idea: "Joba, es que Factorial está muy bien, igual podría ser un, un software as a service que podríamos utilizar desde toda la capa agéntica, ¿no?

O, o algo así". Y-

¿Qué quiere decir esto?

Pues quiere decir que a lo mejor puedes llegar a, a, eh, dotar a, a este agente de todo el acceso a Factorial y que tenga una capa para gestionar toda su lógica de, de HR o de, o de business, ¿no?

Sin interfaz.

Sin interfaz.

Solo agénticamente.

Podría llegar a ser, pero, eh, obviamente, tiene que ha-- podría tener sentido a lo mejor si la fuente de la verdad de, de empleados ya está en otro sitio, se quiere entrar ahí porque, eh, Factorial resuelve perfecto casos de time off, time tracking y no lo quieres meter en otros sitios, pues podría llegar a tener sentido, pero ahora mismo la verdad está todo bastante difuso.

Sí que he visto noticias, creo que era Salesforce, ¿no? Que estaba intentando que la gente ya no entrara en el, en el CRM y tal, pero no sé... No tengo una postura muy clara.

No creo que estén intentando que no entren. Han anunciado, ¿no? Que son headless y que están intentando mantener al menos la base de datos, ¿no? Dice: "Si vamos a perder la app, al menos que lo construyan encima de su plataforma", que ya llevan años, en realidad, ¿no? Salesforce compró hace siglos Heroku, que, que podríamos llegar a decir que es de la misma categoría que YepCode, como una plataforma que te permitiría desarrollar.

No era para integraciones, pero-

Era más different a todo

...digamos, pero, pero era un movimiento que de hecho lanzó force.com. Estoy hablando de hace quince años, quizá, ¿eh? Hace bastante ya. Eh, pero Heroku era lo más cool del momento en su, en su época para Ruby y para algunas otros, eh, lenguajes de, de programación. Entonces, vosotros, o sea, tú no ves, eh, problemas de APIs que te estén haciendo rate limiting, que te estén capando el acceso porque la gente se está volviendo paranoica y dicen: "No quiero, no quiero convertirme en la base de datos en una commodity y que el otro se lleve los datos a otro sitio".

Mmm, no, no me he encontrado con situaciones así. La verdad es, es algo que habría que, que pensar en profundidad, ¿no? Para, para ver qué, qué va a pasar, ¿no?

Mmm. ¿Tú, Miguel, tienes opinión sobre esto?

A ver, em, yo creo que no tanto las APIs, porque la API en sí mismo lo que te da es dato, ¿no? El gran problema del mundo del dato, da igual que sea el mundo analítico, APIs y demás, es entender el significado, el valor, ¿no?

El valor que aporta y tal. Creo que es más importante a día de hoy para, para cualquier software, SaaS o, em, la capacidad de, de, de ese conocimiento, sabes, que es ir a los clientes, entender cuál es su problema. Ahí es donde está la clave, no en, en, en capar una API o no exponer una API, sino en esta parte, ¿no?

Entonces, indudablemente ya hay un montón de compañías y de, y de uso-- de soluciones, y cada día más, em, que exponen menos este tipo de información, que tienes que ser un cliente para poder acceder a ese, a ese dato. Y yo creo que cada día iremos más ahí, sobre todo además por el movimiento que ha-- que-- o sea, uno, cómo están evolucionando los modelos.

Eh, la verdad es que desarrollar, generar código se está volviendo caro con los últimos movimientos que se están haciendo.

Sí, pero caro, cuidado, pero más barato que con humanos.

Más barato que con humanos.

Ahora nos quejamos por cien euros. Lo que cuesta un desarrollador.

Bueno, oye, eh, de momento han hecho en algunos casos un por diecisiete o un por veinticuatro del, del valor, ¿eh? Del coste.

Del coste por token equivalente.

Del coste por token. Entonces, eh, y después, que ese-- esos token que tú estás consumiendo sean eficientes, que esa es otra, otra...

Que la gente no malgasta, ¿no? Que hay mucho-

Exacto, que sea productivo lo que generan, ¿no? Pero bueno, en realidad la línea de código es muy rápida a día de hoy. Eh, y-

Sigue siendo mucho más barata que hace dos años.

Sí, sí, muchísimo más barata. Y, mmm, y bueno, sabes, ellos ya han anunciado que se están-- que se quieren meter en verticales, ¿no? Entonces...

¿Quiénes son ellos?

O sea, ellos es-

Los modelos.

OpenAI, Anthropic, o sea, están-

Bueno, hoy Anthropic, de hecho, que hoy no hacemos tertulia de novedad, pero hablaba de, ah, am, Claude for Legal, que es como ya tenía productos de legal, pero es otra iteración todavía más metiéndose en el terreno de los Harvey y de los Legoras.

Claro. Entonces, ahí es donde vamos a encontrar el punto en, eh, poder aportar valor a los clientes, poder ofrecer la información de cómo tienen que comprar el producto, dónde está, cómo resolvemos sus problemas, pero al mismo tiempo, mmm, pues esta parte del core que, o sea, que hay que en parte, pues no facilitarlo.

Otra cosa que se está limitando mucho ahora con el auge de los agentes es el scrapping, ¿no? Ahora hay un poco de guerra, sobre todo en la parte más consumer, noticias, propiedad intelectual, ¿no? Si tú intentas desde Claude, eh, mirar Twitter, ¿no? Dile-- yo a veces lo hago, digo: ¿Y cuál es ese tuit que vi? Me dice: "Ni de coña".

O sea: "Elon no me deja tal. Tienes que usar Grok si quieres que utilice Twitter y tal", ¿no? Y viceversa con YouTube, que cada uno tiene su rinconcito y lo protege a, a-

O LinkedIn, ¿no?

...a muerte. ¿Eh?

O LinkedIn también.

Todas, todas, LinkedIn, to-todas las plataformas que tienen, eh, networks o datos Públicos, pero que solo quieren que se consuma en su propiedad, están, eh, luchando el scrapping a muerte. Por otra parte, ehm, se pueden hacer muchas integraciones con scrapping.

Mhm. Mhm.

O sea, hace años que existe el RPA-

Mhm. Sí

...¿no? Que creo que es el Robotic Process Automation. Que UiPath es una empresa europea de las más famosas, eh, te permitía hacer esto, ¿no? Que esto es crear una integración con un software que no tiene API, que, que es una interface hecha quizá hace treinta años, que nadie toca y que literalmente imita a un humano, ¿no?

O sea, busca los píxeles y hace clic en el botón. Ehm, ¿esto es, es el futuro? O sea, eh, un YepCode, por ejemplo, o dentro de Factorial, Factorial YepCode, eh, ¿vamos para allá a llegar a hacer integraciones con, eh, soluciones que no tienen API a base de brute force, de meter un modelo muy inteligente y que se espabile y que haga el RPA?

Pues fue justo una duda que, que planteé estas semanas de, de onboarding en Factorial. Eh, sí que lo planteé hablando de, de algunas soluciones como Sage, ¿no? Que suelen ser, eh, aplicaciones de, de escritorio. Dije: "¿Alguna vez valorasteis esto, utilizar RPA para este tipo de clic clic?" Porque hay muchas que no te dejan ningún tipo de API ni nada, ¿no?

Y, mmm, no, no había, no había ningún caso todavía en la compañía, ¿no? Pero yo creo que hay esa, esa posibilidad, ¿no? De llegarlo a hacer. Ya hay herramientas que lo permiten, como CloudCoWork o, o otras que te permiten esa navegación. Entiendo que está limitada de momento a los navegadores, pero, eh, por eso-

Sí, ahí tenemos ese caso en Factorial, ¿eh?

¿Sí? Ah, pues no-

Es que, ¿sabes?

Cuando lo pregunté -

Eso es el challenge de Factorial, que, eh, al final somos un producto tan amplio, cada día más, que es muy complicado estar, eh-

Saber todo lo que está pasando.

Sí, pero precisamente en, en IT, en lo-- en vertical de IT, para la parte de, eh, a veces en la gestión de, de-

Mhm

...la autorización o la, o sea, la activación o desactivación de, de, de seats en, en ciertos softwares que no, no proporcionan por API, pues sí estamos con, con esta solución de poder hacerlo con un RPA.

O sea, hay muchos softwares que tienen API para el producto, pero no tienen API para la administración de la licencia o del billing.

Exacto.

Y eso lo, lo hacemos con scrapping.

Total.

Bueno, no es scrapping, es RPA, digo, porque scrapping es-

Ah, ya

...es, es-- bueno, es que el scrapping lleva mucho tiempo, ya sabes que esto es como los virus y los antivirus, ¿no? Que siguiente evolución y llega el de antivirus y llega.

Totalmente. El perro y el, y el ratón.

Siempre ha sido así, ¿no? Entonces, lo de esto no es repetitivo constantemente, ¿no? Es muy raro que un RPA con el objetivo que-- el propósito que tenemos en Factorial sea detectado como una herramienta de scrapping, porque realmente hacemos acciones automatizadas, ¿no? En scrapping es: hago esas acciones y además me quedo con la información, lo hago, hago mucho recorrido, ¿no?

RPA, o sea, la diferencia, tú estás diciendo, el scrapping se puede entender como: estamos chupando datos de una plataforma y tú dices: "No, no, estoy interactuando con la plataforma para el bien de todo el mundo, no para el mío". No es que yo esté-

No, hago "N" procesos, no estás todo el día recorriendo todo el catálogo, por ejemplo, de un retailer, ¿no? Que lo hacen habitualmente. Recorre todo el catálogo de Mercadona para darle el-- los-- el, el pricing y poder hacer yo, eh-

Que eso lo hacen igualmente todos.

Eso lo hacen igualmente todos.

Pero, pero hay un equipo intentando que no lo hagan-

Sí

...los del otro lado, ¿no?

Constantemente, sí.

Y también hay que estar-- el problema de, de scrapping puro es estar atento a los cambios que puede haber en la plataforma, ¿no? Que te puede romper la integración muy fácil. Si se cambia la fuente de origen, ¿no? Si nos vamos a un, a un RPA más agéntico, pues el propio agente se puede adaptar a la nueva interfaz que haya podido aparecer porque se ha cambiado ese, esa plataforma.

Esto es una idea.

Es cierto que los modelos al principio los-- o sea, hubo un auge de scrapping con los modelos. Ahora lo han estado capando y tal, pero al principio, buf.

Bueno, es que es muy obvio, ¿no? Yo me doy cuenta con mis casos de uso. Típico, preparándome un pódcast o preparándome una tertulia y voy con el móvil, eh, hablándole al, al, al Claude y diciéndole: "Investígame esta compañía", ¿no? Y me dice: "Mmm, no puedo acceder a esta web". Digo: "Pues no, pues usa Dispatch, ves a mi ordenador, abre el navegador de mi ordenador y es-- lee la web desde mi navegador", que esto no es scrapping, esto es computer use.

Que en realidad es scrapping, pero utilizando tu computer en lugar de un headless browser, ¿no?

Sí, sí, sí.

Eso de momento parece que cuela, que, que de hecho toda la tontería, bueno, tontería no, toda la explosión de Mac Minis-

Mhm

...es al final-

Ah, sí

...es un scrapping descentralizado.

Sí, sí, sí.

O sea, la única razón, y yo estaba a punto de comprarme un Mac Mini, solo por esto.

Ah, ¿sí?

Porque-- sí, porque, porque me permite desbloquear el caso de uso de navega New York Times o navega Bloomberg o navega Twitter y, y, y, y guárdate el resultado para luego hacerme el resumen de cara a la preparación del pódcast. Y si lo hago desde un VPS, como me monté el OpenClaude con un VPS, mmm, no consigue nada. Está todo capado, ¿no?

Las IPs de los servidores y de los hostings ya están, vamos, más que, más que machacadas. Em, eh, perdona, que te has dicho, te he dicho: esto solo es una idea. Estabas empezando a hablar, es decir, ahora, ¿no?, las integraciones se rompen. Uno de los problemas de las integraciones, eh, sobre todo si las hacemos, como decía Miguel antes, ¿no? Pues un partner viene, hace una integración y luego partner se va a hacer otra cosa, ¿no?

Porque ya quizá esta integración ya la ha cobrado y no se dedica, no es un SaaS ni una plataforma. Eh, y al cabo de tres meses se rompe. El proveedor de una de las APIs ha hecho un cambio que no es backwards compatible. Eso pasa todo el rato. Eh, ¿se curan solas las integraciones?

Ahora mismo no tenemos esto implementado, pero sí que tenemos el agente que, tal como las construye, pues las puede estar monitorizando y arreglar en, en tiempo real, ¿no? Es decir, tenemos las, la base para poder hacerlo. No, no hemos implementado ese caso de uso, eh, con ninguno de, de nuestros clientes, ¿no?

Pero yo creo que sí, que podemos ir hacia, hacia ahí, porque lo que sí que tiene, eh, YepCode como plataforma es toda la traza de logs, toda-- parámetros de entrada y salida, todas las respuestas, y, y se podría llegar a hacer.

Estuvo un boom en los 2010 de los 3Scale, una startup nacida en Barcelona, de hecho. Eh, Apigee, ¿no? Mashable. ¿Te suenan estos productos? Ya hace unos añitos que las compraron casi todas, ¿no? 3Scale la compró Red Hat, creo, eh, Apigee la compró-

Google

Google, Mashable, IBM o Intel, ¿no? Un-un-un-una empresa muy, muy, muy grande de estas. Y esto ha desaparecido un poco del mapa, que era el API gateway monitoring, eh, ¿no? Como un middleware, eh, para monitorizar y medir las APIs, gestionar los tokens, ¿no? Eh, esto-

Pero ¿qué dices que ha desaparecido del mapa? Siguen ahí, ¿eh? Nosotros lo usamos, además.

¿Sí?

Sí.

Anda, pues ha desaparecido de mi-- es que yo ya como ya no programo, ya no me entero. Pero por eso pregunto a vosotros, que estáis un poco más al día.

No, no han desaparecido, ¿eh? Pero-

Eso es lo que quería preguntar. ¿Qué pasa con esa capa?

No, tiene todo el valor. Lo que pasa es que hay un montón de productos. O sea, Apigee en su momento fue el rey de, de API gateway y se ha acabado convirtiendo cuando lo pilló Google, cuando un poco ya se hizo un combo un poco más mastodonte, ¿no? Acabó de evolucionar todo XML. Pero nosotros utilizamos una versión de esa con Cloufer, una, una parte de que, que hace de, de API gateway, que es necesaria, que al final también un service mesh en Kubernetes es un servicio-

Pero tú lo dices para nuestra API o para las APIs que consumimos.

Para nuestra API.

Vale.

Tenemos un caso de uso, es que ahora que estamos con la parte esta de, de escribir de nuestra solución con arquitectura de celdas, que al final es tener diferentes tenants con, pues-

Vea, vea, Miguel. Explícalo para todos los públicos. Explícalo para todos los públicos, que te has metido en un jardín.

Es que-

¿Qué es de celdas y tenants y...?

Bueno, al final nosotros estamos creciendo, em... Estamos creciendo, pues a un ritmo bastante elevado, ¿no? Eh, eso implica más clientes, más usuarios accediendo a nuestra plataforma, ¿no?

Y más que queremos.

Y más que queremos. Entonces, para poder escalar hacia el infinito, necesitamos hacer un escalado horizontal. Un escalado horizontal, que creo que casi todo el mundo lo conocerá, es en lugar de, de ir añadiendo hardware a la misma máquina, tener diferentes máquinas donde podemos llevar la carga de esos clientes a cada una de las máquinas distintas.

Vale. O sea, un escalado vertical es un servidor más gordo.

Exacto.

Y un escalado horga-- horizontal son más servidores.

Más servidores. Entonces, nosotros lo que estamos evolucionando es hasta ahora teníamos un servidor que íbamos haciendo cada vez más grande.

En la base de datos, concretamente, pero teníamos muchos servidores.

Bueno, teníamos un Kubernetes, pero al final tenemos, digamos, un tenant, ¿no? Una caja que tiene muchos componentes.

Pero no digas que Factorial tiene un servidor, me cago en la leche.

Estamos haciendo una analogía, ¿no? Evidentemente-

Vale, vale, pero Factorial no tiene servidores.

Tenemos un montón de servidores, ¿no? Pero, eh, una analogía es: oye, tenemos una caja muy grande donde tenemos-

Vale

... muchos componentes que sirven a todos nuestros clientes.

Es un solo sistema.

Un solo sistema. Y, y ahora hemos evolucionado a tener varios sistemas. Desde el punto de vista de nuestros clientes usuarios, lo mismo.

No se enteran.

No se enteran. Es totalmente transparente para ellos. Pero nosotros, en nuestro, en nuestra plataforma, tenemos diferentes componentes. Para poder redirigir, tenemos una API gateway. Cada vez que se conecta un cliente dice: "Oye, eh, ¿este cliente en qué caja está?" En la uno.

¿Y estas cajas son todas iguales o son diferentes?

En dimensionamiento son diferentes, eh, pero en componentes son exactamente iguales.

O sea, hay el mismo software, diferentes datos.

El mismo software, diferentes datos. Y a ve-- y puede ser que unas tengan más recursos que otras, porque, oye, si empezamos una, una celda nueva en la que tenemos cien clientes, no va a tener el mismo dimensionamiento que una en la que tenemos cinco mil.

Incluso podrían ser distintos vendors, ¿no?

Podrían, sí, podrían, pero no.

Trabajamos con Microsoft.

Trabajamos con Microsoft.

La cara de Miguel.

Distintas ubicaciones, vamos.

Ubicaciones, eso te quería preguntar, ¿no? Porque hasta ahora, eh, toda la infraestructura estaba en un solo data center.

Exacto.

En Frankfurt.

En Frankfurt.

En Alemania.

Sí.

Y ahora pasaremos a estar en varios data centers.

Sí, ahora vamos a distribuir. Por ejemplo, tenemos mucho cliente en Hispanoamérica, Latinoamérica. Eh, ellos ahora mismo sufren un poco de latencia por la distancia.

Vienen a Europa.

Vienen a Europa.

Para cada llamada a la API, vienen hasta Europa y vuelven.

Exacto.

Que, que son milisegundos, pero es tontería.

Pero cuando hay muchos se nota, ¿no? O sea, los clientes grandes y tal.

La experiencia es peor.

Claro, exacto. Entonces, a esos clientes los vamos a mover a una celda allí en, en, en Latam, más cerca de donde están. Y concretamente, por ejemplo, en Alemania, que ahora con todo el tema de ley y demás, pues hay mucho de esto del, del cloud soberano, pues a los clientes-

Soberanía de los datos.

Sí. Eh, pues en, en ahí concretamente vamos a tener una celda con mucho más, eh, mucho más restrictivo a nivel de seguridad.

Más alemana. Una celda más alemana.

Más alemana todavía.

La otra también estará en Alemania.

También.

Pero una será para alemanes.

Exacto.

¿Y por qué me cuentas esto? Porque, porque la, la API gateway, la API gateway es ese componente que tiene la lógica de decidir cuando ala-- alguien hace login en Factorial, eh, a, a qué celda lo redirige de forma transparente. Y vosotros, Marcos, tenéis un producto equivalente, estabas diciendo, pero no para la API que tú ofreces, sino para monitorizar las APIs que consumes.

Mmm, no tenemos un producto como tal, pero sí que es algo que se, que se puede hacer con el agente que hay dentro de cada cuenta de Yecode, pues tiene su propio agente que, eh, nos apoyamos en OpenCode. Es decir, tú cuando quieres utilizar Yep Agent, se llama, eh, lo arrancas y te aparece un chat en, en tu cuenta de, de Yecode, a quien le puedes decir: "Ay, pues hazme este proceso, toma, esta es la documentación", etcétera, ¿no?

Y eso levanta en un sandbox seguro, una instancia de OpenCode que tiene acceso a tu código, está trabajando ahí, generando el código. Cuando lo tiene finalizado, pues lo puede subir. Pues ese mismo agente puede estar a través de MCP o de, o de la API de, de Yecode, estar viendo los logs de las ejecuciones y puede ser reactivo.

"Ah, ostras, ha fallado este proceso, voy a ver el error. Ah, pues ha cambiado esta firma de este API", y puede evolucionar, ¿no? Para, para sacar una nueva versión. Todo está con control de versiones para que no... bueno, poder hacer releases, etcétera. Pero sí que se puede hacer, ¿no? No es un servicio out of the box, pero el agente lo, lo permite hacer.

Vale, a mí me ha quedado claro lo que, lo que va a pasar. Oye, ot-- la otra noticia, quizá más importante todavía que, que Factorial adquiere Yecode, es que Factorial abre una oficina en Coruña.

Correcto, sí.

Explícanos quién habrá en esta oficina. ¿No estará Álvaro, Santi, Sergio y tú?

Correcto, inicialmente-

Que sois el equipo de Yecode que se incorpora a Factorial. Eh, pero pasarán más cosas en Coruña.

Hombre, sí, yo creo que-- espero que se vea con buenos ojos que aterriza un unicornio en, en Coruña, ¿no? Una empresa de producto.

No, no molestamos a nadie, al revés.

No, no, pero creo que, que, eh, hay muchísimo talento, ¿no? Hay una universidad que lo lleva haciendo muy bien muchísimos años, ¿no? Con la Facultad de Informática en la Universidad de Coruña

Hay grandes empresas que, que atraen muchísimo talento de, de ingeniería, ¿no?

Inditex, que antes decía Miguel, eh, es conocida, entre otras cosas, por, por mucha tecnología.

Mhm.

¿No? Es una empresa de fashion, pero tiene un equipo de ingeniería que, que es una pasada.

Sí, sí, se hacen muchísimas cosas. Hay más empresas muy potentes, ¿no? Pues, por ejemplo, Denodo Technologies es una empresa-- yo fui empleado ya hace muchos años, eh, y también hace las cosas bastante bien. Y, y yo creo que, que hay muchísimo talento, ¿no? Y que se va a poder, eh, atraer, ¿no? Talento para, para hacer crecer esta oficina, que inicialmente será de ingeniería, pero, pero esperemos que, que escale y que, y que haya muchos más Factorials por allí, ¿no?

¿Cuánta gente-- cuántas posiciones tenemos abiertas ahora en, en Coruña?

De momento, no tenemos ninguna posición abierta porque todavía estamos-

Ábrela ya, ábrela ya.

...en stealth mode de que, de que-

Bueno, porque hoy se anuncia.

Hoy se anuncia, sí, sí. Tenemos que, que empezar a, a contratarnos, sobre todo para esta equipo de API marketplace, ¿no? Que, que es donde más estaremos evolucionando todo este framework y, y dando solución. Ah, llevo estas dos semanas teniendo muchísimas reuniones con la gente de partnership. Se están deseando que, que podamos ir más rápido ahí, ¿no?

Y, y se ha estado haciendo un trabajo muy bueno en la parte de, del monolito de Factorial, de, de crear las, las bases para que lleguemos y, y podamos poner YepCode al lado para ejecutar la lógica en sí de las integraciones, ¿no? Y, y la visibilidad del usuario ya es, ya es algo que está resuelto por parte del equipo de API marketplace, ¿no?

Eh, entonces, esperamos vitaminar mucho esta oficina con mucha gente. Sí que va a ser una oficina marca Factorial con visibilidad. Esperamos también, a mí me gustaría personalmente, que generar más comunidad. Sí que hay, eh, movimiento, ¿no? Sobre todo en los últimos años.

Sorprendentemente, ¿no? Yo creo que en proporción a la población o al PIB, creo que hay una comunidad tecnológica-

Mhm

...eh, desproporcionada-

Sí, sí

...en, en Coruña, concretamente, en Galicia en general, ¿eh? Pero en Coruña concretamente. De hecho, en Itnig hicimos una tertulia-

Sí

...que tú antes me has dicho que, que viniste.

Sí, estuve por ahí.

Que hicimos ahora, no sé qué era, un año o así, no sé. Y, y la verdad es que a mí me sorprende, porque dices: coño, es una zona que no es de las más pobladas de España.

Mhm.

Y en cambio, hay mucha comunidad startup y, y tecnológica, mucho programador, eh, gallego por el mundo.

Y, y de hecho, en Factorial hay-

Está mucho gallego

...unos cuantos. Hay unos cuantos. Tenemos unos cuantos y muy buenos, además.

Pero también porque os buscáis los unos a los otros, ¿eh?

Hombre, a ver, siempre los gallegos siempre nos estamos buscando los unos a, a los otros. Vea dónde vamos.

Sí, sí. Em, vale, oye, vamos a hablar del proceso de la compra.

Mhm.

Miguel, ¿cómo se compra una empresa?

O sea, yes-

¿Cómo consigues? Porque ya nos has explicado cómo decides comprarla, pero luego, ¿cómo lo consigues?

A ver, siempre está esta parte, que cuando la digo, siempre me dicen que no suelte el pitch y demás, ¿sabes? Que... Pero lo primero es, oye, ¿sabes? Una de las cosas por las que siempre digo que Factorial es mi mejor experiencia profesional, pero aquí nunca me han puesto limitaciones, sino todo lo contrario, me han puesto retos, ¿no?

Yo no he participado en la adquisición de una empresa n-nunca en mi vida profesional. Y aquí, cuando surgió la oportunidad, lo premio-- lo primero que me dijo Bernat fue: "Oye, Miguel, tú lo lideras, ¿eh?"

Adelante.

"Tú te encargas."

Espabílate.

Exacto. Que pase.

Totalmente. Que pase, me gusta, dos palabras.

Entonces, eh, oye, ha sido un reto superinteresante. Eh, siempre he tenido a Bernat con-- apoyándome y, y dándome esos tips. Y, mmm, creo que la primera parte, que es la más importante, eh, que es un poco enamorar a la otra parte, ¿no? Sin hablar de ninguna otra cosa, ¿no?

El reto, lo que podíais aportar aquí en, en Factorial, el valor que veíamos en vosotros, en e-en el equipo. Ahí es donde he invertido la mayor parte de mi tiempo con, con Marcos y, y con el equipo, ¿no?

Mhm.

Y bueno, creo que ha ido bien, ¿no? Porque este es el-

Aquí estamos

...este es el, el resultado. Después, hay otra parte que ya más es esa, esa parte más de negociación y demás, eh, bueno, que ha sido un aprendizaje.

¿Cómo--? No hemos publicado los detalles de la transacción, eh, pero, pero ¿cómo llegas a hacer una oferta? Porque al final es-- hay que enamorar, estoy de acuerdo contigo, pero una vez incluso enamorado, luego hay que firmar papeles, ¿no? Y hay, hay activos, hay transacciones que pasan.

¿Cómo llegas a, a una oferta? ¿Có-cuál es el proceso? Teniendo en cuenta, además, tu dilatada experiencia comprando empresas.

Por ahí, el, el apoyo, el apoyo de vuestra parte, ¿no? Pues al final, em, te tengo que decir que Claude me ayudó bastante también, ¿eh? Pero bueno, eh, en, en el sector hay una serie de múltiplos, ¿no? Pues en base al revenue, al EBITDA, a ese tipo de cosas. Y, mmm-

O sea, buscas algún tipo de comparable.

He buscado métricas, comparables.

De benchmark, de decir: "Oye, no empiezo desde cero, empiezo de referencias."

Efectivamente, y es importante tener ese mentoring que he tenido con vosotros, eh, hacia dónde, hacia dónde íbamos, si era un punto correcto o no, ese tipo de cosas. Y, y al mismo, al mismo tiempo, creo que una oferta justa, ¿no? Para la otra parte y, bueno, encontrarnos en el camino. Ha sido-- y además, para mí, tengo que decir que es complicado, porque yo soy una persona que no me gusta negociar.

En mi vida, ¿eh?

Pues buen, buen rol.

Es, es, es un tema jodido, ¿no? Entonces, para mí ha sido el doble reto, ¿no?

Negociar, en, en el estereotipo, negociar entre dos gallegos puede ser durísimo, ¿no?

Durísimo.

Oye, y una cosa que no contamos en su momento, porque no se podía contar, pero tuvimos la suerte de que teníamos un offsite del equipo de management, ¿no? Justo cuando estábamos en estas conversaciones y, y dedicamos un buen rato, de hecho, a hablar de esto, que, que sirvió para que tú y el resto del equipo explicarais a todo el management de Factorial lo que queríamos hacer, por qué YepCode, quién era esta gente, ¿no?

Que nos, que nos aportaba, pero también para que todo el mundo pudiera ayudar un poquito en, en esta fase final, ¿no? Porque estábamos justo en este punto de-- con, con Excels arriba y abajo y, y, y trabajitas.

Sí, hubo un trabajo en equipo, ¿no? Aparte de esto, había un trabajo en equipo, de, pues, de el equipo lega-- del legal, finance, Morán, Lucía, todo el mundo.

El director financiero, la responsable legal, ¿no?

Efectivamente.

Obviamente, no, no te has sido tú solo con un papelito y un boli.

No, para nada. Ha sido un equipo coordinado, eh, como el management de Factorial es Todos vamos a-- con un único objetivo. Eh, para mí ha sido una experiencia, en general, espectacular.

Ahora viene lo más difícil, ¿eh? Que las compras de compañía, eh, em, digamos, empiezan el día que llega el equipo aquí. No, no acaban el día que, que se firma contrato, sino que empieza el día que llega ahí, ¿no? Y ahora, pues oficina nueva, equipo... Marcos, eh, ¿por qué vendéis?

Bueno, eh, e-era una de las posibles salidas de, de GetCode, ¿no? Nosotros, eh, bueno, GetCode nace dentro de-

Explícanos un poquito. Has sido muy rápido antes. Sí, explícanos un poquito más de dónde sale esto, porque lo has dicho-

Vale

...muy de pasada.

Vale, pues os cuento, si queréis, un poco mi historia, la historia-

Sí, venga

...de emprendimiento, ¿no? y esto. Bueno, yo soy ingeniero informático. Estuve trabajando-- empecé a trabajar bastante temprano, eh, todavía seguía estudiando y trabajando. Estuve en distintas empresas de, de Coruña. Acabé trabajando para Inditex también y allí coincidí con, con mis dos socios, con César y Felipe, que ya los conocía de la facultad, y siempre s-- fuimos bastante inquietos, ¿no?

Y, y hacíamos cosas allí y dijimos: "Joba, esto se-- creo que se podía hacer mejor". Teníamos ideas, ¿no? Y: "Somos jóvenes, ¿por qué no nos lanzamos?" Esto ya fue hace 17 años, más. Eh, ¿por qué no nos lanzamos? Y nos lanzamos-

2009.

2009, sí. En 2009 constituimos Trileuco Solutions, ¿no? Como teníamos alguna idea de producto, eh, antes de fundarla, ya empezamos a hacer nuestros proyectos por las noches para cuando abandonáramos nuestros puestos de trabajo, pues tener algo de, de revenue, ¿no? Y, y así fuimos empezando.

Y llegó el día de-- que dijimos-- me acuerdo perfectamente, fue, eh, desde la Universidad de Coruña nos concedieron un espacio, que no tiene mucha importancia, un local, pero dices: "Joba, pero hay alguien que-

Al principio, al principio todo, todo cuenta, ¿eh?

Hay alguien que se cree que, que podemos hacer algo, tal. Creo que deberíamos dar el paso, tal. Y, bueno, anunciamos que, que nos íbamos de, de, de esta compañía, de Inditex. Eh, al principio no fue una muy buena noticia, pero después, pues conseguimos negociarlo para, para salir.

Lo dices flojito, como si se fueran a enfadar, ¿eh? Me imagino el-l-la importancia que tiene esta empresa en-

No, pero era más-

...en Coruña y... ¿no? Miguel me mira. Que han pasado 18 años, Marcos, ya ha prescrito todo allí.

Sí, ya ha prescrito todo, sí. Eh, pero bueno, salimos de buenas formas. Algo que, vamos, a mí me lo dijo mi abuelo hace mucho tiempo y-

No te metas con Inditex.

Allá donde vayas, deja la puerta abierta por si tienes que volver, ¿no? Y, y de hecho, pues arrancamos e Inditex pasó a ser uno de nuestros clientes, ¿no? Eh, empezamos como modelo de servicios de desarrollo. Empezamos los tres.

¿Qué desarrollabais?

Pues, mmm, principalmente software de backoffice, eh-

Herramientas internas.

Sí, herramientas internas para Inditex, para alguna administración al inicio, algunos otros clientes, ¿no? Eh, por ejemplo, de NODO, que también habíamos sido empleados de esta compañía, pues también fue, fue cliente, ¿no? Y empezamos a escalar esta empresa hasta, hasta que en el 2023 éramos unas casi 50 personas-

Ostras

...eh, con, con las distintas, eh, líneas que teníamos, ¿no? de servicios de desarrollo. Pero ya durante todos estos años que fuimos escalando, algo que también hacíamos, éramos bastante inquietos y ideas que se nos pasaban por la cabeza, pues: "Esto podía estar bien hacerlo. Venga, pues lo hacemos dentro de la Software Factory", por dos motivos. Uno, que vamos a-- creando otros productos.

Software Factory es como llamabais a, a los side projects que hacíais.

Bueno, no, me refiero a la línea de servicios de desarrollo para clientes.

Ah, no, pero es lo contrario. Eso era lo que vendíais a los clientes.

Sí, sí. Pero, eh, arrancábamos ideas que teníamos. Pues, por ejemplo, mmm, somos bastante aficionados al mundo del deporte y cuando nos íbamos por ahí: "Estaría bien que nos pudiesen seguir desde casa, tal. Pues a este lenguaje Ruby on Rails, ¿por qué no empezamos a hacer algo para probarlo y tal?" Y, y así, pues creamos un producto que se llama Track the Race, ¿no?

Que es una plataforma de seguimiento de eventos deportivos con GPS. ¿Qué nos sirvió eso? Pues, eh, tenía varios, eh, beneficios. Uno, probar cosas nuevas, que el equipo se reciclara en, en tecnologías, eh, nuevas, ¿no? Tener un, un sandbox donde probar cosas, donde nosotros podíamos decidir la velocidad, lo que sea.

Siempre seguíamos atendiendo, obviamente, nuestra línea principal de proyectos, ¿no? Pero nos pers-- permitió ir lanzando ideas que al final algunas se convirtieron en empresas, ¿no? Y hoy en día, por ejemplo, Track the Race es, es una empresa que solamente hay dos personas que hacen labores comerciales vendiendo eventos deportivos, pues este servicio de tracking GPS, ¿no? Y además, cuando vamos a carreras, pues nuestras familias nos pueden seguir desde casa.

Y, y así seguimos escalando. Y, y eso en el 2021 empezamos con la idea de, de GetCode, ¿no? Y también vamos a crear esto porque creemos que tiene sentido. Además, hay un mercado potencial bastante inmenso, ¿no? Y, y eso con la idea de ir reciclando ingenieros que llevaban bastante tiempo en proyectos legacy de algún cliente, trabajando en Java dos punto no sé qué y nos metemos a, a todo.

GetCode nace con unos foundations muy buenos, ¿no? De, de arquitecturas, de tecnologías, etcétera. Entonces, nos permitió eso y, y ahora mismo vemos a GetCode que somos un equipo ahora mismo de cuatro personas, pero ha llegado a haber hasta 20 personas trabajando en GetCode en sus inicios, ¿no? Cuando todavía estaba dentro de la, de la agencia, ¿no?

De Trileuco Solutions. Esto fue entre el 2021 y el 23. Y en el 2023, eh, decidimos crear una nueva compañía para GetCode y yo me desvinculo de, de esta-

¿Por qué? ¿Por qué decidís esto?

Porque empezábamos a tener cierta tracción de clientes y queríamos-

¿Cuánto facturabais? ¿MRR o equivalente?

Yo creo que podíamos estar en los 100 K por aquel momento. A-anuales.

100 K anuales. Ahí es donde decís: "Esto tiene entidad".

Tiene-- sí, puede, puede empezar a, a traccionar, ¿no? Y entonces constituimos una, una nueva sociedad, movemos a-

No, no habéis puesto dinero para GetCode.

Sí que cuando Skin-- funda-

O sea, de fuera, quiero decir.

No, no.

No habéis levantado que-- perdona, no habéis levantado dinero de inversores para GetCode.

No.

Habéis ido invirtiendo los beneficios de la-

Nunca hemos levantado dinero de nadie. Todo lo que fuimos creando siempre fue con nuestro propio-

Reinvertíais los beneficios en ir creando los productos. Perdona.

Sí, sí, sí.

Es un matiz importante.

Sí, sí. Y, y de hecho, cuando nace GetCode, sí que movemos El activo, ¿no? Siempre fuimos muy formales a nivel de contabilidad, de tenerlo todo-

Bien hecho ahora. Si no hubiera tenido problema.

Sí, a nivel de registrarlo todo, ¿no? Y movemos el activo, movemos cierto cash y ya nace Gecod con capital social, ¿no? De 3.000 euros, ¿no? Y, y movemos también a un equipo muy core, pues a, eh, Santi Álvaro, que llevaba más de diez años ya con nosotros en la, en la agencia y, y se-- y pasan a ser parte de, de Gecod.

Y Sergio, que había entrado hace poco en, en Trileuko y también era muy prometedor y, y lo, lo movemos, ¿no?

Y tus dos socios se quedan...

Se quedan en, en Trileuko, sí, como liderando la parte de, de servicios de ellos.

Y luego la venden también. O la vendéis.

Sí. Eh, un año después, en el 24, pues surge una oportunidad de un proceso de, de build up. Pues unos-- una gente salía de, de una empresa que era singular, ¿no? Pues salían de la, de la capa de, de dirección y deciden, pues eso, que querían montar un proceso de build up y estaban buscando empresas que fueran excelentes a nivel técnico, ¿no?

Que, que fueran full servicios, ¿no? Y, y bueno, la verdad, empezamos a hablar con, con este equipo y hubo match, ¿no? Y yo hablando desde la capa de ser owner de, de la compañía, pero no estaba ya en el día a día, ¿no? Y, y bueno, eh, fue una forma de... En ese momento, Trileuko tenía como cuarenta y cinco personas por las que habíamos movido a, a Gecod, ¿no?

Y fue una forma de afrontar una etapa que sabíamos que si seguíamos por nosotros mismos, en ese momento éramos rentables, ¿no? Con un EBITDA bastante positivo y una compañía superoptimizada, ¿no? También los socios éramos hombre orquestas que hacíamos de todo, ¿no? Recursos humanos, administración, etcétera.

Cuando tienes ese, ese tamaño, suelen ser bastante óptimas las compañías. Sabíamos que si, que seguíamos creciendo la empresa de servicios por nuestros propios medios, iba a haber ahí un valle hasta que pasá-- llegásemos a ser unas cien personas, porque iba a haber que montar estructura, equipo de administración, recursos humanos, etcétera. Y valoramos que teníamos un EBITDA que podía tener un múltiplo y que podía ser algo interesante.

Y, y también que íbamos a pasar a, a ser esas cuarenta y pico personas, a pasar a ser más de cien personas, porque en este proceso de build up se integraba no solo Trileuko, sino más empresas, ¿no? Y nos pareció interesante y exploramos esa operación y finalmente, pues se, se materializó. Y mis dos socios, César y Felipe, pues pasaron a ser parte de este nuevo grupo como cofundadores, ¿no?

Y, y la idea es que Diverger, pu-- Diverger es la empresa que, que ha adquirido Trileuko, ¿no? Pues que siga creciendo también en eso, ¿no? Se, se dedica un poco a, a, a aplicar inteligencia artificial al servicio a, a proyectos de servicios de desarrollo, ¿no? Y, y bueno, yo continué liderando Gecod, que el ownership seguía siendo de los tres socios, ¿no?

Que tenemos una holding por encima y, y a full, full focus con esto. Sí que hice... Bueno, en, en ese momento sí que valorábamos-- Gecod estaba creciendo, pero muy poco, mu-muy despacio, ¿no? Porque no teníamos capa de go to market, ¿no? Eh, los-- las tres personas que movimos de Trileuko eran ingenieros que técnicamente son excelentes, pero tampoco tenían esos skills de, de go to market, de ventas, ¿no?

Eh, sí que tenían ownership de la plataforma, pero no tanto como para-- no, no en el sentido de ir a vender, ¿no? Y, y principalmente-

Tipos de skills, son habilidades diferentes.

Sí, que no tienes por qué demandarle a-

Puedes dar las dos, pero...

Claro. Entonces eso recaía siempre en, en mí, ¿no? Y entonces lo que yo buenamente pude ir haciendo para ir consiguiendo más clientes, ¿no? Y sí que hicimos algún intento de-- y tuvimos contratadas personas de, de ventas, ¿no? Con los recursos limitados que teníamos, pero sí que hicimos ese esfuerzo y la verdad es que no llegaron a funcionar, eh, porque nos encontrábamos con la problemática de que Gecod como plataforma es algo supertécnico, ¿no?

Y, y nos costaba, eh, transmitir esa propuesta de valor y, y que sí que, sí que los champions nos veían con muy buenos ojos. Oye, esto me va a ayudar. Intentaba escalarlo dentro de la compañía, pero a veces, eh, si era una compañía muy grande, decían: "Pues ya lo podemos hacer nosotros". Realmente, Gecod out of the box no te resuelve un caso de uso en concreto, ¿no?

Te da las herramientas para ir mucho más rápido, ¿no? Y entonces los ciclos de venta eran largos. Sí que fuimos cerrando-

Hacía falta un poco, como en Palantir, el famoso forward deployed engineer, ¿no?

Y de hecho-

Gecod no hace nada si no le das un poco de cariño.

Sí, sí.

Y eso es una movida. O sea, Palantir es una operación de alcohol.

Sí.

No, no es self-service. Al contrario.

Algunos de los, algunos de los clientes que fuimos cerrando también fue por: "Me encaja tal, pero no tengo la gente que lo pueda hacer". Venga, pues te ayudamos nosotros con los servicios integrales. Pero tampoco queríamos crear-

Tampoco hacer cuatro, hacer de forward deployed engineer más hacer la plataforma más hacer las ventas, eh, no sale.

Y no queríamos volver a ser una empresa de servicios, ¿no? Queríamos la-

Es que es muy fácil que te quedes atascado ahí.

Sí, así creo que podríamos haber escalado muy rápido, pero no era lo que queríamos.

De hecho, aquí hemos hablado alguna vez, te dejo respirar también, que, eh, muchas em-- muchas startups ahora, eh, ofrecen forward deployed engineers y levantan rondas como si fuera una startup de producto a valoraciones de startup de producto. Y dices, luego rascas un poco y dices: "Pues si son servicios".

Son servicios, sí.

Que son fantásticas esas empresas de servicios, pero me costará ver cómo se retorna el dinero de los inversores a esas valoraciones, si en el fondo no tienen la escalabilidad de un producto y tal. Entonces, bueno, estabais en esa tensión, ¿no? De...

Sí, y entonces la-- el camino puede ser seguir creciendo despacio, intentar levantar una ronda de financiación, que sí que hicimos esfuerzos, pero había algunos stoppers que no acababan de gustar. Uno, por ejemplo, era el cap table mismamente, ¿no? De, de Gecod, que estaba yo liderando la iniciativa, pero el ownership era-- yo únicamente tenía un tercio de lo que era la sociedad, ¿no?

Podríamos llegar a articularlo de, de alguna forma, ¿no? Pero era una banderita roja ahí en, en la, en una posible inversión, ¿no?

¿Os llegasteis a plantear Cambiar esto. Porque claro, sois tres . Perdón, sois tres, dos se quedan operando una compañía, otro se queda operando otra compañía. Podríais haber-

Podríamos, sí.

En lugar de mantener, mmm, el Captable como estaba, decir: "Tú te quedas mucho más de Yepcode, ellos se quedan mucho más de la otra-

Mhm.

Y hacéis un directo el cambio de cromos.

Sí, eso lo, lo podríamos hacer y, de hecho, era algo que estaba sobre la mesa. Si un-- si era el blocker para una potencial inversión, lo, lo, lo hubiésemos desbloqueado, ¿no? Después, también, eh, a los inversores les costaba ver la tracción de Yepcode por ese-- claro, estando yo únicamente part-time haciendo el go-to-market, pues no, no era un crecimiento muy grande, ¿no?

Y, pues una última vía podía ser, pues encontrar un ecosistema mayor que viese el valor de todo lo que habíamos construido, no solamente estas cuatro personas, sino, mmm, todo el esfuerzo que habíamos hecho durante todos estos años, ¿no? Y ahí, pues tuvimos varios acercamientos, ¿no? Y, y bueno, finalmente, el, el de Factorial fue el que tuvo esto-

¿Qué tipo de acercamientos tuvisteis?

Pues, por ejemplo, herramientas no-code que veían la potencialidad de-

El CEO de Zapier que te escribió por LinkedIn.

Por ejemplo, o, o algún otro, ¿no? Y, y cree-creo que éramos algo que, que complementaba, ¿no? Esa-esas soluciones. O, o alguna empresa que, pues parecido al caso de Factorial, que las integraciones son un pain, que podría, eh, tener sentido, ¿no? Eh, incluso algunas empresas que estaban únicamente interesadas en el-- en la capa de infraestructura que habíamos construido de estos sandbox, que no es, no es trivial, ¿no?

Montarlo y, y que funcione bien, escale, todo. Entonces, teníamos-- al ser una plataforma horizontal, creo que nos podíamos encajar bien en distintos tipos de ecosistemas, ¿no? Pero bueno, ah, mmm, empezamos también a colaborar con Factorial como, como proveedor y, bueno, se fueron alineando-

Ahí Miguel hizo su cortejo, ¿no? Y os enamoró.

Sí, y vamos, yo muy contento de, de poder estar aquí y de que... De, por una parte, darle al equipo un ecosistema donde crecer muchísimo más rápido, eh-

Go-to-market.

Profesionalmente.

No te va a faltar aquí.

Por eso, go-go-to-market. No, no-- bueno, sé que Factorial es muy, eh, ownership y me encanta, ¿no? Y ya he tenido reuniones con, con potenciales clientes y tal, pero tampoco va a ser mi día a día el go-to-market. Sé que no soy un experto en eso, eh, se me dan mejor otras cosas, ¿no? Yo aporto donde haga falta, ¿no?

Que para eso vengo siendo hombre orquesta desde hace diecisiete años, ¿no? Pero, pero sí que me gustan más ciertas partes, ¿no? Pensar, idear, cómo es una buena solución, que-- y, y, y ayudar a, a hacerla realidad, ¿no? Y creo que ahí, pues, eh, en Factorial, pues que vamos a poder hacer eso. Y también se va a sacar partido a todo lo que hemos estado creando en estos años, ¿no?

Y, y creo que, como decía Miguel, eh, la plataforma encaja muy bien porque, eh, seguramente nos hemos pasado de rosca en: "Esto estaría genial hacerlo. Venga, va, lo vamos haciendo, lo vamos haciendo". Eso suele pasar mucho en los fundadores técnicos, ¿no? Y, y quizás hubiese sido mejor a nivel de compañía no-

La sobreingeniería, ¿no?

Sí, no haber hecho tanto.

Construir una catedral.

Pero también si, si quisiésemos hacer eso con los recursos que teníamos, igual hu-hubiésemos tenido que prescindir de parte del equipo, de contratar otros roles. Y tampoco era algo que me gustaba, desprenderme de, de ese, de ese talento tan f-- bueno que teníamos, ¿no? Y al final, bueno, creo que hemos encontrado ese, ese buen puerto donde llegar y que vamos a dar lo máximo para, para que, eh, Yepcode, o ahora Factorial Code, o como lo denominemos, pues, pues siga creciendo y aportando-

Hemos encontrado el mejor puerto.

Sí.

El mejor posible.

Mmm.

¿Y en-- contratáis un banker, un investment banker?

No, no.

¿Algún tipo de asesor?

No, lo que hicimos para explorar esa... Ah, para, para la operación.

Mhm. No, o sea, primero para la ronda.

Para la ronda no, fue conversación-

La ronda fue tú, fuiste tú.

Sí.

Hablando con inversores.

Sí.

Y-

Hasta, hasta-- tuvimos suerte, nos seleccionaron de un programa de ICEX, eso fue el año pasado, y estuvimos por San Francisco también un par de semanas, que f-- mmm, había un programa de expansión y yo: "Pues estaría bien ver allá". Y, y la verdad, sí que fue muy distinto hablar con, con fondos de, de aquí, de allá, de, de-

Es distinto, sí.

Sí. Tuve una reunión con un fondo de, eh, de San Francisco y era un ingeniero de Meta, era la persona del fondo. Es que entendió la propuesta de valor al, al, al minuto-

Con los fondos españoles no es lo mismo.

Costaba bastante hacer entender la-

Es un producto técnico, además. O sea-

Es un producto muy técnico, sí, sí, lo, lo, lo entiendo, vamos. Pero esta persona nos dio muy buen feedback. Decía que le parecía impresionante lo que habíamos construido con un equipo tan pequeño, pero veía problemas de que habí-- en cada una de las verticales que podíamos cubrir, había grandes players que estaban haciéndolo, ¿no? No-ninguno lo hacía como lo estábamos haciendo nosotros, tan horizontalmente.

Y, y tampoco, eh, fue-- no, no surgió ninguna oportunidad ahí, ¿no? Pero... Y con respecto a la-

¿Y para, y para el proceso de la venta?

De la venta, pues sí que-

¿Os planteasteis contratar un investment banker?

Mmm, no. Ya teníamos la experiencia de la anterior-

Venta.

La anterior venta, ¿no? Sí que era, era-

Ahí tampoco teníais investment banker ni advisor ni nada.

Sí que tuvimos unos abogados bastante buenos y tal, pero no... Bueno, eh, sí que, sí que tuvimos una boutique de M&A que-- con-- en, en la primera operación que nos estuvo apoyando. Sí, sí.

Vale. O sea, que te ayudé a encontrar, eh, potenciales compradores.

Sí.

¿No? Que-

No, no fue tanto eso en, en la, en la primera, en la primera operación, porque ya habíamos encontrado nosotros esa o-operación, ¿no? Y sí que lo, lo contratamos para asesorarnos en todo el proceso de due diligence. Además, era una operation de, de shares deal. No, no com-- no eras únicamente de compra de IP y de equipo.

Entonces, sí que había, mmm, bastantes temas que se nos escapaban. ChatGPT no estaba tan maduro todavía. Pero ahora para la de Yepcode, la verdad que lo hemos gestionado nosotros. Sí que con, con abogados, obviamente, y asesores, pero, pero no hemos-- nos hemos aventurado a, a gestionarlo nosotros.

La verdad, tengo que dar las gracias a todo el equipo también de Factorial, que-- y a nuestros asesores, porque ha sido todo bastante ágil, ¿no? Todos hemos tenido que ceder en algunos puntos, pero, pero lo hemos gestionado bastante rápido. Ya se veía la velocidad de lo que-- es que creo que desde que firmamos un ALO y hasta que se cerró la operación, creo que el objetivo era cerrarlo en un mes y creo que se cerró en dos, tres semanas.

Así que-

Normalmente es al revés. Normalmente se, se marca un objetivo y luego acabas haciendo el doble, ¿no? Como en las obras y como en tal.

No, pero aquí era-

Es, es raro. Esto que acabas de decir es raro, que, que fuera tan rápido.

Sí, la verdad, mmm. Eso, sí que fuimos cediendo de, de ambas partes, pero creo que fue una operación bastante ágil, ¿no?

Pues oye, Marcos y equipo, eh, bienvenidos a Factorial oficialmente. Eh, a todos nuestros clientes, eh, pues integraciones como moscas van a venir ahora y todo el talento técnico de Coruña y alrededores, que estamos llegando con fuerza, ¿no? Y que, y que contacten contigo, Marcos, directamente, ¿no?

Y, y vamos a, vamos a querer con-contratar talento muy, muy bueno ahí. Oye, eh, muchas, muchas gracias por venir y por compartir las noticias. Estamos superexcitados y con todos vosotros. Gracias por seguirnos y nos vemos la semana que viene.