Do you own your software? A source code and access checklist

Most businesses discover whether they own their software at the worst possible moment: when the developer has stopped responding, the agency has folded, or the relationship has ended badly. By then, every missing password is leverage someone else holds.

Ownership has two parts. The rights — whether the law and your contract say the code is yours. And access — whether you can actually reach, run and change it without anyone’s help. You need both.

The rights

This part depends on your contract and your jurisdiction, so treat what follows as questions to ask rather than legal advice, and involve a lawyer where the answer is unclear.

• Is there an assignment clause? In Canada, work produced by employees in the course of their employment generally belongs to the employer, but work produced by an outside contractor can remain the contractor’s unless the contract assigns it. Look for explicit language transferring intellectual property in the deliverables to you.
• What about code the developer reused? Agencies often build on their own libraries or frameworks. You may receive a licence to those rather than ownership. That is normal — but you need the licence to be perpetual and to survive the end of the relationship.
• Open-source components come with their own licences. Most are permissive, but some impose obligations if you distribute the software. Someone should know which ones are in your system.
• Is it built on the vendor’s platform? If the application only runs on a proprietary platform the developer controls, owning the code you can see may not let you run it anywhere else.

The access checklist

This is the practical half. For each item, the test is simple: is it in your organisation’s name, and could you use it tomorrow without asking anyone?

1. Source code repository — administrator access, the full history, every branch. A zip file of the latest code is not the same thing.
2. Hosting and cloud accounts — in your company’s name, billed to your company, with your people as owners.
3. Databases and backups — where the data lives, where the backups go, and whether a restore has ever been tested.
4. Domain registrar and DNS — the domain is often registered by whoever set up the site, in their name.
5. Email sending and notifications — the service that sends your system’s emails, and the records that authorise it.
6. App store accounts — for any mobile application, the developer accounts that publish it.
7. Third-party services and API keys — payment providers, maps, SMS, analytics, AI providers. Each account, and who pays for it.
8. The deployment pipeline — how a change gets from the repository to production, and the credentials it uses.
9. Secrets and credentials — stored somewhere you control, not in one person’s password manager.
10. Documentation — at minimum, how to build it, how to deploy it, and how it is configured.

Test it, don’t trust it

The only proof that you have everything is to use it. Ask someone outside the original team to take the repository and the documentation and produce a working copy of the system in a fresh environment. Whatever stops them is what is missing. It is far cheaper to find that out while the original developer is still answering emails.

If the relationship is already ending

Order matters. Secure the accounts that control everything else first — the hosting account, the domain and the repository — then the third-party services, then the knowledge. Ask for a walkthrough of how the system is deployed and configured, recorded if possible, before the last invoice is paid.

For your next contract

Write it in from the start: intellectual property assigned to you on payment; accounts created in your name; credentials stored where you control them; documentation as a deliverable; and a handover at the end that you test. Every engagement we deliver ends with the repository, the infrastructure and the credentials handed over — see what that looks like in our custom software work, or start with a project rescue assessment if access is already a problem.