Equipo interno vs. equipo externo: cuándo suma cada uno
Contratar desarrolladores in-house cuesta tiempo y plata que a veces no conviene gastar. Pero tercerizar todo tampoco es la respuesta. Te ayudamos a pensar el mix.
Punto por punto.
| Dimensión | Equipo interno | Equipo externo |
|---|---|---|
| Tiempo de arranque | 2 a 4 meses por dev (búsqueda, entrevistas, notice period, onboarding). | 1 a 2 semanas. Un equipo externo ya tiene el stack, los procesos y la gente lista. |
| Costo total anual | Salario + cargas sociales + aguinaldo + PTO + equipo + licencias + manager técnico + bench time. En LATAM, un dev senior ronda USD 55k-90k all-in. | Tarifa por hora o retainer. Pagás solo lo que usás, sin cargas ni bench. Más caro por hora, más barato si el proyecto es acotado. |
| Flexibilidad a cambio de scope | Baja. Si el roadmap cambia, tenés gente contratada para algo que ya no necesitás. | Alta. Subís o bajás horas según el mes. Si el proyecto termina, no despedís a nadie. |
| Retención de conocimiento | Alta si el turnover es bajo. El conocimiento del producto vive en la cabeza del equipo que lo construyó. | Depende de la documentación. Un estudio serio deja el conocimiento documentado, pero nunca es lo mismo que tenerlo in-house. |
| Dependencia externa | Cero. El producto es tuyo y lo mantiene tu gente. | Existe. Si el estudio desaparece o sube tarifas, tenés que migrar. |
| Calidad controlable | Vos definís code review, testing, seniority mix. Requiere tener a alguien técnico que pueda liderar. | La calidad depende del estudio. Uno bueno trae estándares, PR reviews y testing desde el día uno. Uno malo te entrega deuda técnica. |
| Pico de demanda | Mal. Contratar para un pico de 3 meses no tiene sentido. | Bien. Sumás un equipo externo por el pico y lo bajás cuando pasa. |
| Skills diversos en un mismo proyecto | Difícil. Contratar un dev de React, uno de DevOps, un diseñador y un QA para un proyecto de 4 meses es carísimo. | Fácil. Un estudio arma la célula con los perfiles que hacen falta. |
| Onboarding de un proyecto nuevo desde cero | Lento. El equipo interno suele estar ya ocupado con el core. | Rápido. Un equipo externo entra enfocado solo en ese proyecto. |
| Compromiso con el producto core | Máximo. La gente que vive el producto todos los días toma mejores decisiones de largo plazo. | Profesional, pero acotado al scope contratado. Un estudio no va a pelearse por decisiones de producto que no le corresponden. |
La lógica detrás de la diferencia.
Cuándo conviene armar equipo interno
Equipo interno tiene sentido cuando el producto es el core del negocio y la roadmap es de años, no de meses. Si ya tenés tres o más developers justificados por la operación, ya hay volumen para sostener cultura ingenieril: code reviews consistentes, decisiones de arquitectura que maduran con el tiempo, ownership real del producto. También conviene cuando el conocimiento del dominio es tan específico que entrenar a alguien de afuera cada seis meses es más caro que pagar sueldos. Acá el argumento no es costo por hora, es que la gente que vive el producto todos los días toma mejores decisiones de largo plazo que cualquier equipo externo.
Cuándo conviene un equipo externo
Un equipo externo gana cuando estás arrancando un MVP y no sabés si el producto va a existir en seis meses. Contratar tres devs para descubrir que el producto no valida es la peor decisión que podés tomar. También gana cuando necesitás un skill puntual que no justifica una contratación: un especialista en performance para una campaña de tres meses, un equipo de mobile cuando tu producto es web, alguien que sepa de un stack que nadie más maneja. Y gana cuando sos una compañía chica sin management técnico: sin alguien que sepa liderar devs, un equipo interno se convierte en un problema más grande que la solución. Trabajamos con vos en ese mientras tanto.
El modelo híbrido: lo que más funciona
En la práctica, la división interno vs externo es falsa. El modelo que mejor funciona es híbrido: equipo interno chico y senior a cargo del core del producto, y estudio externo para proyectos laterales, picos de demanda o skills específicos. El interno sostiene la visión y la retención de conocimiento. El externo absorbe la variabilidad. De esa forma no terminás con diez personas contratadas para un pico que duró cuatro meses, ni con un estudio manejando decisiones de producto que no le corresponden. Nuestro estudio trabaja bastante seguido codo a codo con equipos internos, en el mismo Slack, con las mismas PR reviews y los mismos estándares.
El costo real de un dev interno vs. hora de estudio
El número que la gente mira primero es el sueldo, y ahí se equivoca. Un dev senior en LATAM con sueldo bruto de USD 4.000 al mes te termina costando cerca de USD 6.500 a USD 7.500 reales por mes: cargas sociales, aguinaldo, PTO, equipo, licencias, parte proporcional del manager técnico que lo lidera, y el bench time inevitable entre proyectos. A eso sumale el costo de onboarding (tres meses de productividad parcial) y el riesgo de turnover: si se va al año, perdiste toda esa inversión. La hora de un estudio parece más cara cuando la comparás contra el sueldo pelado. Cuando la comparás contra el costo total y el riesgo, la ecuación cambia bastante según el escenario.
Lo que nos preguntan primero.
¿Cuándo debería empezar a armar equipo interno?
Cuando el producto ya valida, la roadmap es de años y el volumen de trabajo justifica tres o más developers full-time de forma sostenida. Antes de eso, un equipo externo te da la misma potencia sin el costo fijo. Una señal clara: si estás pagando a un estudio más de lo que te costaría un equipo interno durante doce meses seguidos, ya es momento de empezar la transición.
¿Ustedes "compiten" con mi equipo interno?
No. Trabajamos bastante seguido junto a equipos internos, y nos va mejor cuando el interno es fuerte: hay con quién discutir arquitectura, las PR reviews son de verdad y las decisiones se toman rápido. No venimos a reemplazar a nadie, venimos a absorber el trabajo que el interno no llega a hacer o que no tiene sentido que haga.
¿Qué pasa con la transferencia de conocimiento cuando nos vamos?
Documentamos desde el día uno: README con setup, ADRs para decisiones de arquitectura, diagramas de los flujos críticos y, si hace falta, sesiones grabadas de walkthrough del código. Al cierre del proyecto hacemos un handoff formal con tu equipo. El objetivo es que cualquier dev que entre después pueda levantar el proyecto sin depender de nosotros.
¿Pueden trabajar junto a mi equipo interno como si fueran parte del team?
Sí, es bastante lo que hacemos. Estamos en tu Slack, participamos de las dailies si hace falta, hacemos PR reviews cruzadas con tu gente y seguimos los estándares que ya tienen. La idea no es operar como una caja negra aparte, sino integrarnos al flujo que ya funciona en tu equipo.
¿Cuál encaja con vos?
Contanos tu contexto y te decimos con honestidad cuál conviene. A veces no somos nosotros.
Escribinos por WhatsApp