Escrow of development artefacts: stages and deadlines
Escrow of development artefacts protects the party that pays for software, data or design work if the developer cannot deliver, disappears, or disputes ownership later. The artefacts — source code, build scripts, data models, design files — sit with a neutral holder until agreed conditions are met. The process has five stages, each with its own document and its own deadline. Missing one stage does not stop the arrangement; it delays the release.
What changes once escrow is agreed
Before escrow, the client holds a licence or a delivery obligation on paper only. If the developer stops responding, the client has a claim but no artefact to enforce it against. Once escrow starts, a physical or digital copy of the artefact sits outside the developer's control. The client's position shifts from a promise to a mechanism: a defined trigger event releases the material without needing the developer's further cooperation.
This matters most in three situations: the developer is a small team or a sole contractor, the contract covers source code that never gets handed over during normal delivery, and the client depends on the software for a system that cannot be rebuilt quickly if support stops.
Steps to set up escrow
- Client and developer agree the trigger events. Common triggers: non-delivery by an agreed date, insolvency, and prolonged non-response to support requests. Write each trigger as a fact that can be checked, not as an opinion.
- Both sides select the escrow holder. The holder must be independent of both parties and able to store the material securely for the life of the contract.
- Developer prepares the deposit package. This includes source files, build instructions, dependency lists, and any credentials needed to run the build. An incomplete package is the most common cause of delay at release time.
- Holder verifies the deposit. Verification checks that the package builds and matches the delivered product. Some arrangements skip this step to save cost; skipping it means the client only learns the package is unusable at the moment of release.
- Parties sign off on the deposit record. The record lists what was deposited, when, and in what form. Without this record, a dispute over what should have been deposited has no reference point.
- Client monitors the trigger conditions for the life of the contract and notifies the holder promptly if a trigger occurs.
Who decides and how long each stage takes
The escrow holder decides whether a deposit meets the agreed format. The holder does not decide whether a trigger event has occurred — that decision sits with the parties, or with whoever the escrow agreement names as the adjudicator if they disagree. Typical timeframes vary by how much verification the parties chose to include.
| Stage | What happens | Typical timeframe | Who acts |
|---|---|---|---|
| Agreement and holder selection | Trigger events and holder are fixed in writing | 1–3 weeks | Client and developer, jointly |
| Initial deposit | Developer submits the artefact package | Within the delivery schedule agreed in the main contract | Developer |
| Verification | Holder checks the package builds and runs | 1–2 weeks if included | Escrow holder |
| Update deposits | Developer submits new versions as the product changes | Ongoing, per contract schedule | Developer |
| Release on trigger | Holder releases the deposited material to the client | Days to a few weeks, depending on notice requirements | Escrow holder |
Two common situations
If the developer stops responding to support requests but has not formally breached the contract, the client cannot yet demand release — non-response has to reach the threshold defined as a trigger, usually a set number of days without reply. Open source is found in the delivery technology contract raises a related complication: if the deposited package turns out to contain unlicensed open-source components, release does not solve the underlying licensing problem, and the client inherits it along with the code.
If the client discovers, after release, that the deposit was never verified and does not build, the escrow agreement rarely gives grounds to demand a fresh deposit unless verification was a condition written into the original terms. The deadline that matters in this situation is the one set when the contract was signed, not the one the client would prefer with hindsight.
What this page does not cover
This page describes how escrow is structured and sequenced. It does not establish who owns the underlying intellectual property once released, and it does not resolve a dispute over whether a trigger event has actually occurred — that depends on the wording of the specific agreement. It also does not size the reporting or verification work needed for a particular file. Sample asset report, as delivered overview shows what a completed verification record looks like in practice.
Escrow disputes involving parties in different jurisdictions also raise questions this page does not settle, such as which country's insolvency rules determine when a trigger has occurred. Debtor in Latvia in detail covers what can be established about a counterparty in that jurisdiction specifically.
Verified
Reviewed 2025. This page describes standard commercial escrow practice for software and data artefacts, not a jurisdiction-specific procedure. Where a contract sets stricter or different steps, the contract governs.
Related reading
Cross-border team ownership review ownership of results covers the related question of confirming who owns the artefact before it is even deposited.
Frequently asked questions
How long does escrow of development artefacts take in practice?
Setting up the agreement and holder typically takes one to three weeks. Deposits then follow the delivery schedule already agreed in the main contract. Release, once a trigger occurs, takes days to a few weeks depending on the notice period written into the escrow agreement.
Which documents are needed to start?
The escrow agreement itself, a description of the deposit format, and a list of trigger events. The developer also needs build instructions and dependency lists ready for the first deposit, not just the source files.
What happens if the other side does not respond?
Non-response only matters if it is written into the agreement as a trigger, usually defined as a fixed number of days without reply after a formal notice. Without that clause, silence alone does not release the deposit.