Pricing por resultados: por qué el body shop está muriendo

Un CTO en una fintech Series C nos dijo recientemente: “Le pagamos a nuestro vendor de outsourcing $4.2M al año. No sé qué obtuvimos por eso. Sé cuántas horas facturaron. No tengo idea de qué shippeó”.

Eso es el modelo body shop en una frase. Pagas por esfuerzo, no por resultado, y el incentivo del vendor es maximizar horas facturables, no tu negocio. El modelo ha mostrado grietas por una década. En 2026 está muriendo de verdad.

El FutureScape: Worldwide Services 2026 de IDC le pone número a hacia dónde va esto: para 2029, impulsado por IA agéntica, 30% de todos los contratos con proveedores de servicios serán basados en resultados. A medida que la automatización se expande, el valor se mueve del esfuerzo al impacto. El body shop no se fue —la mayoría de los contratos siguen cotizándose por esfuerzo— pero tiene el reloj corriendo, y los compradores se están dando cuenta.

Esto es lo que está cambiando, qué significa realmente outcome-based, y cómo estructurar un contrato que no te dejen seco.

Qué significa realmente “body shop”

El modelo body shop: compras horas de labor de ingeniería a un precio por unidad (digamos $50-$120/hora offshore, $150-$300/hora onshore), y el vendor te factura mensualmente en base a horas trabajadas.

Los problemas estructurales:

1. Misalineamiento de incentivos. Las ganancias del vendor suben cuando los proyectos toman más. Las tuyas bajan. Cada viernes en la tarde cuando preguntas “¿por qué no está listo esto?”, estás peleando contra la gravedad.
2. Sin skin in the game sobre outcomes. Si el proyecto falla, el vendor igual factura. Si el proyecto tiene éxito y crea $50M de valor, el vendor igual factura lo mismo.
3. Sustitución de esfuerzo por output. El reporte del vendor es “pusimos 800 horas en esto el mes pasado”. Tu reporte al board es “¿qué shippeamos?”. Estos no siempre concuerdan.
4. Padding. Ingenieros junior facturados como mid. Mids facturados como senior. Horas que se acabaron se extienden. Todos en procurement tienen historias.
5. Conocimiento secuestrado. Cuando el vendor se va, el codebase no tiene sentido para tu equipo porque nadie en tu equipo lo estaba manejando.

El modelo body shop funcionaba tolerablemente cuando el software era simple y la labor era el bottleneck. Funciona terriblemente cuando las herramientas IA multiplicaron la productividad senior 2-4x y el bottleneck es juicio de producto, no velocidad de tipeo.

El modelo de pricing y el de engagement son decisiones distintas; staff augmentation vs outsourcing vs HaaS cubre la segunda.

Qué significa realmente outcome-based pricing

El término se tira a la ligera. Las definiciones serias en contratos 2026:

Tipo 1 — Fixed-bid milestone

El vendor entrega el Milestone A en la Fecha X por el Precio Y. Si se pasan de tiempo o presupuesto, es problema de ellos. Si entregan temprano, se quedan el margen.

Esta es la forma más simple de outcome-based. Funciona bien para proyectos bien scoped con criterios de aceptación claros. Se rompe cuando el scope es genuinamente incierto (trabajo de research-heavy, eval suites de IA, cualquier cosa que involucre UX novedoso).

Tipo 2 — Entrega atada a KPI

El vendor entrega un resultado (ej. “la conversión de checkout mejora de 2.1% a 2.8%”) y se le paga solo al alcanzar el KPI. Frecuentemente incluye una fee base más un bonus al hit.

Funciona bien cuando el KPI es medible, atribuible y de ciclo corto. Se rompe cuando el KPI está influenciado por otras 12 cosas (tu marketing, tu equipo de ventas, estacionalidad).

Tipo 3 — Gain-share

El vendor toma una fee menor por adelantado a cambio de un porcentaje del revenue incremental o ahorros que genere el trabajo. Común en trabajo de optimización de costos (cloud bills, license audits) y en algunos engagements de producto.

Funciona bien cuando la ganancia es claramente atribuible y medible. Requiere confianza real y una relación de largo plazo.

Tipo 4 — Outcome-as-a-Service

El vendor toma responsabilidad operacional del outcome (ej. “corremos tu customer support” o “corremos tu security operations”) con una fee mensual fija atada a SLAs definidos. Si el SLA se incumple, la fee se reduce.

Este es el nuevo modelo dominante para seguridad, soporte e infra managed. Funciona bien cuando el outcome es steady-state y continuo.

Cómo leer el forecast honestamente

Vale la pena separar dos cosas, porque los vendors las mezclan constantemente.

Lo que los analistas realmente proyectan. El número de IDC es 30% de los contratos para 2029 —significativo, pero también implica que cerca de siete de cada diez seguirán cotizándose por esfuerzo al final de la década. Quien te diga que el body shop ya murió te está vendiendo algo. La lectura honesta es que el pricing por resultados pasa de exótico a normal, no de normal a universal.

Dónde lo vemos aterrizar primero. En nuestro propio flujo de deals el cambio es desparejo, y sigue qué tan medible es el trabajo más que qué tan grande es el contrato. El delivery de alcance fijo (un producto definido, una migración, una integración) cotiza por resultado con facilidad porque “terminado” es observable. Security operations e infraestructura managed vienen después, porque uptime y tiempo de respuesta ya están instrumentados. La categoría que más se resiste es el trabajo de discovery abierto, donde ninguna de las dos partes puede definir el entregable al firmar —y ahí es exactamente donde la facturación por hora conserva su lugar legítimo.

La categoría rezagada es el staff augmentation básico. Donde el comprador está rentando capacidad en vez de comprar un resultado, las horas siguen siendo la unidad honesta. Eso no es una falla del modelo; es la señal de que estás comprando otra cosa.

Por qué ahora: la IA cambia la matemática del trabajo

La razón por la que el modelo está muriendo específicamente en 2026: la asistencia con IA comprimió la varianza del input de trabajo.

Si un ingeniero senior con IA puede producir en 3 días lo que antes tomaba 10, ¿cuánto vale “una hora”? Nadie sabe. El vendor vendiendo horas no quiere saber. El comprador pagando por horas definitivamente quiere saber.

El outcome-based pricing esquiva la pregunta. El vendor dice “entrego la feature X por $Y”, y cómo llegan ahí (5 ingenieros sin IA, 2 con IA, 1 arquitecto más uso agresivo de IA) es problema del vendor, no tuyo.

Por eso cada comprador de outsourcing inteligente en 2026 está pidiendo a los vendors que coticen por outcomes, no por horas. Los vendors que se rehúsan están señalizando que su margen depende de que no preguntes.

Redistribución del riesgo

El framing honesto: el outcome-based pricing transfiere el riesgo del comprador al vendor. A los compradores les encanta. Los vendors se resisten porque ahora se están comiendo riesgo de delivery que antes pasaban hacia el cliente.

Tres cosas que saber antes de negociar:

1. Los vendors cobran más por trabajo outcome-based, y deben hacerlo

Un precio justo outcome-based es aproximadamente 1.3-1.7x el equivalente time-and-materials estimado. El vendor toma el riesgo; les pagas por eso. Si un vendor ofrece outcome-based al mismo precio que T&M, o no entienden el riesgo que están tomando o el scope está tan apretado que es efectivamente T&M con un cap fijo.

2. El contrato es la ingeniería

El vendor que acepta “shippearemos esta feature en Q3” sin un doc de scope detallado es un vendor a punto de discutir contigo en Q3. El contrato tiene que definir:

• Cómo se ve “listo”. Criterios de aceptación, plan de test, barras de performance.
• Qué está en scope y (más importante) qué está fuera.
• Qué pasa cuando el comprador cambia requerimientos. Change orders, reglas de re-pricing.
• Qué pasa cuando el delivery se atrasa. Penalidades, rebates por entrega tardía, remedios de breach de SLA.

Gasta tres semanas negociando el contrato. Te ahorrará seis meses después.

3. Los outcomes necesitan atribución clara

El modelo atado a KPI se rompe si el KPI se mueve por razones no relacionadas al trabajo del vendor. Antes de firmar, escribe el modelo de atribución. “La conversión mejora” es muy vago. “La conversión en el nuevo flow de checkout, medida sobre tráfico ruteado a él, A/B contra el checkout viejo, sobre una ventana mínima de 4 semanas” es claro.

Cómo estructurar un contrato outcome-based favorable al comprador

Una plantilla que hemos visto funcionar en 30+ engagements:

• Retainer base. Cubre costos fijos del engagement (gente en el equipo, acceso a infra, demos semanales). 50-65% del fee total esperado.
• Pagos por milestone. Atados a entregables específicos con criterios de aceptación duros. 25-40% del total.
• Bonus por outcome. Una prima de 10-15% pagada solo al alcanzar un KPI de negocio definido dentro de una ventana definida.

Esto balancea predictibilidad de cash-flow para el vendor (no están apostando la empresa a un solo KPI) con skin-in-the-game sobre outcomes (el bonus es suficientemente significativo para mover comportamiento).

El error que vemos: contratos 100% atados a bonus. Se ven bien en papel. En la práctica el vendor sub-resourcea el engagement porque no puede justificar el costo de un equipo senior por un payout incierto. Obtienes un equipo junior y un KPI no alcanzado.

Cuándo fixed-bid todavía gana (y outcome-based pierde)

Outcome-based no siempre es la respuesta correcta. Casos donde T&M o milestones fixed-bid le ganan:

• R&D genuinamente exploratorio. Cuando nadie sabe cómo se ve el outcome, no puedes ponerle precio. T&M con demos semanales y un kill switch es más honesto.
• Staff augmentation puro donde el comprador maneja. Si tienes un CTO corriendo la arquitectura y solo necesitas manos extra, no necesitas al vendor con riesgo de outcome. Necesitas manos rápidas y baratas.
• Scope que controlas completamente y quieres cambiar semanal. Los contratos outcome-based odian cambios de scope. Si genuinamente no sabes qué quieres, T&M es más flexible (y más caro).

El modelo Softronic

Usamos un híbrido. La mayoría de engagements corren como discovery a precio fijo (una semana), seguido de fase de build a precio fijo (6-14 semanas), seguido de un retainer con bonuses atados a milestones.

Para colocaciones tipo HaaS usamos retainer mensual directo. El “outcome” ahí es “el ingeniero está contribuyendo a tu equipo” — eso se mide en tu sprint output, no en nuestro contrato.

Para builds custom el contrato tiene criterios de aceptación explícitos y un precio fijo después del discovery. Si nos pasamos de tiempo o presupuesto, es nuestro. No facturamos T&M para builds nuevos.

Esto es más caro por proyecto para el comprador en papel que la cotización body-shop más barata. Es casi siempre más barato en total porque shippeamos y paramos, en vez de facturar por siempre.

Cómo detectar un body shop disfrazado

Algunos vendors empezaron a llamar a sus contratos T&M “outcome-based” porque vende. Señales para buscar:

• “Outcome-based” sin criterios de aceptación. Quieren mantener la facturación por hora y la palabra de moda.
• Sin disposición a comprometerse a una fecha de entrega. Outcome-based requiere fecha. Los body shops resisten fechas porque las fechas crean accountability.
• El bonus es simbólico (2-3% del contrato). Eso no es skin in the game. Es marketing copy.
• Quieren T&M para “la primera fase” y outcome-based después. La primera fase es donde el proyecto vive o muere. Quieres outcome-based exactamente ahí.

¿Listo para hablar de pricing?

Cotizamos tu proyecto en términos outcome-based cuando el scope lo soporta. Te decimos cuando no, y ofrecemos alternativas T&M o fixed-bid. No te vamos a cobrar tarifas hourly body-shop para averiguarlo.

Lee más en nuestros servicios. Si estás comparando modelos de contratación, revisa nuestra guía de Hiring as a Service y cómo colocamos ingenieros senior LatAm en 14 días.