Source code escrow and owning your code: a founder’s guide

When source code escrow makes sense

Escrow is designed for licensed software: you rely on a product that someone else owns and maintains. A classic case is a business-critical system from a small vendor, where losing the vendor would leave you unable to fix or run the software.

A typical escrow arrangement has three parties (you, the vendor and the escrow agent) and defines:

• What gets deposited: source code, build scripts, dependency lists, documentation, and ideally deployment configuration.
• How often it’s updated: every release, monthly, or quarterly. A deposit from two years ago is of limited use.
• Release conditions: bankruptcy, the vendor ceasing to trade, failure to meet support obligations, and so on.
• Verification: whether the agent checks that the deposit can actually be built. Without verification, you may find out at the worst moment that the deposit is incomplete.
• What you can do with released code: usually maintain and run it for your own use, not resell it.

Escrow is less useful for cloud-hosted SaaS, because the code alone doesn’t give you the running service, the data or the infrastructure. Some escrow providers offer arrangements that cover cloud environments and data too; ask what’s included.

Who owns the source code when an agency builds it?

Don’t assume you do. In many countries, the default is that the person or company who writes code owns the copyright unless a written agreement transfers it. Paying for the work doesn’t automatically make you the owner. Employees are usually treated differently from contractors, but the rules vary, so check locally.

What you want in the contract, in plain terms (and confirmed by a lawyer):

• An assignment of intellectual property to your company for everything built for you, including code, designs and documentation, typically on payment.
• A clear position on pre-existing code. Agencies reuse their own libraries and frameworks. That’s fine, but you should get a perpetual, transferable license to whatever of theirs is in your product.
• Open-source disclosure. A list of open-source dependencies and their licenses, so you don’t discover a license conflict during due diligence.
• Handover obligations: what the vendor must provide when the engagement ends, such as documentation, credentials and a reasonable amount of handover time.

Own the repository, not just the rights

Legal ownership is necessary but not enough. If the only copy of your code lives in the agency’s GitHub organization, you depend on their goodwill to get it. The practical fix is simple and costs nothing:

1. Create the GitHub or GitLab organization under your company’s account, with you (or a cofounder) as owner.
2. Invite the agency’s developers as members, with the least access they need. They push to your repository, not theirs.
3. Own the cloud accounts too: hosting, database, DNS, domain registrar, email provider, app store accounts, payment provider. Invite the vendor in; don’t let them create accounts for you under their own email.
4. Keep secrets in a manager you control, not in the agency’s password vault or in a shared document.
5. Make sure CI/CD and deploys run from your accounts, so you can deploy without them.

Avoiding software vendor lock-in

Software vendor lock-in with an agency rarely comes from the contract. It comes from knowledge and access that only the agency has. Warning signs:

• Only the agency can deploy, and nobody on your side has ever done it.
• There’s no documentation for setting up the project locally.
• The agency uses an in-house framework or platform nobody else knows.
• Infrastructure was configured by hand in a console, with no code or notes.
• You don’t know which third-party services the product depends on, or who pays for them.

Ask for a README that lets a new developer run the project locally, infrastructure defined in code where practical, and a short architecture document. Make them deliverables, not favors. If you’re a non-technical founder working with an agency, an independent technical person on your side can check all this; that’s part of how I work with non-technical founders.

How to leave a vendor cleanly

1. Check your position first. Confirm you own the IP, the repository and the accounts. Fix any gaps before you give notice, not after.
2. Get a full inventory: repositories, environments, third-party services, credentials, scheduled jobs, DNS records, certificates.
3. Agree a handover period with documentation and at least one walkthrough session, recorded.
4. Have your new team or a technical advisor do a test deploy while the old vendor is still available to answer questions.
5. Remove the vendor’s access from every system once the handover is complete, and check audit logs for anything unexpected.
6. Then rotate every credential: API keys, database passwords, cloud access, SSH keys, deploy tokens.
7. Get an independent review of the codebase, so you know what you’ve inherited. A code audit tells the new team where the risks are.

Due diligence: why this matters when you raise or sell

Investors and acquirers will ask who owns your code, whether contractors signed IP assignments, and what open-source licenses you depend on. Gaps found then are expensive to fix, because the contractor you need a signature from may be hard to reach years later. Sorting it out at the start of every engagement is far cheaper. If you’re heading into a raise or sale, see the technical due diligence checklist.

If the relationship has already gone wrong

If the agency is unresponsive, holding code back, or the project has stalled and you need to take it elsewhere, start by securing what you can: accounts you own, the latest code, and your data. Then get a lawyer’s view of your contract and a technical view of what you have. This is a common starting point for software project rescue work: stabilizing access first, then working out whether the existing code is worth continuing.

Related

• Building without a technical cofounder
• Software project rescue for late, stalled and inherited projects
• A code audit that tells you what you’ve actually got
• Staff augmentation vs outsourcing: which model fits your team?
• A technical due diligence checklist, with what “red” looks like