What Owning Your Source Code Actually Means

A contract clause saying you own the code is necessary and not sufficient. Ownership without the means to run it is a filing-cabinet asset.

The gap between the two is where vendor lock-in lives, and it is rarely malicious. It is usually just the accumulated result of nobody writing down who holds what.

The five things to check

The repository, with its history. A zip file of the current state is not the same as the git history. History is how a future developer answers "why is this like this", and losing it makes every subsequent change more expensive.

The deployment configuration. Dockerfiles, CI pipelines, server setup, and the list of environment variables the application expects. Not the secret values, which should rotate anyway, but the names and what each one is for. Without this, running your own code becomes an archaeology project.

Database migrations. The schema needs to be reproducible from scratch, not just a dump of the current production database. If the schema only exists in production, you have no way to spin up a test environment.

The accounts. Domain registrar, DNS, hosting, error tracking, analytics, payment gateway, email sending. Every one of these should be registered to your company with the vendor added as a collaborator, not the other way round.

Third-party licences. If any commercial component was bought, whose name is on the licence? A theme or a component library purchased under the vendor's account may not transfer with the code.

Why the timing matters

Ask for all of this before final payment. Not because vendors are untrustworthy, but because the moment before final payment is the only one where both sides are motivated to close things out cleanly.

After the relationship ends, every request becomes a favour competing with the vendor's current paying work. Most will still help. It will take three weeks instead of a day.

The test that settles it

Hand the handover package to a developer who has never seen the project and ask them to get it running on a fresh machine. Give them a day.

If they can, you own the system. If they cannot, you own a copy of some files and the vendor still holds the part that matters. This test is worth paying an independent developer for, and it costs a fraction of discovering the answer during an emergency.

What this looks like when it is done right

You have a repository you control, a document listing every account and who has access, a README that gets the project running locally, and a runbook for deploying. None of that is exotic. It is a day of work at the end of a project, and it is the difference between a supplier and a dependency.

We put ownership transfer in writing on every engagement, covering code, designs, and infrastructure configuration on final payment. Ask any vendor you are considering to do the same, in the contract, before work starts.