¿Qué es el pago por hitos en desarrollo de software? (y por qué protege más que pagar todo por adelantado o al final)

El pago por hitos (milestone-based payment) es un modelo de pago donde el dinero de un proyecto de software no se transfiere completo por adelantado ni se espera hasta la entrega final: se divide en partes ligadas a hitos concretos, y cada parte se libera recién cuando ese hito se cumple y se verifica. Existe para que ninguna de las dos partes cargue sola con el riesgo — la empresa no paga por trabajo que todavía no existe, y el equipo no entrega semanas de trabajo sin ninguna garantía de cobro.

Es el modelo que usa la mayoría de los proyectos remotos entre partes que recién empiezan a trabajar juntas, y la razón de fondo por la que existe el escrow de software: alguien retiene el dinero hasta que el hito se cumple, en vez de que quede a criterio de una sola parte decidir cuándo pagar o cuándo dar por terminado el trabajo.

¿Cómo funciona el pago por hitos en la práctica?

El mecanismo tiene tres piezas que se acuerdan antes de que arranque el proyecto, no sobre la marcha. Primero, se definen los hitos: puntos de entrega concretos y verificables —una feature funcionando, un módulo integrado, una versión desplegada—, no fechas de calendario ni un porcentaje de tiempo transcurrido. Segundo, se fija el criterio de aceptación de cada uno: qué hay que ver exactamente para darlo por cumplido. Tercero, el dinero de cada hito se bloquea antes de que el equipo empiece a trabajar en él, y se libera recién cuando la entrega se verifica contra ese criterio.

¿En qué se diferencia de pagar todo por adelantado o todo al final?

Los otros dos modelos comunes concentran el riesgo entero de un solo lado.

• Todo por adelantado: la empresa asume todo el riesgo. Si el equipo no entrega, entrega tarde o desaparece a mitad de camino, el dinero ya salió.
• Todo al final (contra entrega o a 30 días): el riesgo se invierte por completo. El equipo trabaja semanas o meses sin ninguna garantía de cobro, y si el cliente discute el alcance recién al final, no hay nada retenido que obligue a resolverlo rápido.
• Pago por hitos: el riesgo se reparte en partes del tamaño de lo que ya se puede verificar. Nadie paga ni trabaja más de lo que corresponde a lo entregado hasta ese punto.

¿Por qué importa repartir el riesgo así?

Porque el riesgo de que algo salga mal en un proyecto de software no es hipotético. Según el CHAOS Report 2020 del Standish Group —la base de datos más grande sobre resultados de proyectos de TI—, solo el 31% de los proyectos termina dentro de alcance, tiempo y presupuesto: el 50% termina "desafiado" (con sobrecosto o recorte de alcance) y el 19% se cancela directamente. Pagar todo por adelantado expone el presupuesto completo a esa estadística. Pagar por hitos limita la exposición a lo que ya se entregó y se verificó, hito por hito — si el proyecto se desvía, lo que está en juego es una porción, no el total.

¿Es una práctica formal o solo un truco de marketplaces?

No es una práctica inventada por marketplaces de talento. El Project Management Institute la formaliza dentro de su Practice Standard for Earned Value Management bajo el método de "milestone weights": cada hito acordado tiene un valor de presupuesto asignado de antemano, y ese valor recién se considera "ganado" cuando el hito se cumple —no antes, ni de forma proporcional al tiempo que pasó—. Y ya es infraestructura estándar en la contratación remota: Deel, una de las plataformas más grandes de nómina y contratos para equipos globales, incluye el pago por milestones como uno de sus tres tipos de contrato estándar para 2026, junto con tarifa fija y pago por uso.

¿Qué pasa si un hito no se cumple?

Ahí es donde el escrow hace el trabajo real: el dinero retenido para ese hito no se libera hasta que la entrega se verifica, así que ninguna de las partes puede forzar el pago —ni el trabajo— sin cumplir la suya. Si el equipo no puede terminar, lo que queda expuesto es la porción de ese hito puntual, no el proyecto completo, y el resto del presupuesto sigue protegido para lo que falta.

¿Cómo lo implementa Zenit?

En Zenit ese mecanismo es SafePay: los fondos se bloquean antes del primer commit y se liberan milestone por milestone, no todos juntos al final del proyecto. El criterio de aceptación de cada milestone se firma antes de que el squad empiece a trabajar en él —no se negocia después de que el trabajo ya está hecho—, y la reputación de ZenitRank de cada squad se construye sobre ese mismo historial de milestones cumplidos, no sobre reviews autodeclaradas.

Definir bien los hitos, sin embargo, depende de haber entendido el proyecto real antes de arrancar — que es exactamente el trabajo que hace Kaizen antes de armar cualquier match.