Durante años trabajé como desarrollador freelance.
Construía productos, resolvía problemas técnicos y entregaba funcionalidades.
Pero hubo tres startups que cambiaron mi forma de entender mi rol.
No fue una transición planificada.
Fue una evolución forzada por errores, decisiones difíciles y contexto real.
1. Startup A: cuando el problema no era el código
Entré como desarrollador Android. Ya había un CTO.
Desde el principio propuse validar el producto con un MVP.
No construir durante años sin feedback real.
Insistí.
La insistencia generó fricción.
Y finalmente desistí.
El resultado fue un desarrollo de más de cuatro años sin validación comercial sólida.
Se invirtió mucho dinero.
Se contrataron perfiles sin demasiado escrutinio.
La sensación era de progreso constante… pero no había validación real.
La empresa cerró en 2025.
Durante ese periodo me sustituyeron por alguien más económico.
No fue algo personal. Fue negocio.
Pero me confirmó algo que intuía: las decisiones técnicas mal alineadas con estrategia terminan siendo caras.
Mi mayor aprendizaje allí no fue técnico.
Fue este:
Tener razón no es suficiente si no sabes influir.
No supe trasladar con eficacia mi punto de vista.
No supe convertir criterio en liderazgo.
2. Startup B: cuando el título no garantiza el liderazgo
En esta ocasión había tres fundadores.
Uno asumía el rol de CTO, pero sin experiencia previa real en esa responsabilidad.
El proyecto avanzaba como side project.
La plataforma era más una herramienta personal que una base escalable.
Con el tiempo, la dedicación del CTO disminuyó.
Hasta que reconoció algo importante:
“Este es el perfil que nos hace falta.”
Tomé el rol.
Mi primera decisión fue clara: reconstruir la plataforma desde cero, reutilizando lo aprovechable, pero diseñando con visión de producto real.
Aquí entendí una diferencia clave:
- Un desarrollador optimiza código.
- Un CTO optimiza decisiones.
La arquitectura dejó de ser una cuestión técnica y pasó a ser estratégica.
3. Startup C: el momento en que ya no eres “solo desarrollador”
En esta startup fintech comencé como desarrollador Android.
Desde el inicio estaba previsto que el backend tendría que evolucionar.
Pero un cambio regulatorio externo nos obligó a priorizarlo antes de lo planeado.
La diferencia con mi primera experiencia fue clara.
Esta vez:
- Analicé el contexto completo (regulación, costes, equipo, tiempos).
- Elegí AWS equilibrando presupuesto, resiliencia y escalabilidad.
- Diseñé pensando en crecimiento futuro, no solo en entregar rápido.
- Equilibré deuda técnica y avance real de negocio.
El backend no era una sorpresa.
El cambio de rumbo lo convirtió en crítico.
Y ahí entendí algo fundamental:
Liderar tecnología es decidir bajo incertidumbre, no programar sin ella.
Lo que realmente cambió
Entre la primera y la tercera startup hubo una transformación.
Aprendí que:
- La validación temprana no es opcional.
- Los ciclos de feedback deben ser cortos.
- Contratar es una decisión estratégica, no solo operativa.
- Las buenas prácticas no son burocracia, son protección futura.
- El contexto importa más que la tecnología elegida.
- La autoridad técnica se ejerce con claridad y responsabilidad, no con ego.
Hoy, cuando trabajo con una startup, no me limito a ejecutar tareas.
Asumo responsabilidad por el rumbo tecnológico.
Incluso cuando el título no lo exige explícitamente.
Eso es, para mí, ser CTO fraccional.
No se trata de jerarquía.
Se trata de asumir que tus decisiones técnicas cambian el destino de la empresa.