Com Factorial ha comprat YepCode per accelerar integracions

Hoy se anuncia que Factoria ha adquirido Jeep Code. Miguel, ¿cómo se compra una empresa? Lo primero que me dijo Bernard fue, oye Miguel, tú lo lideras, adelante, tú te encargas. Espí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 Jeep Code. ¿Por qué comprar la empresa? ¿Por qué no somos simplemente clientes de Jeep Code? 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 chulo. Tardábamos meses, hemos pasado a hacerlo en semanas y queremos avanzar más. En youtu tenemos nuestro propio agente, le puedes dar un unas especificaciones, un driven y que ya se quede ejecutándose. Esa es la visión hacia donde vamos, que las integraciones casi se puedan construir on the flight con las especificaciones, ¿no? La otra noticia quizá más importante todavía es que Factor 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 contrato, sino que empiezan. Bienvenido a las historias de Startups de Idnic. Bienvenidos una semana más al podcast de Idnic. 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 podcast VP ingeniería en Factorial y Marcos es fundador y CEO de Yepat hasta hace poco. Sí. Eh, Marcos, empezamos con la noticia. Y luego vamos un poquito para atrás. Eh, hoy se anuncia que Factoria ha adquirido JEPC, la empresa que Marcos cofundó hace un montón de años y que ahora nos contará. E explícanos qué es JEPCE y de dónde sale. Bueno, JEPCE es una plataforma para desarrolladores para agilizar el 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 Code con un modelo startup separado de la línea de servicios de desarrollo y que finalmente pues ha encontrado un un nuevo ecosistema donde integrarse, ¿no? O sea, para entenderlo, eh 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 paro 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 superclicados, pero sí que había un tradeoff de eh hay que arrancar un proyecto de cero, hay que desplegarlo, gestión de credenciales, auditoría, logs, scheduling, weh hooks, 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? preguntar, existen los Zappiers, los If This, los Mulesoft, ¿no? Los workoutos, o sea, hay varias plataformas más o menos que permiten conectar un software con otro porque 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 Drah 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? Jep Code es de no code stream, ¿no? Y y lo que queríamos era adotar a los developers de toda esa de todo ese Paint, pero permitiéndoles seguir escribiendo código JavaScript o Python, utilizando cualquier librería de npm, pipi, 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. 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 visto pantallas de cajitas y muchísimas cajitas, ¿no? Que que eso acaba siendo complicado de mantener, de evolucionar. También hay un altísimo vendor locking, ¿no? Con cuando desarrollas con esa con ese tipo de soluciones. Se quiere decir que metes mucho código y inviertes mucho en un partner o en una integración en concreto. Sí. Cuando realmente si 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 podcast es posible gracias a nuestro sponsor My Traffic. 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 que utilices la herramienta de My Traffic Genie, que por vía conversacional te va a permitir saber cuántos visitantes tiene una ubicación, conocer el potencial de las zonas, el tráfico peatonal, las áreas de influencia. Pruébalo totalmente gratis y si quieres su versión Pro, utiliza el código INI para conseguir un 10% de descuento. Si te interesa, te dejamos el enlace en la descripción de mytraffic.io. Miguel, aquí el que compra Yepotter 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 dónde sale? Eh, aparte de que sois todos gallegos, pero pero aparte de ser gallegos, ¿por qué cómo llegas tú a a Yepode y a la conclusión de que Factorial debería quiquir Yepode? O sea, nosotros ya hace tiempo que que hemos detectado, ¿no?, una necesidad que es evolucionar nuestra capacidad 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 un única pieza de software, por simplificarlo, a medida que vamos creciendo y las integraciones se hacen más necesarias, más complejas 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 de ¿Por qué? ¿Por qué necesitamos una plataforma más desacoplada de nuestros? parte, eh, necesitamos que, déjame explicarte el proceso y entonces lo vamos a entender mejor, ¿no? Eh, digamos, hay tres tipos de servicios de este tipo, los zapier, que son los low code. O sea, no tienes que hacer nada, simplemente es lo que dices tú, estás completamente eh bueno, pues ese locking a lo que te ofrece el componente. Después tenemos los los servicios tipo Five Trum, que están son ETLs muy orientadas a procesor de datos, generalmente con cajitas, ese tipo de cosas. Tenemos los Mulsof 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 Jef Code, ¿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 concretamente TypeScript. Nuestros desarrolladores están supercmodos con eso. Entonces, eh el ¿Por qué 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 RPS, la actualización de los empleados, eh pues con los sistemas de nóminas, etc., 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 en 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 modulito siempre es mucho más pesado, mucho más lento. Desarrollar en una en una plataforma desacoplada en el que cada proceso está aislado del siguiente, ¿no? Imagínate que vienen dos compañías que seando en microservicios, no que se microservicios medios servicios. Sí, 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, 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 coreo, ¿vale? 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 Jepode. Exacto. ¿Y tú cómo descubres Jep Code? O sea, lo descubro. Bueno, primero e o sea, yo he trabajado unos años en Soy gallego, segundo he trabajado unos años en en Inditex, unos cuantos. e la la empresa inicial antes de Jepcot, que era Trileuco, ¿no? Es una empresa supercilla, conocida. Ellos son muy conocidos en el sector allí en Coruña, por lo bien que hacían su trabajo, la calidad, etc. Tenemos amigos en común y ya en otras experiencias ya habíamos yo ya había evaluado Jeep Code, ¿no? Porque eh pues es muy parecido a Airbait en cierta manera siempre hay esta necesidad en cualquier cualquier solución siempre tiene una necesidad de de integración. Entonces, ya lo tenía en el radar. Y después, eh, Marcos también tiene esa ese espíritu emprendedor que tú también conoces perfectamente. Es así una persona muy persistente, que es super positivo 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 gente quería vender, o sea, que Factoria fuera cliente de la plataforma Yep y te y te dio por saco hasta que le hiciste caso. Hasta que le dimos una oportunidad. Cuántas veces que es a veces hemos hablado aquí de la perseverencia no fue el primero en Factor ya hace años le A mí a mí me escribiste también eh escrib Marcel estuvimos otro gallego medio gallego. Estuvimos hablando con ellos de hecho hicimos mogollón de recipes de oye conecta factorial con esto.

O sea, pero activamente tú venías con mira qué puedo hacer para factorial ya prehecho, ¿no? O sea, precocinado. Sí. No es que quisiésemos vender servicios de desarrollo porque no es el modelo de negocio de Factorial, sí que lo era de la anterior empresa, pero queríamos creíamos que la plataforma os podía aportar mucho valor en eso, en ser más ágiles, ¿no? Y nosotros empezamos siendo clientes de Jeep Code, ¿no? O sea, tú decides, ves que nosotros tenemos un problema que es que, bueno, 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 y tal y ahí dices, "Bueno, voy a probar si pongo Yepode y nuestros partners y nuestros clientes pueden hacer sus integraciones directamente." Y funciona esto, ¿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 las necesidades que tiene actorial y entonces vimos la oportunidad de hacer todas las integraciones pues con Microsoft, con Pilos, Team también Slack eh a través de esta plataforma, ¿no? y eso empezó a funcionar muy bien y entonces generamos un nuevo caso de uso, otra necesidad en Factorial que era el equipo de de Chil Vili con con Albert que también tenían que hacer desarrollo esa medida en estas customiz audiencia que no conozca nuestro equipo entero, es el equipo de customer experience que es el equipo que trabaja con los clientes que ya tenemos en Factorial y dicen, "Vale, esto va muy bien, pero yo tengo este otro sistema que lo quiero integrar, ayudadme." Y el equipo de Castom Experiencia dice, "Meo, ¿quieres que qué quieres que haga?" No te voy a hacer una integración, yo no me dedique a esto, ¿no? Efectivamente. Y tú dices, "Cuidado." Ahí ya decimos, o sea, a mí en el fondo la la arquitectura, porque ellos venía aquí, no explicado la arquitectura, el producto siempre me ha gustado, creo que tiene unos fundamentos muy buenos, pero después había que mostrarlo, ¿sabes? E y entonces estos dos signos dijeron, ostras, estas dos señales son potentes, son buenas, ¿no? Entonces ya con nuestro equipo de de integraciones de AP Marketplace que 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 toda 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 JEP Code y pagamos el fi 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 generarse engagees, que tú sabes que es fundamental. Yo también creo en el equipo este sentimiento de estar todos en eh bueno, pues en el bar con el sentimiento de 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 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? que me han reconocido también todo ese trabajo que habéis hecho, pero en el impacto en los clientes. Ha mucha gente que que la va a usar ahora esta plataforma, ¿no? Y oye, Marcos, 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 Iepode y cómo es el producto, qué se ve y qué se toca del producto. Vale, muy bien. Pues podría [ __ ] por ejemplo, uno como 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 algún sitio, eh, y está el API de factorial, ¿no? Pues en lugar de extender el monolito, lo que se ha hecho es simplemente entras en una ya codes un SAS, ¿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 Jack Code, que no hay un vendor ling super alto, pero sí que hay cierta sintaxis de para leer los parámetros de entrada, scheduling, todo esto, ¿no? Entonces, pues tú entras ahí y desde un navegador puedes estar subiendo el código. También puedes trabajar en local con Cloud Code, con Open Code, con lo que quieras, porque tenemos un CLI que te permite descargarte el CLI es un Commandline Interface, ¿no? Que es básicamente una herramienta de terminal para la gente que nos técnica, que nos escucha, que te permite hablar con la API de JEP code, ¿no? Hablar con el servicio de Jeepode desde tu ordenador local, desde tu terminal, que es lo que usan los programas. Los desarrollas normalmente no se quieren salir mucho de su No, no le saques de la terminal. Bien, entonces dijemos, no pasa nada, permitimos, clonas tu workspace a tu máquina local, desarrollas ahí con las los procesos de Code. Cuando estás cómodo, pues haces un push a la nube de Code. un enfoque similar a Git para para ese intercambio de de esos ficheros, pero va directamente a, o sea, es CLI, o sea, es Yep code push, no es git push, no es también algo positivo porque no le

vas a vender de muy buena gada a un developer si no puede tener el código en su repit con Jecode también. Él puede tenerlo igualmente de mientras lo empuja en jecode y después tenemos cosas más avanzadas como Gha Pat para promocionar entre entornos, etcétera, ¿no? Entonces desarrollas el código, lo subes y ya se queda en la plataforma y Code que puede estar recibiendo ya un webhook y por ejemplo este cliente de Factorial pues enganchó un weh hook desde el sistema origen y cada tracking pues invoca un process y ahí está la lógica de hablar con el app 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 mucho el el actual framework de integraciones que que Factorel tiene, que está muy bien, pero tenía un handicap que es que ahora mismo Factorel ya permite detectar cuando hay cambios en ciertas entidades y que son es necesario sincronizarlos, ¿no? Incluso instalar integraciones, pero ahora mismo la lógica corre dentro del monolito o se le dice al partner, eh, dame el web hook. en tu infraestructura, a donde quieres que te lleguen los eventos con la información que hay que sincronizar. 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 un 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 factores el que esté desarrollando integrador integraciones o un partner que venga a desarrollar integraciones. Y no solamente hablemos de que una persona lo esté desarrollando, ¿no? Porque con las capacidades agénticas que hay, incluso en YCK 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 Yco, ¿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 hablando, ¿no? whispering que bueno es para entenderlo lo que si alguien le cuesta imaginárselo, tú me estás diciendo que hay una especie de zapier con un lobable totalmente integrado, con lo cual el zapier en lugar de ser clic click es código, pero el código si quieres se escribe solo, hablando en un chat eh como Aarías con Lovable o con cualquier de las herramientas, ¿no? GitHubilot, etcétera, etcétera. Y esto contra la infraestructura y todo el contexto y conocimiento de de integraciones. En el caso de ahora que Yep parte de Factorial, este producto se sigue llamando Yepode. De momento sigue existiendo la web y de hecho pues en el acuerdo que que hemos cerrado sí que vamos a seguir dando servicio a algunos clientes que teníamos, ¿no? Pero la marca pasará a ser de Factorial y y eventualmente pues sí que bueno, ya no se comercializará a más usuarios, ¿no? Pero sí que queremos seguir eh bueno, que que la gente que ha confiado en nosotros en estos años de nadie tirado. Claro, y además era la forma más rápida de que nosotros pudiésemos pasar a estar full focus en en factores, ¿no? 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 IEP Code? ¿Qué usuario interactuará con Yep Code? 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 JEP Code? 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 podemos llegar a que, es decir, la la los clientes finales de Factorial no van a entrar a la plataforma de Jode, sí que van a ver lo que ya ha integrado en el en Factorial con con esa visibilidad, ese feedback de que está sucediendo por debajo y verán las entidades si ya están sincronizadas, si hay algo pendiente sincronizado, no van a entrar, o sea, verán como un resumen de lo que está pasando en Yepode. en la interface factorial sin tener que entrar en la herramienta entera de de 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 YCO puedan hacer su trabajo, ¿no? Y y se pueda implementar, pero no entrarán ahí. Y pero eventualmente yo creo que incluso usuarios eh finales 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 herramienta, mi RP inhouse y sí que tengo estiper es algo interno y tengo capacidades de desarrollo. Factorio 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 no se va a poner a hacer un desarrollo aunque sea en lenguaje natural, ¿no? 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 Proll, por ejemplo, antiguos, eso ya sabes que está muy fragmentado, que no tienen APIs, esa es la realidad. Estos sistemas no funcionan con API. 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 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 a mano, o sea, la transforma, el ETL que decías tú antes es alguien que se descarga un fichero, lo manipula. Ex. Exacto. Esperemos que lo haga bien y lo importa en otro sistema que se hizo en los 70. Eso es eso este año ya va a estar disponible para el usuario final, ¿no? A día de hoy ya hemos ya tenemos ese desarrollo pasado en espificaciones eh bueno, que hemos presentado en las últimas Pro reviews, que eso sí que la audiencia sabe lo que es una pro review de Factorial, ¿no? E en la que pues requiere que el equipo de desarrollo de ingeniería tarde unos minutos, una hora en hacer esas export, que es lo que hemos estado testeando durante este quarter. ha funcionado bastante bien y ahora vamos a empezar a liberarlo primeramente a nuestro equipo de forward de Play Engineer y finalmente a que el usuario final pueda customizarse 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 los clientes finales con su equipo técnico, nuestro forg de Engineer o los partners, pues con una especificación ya desarrollen eh de forma automática o semiasistida eh esa integración y estamos muy cerca ya de de ese punto. Entonces, de al cliente de Factorial eh lo que le va a cambiar es eh lo que has dicho tú ahora, ¿no? podrá integrarse con cosas custom utilizando la tecnología de de Yepode, 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 un enfoque más el típico enfoque de proyecto, ¿no? Vamos a hacer eh la integración con y tardábamos meses, hemos pasado hacerlo en semanas y queremos avanzar más. De hecho, a día de hoy el problema no es el desarrollo de integración, el problema es la especificación porque en muchos casos, aunque nosotros tengamos esta parte del blueprint 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 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 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 son los que cuentan las APIs. Correcto. En este mundo la especificación es ingenieril, digamos, es mucho más técnica. Exacto. Eh, otra cosa que mejoramos eh que creo que también es super importante porque ha sido una mejor en los últimos años y ahora eh pues son últimos meses 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, o sea, esa integración era un poco un parche. Era un parche. Bueno, que estaba por ahí. Es la típica integración de toda la vida, ¿no? Sí, se han hecho así siempre, casi todas. Siempre ahora y falla, falla y nadie sabe por qué ni dónde está. ¿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 complicado de poder dar soporte porque no corre nuestra plataforma, no en una plataforma conocida, muchas veces en un lenguaje que del que nosotros no tenemos experti por mucho que haya y demás. Y con este modelo evolucionamos un poco. Cualquier integración va a estar preintegrada ya en factorial. el usuario pues en la típica sincronización que tenemos con A3, por ejemplo, de los empleados, si mañana viene un cliente, quiere integrarlo con otro eh sistema, pues en el mismo botón que hoy pone A3 con una serie de de información, pues ahí 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 nuestros usuarios es increíble. Y Miguel, ¿qué valor tiene para ti, para nosotros, las interacciones que ya estaban hechas en Jap code? 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 proactivamente versus la capacidad de hacer integraciones en minutos eh long. Em,

no acabo de entender la pregunta, Jordi. Yep. Viene con interacciones hechas. Ah, con los vi con un catálogo de conectores hechos. Hm. Realmente eh algunos sí, algunas sí que ya las hemos implentado, pero da el los foundations para construirlas, ¿no? Pero no es que son recetas estas que decías tú antes al final. Sí, tenemos templates, pero acaba siendo código, es decir, no hay una no hay cajas de un vendor concreto en Code. Hay la posibilidad de conectarte, pues si ofrece Shopify, ofrece un SDK, pues puedes utilizarlo en Jode. Muy straight forward, ¿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 preconstruido, veo mucho más valor en cómo está estructurada la plataforma de Jep Code con toda la capacidad para tener esta parte de los blueprint, de los SDK compartidos, ¿no? Como una librería, entornos aislados, todo sado, 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, que su claim es 850.000 integraciones y tú dices, "Es que las que tengo me dan igual, te la vuelvo a hacer." Hasta sí, hasta están, yo creo que están pivotando algo. Bueno, como curiosidad, el CEO de Zapier Wight 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 el Venga, vamos ahí, vamos a vamos a las interacciones en el mundo de los agentes. Ahora Zapir ya tiene su chat de hazme esta integración y qué más te da si hay un chat que te acabe transformando ese promp en cajitas de zapier que que te lo acabe transformando en código que resuelve el mismo problema. Pero le puedes pedir que te haga una integración con el RP oscuro que solo se usa en un pueblo de Galicia o solo puedes decir hace una integración con HSpot o con Shopify. Tienes que tener la documentación, pero toda la gente si hay un PDF con la documentación se lo puedes adjuntar a la gente y que lo tenga en su en Zapier. Ah, en Zapier no, no, no. Zapier solo si existe el conector. Sí, tiene un conector genérico. Sí, claro, de esto estamos hablando. Claro. Sí, en Zapier hay conectores genéricos de llamadas, lo 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 e el interfaz programable para aplicaciones, ¿no? En 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 reglas para que los agentes hablen, se comuniquen entre sí, ¿no? Al final es más contexto, más difusión de las reglas, cuál es el propósito de de las tools, cuál propósito de cada una de las cosas. 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, no hay consenso. Cada día hay más 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 mejaron tanto que ya solo con teniendo 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 y bueno, pues ahora viene más el la más la atomizació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? Es que yo cre tú crees que hace falta, Marcos, los MCPs, ¿eh? 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 un 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 Factory, 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 MCP que exponga, "Dame los tipos de time off, eh, déjame crear un un time off porque 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 hm vamos a crear casos de uso más complejos que el

API no soporta h to no y los exponemos como tools. Esto no era graf QL, ¿no? Este esto es los los appate, ¿no? Estamos hablando de Graft QL también empieza un poco la misma premisa, ¿no? Sobre todo con el con el G de Mobile. Bueno, pero Graph está orientado, bueno, al tema de mutation, 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 necesitas que necesitas, no como tú has diseñado las APICs, sino como yo la necesito. Claro, en el caso de las API, si comparas Graph QL con API RAR, ¿no? copyest te ofrece un recurso y tú solo consultas ese recurso, aunque hay empresas que han extendido esto, han creado modelos sobre API que te permiten proyectar y demás, ¿no? Pero bueno, el estándar y graph 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, agregación te da muchísima más potencia, pero también te digo que Rafel tuvo un auge y a día de hoy está super estancado el crecimiento, ¿no? Porque sí, ya no ya no mola grafel, como toda tecnología, ¿no? Coge un pico y y después pues cada tecnología tiene un uso, ¿no? Entonces, en MissP sí que lo veo un poco esa como tú estabas comentando, ¿no? Esa agregación, ese API Gateway que te expone más procesos de negocio, no tanto recurso. Sí, y yo creo que el beneficio que puede tener es que ha sido un estándar para comunicar, pero yo cuando salió en CPI dijo, "Pero esto ya hay APIs, ¿no?" Eh, volviendo atrás, ¿no? Lo que creo que eh cada vez puede tener menos sentido eh para NCP es eh como decís, los modelos tienen cada vez más capacidades de generación de código, ¿no? y tú le puedes dar una especificación de un API y te puede generar un script que sí que te cubre ese caso de uso en Zueno, 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 ser, ¿no? Y eso es una de las cosas que resolvemos en JEC, ¿no? En Jcode cada ejecución estamos dejando que cualquier persona entre una plataforma escriba el código que quiera, es decir, eso tiene que estar blindado, ¿no? Y entonces es algo que también permite Code, ¿no?, de 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 JC te da la facilidad de definir esas credenciales que están a disposición del código, ¿no? Y entonces eso sí que se permite y y así sí que se resuelven estos casos de usu toend con de hecho hemos hecho algún vídeo de demo ya hace tiempo antes de ser incluso proveedores de Factorial de eh oye agente dame dime las vacaciones que le quedan a esta persona. Este es el app de factorial y en tu cuenta de Jcode ya tienes un API key, no le dices el valor y el Llaba un script que atacaba a distintas eh métodos de lápide de factor y daba el resultado, ¿no? y todo eso onde 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 tonto y nació muy mal parido que cuando sacaron primera versión pensando que no tal y pero que quiere decir 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. La única razón por la que creo que ha triunfado el estándar 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 ella y cuando en realidad si todos se hubieran puesto de acuerdo diciendo, "No, lo que tenemos que hacer es arreglar nuestra API para que sea un poquito más case driven y que y que traduzca mejor a la acción, ¿no? Al tool calling y el tipo de acción de data retrievo al que quiera hacer el usuario de la gente, 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 es solo el estándar, ¿no? O sea, si utilizamos eh RES eh pues digamos que la espificación estándar es open API, pero el protocolo es HTTB, ¿no? En MCP, pues al final es un protocolo para gentes. Creo que cada vez tendrá más sentido, porque creo que además es que la eficiencia va a ser más relevante cada día, ¿no? Yo no sé si va si va a ser MCP, pero que hay que seguir evolucionando 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, gasten menos token y piensen menos. Eso seguro que hay mucho camino por delante. Marcos, uno de los debates que también está viendo ú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 SAS Apocalypse, ¿no? Y dice, "El SAS ha muerto, pero yo no 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 SAS están diciendo, yo soy Headless, ¿no? Mi mi SAS, yo era SAS 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

vuestros clientes a consumir muchas APIs eh una dirección a la otra o o es todo lo mismo que era hace un año o dos? Hm, yo creo que 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 Copile o de Work IQ y tal. En alguna reunión salió la idea, joda, es que Factorial está muy bien. Igual podría ser un software 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 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, solo agénticamente interfaz podría llegar a ser, pero obviamente tiene que 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 Factorio 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 Saleforce, ¿no?, que estaba intentando que la gente ya no entrara en el en el CRM y tal, pero no sé, no no tengo creando 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? compró haceoku que que podríamos llegar a decir que es de la misma categoría que JEPC, como una plataforma que te permitiría desarrollar, no era para integraciones, pero digamos, pero pero era un movimiento que de hecho lanzó Force.com, estoy hablando hace 15 años quizá, eh hace bastante ya, eh pero Geroku era lo más cool del momento en su en su época para Ruby, 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 dice, "No quiero no quiero convertirme en la base de datos, en una commodity y que el otro se lleve los datos a otro sitio." Mm, no, no me he contrado con situaciones así, la verdad es es algo que habría que que pensar en profundidad, ¿no? Para ver qué qué va a pasar, ¿no? Tú, Miguel, ¿tienes opinión sobre esto? A ver, e 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, 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, SAS o e la capacidad de de ese conocimiento que sabes que es ir a los clientes entender cuál es su problema. Ahí es donde está la clave, ¿no? 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 soluciones y cada día más e 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 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 que están haciendo. Sí, pero claro, cuidado. Pero más barato que con humanos. Más barato que con humanos. Ahora nos quejamos por 100 € con lo que cuesta un desarrollador. Bueno, oye, eh, de momento han hecho en algunos casos un por 17 o un por 24 del del varón eh del coste del coste por token. Entonces, eh, y después que ese esos tokens que tú estás consumiendo sean eficientes, que esa es otra otra que la gente los gasta, ¿no? Que hay mucho, 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 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 Open AI, Antropic, o sea, está bueno hoy Antropic, de hecho que hoy no hacemos tertulia de novedad, pero hablaba de Cloud 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 harvys de los Legoras. Claro. Entonces ahí donde vamos a encontrar el punto en eh poder aportar valor a los clientes, poder ofrecerle la información de cómo tienen que operar el producto, dónde está, cómo resolvemos sus problemas, pero al mismo tiempo pues esta parte del core que, o sea, hay 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 la parte más consumer, noticias, propiedad intelectual, ¿no? Si tú intentas desde clotar Twitter, ¿no? Dile, yo a veces lo hago, digo, "¿Y cuál es ese tweet que vi?" Me dice, "Ni de coña, o sea, Elon no me deja tal, tienes que usar Grock si quieres que utilice Twitter y tal, ¿no?" Y viceversa con YouTube y cada uno tiene su rinconcito y lo protege a a muerte. Eh, o Linding también todas tod LinkedIn, 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, e se pueden hacer muchas integraciones con scrapping, ¿no? O sea, hace años que existe el RPA,

¿no? Que creo que es el Robotic Process Automation, que UIP Path 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 30 años que nadie toca y que literalmente imita un humano, ¿no? O sea, busca los píxeles y hace clic en el botón. E esto es el futuro. O sea, eh, un Yepode, por ejemplo, o dentro de Factorial Factorial Yep Code, eh, vamos para allá a llegar a hacer integraciones con soluciones que no tienen API a base de brotce, de meter un modelo muy inteligente y que se espabile y que haga el RPA. Pues fue justo una duda que planteé estas semanas de de un boarding en Factorial. Eh, sí que lo 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 click porque hay muchas que no te dejan ningún tipo de API ni nada, ¿no? Y bueno, no había no había ningún caso todavía en la compañía, ¿no? Pero yo creo que hay esa posibilidad, ¿no?, de llegarlo a hacer. Ya hay herramientas que lo permiten como Cloud Cowork o otras que te permiten esa navegación. entiendo que está limitada de momento a los navegadores, pero eh por sí tenemos ese caso uso en factorial, eh. Ah, pues no sabes cuando lo pregunto. Es el challenge factorial, que 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 IT, en el nuevo vertical de IT, para la parte de a veces en la gestión de de la autorización o la, o sea, la activación o desactivación de de seats en ciertos softwares que no proporcionan por API, pues sí estamos 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. Y eso lo hacemos con scrapping. Bueno, no es scrapping, es RPA. digo porque scrapping es es bueno es que el scraping lleva mucho tiempo y ya sabes que esto es como como los virus y los antivirus, ¿no? Que siguiente evolución y llega el de antivirus y venga el perro y el y el siempre ha sido así, ¿no? Entonces lo nuestro repetitivo constantemente, no es muy raro que un RPA con el objetivo que el propósito que tenemos en Factorial se ha detectado como una herramienta de scrapping porque realmente hacemos acciones automatizadas, ¿no? scrapping es hago las acciones y además me quedo con la información, lo hago, hago mucho recorrido, ¿no? RPA, o sea, la diferencia está diciendo 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 proceso, no estás todos los días recorriendo todo el catálogo, por ejemplo, de un retailer, ¿no?, que lo hacen habitualmente. corre todo el cada Mercadona para darle el los el pringo eh que eso lo hacen igualmente todos, pero pero hay un equipo intentando que no lo hagan de los del otro lado, ¿no? Constantemente. 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, 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. Es cierto que los modelos al principio los, o sea, hubo un auge de scrapping con los modelos han estado capando y tal, pero al principio, bueno, es que es muy obvio, ¿no? Yo me doy cuenta con mis casos de uso, típico preparándome un podcast o preparándome una tertulia, yo voy con el móvil eh hablándole al al clot y diciéndole, "Investígame esta compañía, ¿no?" Y me dice, "No puedo acceder a esta web." Ya, pues no, pues usa dispatch, ves a mi ordenador, abre el navegador de mi ordenador y 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? Pero eso de momento parece que cuela. que que de hecho toda la tontería, bueno, tontería no, toda la explosión de McMinis es al final es un scrapping descentralizado. O sea, la única razón y yo estaba a punto de comprarme un McMini solo por esto, ¿no? Sí, porque sí, porque me permite desbloquear el caso de uso de navega New York Times o Navega Bloomberg o Navega Twitter y y y guárdate el resultado para luego hacerme el resumen de cara a la preparación del podcast. Y si lo hago desde un VPS, como me monté el OpenCl con un VPS, no consigue nada. Está todo capado, ¿no? Las IPs de los servidores y de los hostings están, vamos, más que más que machacadas. Perdona que has dicho, te he dicho, esto solo es una idea. Estabas empezando a hablar de decir ahora no las interacciones 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 el partner se va a hacer otra cosa, ¿no? Porque ya quizás esta integración ya la ha cobrado y no se dedica, no es un SAS 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 backws compatible. Eso pasa todo el rato. 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 tiempo real, ¿no? Es decir, tenemos las la base para poder hacerlo. No no hemos implementado ese caso de uso con ninguno

de de nuestros clientes, ¿no? Pero yo creo que sí que podemos ir hacia hacia ahí porque lo que sí que tiene Jecode como plataforma es toda la traza de logs, toda parámetros de entrada, de salida, todas las respuestas y se podría llegar a hacer. Esto hubo un boom en los 2010 de los thescale, una startup nacida en Barcelona, de hecho. Eh, APG, ¿no? Mashable, ¿te suenan estos productos? aos que las comprar casi todas, ¿no? Red, creo, la compró Google y Mashable IBM o Intel, ¿no? Una empresa muy muy grande de estas. Y esto ha desaparecido un poco del mapa que era el API gatewayight monitoring, eh, no como un middleware, eh, para monitorizar y medir las APIs, gestionar los tokens, ¿no? Eh, esto, ¿por qué dices que ha desaparecido en el mapa? Siguen ahí. Eh, nosotros usamos, además. Sí, sí. And preci es que yo ya como ya no programo ya no me entero, pero por eso os 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 que hay un montón de productos. O sea, Pigi en su momento fue el rey de de Pedw acabado compartiendo cuando pilló Google. Bueno, 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 API Getway que es necesaria, que al final también un service en cubernet, pero tú lo dices para nuestra API o para las APIs que consumimos para nuestra tenemos un caso de uso, ¿sabes? que ahora que estamos con la parte esta de escalidad de nuestra solución con la arquitectura de celdas, que al final es tener diferentes tenans con pues para Miguel, eso para todos los explícalo para todos los públicos que te has metido en jardín que celdas y tenans y bueno, al final nosotros estamos creciendo e estamos creciendo pues a un ritmo bastante elevado, ¿no? Eh, eso implica más clientes, más usuarios haciendo 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 ocidental, que creo que casi todo el mundo lo conocerá, es en lugar de 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 escalador vertical es un servidor más gordo. Exacto. Y un escalador 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íos un coberente, pero al final tenemos digamos un tenan, ¿no? Una caja que tiene muchos componentes. Digas que Factoria tiene un servidor. Me han cagado en la leche. Estamos haciendo una analogía, ¿no? Evidentemente Factorial no tiene servidor servidores. Tenemos un montón de servidores, ¿no? Eh, una analogía es, oye, tenemos una caja muy grande, tenemos muchos componentes que sirven a todos los clientes un 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 un pgateway. cada vez que se conecta un cliente y 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 y puede ser que unas tengan más recursos que otras porque oye, si empezamos una una celda nueva en la que tenemos 100 clientes, no va a tener el mismo dimensionamiento que una en la que tenemos 5000, ¿no? Incluso podrían ser distintos vendors, ¿no? Podrían, sí, podrían, pero no. Trabajamos con Microsoft. Trabajamos con Microsoft. La carrera de Miguel, distintas ubicaciones, va, ubicaciones. Vale, esto es lo que voy a preguntar, ¿no? Porque hasta ahora 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, ellos ahora mismo sufren un poco de latencia por la Europa, Europa para cada llamada la API, vienen hasta Europa y vuelven, que que son milisegundos, pero es tontería, pero cuando hay muchos se nota, ¿no? O sea, los clientes grandes y tal, experiencias peor. Claro. Exacto. Entonces, a esos clientes los vamos a mover a una celda allí en en Latam cerca de donde están. concretamente, por ejemplo, en Alemania, que ahora con todo el tema de ley y demás, pues hay mucho esto del cloud soberano, pues sobre los datos, sí. Eh, pues en en ahí concretamente vamos a tengo una celda con mucho más mucho más restrictivos a nivel de más alemana. Una celda es más alemana,

la otra también estará en Alemania, pero una será para alemanes. Exacto. ¿Y por qué me cuentas esto? Porque porque la el gateway la P gateway es ese componente que tiene la lógica de decidir cuando alguien hace el login en Factorial, eh 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. 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 JCO, pues tiene su propio agente, que eh nos apoyamos en Open Code. Es decir, tú cuando quieres utilizar JPA agent se llama, eh, lo arrancas y te aparece un chat en en tu cuenta de de Jcode a quien le puedes decir, "Ah, pues hazme este proceso, toma esta es la documentación", etcétera, ¿no? Y eso levanten un SBOX seguro, una instancia de Open Code 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 del API de de Jcode estar viendo los logs de las ejecuciones y puede ser reactivo. Ostras, ha fallado este proceso. Voy a ver el error. Ah, pues ha cambiado esta firma de este API y puede evolucionarnos, ¿no? 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 auto de box, pero el agente lo permite hacer. Vale, a mí me ha quedado claro lo que lo que va a pasar. Oye, la otra noticia quizá más importante todavía que que Factorial adquiere JEP Code 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 Jeep Code que se incorpora 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 una empresa de producto y no no molestamos a nadie al revés, ¿no? Pero pero que que 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, es conocida, entre otras cosas por mucha tecnología, ¿no? 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, The Nodo Technologies es una empresa, yo fui empleado ya hace muchos años y y también hace las cosas bastante bien 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 estábamos en Ste Mold de que de que hoy se anuncia, o sea, se anuncia, sí, sí, tenemos que que empezar a a contratarnos, sobre todo para esta equipo de App y Marketplace, ¿no?, que que es donde más estaremos evolucionando todo este framework y dando solución. Ah, llevo estas dos semanas teniendo muchísimas reuniones con la gente de Partnerships. Están deseando que podamos ir más rápido ahí, ¿no? Y se ha estado haciendo un trabajo muy bueno en la parte de del monolito de Factorial de crear las bases para que lleguemos y y podamos poner Jecode al lado para ejecutar la lógica en sí de las integraciones, ¿no? Y la visibilidad del usuario ya ya es algo que está resuelto por parte del equipo de API Marketplace, ¿no? Entonces eso, 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 movimiento, ¿no? Sobre todo yo creo que en proporción a la población o al PIB, creo que hay una comunidad tecnológica eh desproporcionada en en Coruña concretamente, en Galicia en general. Eh pero en Coruña concretamente, de hecho en Ind hicimos una tertulia que antes me has dich que que viniste. Sí. que hicimos ahora, no sé, que un año o así, no sé. Y la verdad es que a mí me sorprende dices, [ __ ] es una zona que no es de las más pobladas de España y en cambio hay mucha comunidad startup y y tecnológica, mucho programador eh gallego por el mundo y de hecho en Factorel hay unos cuantos hay unos cuantos tenemos unos cuantos y muy buenos además pero también porque os os buscáis los unos a los otros, ¿eh? Hombre, a ver, siempre los gallegos siempre nos estamos buscandoos unos a los otros. ¿Dónde vamos? E, vale. Oye, vamos a hablar del proceso de la compra, Miguel. ¿Cómo se compra una empresa? ¿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 nunca en mi vida profesional. Y aquí cuando surgió la oportunidad, lo primo, lo primero que me dijo Bernard fue, "Oye, Miguel, tú lo lideras, adelante, tú te encargas."

Exacto. Que pase. Totalmente, que pase, me gusta dos palabras. Entonces, eh, oye, ha sido un reto superinesante. E siempre he tenido a Bernat con apoyándome y y dándome esos tips. Y 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 el equipo. Ahí es donde he invertido la mayor parte de mi tiempo con con Marcos y y con el equipo, ¿no? Y bueno, creo que ha ido bien, ¿no? Porque este es este es el resultado. Después hay otra parte que ya más es 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 ¿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 activos, hay transacciones que pasan. ¿Cómo llegas a a una oferta? ¿Cuál es el proceso? Teniendo en cuenta además tu dilatada experiencia comprando empresas. Ahí el apoyo el apoyo vuestra parte, ¿no? Pues al final e tengo que decir que Cloud me ayudó bastante también, pero bueno, eh en el sector hay una serie de múltiplos, ¿no? Pues en base al revenue, al Evita, a este tipo de cosas. Y o sea, ¿buscas algún tipo de comparable? He buscado benchmark de decir, "Oye, no empiezo desde cero." Eso 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, ¿no? Ese tipo de cosas y y el 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. Buen buen rol. Es es un tema [ __ ] ¿no? Entonces, para mí ha sido el doble reto, ¿no? Negociar 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 dedicamos un buen rato, de hecho, a hablar de esto que sirvió para que tú y el resto del equipo explicarais a todo el management de Factoria lo que queríamos hacer. porque 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 Excels arriba y abajo y un trabajo en equipo, ¿no? Aparte de esto ha habido un trabajo en equipo de pues de el de legal, Finance, Morán, Lucía, todo el mundo financiero, la responsabilidad ilegal, ¿no? Obviamente no no has sido tú solo con un papelito y un bol. No, para nada. ha sido un equipo coordinado, eh, comoamente factoriales, todos vamos a con un único objetivo. Eh, para mí es una experiencia en general espectacular. Ahora viene lo más difícil, eh, que las compras de compañía, eh, 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 era una de las posibles salidas de de Yeko, ¿no? Nosotros Y nace dentro de Explícanos un poquito, siendo muy rápido antes. Sí, explícanos un poquito más de dónde sale esto, porque lo has dicho muy de pasada. Vale, pues os cuento si queréis un poco mi historia, la historia de emprendimiento, ¿no? Y esto, bueno, yo soy ingeniero informático, estuve trabajando, empecé a trabajar bastante temprano, eh, todavía seguí estudiando y trabajando. Estuve en distintas empresas de de Coruña acabé trabajando para Inditex también y allí coincidí con mis dos socios, con César y Felipe, que ya los conocía de la facultad y siempre fuimos bastante inquietos, ¿no? y hacíamos cosas allí y 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. Vamos. Eh, ¿por qué no nos lanzamos si no lo hacemos ahora? 2009, sí, en 2009 constituimos triucosolutos, ¿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 revenue, ¿no? Y y así fuimos empezando y llegó el día que dijimos, me acuerdo perfectamente que fue desde la Universidad de Coruña nos concedieron un espacio que no tiene mucha importancia un local, pero dices, "Joba, pero hay alguien al principio todo cuenta, alguien hay alguien que se cree que podemos hacer algo, tal, creo que deberíamos dar el paso, tal y bueno, anunciamos que que nos íbamos de de esta compañía de Indites. 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 la importancia que tiene esta empresa en en Coruña y Miguel me mira que ha pasado 18 años, Marcos ya prescrito todo allá. Sí, 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 allá allá donde vayas, deja la puerta abierta por si tienes que volver, ¿no? Y y de hecho pues arrancamos e pasó a ser uno de nuestros clientes, ¿no? Eh, empezamos como modelo de servicios de desarrollo, empezamos los tres. ¿Qué desarrollabais? Pues principalmente software de backoffice, eh herramientas internas, herramientas internas para Inditest, 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 fui cliente, ¿no? Y empezamos a escalar esta empresa hasta que en el 2023 éramos unas casi 50 personas eh 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, ¿no? Es lo contrario. Eso era lo que vendíais a los clientes. Vale, sí, sí. Pero eh arrancábamos ideas que teníamos, pues por ejemplo, hm somos bastante aficionados al mundo del deporte y cuando nos íbamos por ahí, oye, estaría bien que nos pudiesen seguir desde casa, tal o pues a este lenguaje Rubian 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. Segundo, probar cosas nuevas, que el equipo se reciclara en en tecnologías eh nuevas, ¿no? Tener un un sbox 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 permitió ir lanzando ideas que al final algunas se convirtieron en empresas, ¿no? Y hoy en día, por ejemplo, Track de Race 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 Jet Code, ¿no? Y también pues 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 2. no sé qué y los metemos a al todo nace con unos fundishos muy buenos, ¿no? De de arquitecturas, de tecnologías, etcétera. Entonces nos permitió eso y ahora mismo vemos a Jecode que somos un equipo ahora mismo de cuatro personas, pero ha llegado a ver hasta 20 personas trabajando en Jecode en sus inicios, ¿no?, cuando todavía estaba dentro de la de la agencia, ¿no?, de Trileucos Solutions. Esto fue entre el 2021 y el 23. Y en el 2023 eh decidimos crear una nueva compañía para Jecode y yo me desvinculo de de esta ¿Por qué decidís esto? Porque empezábamos a tener cierta atracción de clientes y queríamos capturabais MR o equivalente, yo creo que podíamos estar en los 100K por aquel momento anuales. 100K anuales. Ahí es donde decís, "Esto tiene entidad, tiene, sí, puede empezar a a traccionar, ¿no? Y entonces constituimos una una nueva sociedad, movemos a No habéis puesto dinero para JEP Code, sí que cuando Ste fue una, o sea, de fuera." Quiere decir, no habéis levantado, perdona, no habéis levantado dinero de inversores para Jeep Code, habéis ido invirtiendo los beneficios. Hemos levantado dinero de nadie. Todo lo que fuimos creando siempre fue con nuestro propio invertíais los beneficios en ir creando los productos. Perdona, es un matiz importante. Sí, sí. Y y de hecho cuando nace J code sí que movemos el activo, ¿no? Siempre fuimos muy formales a nivel de contabilidad de tener hecho ahora si no hubiéramos tenido problema, ¿sí? a nivel de registrarlo todo, ¿no? Y movemos el activo, movemos cierto cash y ya nace code con un capital social, ¿no? De 3000 € no y movemos también a un equipo muy core, pues a eh Santi Álvaro, que llevaba más de 10 años ya con nosotros en la en la agencia y y pasan a ser parte de de Jecout y Sergio que había entrado hace poco en en Teleuk también era muy prometedor y lo lo movemos, ¿no? Y tus dos socios se quedan se quedan en Trileuco, ¿sí? Como liderando la parte de de servicios de 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 buildup, pues unos una gente que salía de de una empresa que 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 bueno, la verdad empezamos a hablar con con este equipo y hubo match, ¿no? Y yo hablando desde la capa de ser owner de la compañía, pero no estaba ya en el día a día, ¿no? Y bueno, fue una forma de en ese momento Trileuco tenía como 45 personas por las que habíamos movido a a Yekun, ¿no? Y fue una forma de afrontar una etapa que sabíamos que si seguíamos por nosros mismos en ese momento éramos rentables, ¿no? Con evita bastante positivo y una compañía super optimizada, ¿no? También los socios éramos hombre orquestas que hacíamos de todo, ¿no? Recursos humanos, administración, etcétera. Cuando tienes 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 100 personas porque iba a haber que montar estructura, equipo de de administración, recursos humanos, etcétera. y valoramos que teníamos un evita que podía tener un múltiplo y que podía ser algo interesante y y también que íbamos pasar a a ser esas 40 y pico personas a pasar

a ser más de 100 personas porque en este proceso de buildup se integraba no solo trileuco, sino más empresas, ¿no? y nos pareció interesante y exploramos esa operación y finalmente pues 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, Diverger es la empresa que que ha adquirido Trileuco, ¿no? Pues que siga creciendo también en eso, ¿no? Se se dedica un poco a a aplicar inteligencia artificial al servicio a a proyectos de servicios de de desarrollo, ¿no? Y y bueno, yo continué liderando Jecode, que la ownership seguía siendo de los tres socios, ¿no?, que tenemos una holding por encima y ya full full focus con esto sí que hice, bueno, en ese momento sí que valorábamos Code estaba creciendo, pero muy poco, muy despacio, ¿no? Porque no teníamos capa de go to market, ¿no? las tres personas que movimos de TCU 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 en el sentido de ir a vender, ¿no? Y y principalmente son skills, son habilidades, sí, que no tienes por qué demandarle a Claro. Entonces, eso recaía siempre 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 encontramos con la problemática de que Code como plataforma es algo supertécnico, ¿no? y y nos costaba 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 si era una compañía muy grande decía, pues ya lo podemos hacer nosotros. Realmente Code 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 for de Pet Engineer, ¿no? Y no hace nada si no le das un poco de cariño y y eso es una movida, o sea, Palantir es una operación de Alcopón, no no es self service. Correcto. Algunos de los algunos de los clientes que fuimos cerrando también fue por me encajo, tal, pero no tengo la gente que lo pueda. Venga, pues te ayudamos nosotros con los servicios. Pero tampoco queríamos crear cuatro hacer de for de pro engineer más hacer las plataformas más hacer las ventas y no queríamos volver a ser una empresa de servicios. Es que es muy fácil que te Claro te quedas. Sí, sí, creo que podríamos haber escalado muy rápido no era lo que queríamos. Aquí hemos hablado alguna vez, te dejo respirar también, que eh muchas muchas startups ahora eh ofrecen for 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, que son fantásticas las 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, ¿no? Entonces, bueno, estabais en esa tensión, ¿no? De Sí. Y entonces la el camino podía 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, el Cap Table mismamente, ¿no? De de Jod que estaba yo liderando la iniciativa, pero el owner 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? 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 saber en lugar de mantener el capp como estaba, es decir, tú te quedas mucho más de Jepode, ellos se quedan mucho más de la otra y haces un direct cambio de cromos. Eso 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 hubiésemos desbloqueado, ¿no? Pero después también eh a los inversores les costaba ver la tracción de Youte, claro, estando yo únicamente parttime haciendo el go to market, pues 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 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 de factorio fue fue el que tuviste. ¿Qué tipo de acercamientos tuvisteis? Pues por ejemplo, herramientas no Code que veían la potencialidad de el CD Zapier que te escribió por LinkedIn, por ejemplo, o o algún otro, ¿no? Y y creo que éramos algo que que complementaba, ¿no?, esa esas soluciones o o alguna empresa que pues parecido al caso de factor, el que las integraciones son un Pain, que podría tener sentido, ¿no? incluso algunas empresas que estaban únicamente interesadas en el en la capa de infraestructura que habíamos construido de estos sbox 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, empezamos también a colaborar con Factorial como proveedor y bueno, se 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 e profesionalmente por eso Go to market no bueno sé que Factorial es muy 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 goutomark 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 17 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 ayudar a a hacer la realidad, ¿no? Y creo que hay un factor 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, la plataforma encaja muy bien porque 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 quizás hubiese sido mejor a nivel de compañía, ¿no? La sobreingeniería, ¿no? una catedral, pero también si si quisiésemos hacer eso con los recursos que teníamos, igual hubiésemos tenido que prescindir de parte del equipo de contratar otros roles y tampoco era algo que me gustaba desprenderme de de eso, de ese talento tan 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 que Codo ahora Factorial Coudo, como lo denominemos, pues pues siga creciendo y apontado el mejor puerto. Sí, el mejor posible. 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 la operación dies, ¿no? O sea, primero para la ronda. Para la ronda no fue como la ronda fue tú. Fuiste tú hablando con inversores. Sí. hasta hasta tuvimos suerte nos seleccionaron de un programa de licenses, eso fue el año pasado y estuvimos por San Francisco también un par de semanas que había un programa de expansión y pues estaría bien ver allá y y la verdad sí que fue muy distinto hablar con con fondos de de aquí de allá. Es de es distinto. Sí, sí. tuve una reunión con un fondo de de San Francisco y era un ingeniero de meta, la persona del fondo. Es que entendió la propuesta de valor al al minutos españoles no es lo mismo. Costaba bastante hacer entenderlo. Es un producto técnico, además. Es un producto muy técnico. Sí, sí, 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 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 fue no no surgió ninguna oportunidad ahí, ¿no? Pero y y con respecto y para el proceso de la venta de la venta, pues os planteasteis contratar un investment Banker, ¿no? teníamos la experiencia de la anterior la anterior venta, ¿no? Sí que 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 man que en la primera operación que nos estuvo apoyando. Sí, sí. Vale. O sea, que te ayude a contrar eh potenciales compradores. Sí. No, no fue tanto eso en en la en la primera en la primera operación porque ya habíamos encontrado nosotros esa operación, ¿no? Y sí que lo contratamos para asesorarnos en todo el proceso de du diligence. Además era una operación de de Shars deal, no no era únicamente compra de IP y de equipo. Entonces sí que había bastantes temas que se nos escapaban. Chag no estaba tan moduro, pero ahora para la decocó la verdad que lo hemos gestionado nosotros sí que con con abogados obviamente asesores, pero pero no hemos nos hemos aventurado a a gestionar 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, nuevamente se se marca un objetivo y luego acaba siendo el doble, ¿no? como las obras y como en tal. Es raro esto que acabas de decir. Es raro que que fuera tan rápido. Sí, la verdad. Eso sí que fuimos cediendo 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 contratar talento muy muy bueno ahí. Oye, eh, muchas, muchas gracias por venir y por compartir las noticias. Estamos super excitados y con todos vosotros.