Cofundador técnico vs contractor: ¿qué necesita tu proyecto?

Cuando una idea cruza la línea que separa "lo voy a hacer algún día" de "lo estoy haciendo", la primera pregunta técnica que aparece es siempre la misma: ¿con quién la construyo?

La respuesta default —contratar un dev por hora— parece la opción segura. Es la que recomiendan los foros, la que conoces de experiencias laborales pasadas, la que tiene precio claro. Pero para un producto nuevo, contratar por hora es muchas veces la decisión más cara que vas a tomar.

El modelo que parece seguro

Un contractor cobra por su tiempo. Si pagás $50/h y el proyecto necesita 400 horas, gastás $20.000. Si necesita más, gastás más. Tu incentivo y el del contractor están desalineados desde el día uno: vos querés terminar rápido, él gana más mientras más dure.

Esto no es un juicio moral —es matemática. La mayoría de los contractors son profesionales que entregan trabajo decente. Pero cuando el cliente no es un experto técnico, el contractor termina decidiendo cosas que el cliente no puede evaluar:

• ¿Vale la pena refactorizar este módulo o lo dejamos así?
• ¿Probamos esta arquitectura nueva o usamos lo conocido?
• ¿Aceptamos que el feature X tarde 3 días o invertimos una semana en hacerlo "bien"?

Sin skin in the game, todas estas respuestas tienden hacia "lo que cobra más horas" sin que el contractor sea consciente. El proyecto se hace más caro, más lento, y queda más frágil de lo que tendría que estar.

El modelo que parece riesgoso (y no lo es tanto)

Un cofundador técnico no cobra por hora. Cobra por equity —un porcentaje del proyecto. Su retribución depende exclusivamente de que el producto exista, crezca, y eventualmente genere dinero.

A primera vista parece más riesgoso para vos: estás regalando una parte de algo que todavía no existe. Pero al hacer el cálculo:

• Contractor: $20.000+ por adelantado, sin garantía de calidad, riesgo total tuyo.
• Cofundador: 0 inversión inicial, alineación total de incentivos, el dev pone más esfuerzo del que pondría un contractor porque su éxito es tu éxito.

Si el proyecto funciona, perdiste un porcentaje. Si no funciona, no perdiste nada. Comparalo con: si el proyecto funciona, te queda 100%. Si no funciona, perdiste $20K.

Hacé la matemática esperada (expected value) y rara vez gana el contractor.

Cuándo conviene cada modelo

Esto no es un alegato universal contra los contractors. Hay casos donde son la respuesta correcta:

• Necesitás una skill puntual por tiempo definido: una migración de base de datos, un audit de seguridad, una integración con una API específica. Conocés exactamente qué querés y cuánto debería tardar.
• Tu proyecto ya está en producción y necesitás mantenimiento: el riesgo de discovery ya pasó, las decisiones de arquitectura ya están tomadas.
• Tenés equipo técnico interno que va a supervisar al contractor: alguien que pueda evaluar si el trabajo está bien hecho.

Cuando el proyecto está en su fase 0 —cuando ni siquiera sabés si la idea es buena, qué stack usar, cómo va a ser el modelo de negocio— el contractor está optimizando para un problema que no es el tuyo. Vos estás optimizando para descubrir; él está optimizando para entregar lo que pediste.

La pregunta real

No es "¿cuánto cuesta?" sino "¿qué incentivos quiero en la mesa cuando se tomen las decisiones que no puedo evaluar?"

Si tu proyecto está empezando y la respuesta tiene que ver con velocidad, calidad y compromiso a largo plazo, el modelo de equity gana casi siempre. Y si nadie está dispuesto a entrar como cofundador en tu proyecto, esa es información importante —significa que la idea, vista desde afuera, no parece tener potencial suficiente.

A veces ese "no" es la mejor devolución que vas a recibir.

En gitConnections evaluamos cada idea antes de comprometernos. Si crees que tu proyecto tiene potencial,

.