If a developer or agency stops trading, the business does not automatically lose its application. The practical outcome depends on ownership terms, repository access, infrastructure control, third-party accounts and how much knowledge was shared before the failure.
The safest response is to prepare while the relationship is healthy. Once a supplier has disappeared or entered insolvency, access and contractual issues can become slower and more expensive.
Separate the code from the running service
A live application may depend on much more than source code:
- cloud and hosting accounts;
- databases and uploaded files;
- domains, DNS and certificates;
- deployment pipelines;
- payment, email, identity and other provider accounts;
- scheduled jobs and integration credentials;
- commercial software licences;
- operational knowledge and documentation.
A code archive cannot recover accounts or rights held by third parties.
Check the legal position
Review the contract, assignment and licence terms. Payment for development does not by itself prove that copyright transferred. Equally, a licence may permit continued use and modification even where the supplier retained ownership.
In an insolvency or ownership dispute, obtain legal advice before assuming that assets can be taken, copied or transferred. Administrators or other office-holders may control supplier assets and contracts.
Secure access without damaging evidence
If the developer has stopped responding:
- preserve the running service and current backups;
- record existing accounts, administrators and billing contacts;
- make protected copies of available repositories and configuration;
- avoid uncontrolled production changes;
- contact hosting and platform providers through formal account-recovery routes;
- identify contractual notices and insolvency contacts;
- appoint a technical team to assess continuity.
Assess what has actually been recovered
| Recovered item | Question |
|---|---|
| Source files | Are they complete, current and linked to the production release? |
| Repository | Does it contain history, branches, tags and build material? |
| Database backup | Can it be restored and reconciled with uploaded files and external services? |
| Hosting access | Does the business control the account, billing and administrative recovery? |
| Credentials | Can they be rotated without breaking integrations or scheduled work? |
| Documentation | Can another team deploy, diagnose and support the system? |
Expect hidden dependencies
A new supplier may discover that:
- the production code differs from the repository;
- deployments were performed manually from a personal computer;
- licences were purchased in the old supplier's name;
- critical services share an account with other customers;
- secrets exist only in the former developer's records;
- backups were never tested;
- important business rules were not documented.
Allow for an evidence-led discovery phase before committing to normal development estimates.
Choose between stabilisation and replacement
The first objective is usually continuity, not improvement. Stabilise security, backups, monitoring and critical journeys. Then decide whether the system is maintainable.
A controlled rebuild may be safer when the recovered material is incomplete, unsupported or impossible to deploy. Do not rebuild automatically: data migration and business-rule discovery can create more risk than continuing a difficult but recoverable system.
Reduce the risk in advance
- Use a business-controlled repository or protected administrative access.
- Hold critical cloud, domain and provider accounts appropriately.
- Require regular code and documentation updates.
- Maintain tested backups and data exports.
- Record component licences and renewal ownership.
- Test that another authorised person can build and deploy the system.
- Consider escrow where a proprietary supplier controls a critical product and direct access is not available.
Run a supplier-failure exercise
Run a “supplier unavailable tomorrow” exercise. Ask the business and technical teams to locate the current code, production account, database backup, deployment method and integration inventory. Any item that depends on contacting one individual becomes a continuity action.