SafePay: como construímos escrow para projetos de software

O escrow existe há décadas — imóveis, comércio internacional, plataformas de freelance genéricas. O problema é que quase todos esses modelos foram desenhados para transações binárias: o dinheiro fica retido, o bem ou serviço é entregue, o pagamento é liberado. Software não funciona assim, e usar um escrow genérico para um projeto de desenvolvimento deixa brechas exatamente onde mais importam.

Por que o escrow tradicional não é suficiente

Um projeto de software não é entregue de uma vez só no final: é construído em etapas, com decisões que se ajustam ao longo do caminho. Se o escrow tem só dois estados — bloqueado ou liberado — não há como proteger nenhuma das partes no meio do caminho. A empresa não quer liberar todo o pagamento até ver progresso real. O squad não quer trabalhar semanas sem nenhuma garantia de recebimento parcial. Um escrow binário obriga a escolher entre esses dois riscos; não resolve nenhum dos dois.

Além disso, “entregue” é ambíguo em software se não foi definido de antemão o que significa. Um endpoint que responde 200 mas não tem testes? Uma feature que funciona em desenvolvimento mas nunca foi testada em produção? Sem critérios explícitos, a palavra “completo” vira motivo de disputa — e disputas de pagamento são o que mais trava o momentum de um projeto.

O modelo que usamos: milestones com critérios explícitos

O SafePay bloqueia os fundos do projeto antes de o trabalho começar e os libera por milestone entregue, não todos juntos no final. Cada milestone é definido com critérios claros no momento de assinar o escopo — o que será entregue, como se valida que está completo — assim nenhuma das partes descobre depois, no meio do caminho, que tinha uma ideia diferente do que significava “terminado”.

• Os fundos são bloqueados antes do primeiro commit, não depois de o trabalho já ter começado.
• Cada milestone tem critérios de aceitação definidos ao assinar o escopo, não improvisados no final.
• A empresa revisa a entrega, pede ajustes se necessário e só então aprova — o pagamento é liberado depois dessa validação, não antes.
• O squad recebe pelo trabalho já entregue e validado, sem depender do fechamento completo do projeto para ver o primeiro pagamento.

O que acontece quando algo dá errado

Nenhum sistema elimina o risco de um projeto se complicar. O que muda é como isso se resolve quando acontece. Se um squad não entrega, os fundos daquele milestone ficam retidos — não se perdem, não são liberados mesmo assim — e o desacordo se resolve com a evidência disponível: o escopo assinado, os critérios combinados e o histórico de avanço. A estrutura de milestones existe justamente para que um problema fique contido naquela etapa, sem contaminar o projeto inteiro.

Por que isso importa mais em software do que em outras indústrias

Na maioria das transações onde se usa escrow, o bem é tangível e verificável a olho nu: um imóvel, uma mercadoria que chega em um contêiner. Em software, verificar que algo está “terminado” exige critérios técnicos explícitos e, em muitos casos, revisar o próprio código. Construir o SafePay especificamente para desenvolvimento de software — em vez de adaptar um escrow genérico — é o que permite que essa validação seja parte do sistema, não um passo manual que alguém precisa inventar toda vez.

O objetivo de fundo é simples: que nenhuma das partes precise confiar cegamente. A empresa vê progresso real antes de aprovar cada etapa. O squad tem garantia de recebimento pelo que já entregou. Nenhum depende da boa vontade do outro para o projeto avançar.