Artículos / · 9 min de lectura

Los primeros 90 días de un engagement como Fractional CTO

Qué hace realmente un fractional CTO en los primeros 90 días, semana a semana. Auditoría, revisión de vendors, decisiones de arquitectura, preparación para contratar. El proceso concreto, no el pitch.

  • #fractional-cto
  • #engineering-leadership
  • #startup

La mayoría de los founders, cuando preguntan por primera vez sobre un engagement de fractional CTO, formulan la misma pregunta de dos maneras. Primero: “¿lo necesito?” — algo que respondí por separado en fractional CTO vs contratación a tiempo completo. Y casi de inmediato: “vale, pero ¿qué HACES exactamente?”.

Esa segunda pregunta es más difícil de responder en abstracto. Así que dejé de intentarlo. La forma más honesta que tengo de describir el rol es contar cómo se desarrollan los primeros 90 días en la realidad, porque el onboarding de 90 días es donde el trabajo se vuelve concreto. Ves el codebase. Te sientas con el equipo. Tocas la factura del cloud. Al final, el founder confía lo suficiente en el diagnóstico para seguir, o no — y ambos resultados son útiles.

Así suelen verse esos 90 días.

Semanas 1–2: Auditoría, no consejos

El mayor error que puede cometer un fractional CTO nuevo es aparecer en la semana uno con opiniones. Todavía no te las has ganado. No sabes qué trade-offs ha discutido ya el equipo, qué restricciones vinieron de una llamada con un inversor en la que no estuviste, o qué decisión clave tomó alguien que ya se fue.

Por eso las dos primeras semanas son diagnósticas, no prescriptivas. Pido acceso read-only al repo, acceso de lectura a la consola del cloud, la lista de vendors y el calendario. Asisto a los standups sin hablar. Hago un 1:1 con cada ingeniero — normalmente 30 minutos, a veces más si quieren desahogarse — y a todos les hago las mismas tres preguntas: ¿qué es lo que te molesta desde hace meses?, ¿qué arreglarías si nadie estuviera mirando? y ¿qué te gustaría que el founder entendiera del codebase?.

Mientras tanto, leo. Un recorrido por el codebase: cómo está estructurado el repo, cómo es el pipeline de deploy, dónde están los foot-guns evidentes. La infra: cuántos entornos, qué tiene auto-scaling, qué es un single point of failure. La lista de vendors: cada gasto recurrente, qué hace, quién lo contrató.

En CryptoUnity la fase de auditoría sacó a la luz 32 problemas de seguridad que había que resolver antes del lanzamiento — ninguno lo estaba escondiendo el equipo, todos eran invisibles desde fuera del código. Ese es el valor de las semanas 1–2: encuentras las cosas de las que nadie habla porque hoy no están ardiendo. El deliverable al final de la semana 2 no es un deck estratégico. Es un diagnóstico escrito. Bullets. Brutalmente honesto.

Semanas 3–4: A dónde va el dinero

Una vez que existe el diagnóstico, lo segundo que miro es el gasto. Casi cada startup que he auditado tenía un 30–60 % de desperdicio en herramientas de desarrollo, cloud y suscripciones SaaS. No porque alguien fuera imprudente — porque nadie había tenido tiempo de mirarlo todo junto, y los gastos individuales siempre parecen razonables aislados.

La táctica no es glamurosa: una sola hoja de cálculo con cada gasto mensual recurrente, etiquetado de una de tres formas. Critical — si se apaga mañana, el producto se rompe. Nice-to-have — útil, pero sobreviviríamos sin él. Cancelled — pagamos pero no usamos, o es reemplazable por algo que ya está en la lista critical.

Esto normalmente lleva una sesión de trabajo con el founder y el ingeniero senior, porque el founder sabe qué se prometió comercialmente y el ingeniero sabe qué está realmente conectado. La salida es un número: cuánto burn mensual podemos recuperar en los próximos 30 días sin romper nada.

Un ejemplo pequeño: en Adriatic Investors consolidamos dos sitios en un solo hosting durante el engagement. No fue un cambio heroico de arquitectura — solo una de esas cosas obviamente correctas cuando ambos sitios pasaron a ser del mismo equipo, y bajó la factura mensual al instante. Aburrido. Dinero real.

Semanas 5–8: La conversación de arquitectura

Hacia la semana 5 ya tengo contexto suficiente para tener opinión de verdad. Esta es la parte del engagement donde me gano el sueldo, y trato de hacerlo con mucho cuidado, porque las decisiones de arquitectura que se toman en pre-seed o seed son las que los founders refactorizan con dolor en Series A.

Las conversaciones de esta ventana son las que me quitan el sueño:

  • Monolito vs servicios. En tu etapa, casi siempre monolito. El equipo no es lo bastante grande para pagar el impuesto operativo de los servicios, y el supuesto problema de scaling no es tu verdadero cuello de botella.
  • Build vs buy. Auth, billing, email, búsqueda — buy. Las cosas que son tu moat — build. Los founders se equivocan en esto de forma consistente y construyen lo aburrido porque les suena a “engineering de verdad”.
  • Qué migrar ahora vs qué dejar quieto. La tentación de reescribir siempre está. Casi siempre la respuesta es: déjalo, instrumentalo, toca solo las partes que bloquean los próximos 12–18 meses de producto.
  • Decisiones de modelo de datos. La categoría más difícil de deshacer. Si vamos a tomar una decisión que no voy a lamentar en dos años, vive aquí.

En GetThrivin la entrada fue en fase de scaling, lo que significó que las decisiones de arquitectura no eran teóricas — ya estaban en producción bajo carga real. Es un sabor distinto de la misma conversación: menos “¿deberíamos?” y más “ahora que está roto bajo tráfico, ¿cuál es el menor arreglo correcto?”. Sea cual sea el sabor, el deliverable de esta ventana es el mismo: un memo de arquitectura escrito, con la decisión, el trade-off y las alternativas que rechacé y por qué. Los founders tendrían que poder pasarle ese memo al próximo CTO y que este entienda la decisión.

Semanas 9–12: Preparación para contratar y plan de handoff

Llegado el tercer mes, la forma del engagement se ha revelado, y normalmente es una de dos.

Bridge engagement. El fractional cubre temporalmente un puesto de CTO de tiempo completo que aún no se ha contratado. En ese caso, en las semanas 9–12 escribo el JD del futuro full-timer, diseño el interview rubric y redacto el 30/60/90 plan que ejecutará cuando entre. Suelo correr las dos primeras rondas del loop de recruiting con el founder, y luego me hago a un lado cuando sale la oferta.

Fractional permanente. El founder ha decidido que aún no necesita un full-timer, y el engagement continúa con cadencia trimestral. En ese caso, en las semanas 9–12 cerramos los OKR del próximo trimestre, acordamos un ritmo semanal (asistencia a standups, cadencia de architecture reviews, board prep) y establecemos las reglas de escalación — qué va por mensaje de Slack y qué por llamada el mismo día.

Ambas formas son válidas. El founder elige según lo que realmente necesita, no según lo que suena más impresionante. Tengo un ligero sesgo hacia el modelo bridge porque las salidas limpias son más saludables que los retainers abiertos, pero he llevado muchos engagements de fractional permanente donde los números simplemente no justificaban un full-time.

Lo que NO está en los primeros 90 días

Vale la pena ser explícito aquí, porque las expectativas se calibran mal.

  • No: escribir código de producción. A veces lo hago, si hay un hueco muy específico y es más rápido que briefar a alguien. Pero no es el trabajo, y si estoy programando más de unas pocas horas a la semana, algo está mal dimensionado.
  • No: reemplazar a tu ingeniero senior. Un buen fractional vuelve más efectivo a tu ingeniero senior, no redundante. Si se siente socavado, el engagement va a fallar, sin importar lo que entregue.
  • No: un deck de estrategia. Yo escribo memos. El medio importa — un deck es para vender, un memo es para decidir.
  • No: consejos gratis en una discovery call. El engagement arranca con un contrato, un scope y una base de horas semanales. Con gusto hago una llamada de diagnóstico gratuita, pero desde el momento en que estamos trabajando de verdad, es pagado.

Cierre

90 días es la duración correcta para este tipo de engagement porque es lo bastante largo para diagnosticar de verdad — el equipo supera la fase educada, la factura del cloud llega dos veces, la arquitectura se stress-testea contra un sprint real — y lo bastante corto para ser reversible si el fit no es el adecuado. Cualquiera de los dos puede irse al final sin cicatrices.


Si estás considerando un engagement de fractional CTO, reserva una llamada de diagnóstico gratuita de 30 minutos. Sin pitch deck.

Hablemos

¿Listo para arreglar, construir
o escalar?

30 minutos, conmigo personalmente. Leo tu sistema como un archivo de logs y te digo qué haría primero. Sin presentaciones, sin embudo de ventas.

Davor Majc, fundador, Numen

Qué obtienes en la llamada
→ un diagnóstico de una página
→ 2–3 formas de solución, ordenadas por impacto
→ coste aproximado + plazo para cada una
→ sí/no — ¿soy la elección adecuada?
+386 40 828 474 · Blejska Dobrava, SI