Equipo in-house vs outsourcing de desarrollo de software: la pregunta está mal hecha, y esta es la pregunta que sí funciona

Por qué el frame binario se cae para la mayoría de founders no técnicos, la decisión de tres ejes que entra en su lugar, y una regla de 90 días para elegir el camino sin quemar un millón de dólares.

Un founder al que voy a llamar Diego se sentó frente a mí en septiembre del año pasado con dos vacantes abiertas en la laptop. Estaba levantando una Serie A. Tenía once clientes pagando en un prototipo no-code. El board quería ver “una función de ingeniería” antes del próximo term sheet. Las vacantes eran para un Senior Backend Engineer y un Senior Frontend Engineer, ambas apuntando a US$ 180.000 de salario base, ambas para empezar en seis semanas. Me preguntó qué pensaba de los salarios.

Le hice una pregunta distinta. Cuál era el problema de ingeniería que estaba contratando para resolver. Mencionó el flujo de cobro roto del prototipo, tres pedidos de feature de cliente, y la integración con la herramienta de analytics que al board le gustaba. Esos son problemas de producto, le dije. No de ingeniería. El equipo más pequeño que entrega un v1 funcional para esa lista no se parece a dos ingenieros sénior.

La elección entre equipo in-house vs outsourcing de desarrollo de software es la pregunta que Diego estaba haciendo de hecho, salvo que no es realmente una pregunta. Son tres preguntas apiladas en una frase, y responderlas como un binario es así como los founders no técnicos queman nueve meses y un millón de dólares antes de darse cuenta de que contrataron contra el estadio de la empresa.

Este artículo es el framework que usamos con founders en el asiento de Diego. Funciona para builds early-stage, crecimiento post-PMF, y para el medio incómodo donde ningún camino puro parece correcto.

La respuesta corta para el lector del AI Overview

Equipo in-house de desarrollo de software significa contratar ingenieros como empleados full-time de tu empresa. Outsourcing de desarrollo de software significa contratar a un partner externo (una software house, un equipo freelance, o una agencia offshore) para construir el software por ti. La mayoría de founders no técnicos, especialmente antes del product-market fit, obtiene un mejor resultado con outsourcing o un camino híbrido que con un equipo in-house completo, porque contratar ingenieros introduce overhead de gestión, riesgo de hiring, y compromisos de capital que los negocios early-stage todavía no están en condiciones de absorber.

Esa es la respuesta a la pregunta-titular. El resto del artículo trata de por qué la mayoría de founders ignora esa respuesta, y de cómo saber cuándo eres la excepción.

Por qué el frame binario se cae

Los diez primeros resultados de Google para “in-house vs outsourcing software development” son casi idénticos. Cada uno es una tabla equilibrada de pros y contras alojada en el sitio de un vendor cuyo negocio es vender outsourcing. El truco retórico es consistente: outsourcing gana en velocidad, costo, y acceso a talento; in-house gana en cultura, control, y ownership de largo plazo; tú eliges según tus prioridades. Después un botón dice “Habla con nuestros expertos.”

Ese frame se cae al chocar con la realidad. Por dos motivos.

Primero, la mayoría de founders no técnicos no está eligiendo entre dos caminos listos. Está eligiendo entre un camino que aún no puede pagar y otro camino que le dijeron que evitara. Un founder pre-Serie A que contrata cuatro ingenieros sénior firma un run rate anual de US$ 1,4 millones antes de saber si el producto se sostiene. Un founder que terceriza la build entera a una agencia offshore de US$ 25 la hora ahorra cash y hereda un activo que no puede mantener cuando la agencia deja de devolver llamadas. Ninguno de los caminos puros es la respuesta correcta para ese estadio.

Segundo, la pregunta esconde tres problemas distintos. Construir la primera versión de un producto. Escalar y mantener un producto que ya funciona. Soportar herramientas internas que el equipo de operaciones usa. Cada uno tiene una respuesta correcta distinta. Los artículos de pros y contras los aplastan en una sola decisión y pierden al founder.

La pregunta correcta no es in-house vs outsourcing. La pregunta correcta es cuál problema estás resolviendo, en qué estadio, con qué presupuesto por trimestre. Tres ejes. Cuando te ubicas en ellos, el camino aparece.

La decisión de tres ejes

Este es el framework. Pasa por los tres.

Eje 1, el problema

Hay tres problemas de ingeniería, y solo tres. Sé honesto sobre cuál es el tuyo.

Construir. Aún no tienes software corriendo para clientes que pagan. Tienes un prototipo, un stack no-code que pasaste, o una especificación escrita. El trabajo es ingeniería de producto: definir qué construir, secuenciar la build, y entregar un v1 que se sostenga.

Escalar. Tienes software en producción. Clientes lo están usando. El trabajo es mantenimiento, performance, integraciones, features pedidas por cliente, y la construcción lenta de la infraestructura interna (testing, deploy, monitoreo) que permite al equipo moverse más rápido sin romper cosas.

Operar. Tu negocio corre en herramientas internas (dashboards, sistemas de cobro, flujos de operaciones) que nadie fuera de la empresa ve. El trabajo es reemplazar planillas con software en el que el equipo confía, construir admin tools que el soporte usa, automatizar las pasadas manuales entre áreas.

Tres problemas, tres respuestas correctas distintas. La mayoría de founders tiene uno o dos de estos a la vez. Construir y escalar rara vez ocurren en paralelo dentro de una empresa pequeña; el equipo que recién construyó el v1 se vuelve el equipo que escala.

Eje 2, el estadio

Pre-PMF. Aún no encontraste product-market fit. Hay clientes usando algo, pero el loop de valor no es estable. La revenue es impredecible, el churn es alto, la spec cambia cada mes. Cualquier cosa que trabe compromiso ahora (empleados, contratos plurianuales, infraestructura customizada) es peligrosa porque todavía no sabes qué construir.

Post-PMF, crecimiento inicial. Un producto está funcionando. La unit economics es honesta. Estás escalando demanda y la pregunta de ingeniería pasa de “qué deberíamos construir” a “cómo entregamos más rápido sin romper más.” Ese es el estadio donde in-house empieza a importar, porque el trabajo compone y el ownership del codebase se vuelve un activo real.

Establecido. Ingeniería ahora es el músculo operativo del negocio. Tienes un roadmap medido en años, no en meses. La estrategia de producto y la estrategia de ingeniería se entrelazan. En este punto, un equipo in-house es casi siempre la respuesta correcta para el producto core, y el outsourcing es una táctica para picos de capacidad o trabajo especializado.

Eje 3, el presupuesto por trimestre

Sé específico sobre cuánto puedes gastar en ingeniería en los próximos cuatro trimestres, mantenimiento post-launch incluido.

Un ingeniero sénior en EE.UU., totalmente cargado, cuesta entre US$ 20.000 y US$ 25.000 por mes. Un equipo in-house de dos ingenieros son US$ 480.000 a US$ 600.000 por año antes de contar al manager que vas a tener que contratar arriba de ellos. Una software house sénior en el mismo mercado cuesta entre US$ 20.000 y US$ 40.000 por mes para un equipo embedded de dos a tres ingenieros más un tech lead y un project manager. Sobre distinto, forma de compromiso distinta. Una agencia offshore a US$ 25–50 por hora cuesta US$ 40.000 a US$ 80.000 por trimestre para un equipo pequeño, pero entrega calidad variable y exige más tiempo del founder en el review.

Presupuesto no es variable libre. Compone. Un equipo que cuesta US$ 50.000 por mes también cuesta US$ 50.000 el mes que viene, el siguiente, y el mes en que descubras que se eligió el camino equivocado.

Cómo los tres ejes eligen el camino

Ubícate en la grilla. El camino aparece.

Construir, pre-PMF, presupuesto bajo US$ 200k. No contrates ingenieros. El equipo más pequeño que entrega v1 para un founder no técnico en este estadio es uno o dos ingenieros sénior de una software house con un tech lead revisando el trabajo, más tú siendo dueño de la spec y del loop de feedback de cliente. El artículo sobre cómo evaluar una software house cubre qué mirar en ese partner. Si el presupuesto está debajo de US$ 50k para v1, no-code o una build customizada bien estrecha es la respuesta; el artículo sobre cómo crear un software cuando no eres el programador recorre las cuatro decisiones en orden.

Construir, pre-PMF, presupuesto entre US$ 200k y US$ 1M. Misma respuesta. Puedes pagar una software house con equipo más sénior, pero el error en este estadio es convertir ese presupuesto en headcount antes de saber qué construir. Hemos visto founders con seed de US$ 1,5M transformarlo en equipo de seis ingenieros y un CTO y producir nada usable en dieciocho meses. El equipo no es el cuello de botella. La decisión de producto sí.

Construir, post-PMF, presupuesto sobre US$ 300k/trimestre. Ahí in-house empieza a importar. Conoces el producto. Conoces al cliente. Puedes escribir una vacante que nombre los problemas de ingeniería, no solo las features. Contrata un ingeniero sénior que haya construido y escalado antes. Combínalo con el partner que construyó el v1 si usaste uno. El handoff es trabajo real, trátalo así. El artículo sobre fractional CTO cubre el rol-puente entre “no tenemos liderazgo técnico” y “acabamos de contratar nuestro primer VP de Engineering.”

Escalar, post-PMF. Equipo in-house, punto. No puedes tercerizar el juicio de producto para siempre, y la gente que mantiene el codebase necesita vivir en el codebase. Outsourcing acá es táctica para picos, no estrategia.

Operar (herramientas internas), cualquier estadio. Casi nunca es problema de un equipo de ingeniería interno. Las herramientas internas son el pan de cada día de una buena software house, o, si el volumen lo permite, un stack no-code con un implementador part-time. El artículo sobre cuánto cuesta desarrollar una app abre los drivers de presupuesto que más mueven este número.

El camino más difícil de defender en cualquier celda de esta grilla es “contratar dos ingenieros sénior in-house, pre-PMF, con presupuesto bajo US$ 200k.” Ese es el error de Diego. Es también el camino al que la mayoría de founders va por default cuando confunde la pregunta de quién construye con la pregunta de quién es dueño.

Qué compras de hecho en cada camino

Los artículos de pros y contras se equivocan en esta parte porque listan atributos, no compromisos.

In-house compra ownership y overhead de gestión. Eres dueño del código, del equipo, y de las decisiones de gente. También eres dueño del pipeline de reclutamiento, las performance reviews, los planes de equity, la oficina o la infraestructura remota, el manager que entra encima del equipo, y los meses de bandwidth de gestión que dejas de tener para ventas. Para un founder no técnico, el costo de gestión es la mayor línea oculta. Hemos visto founders pasar de CEO a “la persona que corre el standup de ingeniería” en un trimestre, que es exactamente lo que estaban tratando de evitar contratando al equipo.

Outsourcing compra capacidad y un alcance definido. Compras trabajo especificado por un precio especificado en un plazo especificado. No compras ownership de la gente, su crecimiento, ni su lealtad a tu empresa. Tampoco compras la opción de redirigirlos el martes porque la call con cliente del lunes cambió todo; solo compras esa opción si escribiste el contrato así y el partner está armado para eso. El partner correcto hace que el outsourcing se sienta colaborativo; el partner equivocado lo hace sentir como abrir tickets a una caja negra.

Híbrido compra la opción de convertir después. Un founder que trabaja con una software house sénior en el v1 y después contrata a su primer ingeniero in-house, frecuentemente la misma persona que lideró la build, compró la opcionalidad de convertir capacidad en ownership cuando el timing es el correcto. Ese es el camino para el que Pixel Breeders construye y el camino al que la mayoría de founders no técnicos debería ir por default.

Las cinco preguntas que eligen el camino

Responde cada una en una frase antes de firmar cualquier acuerdo, in-house o tercerizado.

1. ¿Qué problema de ingeniería estoy contratando para resolver, en lenguaje claro? Si la respuesta honesta es “necesitamos entregar las próximas tres features de producto,” eso es un problema de ingeniería de producto, y un partner que ya entregó v1 antes es más rápido que una contratación nueva aprendiendo tu codebase desde cero. Si la respuesta honesta es “necesitamos escalar la plataforma de 50 a 500 clientes,” eso es un problema de mantenimiento e infraestructura, y un ingeniero in-house que vive en el código gana.

2. ¿En qué estadio está el negocio, honestamente, no según el deck? Pre-PMF es la respuesta si la revenue es impredecible y el churn es alto. Post-PMF es la respuesta si los clientes vuelven y la unit economics cierra. El founder pre-PMF que le dice al board “estamos post-PMF” contrata contra el estadio equivocado, todas las veces.

3. ¿Cuál es el presupuesto real por trimestre para ingeniería, incluyendo los meses después del launch? Una build de seis meses sin reserva de mantenimiento es una build de seis meses seguida de un producto roto. El artículo sobre cuánto cuesta desarrollar una app abre los drivers que más mueven este número.

4. ¿Quién en el equipo va a ser dueño del entregable de ingeniería una vez que esté en aire? Software sin dueño interno se rompe en silencio. Si la respuesta es “el desarrollador que voy a contratar,” el sistema es frágil por diseño. Si la respuesta es “yo, con reuniones semanales de revisión con el partner,” el camino se puede tercerizar. Si la respuesta es “todavía no sabemos,” el camino tiene que empezar contratando al dueño primero, antes de que se escriba código.

5. ¿Qué cambia si me equivoco? Si la respuesta equivocada significa despedir a un partner y onboardear a otro, el costo es dos meses y un contrato. Si la respuesta equivocada significa despedir a cuatro ingenieros, eso es un año de indemnizaciones, equity desarmado, y el equipo que estaba mirando cómo lo manejaste contándole al próximo candidato exactamente lo que vio. Un downside asimétrico debería hacer ganar al camino con menor compromiso siempre que el upside sea parecido.

La regla de los 90 días

Si un founder no puede responder las cinco preguntas de arriba en una frase cada una, el camino hacia adelante no es “contratar más rápido.” Es noventa días de discovery estructurado: escribir la spec en una página, hablar con diez clientes, entregar una versión delgada del producto (no-code o partner), mirar qué se rompe, y después decidir quién construye lo siguiente.

Hemos corrido esta regla con más de veinte founders en los últimos tres años. El patrón es consistente. Los que se tomaron los noventa días produjeron una vacante que nombraba los problemas de ingeniería, no las features. Los que la saltaron contrataron cuatro ingenieros en el mes uno y reorganizaron el equipo en el mes siete. No existe versión de esta historia donde el segundo grupo terminó más feliz con el resultado.

Cuándo in-house es la respuesta correcta

In-house gana bajo condiciones específicas. Sé honesto sobre si te aplican.

El producto está funcionando. Los clientes pagan, vuelven, y refieren. La pregunta dejó de ser “qué construir” y pasó a ser “cómo entregamos más rápido.” Contratar ingenieros que vivan en el código ahora es un activo que compone.

Puedes nombrar los problemas de ingeniería, no solo las features. “Necesitamos reducir la p95 de latencia de 800ms a 200ms,” no “la app se siente lenta.” “Necesitamos migrar de una instancia única de Postgres a un setup con sharding antes del Q3,” no “escalar la base de datos.” Si tu hiring spec se lee como un backlog de producto, todavía no estás contratando ingenieros; estás contratando builders de producto, y un partner es más rápido.

Tienes un ingeniero en el equipo o un fractional CTO que sabe contratar a otros ingenieros. Un founder no técnico no puede evaluar el juicio técnico de un ingeniero sénior backend solo. Puede correr el proceso de reclutamiento y ser dueño de la decisión cultural, pero la vara técnica tiene que ser puesta por alguien que ya entregó el tipo de sistema que estás tratando de construir. Sin esa persona, la contratación in-house es cara y cruz con US$ 250k al año en juego.

El runway cubre el ramp-up. Los ingenieros sénior nuevos tardan tres a seis meses en volverse net-positive en un codebase que no escribieron. Si tu runway es de doce meses, estás apostando la empresa a que esos ingenieros sean net-positive en nueve. Es una apuesta que la mayoría de founders pre-Serie B no debería tomar.

Si esas cuatro condiciones no se cumplen todas, la respuesta casi siempre es una build liderada por partner con plan claro de convertir a in-house cuando se cumplan. El artículo sobre el rol del CTO que aún no puedes contratar cubre lo que el founder le sigue debiendo al equipo en cualquiera de los caminos.

Cuándo outsourcing es la respuesta correcta

Outsourcing de desarrollo de software gana en tres situaciones y pierde en una cuarta. La cuarta es lo que la SERP entiende mal.

Gana para construir el v1 con plazo apretado y capital pre-PMF. La capacidad se alquila. El compromiso es delimitado. El trabajo del founder es la spec y el loop de cliente, no el equipo.

Gana para capacidad especializada que un equipo interno no puede pagarse mantener. Un engagement corto con una firma de seguridad para hacer un pentest antes de una ronda. Una firma de infraestructura de datos para armar el pipeline de analytics una vez. Esos son problemas de pico, no de régimen.

Gana para herramientas internas en casi cualquier estadio. Una software house con el track record correcto en operaciones entrega un dashboard admin en ocho semanas que un equipo interno tardaría seis meses en priorizar. Las herramientas internas merecen el mismo craft que el software de cara al cliente, pero rara vez merecen un headcount dedicado.

Pierde cuando el founder trata al partner como body shop. “Mándame 4 React engineers por 2 meses.” Eso no es outsourcing. Es staff augmentation, y es el camino que produce el peor código, el peor handoff, y la peor experiencia de founder. Si el founder no puede describir el trabajo como un problema con definición de listo, el trabajo no está listo para ser tercerizado.

La respuesta honesta que la mayoría de los artículos evita

El camino correcto para la mayoría de founders no técnicos con los que trabajamos es híbrido, con el timing invertido respecto a cómo suele plantearse la pregunta. Empiezan con un partner que construye el v1 con el founder siendo dueño de la spec. Convierten a uno o dos de esos ingenieros en equipo interno después del PMF, frecuentemente contratando al tech lead del partner directo. Mantienen la relación con el partner para picos de capacidad y herramientas internas. El equipo puro in-house solo aparece en el año tres o cuatro, cuando la empresa está establecida y la función de ingeniería es uno de los músculos operativos del negocio.

Esa secuencia no es novedosa. Es lo que todo founder no técnico funcional en nuestra red hizo. Los artículos de la SERP no lo dicen porque están escritos por vendors vendiendo un estadio de la secuencia a la vez. La decisión no es in-house versus outsourcing. Es in-house y después outsourcing, o outsourcing y después in-house, con el orden definido por lo que la empresa de hecho necesita en cada estadio.

FAQ

¿Cuál es la diferencia entre outsourcing y desarrollo de software in-house?

Outsourcing de desarrollo de software significa contratar a un partner externo (una software house, un freelancer, o una agencia) para construir el software por ti bajo un alcance y presupuesto definidos. Desarrollo de software in-house significa contratar ingenieros como empleados full-time de tu empresa, que son dueños del codebase y reportan a tu cadena de gestión. La diferencia no es solo dónde se sientan los ingenieros; es a qué te comprometes financiera, organizacional, y operativamente.

¿Cuáles son las desventajas del desarrollo de software in-house?

Riesgo de hiring, overhead de gestión, compromisos de payroll que no se desarman rápido, y el tiempo del founder corriendo una función de ingeniería en lugar de correr el negocio. Para un founder no técnico pre-PMF, el costo de gestión solo suele ser el mayor renglón oculto.

¿Cuáles son las desventajas del outsourcing de desarrollo de software?

Menos control directo sobre prioridades del día a día, overhead de comunicación con un equipo que no vive en tu empresa, y el riesgo de largo plazo de heredar código que no puedes mantener si el partner se vuelve poco confiable. El partner correcto mitiga los tres. El partner equivocado los amplifica.

¿Cuándo una startup debe contratar ingenieros in-house?

Después de que el product-market fit es real, después de que el founder puede nombrar problemas de ingeniería (no solo features de producto) en la vacante, después de que hay al menos una persona técnicamente creíble en el equipo que puede evaluar candidatos de ingeniería, y cuando el runway cubre un ramp-up de seis meses antes de que el nuevo hire sea net-positive.

¿Cuánto cuesta el outsourcing de desarrollo de software?

Una software house sénior basada en EE.UU. cobra típicamente US$ 20.000 a US$ 40.000 por mes para un equipo embedded de dos a tres ingenieros más un tech lead. Las agencias offshore van de US$ 25 a US$ 50 por hora, ubicando a un equipo pequeño en US$ 40.000 a US$ 80.000 por trimestre, con calidad más variable y más tiempo de revisión del founder. El artículo sobre cuánto cuesta desarrollar una app cubre los seis drivers que más mueven el número.