Code ownership and handover clauses for your dev contract

In short: put five things in your software development contract: who owns the code, when ownership transfers, that you hold the accounts from day one, what documentation and handover the vendor must provide, and what happens if the engagement ends early. This is a practical checklist, not legal advice; have a lawyer in your jurisdiction review the final text.

Why this matters more than the price

Without access to the source and the technical accounts, you are not managing your vendor, you depend on them. It is the most expensive thing to fix after signing, and it is often discovered exactly when the relationship is breaking down. In one due diligence the code was better than expected; the real risk was that a single contractor held the only credentials to the production database and deployment pipeline and had not been paid in seven weeks.

The five clauses

1. Ownership of the work

• State plainly that the client owns the deliverables, including source code, designs, data and documentation.
• Specify when ownership transfers: on creation, on payment, or at acceptance. Prefer "as created" or "as paid", not "at the end of the project".
• Deal with third-party and open-source components: list them, and state which licences apply.
• Check how the contract treats the vendor's pre-existing tools or frameworks. You usually receive a licence to use them, not ownership; make sure that licence is perpetual and survives the end of the contract.

2. Accounts and access from day one

• The source repository, hosting, domain, database, app-store accounts and third-party services are created in your name or organisation, with the vendor added as a collaborator.
• Credentials are never held by one individual alone.

3. Documentation and handover

• A defined minimum: how to run it locally, how to deploy, architecture overview, data model, environment variables and where secrets live.
• Test: can a new developer run the project in a day using only what is written?
• Handover is a deliverable with an acceptance check, not a courtesy.

4. Acceptance and payment

• Payment tied to accepted deliverables against written acceptance criteria, not only to calendar dates.
• A warranty period for defects found after acceptance, with a stated length and response time.

5. Exit terms

• Notice period and what is delivered on early termination: the code as it stands, all accounts, and documentation for completed work.
• No vendor right to withhold code over a payment dispute on unrelated work, or if there is a dispute mechanism, access continues while it is resolved.
• Confidentiality and data-protection obligations that survive the contract.

Vendor lock-in: the quieter version of the same problem

Even with ownership clearly yours, you can be locked in by choices that only the vendor understands: a proprietary framework, an obscure hosting setup, undocumented build steps, or a data model nobody else can read. Ask at the proposal stage: which technologies will you use and why, how common are developers who know them, and how would another team take this over? An answer that depends on the vendor staying is a lock-in risk, whatever the contract says.

A short checklist to send before signing

• Who owns the code, and from when?
• Will the repository and hosting be in our name from the first day?
• What exactly is the handover, and how will we accept it?
• What do we receive if either side ends the contract early?
• Which third-party and open-source components are used, under which licences?

Ask for answers in writing, and treat hesitation as information. For a broader view of choosing a vendor, use the vendor scorecard. If a project is already running and you are unsure where you stand, the Delivery Risk Audit checks access, ownership and key-person risk first, and Build Oversight confirms in month one that access and documentation exist.