Estudié Ingeniería de Telecomunicaciones en la Universidad de Granada (Grado y Máster, este último con un trabajo sobre sistemas embebidos). Mi primer trabajo formal fue en Beebit, desarrollando sistemas embebidos para clientes finales — firmware, integración hardware-software, debugging con osciloscopio. En paralelo, gestionaba proyectos de I+D+i en la propia UGR. Y en 2016 cofundé Bracelit, que empezó siendo una idea de pulsera NFC y terminó siendo una plataforma SaaS de pagos a escala.
Pasé los siguientes 9 años cruzando el puente entre hardware y software hasta quedarme del lado SaaS por completo. Diez años después, dirijo la tecnología en plataformas con millones de usuarios. Lo escribo porque es un cambio de carrera poco contado, y porque cuando contratas o evalúas a un CTO con ese fondo, conviene saber qué se traduce de un mundo al otro y qué no.
01Lo que sí se traduce (y aporta valor en SaaS)
1. Disciplina con los recursos
En sistemas embebidos cada byte cuenta. Cada ciclo de CPU cuenta. Cada miliamperio de batería cuenta. Esa mentalidad — entender que los recursos son finitos y que una decisión cara dentro de un loop crítico se paga durante el ciclo de vida del producto — se traduce muy bien al SaaS. La diferencia es de magnitud, no de principio: en un servidor SaaS también hay queries que ejecutas millones de veces al día, y cada milisegundo extra son costes de infraestructura y latencia que el usuario nota. La gente que viene del software puro a veces optimiza solo cuando hay un problema; el que viene de embebido optimiza desde que diseña.
2. Pensar en fallos como variable de diseño, no de operación
Cuando programas firmware para un dispositivo que va a estar en una pulsera en una barra de festival, asumes que va a fallar. La conexión va a caer. La memoria se va a corromper. El usuario va a hacer cosas raras. Tu código tiene que asumir el fallo y resolverlo, no asumir que todo va bien y reaccionar cuando no.
Esa mentalidad se traduce literalmente al SaaS: webhooks que no llegan, APIs externas que tardan, usuarios que dan al botón dos veces. Hay un sesgo en gente que viene del software web a tratar el fallo como excepción; en embebido, el fallo es la norma y el funcionamiento correcto es el resultado del diseño defensivo. Esto se nota mucho en integraciones críticas, pagos y sistemas con dispositivos físicos.
3. Lectura del hardware como variable de negocio
Cuando el producto incluye dispositivos físicos (pulseras NFC, lectores, terminales de pago), entender el hardware no es un detalle: es una palanca de coste y de experiencia. Saber por qué un protocolo NFC añade 200 ms al tap, o por qué una batería de un dispositivo de mano cae a la cuarta hora de festival, es información que cambia decisiones de producto. Eso lo aporto cuando trabajo con startups en eventtech y, en menor medida, en fintech con hardware integrado.
4. Concurrencia y tiempo real entendidos en serio
La programación embebida obliga a pensar en concurrencia, interrupciones, race conditions y orden de ejecución como parte del diseño básico. Cuando llegas al mundo SaaS, los problemas de concurrencia (transacciones simultáneas, idempotencia, colas mal sincronizadas) no son nuevos — son los mismos problemas con otra notación. La gente que ha pasado por embebido entiende rápido por qué importan; la que viene solo de aplicaciones CRUD a veces los descubre tarde.
02Lo que no se traduce (y conviene reaprender)
1. La velocidad del producto
En embebido cada release pasa por validación rigurosa, certificaciones, pruebas en hardware real. Es lento por motivos sólidos: si subes un firmware roto a 100.000 dispositivos físicos, no hay rollback fácil. En SaaS la velocidad es otra: deploys diarios, feature flags, A/B testing, rollback instantáneo. La gente que viene de embebido tiende a ralentizar el ciclo de release con métodos que no aplican. Hay que reaprender que en SaaS la rapidez de iteración es ventaja competitiva, no riesgo.
2. El producto como conversación, no como artefacto
En embebido el producto es algo que se diseña, se fabrica y se entrega. Una vez en el campo, evoluciona poco. En SaaS el producto es una conversación continua con usuarios: telemetría, feedback, iteración, deprecación. El cambio mental es importante: dejar de ver el producto como un objeto terminado y empezar a verlo como un sistema vivo que cambia cada semana.
3. La complejidad organizacional
Un producto embebido se diseña y mantiene con equipos relativamente pequeños y muy especializados. Un SaaS a escala se construye con squads multifuncionales, dependencias entre marketing/producto/tech/operaciones y conversaciones constantes entre roles. La complejidad organizacional es enorme y no la aprendes haciendo firmware. La aprendes liderando.
4. La economía del SaaS
Margen recurrente, churn, LTV, CAC, expansion revenue. La economía SaaS es una disciplina que no existe en el mundo embebido y que un CTO en SaaS necesita entender — no para ser CFO, sino para tomar decisiones técnicas alineadas con el modelo. Esto se aprende a base de mirar dashboards de negocio, conversar con fundadores y pasar suficiente tiempo en reuniones que no son técnicas.
03Por qué este background importa más en CTO que en developer
Como developer puro, lo que importa es lo que sabes hacer hoy con el stack que usa la empresa. Tu fondo previo es un detalle de CV. Como CTO, lo que importa es el repertorio de problemas que has resuelto antes, las analogías que puedes tirar cuando aparece algo nuevo y la disciplina que aplicas a las decisiones arquitectónicas. Ahí el fondo embebido no es solo un ítem de currículum: es una forma de pensar que cambia cómo abordas problemas en SaaS.
He visto la diferencia varias veces. Cuando montamos la arquitectura de Bracelit, decisiones que parecían sobreingeniería desde el ángulo SaaS (idempotencia obsesiva, observabilidad detallada, fallback ante caída de comunicaciones) eran obvias desde el ángulo embebido. Y resultaron clave cuando la plataforma empezó a procesar 25M€ en eventos en directo donde no había margen para fallar. Lo contamos con más detalle en el caso Bracelit.
Lo mismo aplicó al asumir la dirección técnica de Wegow, una plataforma musical SaaS pura sin hardware: la disciplina de fallos del mundo embebido se traduce directamente a observabilidad y resiliencia en un sistema con 100k usuarios diarios.
04Qué decirle a un fundador que evalúa contratar un CTO con este perfil
- Pregunta por proyectos SaaS reales, no por años de experiencia abstractos. Lo importante es que haya hecho la transición y tenga proyectos SaaS a escala que respaldan que la transición se completó.
- Mira si entiende la economía SaaS. Una conversación de 30 minutos sobre churn, márgenes y CAC revela si lo entiende o si solo conoce el lenguaje.
- Valora la disciplina de fallos. Si tu producto tiene pagos, integraciones críticas o eventos en tiempo real, este perfil aporta mucho. Si es un CRUD lineal sin partes críticas, el diferencial es menor.
- Cuidado con la velocidad. Si viene muy reciente del mundo embebido y tu producto es SaaS de iteración rápida, asegúrate de que ha hecho el cambio mental hacia ciclos de release cortos.
05Y a alguien que está pensando hacer esta transición
- Empieza por proyectos donde el hardware sigue siendo parte del modelo. Eventtech, IoT industrial, hardware con backend. La transición no es saltar — es ampliar.
- Acepta que vas a estar incómodo varios años. Aprender SaaS desde dentro lleva tiempo. La impostura inicial es real y se va con horas de mirar dashboards de negocio y participar en reuniones que no son técnicas.
- El fondo no es un complejo, es un activo. No escondas el background embebido. Es lo que diferencia tu pensamiento técnico cuando llegues a una mesa de decisión SaaS.
06Conclusión
La carrera de CTO no es lineal. La gente que llega ahí desde caminos no obvios (embebido, telecomunicaciones, I+D, ciencia, hardware) suele aportar formas de pensar que se ven poco en perfiles de software puro. La transición no es gratis — hay cosas que reaprender y hábitos que cambiar — pero el resultado es un perfil que ve el producto desde más ángulos. Si estás en esa transición, vale la pena. Y si estás contratando, no descartes el perfil sin mirar el fondo.
Si estás pensando en cómo este tipo de perfil encaja con tu producto y tu fase, en Nirmana acompañamos como CTO fractional a startups donde la disciplina técnica importa. Hablemos.
