You hired an agency to build your platform. The code works, the invoices are paid, and then one day the lead engineer is gone, the agency is winding down, and nobody can tell you where the repository lives. This is the exact scenario a custom software escrow arrangement exists to prevent.
Most founders treat escrow as a legal checkbox they sign at the end of a contract and never revisit. That is a mistake. A poorly structured escrow agreement is worse than none at all, because it creates the illusion of protection while leaving you with a zip file you cannot build.
This guide walks through what actually goes into an escrow agreement with a development vendor, what release triggers make sense, how verification works, and where the real cost trade-offs sit.
Key takeaways
- Escrow is not just source code; you need build scripts, dependencies, credentials, infrastructure config, and documentation to actually run the system.
- Release conditions should be objective and verifiable, not vague phrases like "vendor failure" that require litigation to interpret.
- Verification is the step most teams skip, and it is the only way to know your deposit is usable.
- Ongoing escrow is a maintenance commitment, not a one-time deposit; stale code is nearly worthless.
- Escrow protects continuity, not ownership; clarify IP assignment separately in your master agreement.
What a software escrow agreement actually covers
A software escrow agreement is a three-party contract between you (the client or beneficiary), your vendor, and a neutral escrow agent. The vendor deposits defined materials with the agent, and the agent releases them to you only when specific conditions are met.
For off-the-shelf enterprise software, escrow usually means the vendor's compiled binaries and source. For custom software built for you, the calculus is different: you often already own the IP, so escrow is really about access and continuity rather than ownership transfer. That distinction matters when you draft the agreement.
What to deposit
Source code alone is rarely enough to run a production system. A useful deposit typically includes:
- Full source code for all custom components, including the commit history or at least a tagged release snapshot.
- Build and deployment scripts, CI/CD pipeline definitions, and environment variable manifests.
- Third-party dependency lists with pinned versions and license information.
- Database schemas, migration scripts, and seed data.
- Infrastructure-as-code files and cloud provider configuration.
- Architecture documentation, API contracts, and runbooks for common operational tasks.
- Access credentials or a documented process for transferring ownership of cloud accounts, domains, and third-party services.
That last item is where many escrow agreements quietly fail. If your application runs on a vendor-owned cloud account, no amount of source code will let you operate it.
Release conditions for software: what triggers handover
Escrow release conditions are the heart of the agreement. Vague triggers are the most common drafting error. "Vendor insolvency" sounds clear until you are arguing about whether a restructuring counts.
Good triggers are objective, documented, and ideally verifiable by a third party:
- Insolvency or bankruptcy filing by or against the vendor, with a defined cure period.
- Cessation of business or formal wind-down announcement.
- Failure to maintain the software after a defined notice period and missed remediation deadline.
- Material breach of the support or maintenance agreement that remains uncured.
- Abandonment, defined as no substantive commits or support responses for a specified duration.
Notice the pattern: each trigger has a measurable threshold. Avoid triggers that require a court to interpret fault, because by the time you get a ruling, your business has already lost months.
Automatic versus agent-mediated release
Some agreements allow automatic release on a documented event; others require the escrow agent to verify the trigger before releasing. Automatic release is faster but riskier for the vendor, so they will push back. Agent-mediated release is more balanced but adds friction and time.
In practice, a hybrid works well: automatic release for unambiguous events like a bankruptcy filing, and agent-mediated release with a short dispute window for softer triggers like abandonment.
Verification: the step that separates real escrow from theater
An unverified deposit is a promise, not a protection. Verification means someone independently confirms that the deposited materials can actually build and run the software.
There are three common levels:
- Completeness review: the agent checks that all defined items are present. Cheap, fast, and shallow.
- Build verification: a technical reviewer attempts to build the software from the deposit in a clean environment.
- Functional verification: the reviewer builds and runs the software, confirming core functionality works.
Functional verification is the gold standard and the most expensive. For a startup with a single critical platform, it is usually worth it at least once, then downgraded to build verification on subsequent refreshes.
If you want a second opinion on whether your deposit is genuinely complete, the engineers who built the system are the right people to ask. Teams that build custom software with proper handover documentation tend to have far cleaner escrow deposits than teams that treat documentation as an afterthought.
Source code escrow for startups: the cost and effort trade-off
Escrow pricing generally scales with the complexity of the deposit and the frequency of verification. A simple completeness review on an annual refresh costs far less than quarterly functional verification of a large codebase.
The bigger cost is often internal. Every meaningful release changes the deposit, and someone has to manage that refresh cycle. If nobody owns it, the deposit goes stale within a few months.
A pragmatic structure for most startups:
- Deposit at each major release, or on a fixed quarterly cadence, whichever is less frequent.
- Full functional verification once, at the point the system reaches production stability.
- Build verification on subsequent refreshes.
- A named internal owner responsible for the refresh calendar.
If your vendor is a small agency, ask whether they already maintain escrow arrangements with other clients. Mature shops have a repeatable process, which reduces friction significantly. You can see how this plays out in practice by looking at how we structure handovers on client engagements.
What happens to custom software if the vendor closes
This is the question founders actually care about, and the honest answer is: it depends entirely on how well you prepared. If escrow is in place, verified, and current, the transition looks like this:
- The escrow agent confirms the trigger and releases the deposit.
- You receive the code, build artifacts, and documentation package.
- A new team (internal or another agency) reconstructs the build environment.
- Cloud accounts, domains, and third-party service ownership transfer to you.
- You resume development on the released codebase.
Steps three and four are where timelines slip. Even with a perfect deposit, expect a non-trivial ramp-up period. The mitigation is documentation quality, not escrow itself.
If escrow is not in place, your options narrow to negotiating with the insolvency administrator, purchasing assets, or rebuilding. All three are slow and expensive.
Practical clauses to insist on
When you review the agreement, push for these specific terms:
- Defined deposit inventory with an itemized list, not a generic "all source code" phrase.
- Refresh obligations with a stated cadence and a consequence for non-compliance.
- Verification rights allowing you to request verification at your cost.
- Release timelines specifying how quickly the agent acts after a trigger.
- Escrow agent independence, ideally a specialist firm rather than the vendor's own lawyer.
- Termination and transition assistance obligations that survive the contract ending.
Each of these is negotiable. Vendors generally accept them because they cost little to grant and signal professionalism.
Avaton builds custom software for founders and CTOs, and we structure escrow and handover terms as part of the engagement rather than as an afterthought. If you are evaluating a vendor or renegotiating an existing agreement, talk to our team about what a workable deposit looks like for your stack.
Frequently Asked Questions
Do I need a software escrow agreement if I already own the source code?
Yes, in most cases. Ownership and access are different things. You may own the IP while the vendor still holds the repository, build pipeline, cloud accounts, and operational knowledge. An escrow agreement ensures you can actually obtain and run the software if the vendor stops operating, regardless of who holds the copyright.
What are typical escrow release conditions for software?
Common triggers include vendor insolvency or bankruptcy, cessation of business, uncured material breach of support obligations, and abandonment defined as a lack of substantive commits or support responses over a specified period. The best triggers are objective and measurable so they do not require litigation to interpret.
How often should the escrow deposit be updated?
At minimum with each major release, or on a fixed quarterly cadence if releases are frequent. A stale deposit is one of the most common failure modes, because the released code may not match the version running in production. Assign a named owner internally to manage the refresh calendar.
Is escrow verification worth the cost?
For a platform your business depends on, yes. Completeness review is cheap but shallow. Build verification confirms the deposit compiles. Functional verification confirms it runs. Many teams do full functional verification once at production stability, then downgrade to build verification on later refreshes.
What happens to custom software if the vendor closes without escrow?
Your options are limited to negotiating with an insolvency administrator, purchasing assets, or rebuilding from scratch. All three are slow and costly. Without a verified escrow deposit, you may also lack the build scripts, credentials, and documentation needed to operate the system even if you recover the source code.
Cover: Photo by Digital Buggu on Pexels