It happens more often than the industry admits. A development agency closes its doors. A freelancer stops responding. A vendor pivots to a different market and sunsets client relationships. When it happens to you, the outcome depends almost entirely on decisions you made before you hired them — specifically, how you structured the contract and how you managed access to your own code throughout the engagement.

This is not a hypothetical. Roughly 20% of software agencies do not survive their fifth year. Freelance developers go dark at a higher rate. If you have invested meaningful money in custom software, the question is not whether to protect yourself from this risk — it is how.

The access problem: who holds the keys

In a poorly structured engagement, the vendor controls the code repository, the deployment infrastructure, the domain credentials, the API keys, and the documentation. If that vendor disappears, you have a product in production that you cannot modify, redeploy, or hand to someone else. The most important question to ask any development partner before you sign: "From day one, will I have direct access to the source code repository?"

Reputable development firms using services like GitHub, GitLab, or Bitbucket can give you repository access trivially — you are added as an owner or co-owner of your own repo from the first commit. If a vendor cannot or will not do this, that is a significant red flag. See red flags when hiring an app development agency for this and the other signs that predict a difficult relationship.

Source code escrow: the nuclear option worth considering

For critical systems — software that your business operations depend on — source code escrow is worth the cost. In an escrow arrangement, a neutral third party (EscrowTech, Iron Mountain, NCC Group) holds a copy of your source code and releases it to you automatically if the vendor fails to fulfill defined conditions — typically: bankruptcy, dissolution, or material breach. The fee is modest relative to the risk it hedges. This is standard practice in enterprise software contracts and underused in the mid-market.

IP assignment in the contract: the legal foundation

Without explicit IP assignment language, your vendor likely owns the code they wrote for you as a matter of copyright law — even if you paid for it. This default is counterintuitive but legally standard in most jurisdictions. Your software development contract must explicitly state that IP transfers to you upon full payment, including source code, documentation, and any open-source components or licenses used in the build. A "perpetual license" is not the same as ownership — it can be revoked if the relationship deteriorates or the vendor ceases to exist.

Continuity documentation: what you need to run without them

Even with code access and legal ownership, you cannot run a software system you cannot understand. Continuity documentation includes: a system architecture diagram, a runbook for common operational tasks, environment variables and their purpose, third-party service dependencies and their renewal dates, and a deployment guide sufficient for a competent developer to take over. This documentation should be part of every milestone delivery, not an afterthought at project close.

What to do if your developer has already gone dark

If you are already in this situation: first, document everything you have access to — credentials, code, backups. Second, engage a technical consultant to audit the codebase and assess what you actually own. Third, review your contract for IP provisions and breach remedies. Fourth, if you have production dependencies on infrastructure the vendor controls (hosting, email, payments), prioritize migrating those first — your business continuity depends on it, not the code.

How TTGC builds continuity by default

Through The Glass Creatives structures every engagement so that a client could walk away tomorrow with a fully functional, fully documented, fully owned system. Code lives in client-owned repositories. Deployment documentation is part of the standard delivery package. IP assigns on final payment without a negotiation. Ravve Jay Prevendido built this structure because he has seen the alternative — and the alternative is a business hostage to a vendor relationship.

You should be able to fire your development partner today and have a new team productive next week. If your current setup does not allow that, you have a business continuity risk, not just a vendor preference.