Nearshore es contratar desarrollo de software a un equipo en un país cercano, con un horario parecido al tuyo; para una empresa de EE. UU., eso suele significar Latinoamérica. Offshore es contratarlo lejos, con muchas horas de diferencia, por ejemplo en India o Filipinas.
Cuando una empresa me pide comparar las dos opciones, casi siempre llega con una hoja de cálculo con un solo número por opción: la tarifa por hora. En esa comparación gana siempre el offshore. Si la tarifa lo dijera todo, nadie contrataría en Bogotá o en Caracas, y tampoco en Austin.
El offshore suele costar menos por hora. El nearshore en Latinoamérica suele costar menos por funcionalidad terminada cuando el trabajo necesita conversar el mismo día, porque Bogotá, Lima, Caracas y Ciudad de México comparten casi toda la jornada de Nueva York y Bangalore no comparte nada. Si el trabajo está bien especificado y nadie necesita discutirlo, decide la tarifa. Si exige criterio, pesa más el horario compartido.
Mi empresa, Softronic, coloca ingenieros latinoamericanos dentro de equipos de clientes, así que léelo sabiendo que tengo un interés. Voy a argumentar con datos que puedes comprobar, y te diré en qué casos el offshore es mejor opción.
Primero, los números que se pueden verificar
Casi todas las tablas de “costo por región” que publican los proveedores son estimaciones sin un método que se pueda rastrear, así que me quedo con cifras de fuente pública.
La Oficina de Estadísticas Laborales de EE. UU. (BLS) sitúa el salario anual mediano de un desarrollador de software en 135.980 dólares a mayo de 2025 (en inglés). Eso es solo el sueldo. Según el informe de costos del empleador por compensación de junio de 2026, de la misma BLS, el sueldo es el 70% de lo que gasta en compensación un empleador privado y los beneficios el 30% restante. Con esa proporción, un desarrollador mediano en EE. UU. le cuesta a su empresa unos 194.000 dólares al año, sin contar reclutamiento, equipo ni el tiempo de quien lo dirige. Es un promedio general aplicado a una ocupación: tómalo como orden de magnitud.
Mis precios están publicados en el sitio. Una colocación senior a jornada completa cuesta entre 6.000 y 8.000 dólares al mes para clientes de EE. UU. e internacionales, es decir, entre 72.000 y 96.000 al año, con la nómina, los impuestos locales y el cumplimiento laboral de mi lado. No es una comparación exacta (una mediana contra un perfil senior), pero da el tamaño de la diferencia.
No voy a publicar salarios por país para India, Polonia o Colombia: los datos públicos que encontré son encuestas autorreportadas con muestras pequeñas o cifras de proveedores interesados en el resultado. Si un proveedor te da una tarifa, pregúntale qué incluye y cuánto te costaría reemplazar a esa persona en el cuarto mes.
Qué cubre la tarifa y qué deja fuera
La diferencia de tarifa existe. El resto de la factura llega después, por donde la tarifa no mira:
| Costo | ¿Está en la tarifa? | Dónde aparece | Cómo medirlo |
|---|---|---|---|
| Sueldo del ingeniero | Sí | En la factura | Compara cotizaciones del mismo nivel de experiencia |
| Nómina, impuestos, cumplimiento laboral | Depende (en mis colocaciones, sí) | Factura o cargo aparte | Pregunta qué cubre el monto mensual |
| Esperas por la diferencia horaria | No | Tickets que tardan días | Cuenta las horas compartidas (tabla más abajo) |
| Retrabajo | No | Tu gente senior revisando y corrigiendo | Registra esas horas durante un mes |
| Rotación | No | Semanas de arranque y contexto perdido | Pregunta cuántas personas ha colocado y por cuánto tiempo |
| Reasignación | No | Tu ingeniero pasa a un cliente que paga más | Pregunta si puede reasignarlo sin tu aprobación |
| Propiedad intelectual | No | Un hueco al levantar capital o vender | Pide la cesión entre ingeniero y proveedor |
La zona horaria decide cuánto tarda una respuesta
De esta parte estoy más seguro, porque es aritmética.
India usa la hora IST, UTC+5:30, y no cambia de horario en verano. Eso deja a Bangalore nueve horas y media por delante de Nueva York en verano y diez y media en invierno. Sigamos un ticket:
- Una gerente de producto en Nueva York escribe un ticket a las 4 de la tarde.
- El ingeniero en Bangalore lo toma a la mañana siguiente, que en Nueva York es más o menos medianoche.
- A mediodía, hora de India, encuentra una ambigüedad y deja una pregunta. Ella está dormida.
- Ella responde a primera hora, cuando él ya terminó su jornada. Él lee la respuesta al empezar su día siguiente.
Esa sola pregunta le costó al ingeniero un día completo. Un ticket con dos o tres dudas puede perder dos o tres días sin que nadie haya sido lento: las dos personas que necesitaban hablar nunca estuvieron despiertas a la vez.
Ahora el mismo ticket con un equipo en Latinoamérica. Bogotá y Lima (UTC-5), Caracas (UTC-4), Ciudad de México (UTC-6 fijo desde que México eliminó el horario de verano en 2022) y Buenos Aires (UTC-3) no cambian la hora en todo el año. Para una empresa de la costa este de EE. UU., casi toda la jornada coincide. La pregunta sale a las 11 de la mañana y la respuesta llega a las 11:20. Europa del Este queda en un punto intermedio: Varsovia deja un par de horas compartidas en la mañana de Nueva York.
La misma aritmética, en una tabla. Nueva York usa EDT (UTC-4) de marzo a noviembre y EST (UTC-5) el resto del año. Las horas compartidas suponen que los dos equipos trabajan de 9 a 5, hora local.
| Ciudad | Huso horario | Frente a Nueva York, mar.–nov. | Frente a Nueva York, nov.–mar. | Horas compartidas, mar.–nov. | Horas compartidas, nov.–mar. |
|---|---|---|---|---|---|
| Bogotá / Lima | UTC-5 | 1 h menos | Misma hora | 7 | 8 |
| Caracas | UTC-4 | Misma hora | 1 h más | 8 | 7 |
| Ciudad de México | UTC-6 | 2 h menos | 1 h menos | 6 | 7 |
| Buenos Aires | UTC-3 | 1 h más | 2 h más | 7 | 6 |
| Varsovia | UTC+1, UTC+2 en verano | 6 h más | 6 h más | 2 | 2 |
| Bangalore | UTC+5:30 | 9,5 h más | 10,5 h más | 0 | 0 |
Europa y EE. UU. cambian la hora en fines de semana distintos, así que durante unas semanas de marzo y alrededor de fines de octubre la diferencia con Varsovia es de cinco horas. Cualquiera puede mover su jornada una o dos horas para ganar coincidencia. Moverla diez no es algo que alguien sostenga mucho tiempo.
Cuánto pesa esto depende del tipo de trabajo. Con tickets bien especificados que una persona termina sin preguntarle nada a nadie, la diferencia horaria cuesta poco. Si tus ingenieros pasan el día decidiendo con producto, depurando fallas en producción o discutiendo arquitectura, cada intercambio que cruza la brecha cuesta un día en vez de unos minutos, y en una empresa de software que está creciendo ese es casi todo el trabajo.
El retrabajo encarece la hora barata
El retrabajo nace más a menudo de un malentendido que de falta de capacidad. Lo he visto desde el lado de quien recibe el código, cuando un cliente me trae un sistema que construyó otra persona: un ingeniero que no puede hacer una pregunta rápida supone algo razonable, construye encima y tres días después descubre que la suposición estaba mal. El arreglo suele caer en tu persona más cara, la que está despierta cuando aparece el error.
Por eso, al comparar cotizaciones, compara cuánto cuesta una funcionalidad terminada, incluidas las horas que tu propia gente senior dedica a revisarla y corregirla. Ese número te va a decir más que cualquier tarifa.
Cada salida reinicia el reloj
Un ingeniero necesita semanas para ser útil en un código que no escribió. Cada vez que alguien se va, vuelves a pagar ese arranque, y el contexto que tenía casi siempre se va con él.
Cuando el margen del proveedor depende de tener a todo el mundo facturando, el ingeniero que crees dedicado a tu empresa puede terminar con un cliente que paga más. Por eso lo primero que le preguntaría a cualquier proveedor es si puede reasignar a tu ingeniero sin tu aprobación: una reasignación te cuesta el mismo arranque que una renuncia. El resto de las preguntas que vale la pena hacer están en mi lista para evaluar un proveedor nearshore, y por qué no publico un porcentaje de retención lo explico en el artículo sobre retención.
Revisa la cadena de propiedad intelectual a tiempo
Si algún día levantas capital o vendes la empresa, alguien va a preguntar si el código es tuyo, y con cualquier equipo remoto el eslabón débil suele ser si cada ingeniero le cedió sus derechos al proveedor. Pide esa cláusula antes del primer commit y que la revise tu abogado (yo no lo soy), no en medio de una auditoría previa a la compra (due diligence); la lista que enlacé arriba recorre la cadena completa.
¿Cuándo conviene el offshore?
Le recomendaría offshore a un cliente en estos casos:
- El trabajo está bien especificado y no necesita conversación el mismo día: etiquetado de datos, migraciones con reglas claras, una lista larga de pruebas por escribir, procesos por lotes.
- Tienes de tu lado a una persona senior que escribe especificaciones detalladas y revisa cada pull request. Pagas su criterio más una ejecución más barata, y puede funcionar bien.
- El equipo se encarga de una parte separada del producto, con una interfaz limpia hacia la tuya, y la despliega y la soporta en su propio horario.
Si tu trabajo se parece más a la otra lista (decisiones de criterio, incidentes en producción, idas y vueltas constantes con producto), lo que estás comprando es horario compartido, y eso vale más que la diferencia de tarifa.
El primer número que conviene reunir
Antes de comparar cotizaciones, pasa un mes registrando cuántas horas dedica tu gente senior a revisar, aclarar y corregir trabajo que viene de fuera del equipo. Al lado de la tabla de horas compartidas, la diferencia de tarifa se verá distinta, para un lado o para el otro. Si la respuesta apunta a Latinoamérica, así es como coloco ingenieros.
Actualizado el 23 de septiembre de 2026: reescrito, y se retiraron cifras que no podía respaldar.