SafePay: cómo construimos escrow para proyectos de software

El escrow existe hace décadas —bienes raíces, comercio internacional, plataformas de freelance genéricas—. El problema es que casi todos esos modelos se diseñaron para transacciones binarias: el dinero se retiene, se entrega el bien o servicio, se libera el pago. El software no funciona así, y usar un escrow genérico para un proyecto de desarrollo deja huecos exactamente donde más importan.

Por qué el escrow tradicional no alcanza

Un proyecto de software no se entrega una sola vez al final: se construye en etapas, con decisiones que se ajustan sobre la marcha. Si el escrow solo tiene dos estados —bloqueado o liberado— no hay forma de proteger a ninguna de las dos partes en el medio del camino. La empresa no quiere liberar todo el pago hasta ver progreso real. El squad no quiere trabajar semanas sin ninguna garantía de cobro parcial. Un escrow binario obliga a elegir entre esos dos riesgos; no los resuelve.

Además, “entregado” es ambiguo en software si no se definió de antemano qué significa. ¿Un endpoint que responde 200 pero no tiene tests? ¿Una feature que funciona en desarrollo pero nunca se probó en producción? Sin criterios explícitos, la palabra “completo” se vuelve motivo de disputa — y las disputas de pago son lo que más frena el momentum de un proyecto.

El modelo que usamos: milestones con criterios explícitos

SafePay bloquea los fondos del proyecto antes de que arranque el trabajo y los libera por milestone entregado, no todos juntos al final. Cada milestone se define con criterios claros en el momento de firmar el scope —qué se va a entregar, cómo se valida que está completo— así ninguna de las dos partes descubre después, sobre la marcha, que tenían una idea distinta de lo que significaba “terminado”.

• Los fondos se bloquean antes del primer commit, no después de que el trabajo ya empezó.
• Cada milestone tiene criterios de aceptación definidos al firmar el scope, no improvisados al final.
• La empresa revisa la entrega, pide ajustes si hace falta y recién ahí aprueba — el pago se libera después de esa validación, no antes.
• El squad cobra por el trabajo ya entregado y validado, sin depender del cierre completo del proyecto para ver el primer pago.

Qué pasa cuando algo sale mal

Ningún sistema elimina el riesgo de que un proyecto se complique. Lo que cambia es cómo se resuelve cuando pasa. Si un squad no entrega, los fondos de ese milestone quedan retenidos —no se pierden, no se liberan igual— y el desacuerdo se resuelve con la evidencia disponible: el scope firmado, los criterios acordados y el historial de avance. La estructura de milestones existe justamente para que un problema quede contenido a esa etapa, sin contaminar todo el proyecto.

Por qué esto importa más en software que en otras industrias

En la mayoría de las transacciones donde se usa escrow, el bien es tangible y verificable a simple vista: una propiedad, una mercadería que llega en un contenedor. En software, verificar que algo está “terminado” requiere criterios técnicos explícitos y, en muchos casos, revisar el código mismo. Construir SafePay específicamente para desarrollo de software —en vez de adaptar un escrow genérico— es lo que permite que esa validación sea parte del sistema, no un paso manual que alguien tiene que inventar cada vez.

El objetivo de fondo es simple: que ninguna de las dos partes tenga que confiar a ciegas. La empresa ve avance real antes de aprobar cada etapa. El squad tiene garantía de cobro por lo que ya entregó. Ninguno depende de la buena voluntad del otro para que el proyecto avance.