Do You Need Source Code Escrow for Custom Software?

You paid a developer to build something for your shop. Scheduling, maybe a quote tool, maybe the whole office stack. It works. Then one night you think: what happens if this guy stops answering the phone?

That's usually when an owner starts reading about source code escrow for custom software. Somebody mentioned it, or a lawyer did, and it sounds like the responsible thing to ask for. A third party holds a copy of the code. If the developer goes dark, you get the copy.

It's a real protection against a real problem. It's also a workaround for a setup you probably shouldn't have agreed to in the first place.

By the end of this page you'll know whether to ask your vendor for escrow or ask for something better.

What owners really fear is losing business continuity

Nobody asks about escrow because they're curious about contract law. They ask because they've pictured a specific bad morning.

The dispatch screen won't load. You call the developer. It rings out. You text. Nothing. Your crew is sitting in the lot waiting on their first job and you're scrolling back through old emails looking for anything that smells like a server login.

Or the softer version: the developer answers, but now the price went up, or the work takes six weeks, or he's got a new full-time gig and your shop is a side project he'd rather drop. You want to hire someone else. You can't, because he's the only one who can get to the code.

That's the fear. Business continuity is just the formal name for it. Your office runs on a system, one person controls that system, and your ability to take calls and send invoices next Tuesday depends on whether that person feels like picking up.

A software vendor who wants to keep the code in their own account is asking you to carry that risk. Escrow is one way to cover it, by parking a copy with a neutral third party. There are better ones.

What a source code escrow agreement actually does

Three parties sign a contract. Your developer, you, and a neutral company that holds things in trust.

The developer is the depositor. They send a copy of the code to the third party, usually a specialist escrow firm, sometimes a law firm, and they're supposed to send an updated copy every time the software changes. You're the beneficiary. You don't get the code. You get a promise that it's sitting somewhere safe and that it comes to you if something specific happens.

That something is called a release event, and it's spelled out in the escrow agreement. Common ones: the developer goes out of business, files for bankruptcy, stops providing maintenance and support for the software, or breaches the contract. When a release event is triggered, the third party hands you the code and you can take it to another developer.

Two details matter more than people expect. The first is verification — whether anyone actually checked that the deposit builds into working software, or whether it's a zip file nobody opened. A deposit that's two years stale and missing the database setup is not a backup. The second is what the agreement says about intellectual property. Getting the code is separate from getting the legal right to modify it and run it. A good source code escrow deal grants both. A sloppy one hands you a folder you're not licensed to use.

All of that costs money every year, and the developer still owns the system.

Custom software and SaaS aren't the same problem

Pay a monthly fee for something like Jobber or Housecall Pro and you're a licensee of a product thousands of other shops use. The code lives on their servers, tied to their infrastructure and their staff. A copy of it wouldn't do you much good; you'd have no way to run it. With SaaS, the thing worth protecting is your data. Can you export customers, job history, quotes and invoices in a format another system can read? Ask that before you sign, not after.

Custom software is a different animal. Someone built it around your pricing, your dispatch rules, the way your office actually books work. No other company needs it, so no other company is keeping a copy alive. If your developer stops answering email and you don't have the code, that system is finished.

That's why source code escrow comes up in custom software work and almost never in subscriptions. The question for a cloud product is how you get your records out. The question for custom code is who holds it, and in whose name.

We put the repo in your name, not with a third party

The repo sits in a GitHub account in your name. You set it up, you're the owner on it, and we work inside it. That's the whole arrangement.

There's no copy held somewhere waiting for a trigger event, because the code was never ours to hold. A source code escrow is a way to get you something you don't have. You already have it. On day one, before a single line is written, the account exists and you control who has access to it.

What that means in practice: if you decide tomorrow to hire a different developer, you add them to your repo and remove us. Nothing has to be requested, verified or released. No lawyer reads a clause to decide whether we've genuinely gone out of business. You just change who has the keys.

It also changes what maintenance and support actually mean. We keep working on the system because the work is good and the relationship works, not because we're the only ones who can open the file cabinet. That's a healthier footing for both sides. An owner who can leave and doesn't is telling you something real.

Ask any software vendor to show you where the code lives. Ask for the repository itself, and for whose account holds it. A screenshot of the app tells you nothing. If the answer is "our GitHub, under our organization," then escrow is the patch for that. It's a reasonable patch. It's also a patch for a problem that didn't need to exist.

One practical note: owning the account means you're the one who keeps billing current on it and keeps two-factor set up on your own login. Small housekeeping. Put the login in your password manager with the bank and the insurance, not in a sticky note in the truck.

The Make It Rain rebuild: four client-owned repos

Right now we're building the Make It Rain rebuild across four separate repositories. All four sit in the client's own GitHub account. We work in them as developers. The client holds the keys.

Four repos instead of one because the pieces do different jobs and get updated on different schedules. That's a normal way to structure a build of any size. What matters for the owner is that every one of those repos lives under a login they control. If they decided tomorrow to bring in a different shop, they'd remove our access and send the new developer an invite. No letter to an escrow agent, no release conditions, no waiting period.

That's business continuity in the plain sense of the phrase: the work keeps going even if the people change.

It also changes how we behave. We know the client can walk. So the code gets commented, the setup steps get written down, and nothing important lives only in one developer's head. A vendor who holds your repo has no pressure to document anything. A vendor who's a guest in your account has every reason to leave the place tidy.

When a vendor keeps the code, read the release events

Some vendors won't hand over the repo. They've built a platform, they serve a hundred shops off the same codebase, and your custom pieces sit inside something they can't give away. That's a real constraint, not always a trick. If that's the deal in front of you and you want the deal anyway, an escrow agreement is the right thing to ask for.

Here's the honest framing. Escrow is a fallback for a structure that already tipped against you. The software vendor holds the keys, and you're buying a promise that a third party will hand you a copy if certain things happen: the vendor shuts down, files for insolvency, stops supporting the product, breaches the contract. You're paying for protection against a risk the arrangement created.

So if you go that route, read the release conditions closely. "Ceases to do business" is narrow. A vendor who stays technically alive while ignoring your emails may not trigger anything. Ask how often the code gets deposited, because a copy from two years ago is a museum piece. Ask whether the deposit includes the build instructions, the database structure and the third-party keys, or just the source files. Code with no setup notes is a pile of text another developer has to reverse-engineer on your dime.

And ask yourself whether you'd rather spend that legal budget on a vendor who just puts the repo in your name.

The one sentence to say to any software vendor

Here's the line. Use it on the first call, before you talk price:

> "I want the repo in an account in my name, and I want to be an owner on it, not a collaborator."

That sentence does two jobs. It tells you where the code will live, and it tells you what your access level is. Those are different things, and the second one trips people up. A collaborator can read and write code in someone else's repository. An owner controls the account, the billing, the permissions, and who gets removed. Collaborator access can be revoked by the person above you. Owner access can't.

Watch what happens after you say it. A vendor who agrees without flinching has probably built this way before. One who explains why it's complicated is telling you the code is going to live in their account.

A quick gut check before you sign anything

Three questions, and you can answer them in about ten minutes.

Whose name is on the account the code lives in? The account itself. The project and the folder both sit inside it. If the answer is the vendor's company, you're renting.

Who has admin rights? Ask to see it. Log in and look at the members or people page. Your name should sit at the top with owner or admin next to it. That's the verification step most owners skip, and it's the one that matters, because a contract can say you own the software while the account settings say otherwise.

Could you hand the code to another developer today? Not after a support ticket, not after a thirty-day notice. Today. If you can add a new developer to the repository yourself and they can clone it, the answer is yes.

Then read what the contract says about intellectual property. You want plain language saying the code and the work product belong to you on delivery. If the words are vague, ask for them to be made specific before you sign, not after.

If you want a second set of eyes on an agreement you've been handed, book a New Project Consultation.

Common questions about source code escrow

What is source code escrow?

It's an arrangement where a third party holds a copy of your software's source code. The developer deposits the code with that third party, and you get access to it only if something specific happens: the developer shuts down, goes bankrupt, or breaks the contract. Until then, the copy sits with the escrow agent and you can't touch it.

What is an escrow agreement for software?

The contract that spells all of that out. It names three parties: the depositor (the developer who puts the code in), the escrow agent who holds it, and the beneficiary (you, the customer who gets it released). The escrow agreement defines the release conditions, how often the depositor has to update the deposit, and what you're allowed to do with the code once it's yours. Most of the arguments happen over those release conditions, because a vendor who's still technically in business can dispute whether the trigger was met.

Do I need one for a small shop's field service app?

Not if you already own the account the code lives in. Escrow exists to cover a gap. No gap, nothing to cover.

Can I ask for escrow and ownership?

You can ask for both. Most owners find that once the repository is in their name with them as an owner, the escrow conversation stops mattering. The code is already in hand.

What if my current vendor says no to both?

That's an answer. Keep working with them if the software does the job, but know that the day you want to move, you're starting over. Plan for that cost now instead of discovering it later.

If you want to talk through what your setup looks like today, book a New Project Consultation.