SafePay: how we built escrow for software projects

Escrow has existed for decades — real estate, international trade, generic freelance platforms. The problem is that almost all of those models were designed for binary transactions: money gets held, the good or service gets delivered, payment gets released. Software doesn't work that way, and using generic escrow for a development project leaves gaps exactly where they matter most.

Why traditional escrow isn't enough

A software project doesn't get delivered once at the end: it gets built in stages, with decisions that adjust along the way. If escrow only has two states — locked or released — there's no way to protect either party in between. The company doesn't want to release the full payment until it sees real progress. The squad doesn't want to work for weeks with no guarantee of partial payment. Binary escrow forces a choice between those two risks; it doesn't solve either one.

“Delivered” is also ambiguous in software if it wasn't defined up front. An endpoint that returns 200 but has no tests? A feature that works in development but was never tested in production? Without explicit criteria, the word “done” becomes a point of dispute — and payment disputes are what slows a project's momentum the most.

The model we use: milestones with explicit criteria

SafePay locks the project's funds before work starts and releases them per delivered milestone, not all at once at the end. Each milestone gets defined with clear criteria at the moment the scope is signed — what will be delivered, how completeness gets validated — so neither party discovers later, mid-project, that they had a different idea of what “done” meant.

• Funds get locked before the first commit, not after work has already started.
• Every milestone has acceptance criteria defined when the scope is signed, not improvised at the end.
• The company reviews the delivery, requests adjustments if needed, and only then approves — payment gets released after that validation, not before.
• The squad gets paid for work already delivered and validated, without depending on the full project closing to see the first payment.

What happens when something goes wrong

No system eliminates the risk of a project running into trouble. What changes is how it gets resolved when it does. If a squad doesn't deliver, that milestone's funds stay held — they don't get lost, they don't get released anyway — and the disagreement gets resolved with the available evidence: the signed scope, the agreed criteria, and the progress history. The milestone structure exists precisely so a problem stays contained to that stage, without contaminating the whole project.

Why this matters more in software than in other industries

In most transactions where escrow gets used, the good is tangible and verifiable at a glance: a property, goods arriving in a container. In software, verifying that something is “done” requires explicit technical criteria and, in many cases, reviewing the code itself. Building SafePay specifically for software development — instead of adapting a generic escrow — is what lets that validation be part of the system, not a manual step someone has to invent every time.

The underlying goal is simple: neither party should have to trust blindly. The company sees real progress before approving each stage. The squad has a payment guarantee for what it already delivered. Neither depends on the other's goodwill for the project to move forward.