Ealyx: de la idea a producción en 90 días, con cuatro ingenieros y un CTO fraccional

Primero los hechos, porque un caso de estudio escrito por el proveedor vale exactamente lo que valen los hechos que lo sostienen. Ealyx es una empresa de Barcelona que hace software de circularidad para e-commerce. En mayo de 2024 tenía una idea y unos fundadores que conocían su mercado. Noventa días después tenía un producto en producción. El equipo que lo construyó fueron cuatro ingenieros de Conectia y un CTO fraccional, trabajando como un solo equipo con los fundadores. La relación sigue viva en 2026.

Esa es toda la historia en cuatro frases. El resto de esta página explica qué costó cada una, qué exigió de los fundadores y qué comprobaríamos antes de comprarle lo mismo a cualquiera, nosotros incluidos.

Por qué «de la idea a producción en 90 días» es la unidad correcta, y «MVP» no

La mayoría de startups mide la primera fase en funcionalidades. Nosotros la medimos en la distancia entre una idea y el primer día en que clientes reales dependen del software. Para Ealyx esa distancia fueron noventa días, y el número importa menos que lo que descarta: no hubo un «discovery» de seis meses, ni un prototipo que hubiera que tirar, ni un traspaso entre quienes diseñaron el producto y quienes lo construyeron.

Que la distancia sea corta es cuestión de estructura, no de heroísmo. Un CTO fraccional es dueño de la arquitectura y del alcance desde la primera semana. Cuatro ingenieros que ya trabajan juntos se encargan del desarrollo. Los fundadores están en el circuito cada semana y deciden; no hacen de traductores entre un diseñador, una agencia y un freelance. Un equipo, un backlog, una definición de terminado.

Qué cambia un CTO fraccional en los primeros noventa días

En una empresa que empieza, los errores más caros no son bugs. Son decisiones que nadie estaba cualificado para tomar: qué partes construir y cuáles comprar, qué tiene que aguantar el modelo de datos, dónde se van a romper las primeras integraciones, cuánto gastar en infraestructura antes del primer cliente de pago.

Ealyx no tenía un CTO a tiempo completo, y contratarlo antes de tener producto habría costado un trimestre y buena parte del runway. Un CTO fraccional dio a los fundadores las mismas decisiones, tomadas por alguien que ya las había tomado antes, a una fracción del coste y desde la primera semana. En la práctica fueron tres cosas:

1. Alcance cerrado pronto. La primera versión en producción quedó definida en las primeras semanas, con lo que no incluía por escrito. Todo lo que vino después fue una segunda fase, no alcance que se cuela en la primera.
2. Arquitectura elegida para los dos años siguientes, no para la siguiente demo. Stack estándar, una sola base de datos, fronteras limpias entre módulos, para que el producto pudiera ampliarlo el mismo equipo o un equipo interno futuro.
3. Decisiones semanales con los fundadores. Prioridades, compromisos y qué enseñar a los clientes se decidían cada semana con quienes eran dueños del negocio, no en un comité trimestral.

Cuatro ingenieros, un solo equipo: cómo fue el desarrollo de verdad

Los ingenieros estaban contratados por Conectia y trabajaron dentro del repositorio y las herramientas de Ealyx desde el primer commit. La cadencia fueron sprints de dos semanas con demo de software funcionando al final de cada uno. Los fundadores veían crecer el producto cada quincena y corregían el rumbo cuando el mercado se lo pedía.

Lo que esto no es: un marketplace de freelances coordinados por el cliente, ni un proyecto entregado a una agencia y recibido como un zip tres meses después. Los fundadores nunca tuvieron que gestionar a ingenieros uno a uno; eso lo hacían el CTO fraccional y el equipo. Lo que hicieron los fundadores fue lo único que nadie puede hacer por ellos: decidir para qué sirve el producto.

Qué significa «desde mayo de 2024»

Un producto en producción el día noventa es un principio, no un final. Los clientes reales encuentran los bordes, las integraciones cambian, el roadmap crece. El mismo equipo que construyó la primera versión ha seguido construyéndola, y esa es la parte de la historia que más nos importa: la arquitectura elegida en las primeras semanas no hubo que sustituirla, y el conocimiento del producto no salió por la puerta al terminar «el proyecto».

Por eso tampoco vendemos «un MVP» como una caja cerrada. Vendemos una primera versión que aguanta clientes de pago, construida por un equipo que puede quedarse mientras sea útil e irse cuando deje de serlo. El código, el repositorio y la infraestructura son del cliente desde el primer día, así que quedarse es una decisión, nunca una dependencia.

Qué comprobaríamos antes de comprarle esto a cualquiera

Si eres fundador y estás valorando un CTO fraccional más un equipo pequeño para llevar una idea a producción, estas son las cuatro preguntas que le haríamos a cualquier proveedor, nosotros incluidos:

• ¿Quién es dueño de las decisiones de arquitectura, y está en el proyecto cada semana? Un nombre y un calendario, no un rol en un organigrama.
• ¿Quién emplea a los ingenieros, y con qué contratos? Empleo directo con cesión de propiedad intelectual es un producto distinto de una cadena de subcontratas.
• ¿Dónde vive el código desde el primer día? En vuestro repositorio, en vuestra cuenta de nube, a vuestro nombre.
• ¿Qué pasa al final? Un preaviso de treinta días y un traspaso documentado es la respuesta correcta. Un contrato marco medido en trimestres no lo es.

Preguntas frecuentes

¿Cuánto cuesta llevar una idea a producción con un CTO fraccional y un equipo pequeño?

Depende del alcance que tenga que cargar la primera versión y de cuánto exista ya. Cerramos el precio de cada fase al terminar el diagnóstico, por escrito, y el diagnóstico se descuenta del desarrollo. Los paquetes de entrada están en la página de precios.

¿Noventa días es realista para cualquier producto?

No. Noventa días es lo que tarda una primera versión con alcance ajustado, un equipo sénior y un fundador que decide cada semana. Los productos con requisitos regulatorios pesados, hardware o migraciones de datos complejas tardan más, y lo decimos en el diagnóstico.

¿Y si ya hemos hecho un MVP con herramientas de IA?

Entonces la primera fase es una auditoría de lo que tenéis en lugar de una página en blanco: qué conservar, qué endurecer y qué rehacer. Así llevamos a producción un MVP hecho con IA.

¿Nos quedamos el código si dejamos de trabajar con vosotros?

Sí. Todo está en vuestro repositorio y vuestra infraestructura desde el primer commit. Parar significa un preaviso y un traspaso, nada más.

---

Si tienes una idea, una especificación o un prototipo que tiene que convertirse en un producto en producción, cuéntanos qué tienes y un CTO te responde por escrito en 24 horas.