Escrow for software projects, explained without the jargon

In an ordinary software contract, one side always carries the risk. Pay up front, and the client carries it: if the work never arrives, the money is gone. Pay on completion, and the development team carries it: they can work for months and then wait, or argue, for payment.

Escrow splits that risk. Money for a piece of work is set aside before the work starts, held by a neutral party, and released when the work is accepted. The team knows the money exists. The client knows it will not move until the work does.

That is the whole idea. The details are where it succeeds or fails.

How it works, step by step

1. Milestones are defined. The project is divided into pieces, each with a deliverable, a date and written acceptance criteria.
2. The client funds the milestone. The amount for the next milestone is deposited with the escrow holder before work on it begins.
3. The work is delivered and reviewed. The deliverable is checked against the acceptance criteria that were agreed at the start.
4. Escrow releases. When the criteria are met, the money goes to the development team. Then the next milestone is funded.

If the engagement changes direction — a partner is replaced, or the project stops — the money for milestones that were never accepted has not been paid out, so it is still available.

Escrow is only as good as the acceptance criteria

Escrow does not judge quality. It releases money when the agreed condition is met. If the condition is vague, the protection is vague.

Compare two versions of the same criterion:

• “The checkout works.”
• “A logged-in customer can pay for a basket of up to 50 items by card through the payment provider’s production environment; the order appears in the ERP within five minutes with the correct VAT; a failed payment leaves the basket intact and shows the provider’s error message.”

The first invites an argument. The second can be tested by someone who was not in any of the meetings.

Good acceptance criteria are:

• Observable. Someone can see or measure whether it happened.
• Bounded. They say what is included, so they cannot silently grow.
• Written before the work starts. Criteria written after delivery are a negotiation, not a test.
• Agreed by both sides. The team building it must be able to say “yes, that is what we will deliver” before the milestone is funded.

Milestone size matters more than milestone count

A common mistake is to create lots of tiny milestones to feel safe, or a few huge ones to keep administration low. Neither works well.

Very small milestones turn every week into an acceptance meeting and encourage the team to deliver pieces that cannot be tested on their own. Very large milestones mean months of work sit behind a single decision, which is exactly the concentration of risk escrow was supposed to remove.

A useful rule of thumb: a milestone should produce something a person can use or test end to end, and should take roughly two to six weeks of work. “Customers can register, log in and reset their password” is a good milestone. “Backend 40% complete” is not, because nobody can accept a percentage.

What escrow protects you from

• Paying for work that never arrives.
• A team disappearing mid-project with a large deposit.
• Payment disputes turning into leverage, such as withheld code or credentials.
• Being unable to change partners because all the money has already been spent.

For the development team, escrow protects against the mirror-image problems: a client who stops paying after delivery, or who keeps finding reasons not to accept finished work. That is why good studios are generally comfortable with it.

What escrow does not protect you from

• A bad scope. If the scope describes the wrong product, escrow will faithfully release money for the wrong product.
• Weak acceptance criteria. See above. The protection lives in the wording.
• Hidden quality problems. A feature can pass its acceptance test and still be badly built. Code review, test coverage and technical oversight are separate safeguards.
• Delays. Escrow keeps money safe while a milestone runs late; it does not make it run on time.

Practical questions to settle before you sign

• Who holds the funds, and under what terms can they release them?
• What happens if client and team disagree about acceptance — who decides, and within what time?
• What happens to funds for a milestone that was started but not finished?
• In which currency are funds held, and who bears conversion or transfer costs?
• Are the acceptance criteria attached to the contract, or referenced in a separate document?

The answers belong in the signed agreement, not in an email thread.

How we use it

At ANASBRENT every project runs on escrow-backed milestones with acceptance criteria written into the approved scope before a partner quotes. Our delivery manager reviews each milestone against those criteria before it comes to you, so acceptance is a checklist rather than an opinion. Start with a scope and we will show you how your project would be divided.