Outsourcing dev vs nearshore vs in-house: framework de decisión para founders y gerentes

Una scale-up regional de logística con 90 personas y proyección de duplicar el negocio en 18 meses estuvo dos años construyendo su core de software con una fábrica de software internacional contratada bajo fixed-price. El número en el contrato se veía bien: $28 USD por hora promedio (rangos típicos de outsourcing offshore documentados por Crunchbase News y reportes de mercado IT de LinkedIn Economic Graph). El número real, dos años después, no se parecía a la propuesta original. Tres reescrituras completas del módulo de ruteo por errores de especificación, seis meses de retraso en el lanzamiento del producto B2B, propiedad intelectual del modelo predictivo en zona gris contractual y un equipo del cliente que pasó el 35% de su tiempo gestionando al proveedor en lugar de definir producto. Cuando el COO calculó el costo total cargado del proyecto, la cifra era equivalente a haber montado un equipo nearshore LATAM de doce desarrolladores en planilla por el mismo período, con código propio, conocimiento del dominio retenido y velocidad de iteración el triple de alta.

La decisión sobre el modelo de delivery tech no es una pregunta de precio por hora, es una pregunta de arquitectura operacional. Tres opciones reales conviven hoy en el mercado, más una cuarta familia de combinaciones: outsourcing tradicional offshore (fábrica de software internacional con entrega de proyecto cerrado), nearshore LATAM (talento en Argentina, Colombia, México, Perú, Chile con time zone compartido y modalidades flexibles), in-house propio (equipo permanente FTE en planilla) e híbridos inteligentes que combinan dos o tres modelos según el rol y la criticidad. Cada uno resuelve un problema distinto. Aplicar el modelo equivocado para la etapa de la compañía cuesta entre dos y cinco veces más que aplicar el correcto, y la cuenta no se ve en la línea del fee facturado sino en el costo de oportunidad de roadmap atrasado, retrabajo no facturado y propiedad intelectual perdida.

Este reporte entrega un marco de decisión estructurado para founders, CTOs, VPs of Engineering, COOs y CFOs. Sin venta, sin tonos comerciales y sin nombrar competidores reales. Comparativa de los tres modelos en ocho dimensiones, ejemplos de costo total (TCO) numéricos por escenario, árbol de decisión paso a paso, errores típicos al elegir mal, casos por etapa (Seed, Serie B y corporativo digital) y FAQ de 10 preguntas largas. Tres mil seiscientas palabras escritas con la única regla de recomendar lo que aplica al lector, no lo que vende el autor.

1. Qué es outsourcing tradicional offshore y cómo opera

Outsourcing tradicional offshore consiste en contratar a una compañía proveedora de software localizada en una geografía distante al cliente (típicamente India, Filipinas, Vietnam, Bangladesh, Polonia, Rumania o Ucrania, según la ola histórica) para entregar un proyecto o producto bajo un alcance contractual definido. El modelo nació en los años noventa como respuesta al diferencial salarial entre desarrolladores en Estados Unidos y Europa Occidental versus mercados emergentes, y operó dos décadas bajo la promesa central de "el mismo trabajo, una fracción del precio". Esa promesa fue real para ciertos escenarios. Fue catastrófica para otros.

El cliente típico de outsourcing offshore tradicional es una empresa que tiene un proyecto con scope congelado: documentación técnica detallada, requerimientos funcionales acordados antes de codificar, criterios de aceptación claros y baja expectativa de iteración. El proveedor opera con un Project Manager de cliente que coordina con un Delivery Manager del proveedor en time zone opuesto, comunicación asíncrona principalmente por correo y reportes semanales, y entregas por hitos contractuales. El equipo del proveedor es típicamente piramidal: pocos Senior, muchos Junior y un margen alto sobre la diferencia salarial.

Estructura comercial típica

El outsourcing offshore tradicional se contrata a través de un contrato marco (Master Service Agreement) más Statement of Work (SOW) específicos por proyecto. Los SOW incluyen: alcance funcional detallado, hitos de entrega con fechas, criterios de aceptación, equipo asignado (rol y cantidad por seniority), tarifa por hora o precio cerrado por hito y cláusulas de cambio de alcance (Change Request). La duración típica de un SOW es de 6 a 24 meses. Los proyectos más allá de 24 meses normalmente se reestructuran como contratos de operación continua.

Modalidades: fixed-price vs T&M

Dos modelos de facturación dominan el outsourcing offshore. Fixed-price: el proveedor cobra un precio cerrado por el proyecto definido en el SOW. Aparenta ser seguro para el cliente porque el costo está acotado, pero traslada al proveedor todo el riesgo de scope, lo que incentiva a sobre-cotizar al inicio y a defender el SOW literal cuando el cliente pide cambios. El resultado típico es un Change Request por cada feature no documentada en el SOW original, con costos adicionales que pueden duplicar el precio original. Time and Materials (T&M): el proveedor factura horas efectivas trabajadas a tarifa acordada. Más flexible para iteración, pero el cliente asume el riesgo de costo y necesita capacidad de gerencia técnica para evitar que las horas se descontrolen. El error más común es contratar fixed-price para un producto en construcción que requiere iteración; el segundo más común es contratar T&M sin tener gerencia técnica capaz de auditar el tiempo facturado.

2. Qué es nearshore LATAM y por qué creció post-2020

Nearshore LATAM es el modelo de contratación de talento tech localizado en Argentina, Colombia, México, Perú, Chile, Uruguay, Brasil o Costa Rica para clientes en Estados Unidos, Canadá o el resto de Latinoamérica. La proposición de valor central no es costo absoluto (LATAM es más caro por hora que India o Filipinas) sino velocidad efectiva de delivery: time zone compartido, idioma nativo o casi nativo en español e inglés, cultura compartida con clientes hispanos y fricción cultural mínima con clientes anglo (la expansión de nearshore LATAM post-2020 está documentada en First Round Review y a16z portfolio resources).

El nearshore LATAM creció aceleradamente entre 2020 y 2025 por tres factores convergentes. Primero, la pandemia normalizó el trabajo remoto y eliminó el último argumento operativo a favor del in-house puro. Segundo, el diferencial cambiario favoreció a Latinoamérica frente a Europa Oriental y a India en términos de relación calidad-precio percibida por compradores estadounidenses. Tercero, una nueva generación de boutiques tech locales (no nombramos competidores) elevó el estándar de comunicación, gestión y entrega, capturando demanda que antes iba por defecto a India o Polonia. Hoy el nearshore LATAM es la opción default para scale-ups norteamericanas y europeas que necesitan equipos ágiles, español como segundo mercado y velocidad de iteración semanal.

Ventajas de time zone y cultura compartida

El time zone compartido entre LATAM y la Costa Este de Estados Unidos (típicamente entre cero y dos horas de diferencia) habilita ceremonias ágiles en horario común: daily stand-ups a las nueve de la mañana, sprint reviews los viernes, retros sincrónicas, pair programming en tiempo real. Frente a un equipo offshore con ocho a doce horas de diferencia, donde el día del cliente termina cuando el del proveedor empieza, el nearshore convierte la jornada en colaboración real en lugar de un ping-pong asíncrono. Cada hora de overlap reduce el lead time desde commit a producción y mejora la calidad de las decisiones técnicas. El idioma compartido amplifica el efecto: discutir trade-offs arquitectónicos en español nativo es muy distinto a discutirlos en inglés como segundo idioma de ambas partes.

Modalidades: staff augmentation, equipo dedicado, BOT

El nearshore LATAM se ofrece bajo tres modalidades operativas. Staff augmentation: el proveedor entrega uno o más desarrolladores que se integran al equipo del cliente, asisten a las ceremonias ágiles del cliente, reportan al Tech Lead del cliente y operan como extensión del equipo interno. Modelo más flexible y económico, ideal cuando el cliente tiene capacidad técnica interna para dirigir el trabajo. Equipo dedicado: el proveedor entrega un equipo cerrado con Tech Lead, Product Owner, devs y QA que opera de forma autónoma sobre un producto o módulo asignado. Modelo más estable, ideal cuando el cliente quiere outsourcing de capacidad sin asumir gerencia técnica. Build-Operate-Transfer (BOT): el proveedor monta un equipo bajo su entidad legal, lo opera durante 12 a 36 meses y luego transfiere los contratos al cliente al final, pagando un fee de transferencia. Modelo útil cuando el cliente quiere terminar con equipo propio pero no quiere asumir el costo inicial de constituir entidad y contratar localmente.

3. Qué es in-house propio y cuándo conviene

In-house propio significa contratar a los desarrolladores directamente en la planilla de la compañía como empleados a tiempo completo. Es el modelo más antiguo, más caro en costo fijo y, simultáneamente, el más estratégico cuando los criterios de decisión son los correctos. Un equipo in-house construye conocimiento profundo del dominio de negocio, retiene propiedad intelectual de forma natural, opera bajo la cultura interna y se vuelve activo de la compañía con valor de mercado en caso de M&A. Falla cuando el volumen de trabajo es bajo o desigual, cuando el mercado local no tiene oferta del perfil requerido o cuando el costo fijo no se justifica frente a la utilización real.

El argumento central a favor de in-house no es el costo. En costo unitario por hora, un Senior in-house chileno y un Senior nearshore facturado terminan dentro del mismo rango. El argumento es el contexto acumulado: un ingeniero in-house con dos años en la compañía conoce el negocio, las decisiones del board, las restricciones del CFO, las expectativas del producto y los compromisos con clientes específicos. Ese contexto es lo que permite escribir código que resuelve el problema real, no la especificación literal. Un proveedor externo, por estructura, nunca acumula ese contexto al mismo nivel.

Estructura de costo cargado

El costo real de un desarrollador in-house en Chile incluye al menos siete componentes. Renta líquida (lo que la persona recibe en su cuenta). Cargas legales (AFP, salud, AFC, mutual, seguro de cesantía, gratificación) que añaden 38% a 45% sobre la renta bruta (rangos consistentes con los reportes de compensación total de Mercer y comparables salariales de Glassdoor). Beneficios opcionales pero estándar de mercado (seguro complementario, aguinaldos, días administrativos, capacitación). Hardware y herramientas (laptop renovada cada dos a tres años, licencias de software, cuentas cloud personales, monitor, equipamiento ergonómico). Espacio físico u oficina, incluso en empresas remotas (algunas mantienen oficina como opción). Costo del proceso de contratación inicial (típicamente $4M a $12M CLP por hire Senior considerando headhunter, tiempo del equipo y bench técnico). Costo de retención durante los primeros 12 meses (riesgo de rotación temprana). La suma supera por amplio margen la renta bruta visible en planilla.

Velocidad real vs percibida

Existe un mito recurrente entre fundadores no técnicos: in-house es más lento que outsourcing porque "hay que contratar". El mito tiene una verdad parcial (el time-to-hire de un Senior tech es de 45 a 90 días en mercado escaso) pero ignora un dato más relevante: una vez que el equipo está formado, in-house entrega más rápido por release que cualquier modelo externo porque tiene contexto, autonomía y ownership. Outsourcing puede arrancar más rápido (un proveedor entrega un equipo en 4 a 8 semanas), pero el tiempo desde arranque hasta velocidad efectiva en producción es mayor por la curva de aprendizaje del dominio. La regla práctica: para horizontes menores a 9 meses, outsourcing o nearshore arrancan antes; para horizontes mayores a 18 meses, in-house llega más lejos.

4. Comparativa 3 modelos en 8 dimensiones

La tabla siguiente sintetiza las diferencias estructurales entre los tres modelos en ocho dimensiones críticas para la decisión. Los valores reflejan el rango típico de mercado en 2026, no garantías contractuales de un proveedor específico. Los acrónimos: PI (propiedad intelectual), TZ (time zone), TTH (time-to-hire), IP/IT (propiedad intelectual).

5. Costo total (TCO) con ejemplos numéricos

El error más caro al elegir modelo de delivery tech es comparar solo la tarifa por hora del proveedor o el sueldo bruto del Senior in-house, ignorando el resto del costo operacional. El costo total real (Total Cost of Ownership) incluye al menos siete componentes: facturación o sueldo cargado del equipo, costo de gerencia técnica del cliente, costo de retrabajo esperado, costo de oportunidad de velocidad perdida, costo de transición entre modelos, costo administrativo del contrato y costo de protección de propiedad intelectual. Los cuatro escenarios siguientes asumen una scale-up regional B2B con necesidad equivalente a un equipo de ocho ingenieros durante doce meses.

Escenario A: outsourcing offshore puro (fixed-price)

Escenario B: nearshore LATAM puro (staff augmentation)

Escenario C: in-house propio

Escenario D: híbrido inteligente (3 in-house core + 5 nearshore)

6. Árbol de decisión paso a paso

El siguiente árbol de decisión sintetiza la lógica de selección en seis preguntas secuenciales. Recorrer las preguntas en orden lleva al modelo correcto en la mayoría de los casos. La regla de oro: si al final del árbol el resultado contradice la intuición del CTO o el founder, vale la pena pausar y revisar antes de firmar contrato.

7. Errores típicos al elegir mal

Después de auditar decisiones de modelo de delivery tech en compañías regionales durante diez años, los cinco errores más caros se repiten con claridad. Tres son errores de optimización equivocada (comparar la métrica incorrecta). Dos son errores de proceso (no negociar las cláusulas correctas).

Error 1: contratar offshore por precio por hora, no por calidad

Una compañía recibe tres propuestas y elige la de menor tarifa horaria ($22 USD vs $52 USD nearshore vs $68 USD in-house equivalente). Al sexto mes, descubre que la velocidad real de delivery del proveedor offshore es la mitad de la nearshore por retrabajo, mala documentación inicial y diferencias culturales. El costo cargado real por feature entregado termina siendo el doble. El precio por hora es la métrica menos predictiva del costo total. Métricas mejores: lead time desde feature aprobado a producción, bugs por release, satisfacción del Product Owner del cliente con el proveedor a los 90 días.

Error 2: subestimar la fricción de time zone

Empresas que firman contratos offshore asumiendo que "el equipo trabaja mientras nosotros dormimos, productividad 24/7". La realidad es opuesta: el time zone de 8 a 12 horas convierte cada decisión técnica en un ciclo de 48 a 72 horas. El cliente envía pregunta el lunes, el proveedor responde el martes, el cliente clarifica el miércoles, el proveedor empieza a trabajar el jueves. Lo que en un equipo con time zone compartido se resuelve en una llamada de 15 minutos, en offshore puede tardar una semana. Cuando la velocidad de iteración importa, ese diferencial es decisivo.

Error 3: firmar fixed-price para producto nuevo

El error estructural más caro del outsourcing tradicional. Un producto nuevo, por definición, no tiene scope congelado: el equipo aprende cada sprint, el mercado responde, el product manager pivotea. Firmar fixed-price para algo que aún no se conoce condena a la relación cliente-proveedor a una guerra de Change Requests donde cada feature adicional cuesta el doble que en el SOW original. Regla práctica: fixed-price solo aplica cuando el cliente puede escribir el SOW con confianza absoluta de que no cambia. Para todo lo demás, T&M o nearshore staff augmentation.

Error 4: no negociar propiedad intelectual en el contrato

Compañías que firman con proveedores extranjeros sin cláusulas explícitas de cesión total de propiedad intelectual, NDA recíproco, no-competencia para personal asignado y derecho de auditoría sobre repositorios. Cuando la compañía intenta levantar capital o se prepara para M&A, los due diligence técnicos revelan que la propiedad del código está en zona gris y los compradores aplican un descuento significativo o exigen reescritura. Costo de reescritura: 30% a 80% del costo original. Negociar IP en el contrato cuesta una conversación de dos horas con un abogado; no negociarla cuesta meses de ingeniería.

Error 5: subestimar el costo de transición de modelos

Empresas que migran de outsourcing offshore a in-house propio asumen que el switch es rápido. La realidad: una transición ordenada demora entre 6 y 12 meses, requiere documentación que probablemente no existe, contratación paralela de Senior internos que toma 4 a 6 meses por perfil, y suele incluir un período de tres a seis meses de operación dual donde se paga tanto al proveedor saliente como al equipo entrante. Saltarse fases produce regresiones de calidad y caída de velocidad por meses. Toda decisión de modelo de delivery debe incluir el costo de salir de ese modelo, no solo el costo de operarlo.

8. Casos por etapa: Seed, Serie B y corporativo digital

El modelo correcto depende fuertemente de la etapa de la compañía. Tres casos prácticos anonimizados ilustran cómo se ve la decisión correcta en cada uno.

Caso Seed: startup B2B SaaS, 8 personas, primer MVP

Compañía recién fundada por dos cofundadores técnicos. Levantaron $400K USD de pre-seed y necesitan llevar el MVP de su producto B2B a primer cliente pagante en seis meses. Equipo actual: dos cofundadores ingenieros, un diseñador medio tiempo, un fundador comercial. Modelo recomendado: nearshore LATAM staff augmentation por seis meses (dos a tres desarrolladores Senior nearshore integrados al equipo de los founders). No abrir FTE: el time-to-hire de Senior chileno (45 a 90 días) consume la mitad del runway. No firmar outsourcing offshore: el producto aún se está descubriendo y la velocidad de iteración semanal es crítica. Presupuesto proyectado: $90M-$120M CLP en seis meses por el equipo nearshore. Velocidad: primer release productivo en ocho semanas.

Caso Serie B: scale-up regional fintech, 110 personas, escalamiento producto

Fintech regional con producto consolidado, Serie B de $14M USD, equipo de 110 personas con 28 ingenieros internos. Plan tech agresivo: lanzar tres productos nuevos en 18 meses cruzando geografías, mantener el legacy, levantar plataforma de datos y un equipo de IA aplicada. Modelo recomendado: híbrido inteligente. Mantener y crecer in-house el equipo de plataforma core (sistemas de pagos, motor de scoring, modelo de fraude) que es el diferenciador competitivo, sumando dos Senior in-house en los próximos seis meses. Sumar un equipo nearshore staff augmentation de seis desarrolladores para acelerar los productos nuevos por 12 meses, integrado a las squads internas. Mantener operación offshore acotada solo para soporte L1 y testing manual de cobertura masiva. TCO total proyectado año dos: ~$1.250M CLP versus ~$1.450M CLP de in-house puro o ~$1.100M CLP de offshore puro pero con velocidad 50% inferior. La decisión correcta no es la más barata; es la que protege el core y acelera el resto.

Caso corporativo digital: banco regional, 6.500 personas, transformación tech

Banco multi-país con 6.500 empleados y 380 personas en tecnología bajo Chief Digital Officer. Programa de transformación digital de tres años con presupuesto de $40M USD. Mix actual: 60% in-house, 40% repartido entre dos consultoras globales tradicionales contratadas a $95 USD/hora promedio. Modelo recomendado: rebalancear hacia 55% in-house (crecer el equipo interno con foco en producto digital), 30% nearshore equipo dedicado (boutiques especializadas en banca digital, $70 USD/hora promedio) y 15% offshore acotado a operación commodity (testing automatizado, mantención de sistemas legacy de planilla y RRHH). Ahorro proyectado año uno: $4.8M USD (~$4.800M CLP) reasignados a contratación de Senior internos y capacidad nearshore. Velocidad de delivery proyectada: 1.6x respecto a baseline anterior. La transformación digital de un corporativo no se resuelve con un solo proveedor ni un solo modelo; se resuelve con arquitectura operacional explícita por capa.

9. Híbridos inteligentes: cuándo combinar 2 o 3 modelos

La realidad de las compañías tech maduras no es elegir un modelo único, sino diseñar un mix de modelos por capa, criticidad y horizonte. El híbrido inteligente reconoce que ningún modelo es óptimo para todo, y construye una arquitectura de delivery explícita donde cada componente del software vive en el modelo que mejor lo soporta. Las cuatro combinaciones siguientes son las más recurrentes en empresas que pasan de Serie A a Serie C entre 2024 y 2026.

La regla de diseño de un híbrido inteligente es simple: cada componente del software debe vivir en el modelo donde tiene menor costo total cargado y mayor alineación con el horizonte de la compañía. El núcleo competitivo va in-house. La velocidad de escalamiento va nearshore. La operación commodity y mantención de bajo riesgo de cambio va offshore. La línea entre las tres se redibuja cada 12 a 18 meses a medida que la compañía evoluciona. Lo que era core en Serie A puede volverse commodity en Serie C; lo que era nearshore satélite puede convertirse en in-house core. El error es no revisar la arquitectura de delivery con la misma cadencia con la que se revisa el roadmap de producto.

10. Preguntas frecuentes sobre outsourcing, nearshore e in-house