Durante a\u00f1os trabaj\u00e9 como desarrollador freelance.
Constru\u00eda productos, resolv\u00eda problemas t\u00e9cnicos y entregaba funcionalidades.<\/p>\n\n\n\n
Pero hubo tres startups que cambiaron mi forma de entender mi rol.<\/p>\n\n\n\n
No fue una transici\u00f3n planificada.
Fue una evoluci\u00f3n forzada por errores, decisiones dif\u00edciles y contexto real.<\/p>\n\n\n\n
Entr\u00e9 como desarrollador Android. Ya hab\u00eda un CTO.<\/p>\n\n\n\n
Desde el principio propuse validar el producto con un MVP.
No construir durante a\u00f1os sin feedback real.<\/p>\n\n\n\n
Insist\u00ed.
La insistencia gener\u00f3 fricci\u00f3n.
Y finalmente desist\u00ed.<\/p>\n\n\n\n
El resultado fue un desarrollo de m\u00e1s de cuatro a\u00f1os sin validaci\u00f3n comercial s\u00f3lida.
Se invirti\u00f3 mucho dinero.
Se contrataron perfiles sin demasiado escrutinio.
La sensaci\u00f3n era de progreso constante\u2026 pero no hab\u00eda validaci\u00f3n real.<\/p>\n\n\n\n
La empresa cerr\u00f3 en 2025.<\/p>\n\n\n\n
Durante ese periodo me sustituyeron por alguien m\u00e1s econ\u00f3mico.
No fue algo personal. Fue negocio.
Pero me confirm\u00f3 algo que intu\u00eda: las decisiones t\u00e9cnicas mal alineadas con estrategia terminan siendo caras.<\/p>\n\n\n\n
Mi mayor aprendizaje all\u00ed no fue t\u00e9cnico.<\/p>\n\n\n\n
Fue este:<\/p>\n\n\n\n
\nTener raz\u00f3n no es suficiente si no sabes influir.<\/p>\n<\/blockquote>\n\n\n\n
No supe trasladar con eficacia mi punto de vista.
No supe convertir criterio en liderazgo.<\/p>\n\n\n\n
\n\n\n\n2. Startup B: cuando el t\u00edtulo no garantiza el liderazgo<\/h2>\n\n\n\n
En esta ocasi\u00f3n hab\u00eda tres fundadores.
Uno asum\u00eda el rol de CTO, pero sin experiencia previa real en esa responsabilidad.<\/p>\n\n\n\nEl proyecto avanzaba como side project.
La plataforma era m\u00e1s una herramienta personal que una base escalable.<\/p>\n\n\n\nCon el tiempo, la dedicaci\u00f3n del CTO disminuy\u00f3.
Hasta que reconoci\u00f3 algo importante:<\/p>\n\n\n\n\n\u201cEste es el perfil que nos hace falta.\u201d<\/p>\n<\/blockquote>\n\n\n\n
Tom\u00e9 el rol.<\/p>\n\n\n\n
Mi primera decisi\u00f3n fue clara: reconstruir la plataforma desde cero, reutilizando lo aprovechable, pero dise\u00f1ando con visi\u00f3n de producto real.<\/p>\n\n\n\n
Aqu\u00ed entend\u00ed una diferencia clave:<\/p>\n\n\n\n
\n
- Un desarrollador optimiza c\u00f3digo.<\/li>\n\n\n\n
- Un CTO optimiza decisiones.<\/li>\n<\/ul>\n\n\n\n
La arquitectura dej\u00f3 de ser una cuesti\u00f3n t\u00e9cnica y pas\u00f3 a ser estrat\u00e9gica.<\/p>\n\n\n\n
\n\n\n\n3. Startup C: el momento en que ya no eres \u201csolo desarrollador\u201d<\/h2>\n\n\n\n
En esta startup fintech comenc\u00e9 como desarrollador Android.<\/p>\n\n\n\n
Desde el inicio estaba previsto que el backend tendr\u00eda que evolucionar.
Pero un cambio regulatorio externo nos oblig\u00f3 a priorizarlo antes de lo planeado.<\/p>\n\n\n\nLa diferencia con mi primera experiencia fue clara.<\/p>\n\n\n\n
Esta vez:<\/p>\n\n\n\n
\n
- Analic\u00e9 el contexto completo (regulaci\u00f3n, costes, equipo, tiempos).<\/li>\n\n\n\n
- Eleg\u00ed AWS equilibrando presupuesto, resiliencia y escalabilidad.<\/li>\n\n\n\n
- Dise\u00f1\u00e9 pensando en crecimiento futuro, no solo en entregar r\u00e1pido.<\/li>\n\n\n\n
- Equilibr\u00e9 deuda t\u00e9cnica y avance real de negocio.<\/li>\n<\/ul>\n\n\n\n
El backend no era una sorpresa.
El cambio de rumbo lo convirti\u00f3 en cr\u00edtico.<\/p>\n\n\n\nY ah\u00ed entend\u00ed algo fundamental:<\/p>\n\n\n\n
\nLiderar tecnolog\u00eda es decidir bajo incertidumbre, no programar sin ella.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nLo que realmente cambi\u00f3<\/h2>\n\n\n\n
Entre la primera y la tercera startup hubo una transformaci\u00f3n.<\/p>\n\n\n\n
Aprend\u00ed que:<\/p>\n\n\n\n