A great many companies discover at the worst possible moment that they do not own the software they paid to have built. The code sits in the supplier’s organisation on GitHub. The cloud account is in the supplier’s name and billed to their card. Deployment happens because one person runs a script on their laptop. The domain is registered to whoever set it up in 2019. None of this is necessarily malicious, but all of it makes ending the relationship expensive.
Handover is not a phase at the end of a project. It is a set of properties the project either has from week one or does not have at all. Everything below is easy to arrange at the start and difficult to retrofit.
Intellectual property, in writing, before work starts
Under UK law, copyright in work created by an employee in the course of their employment belongs to the employer by default. Work created by a contractor or supplier does not: absent an assignment, copyright stays with the party that created it, and the client typically has an implied licence to use it, the extent of which is exactly the sort of thing that gets argued about later. Paying an invoice does not transfer copyright.
What your contract needs to say, at minimum:
- A present assignment of all IP in the deliverables to you, with the supplier agreeing to execute any further documents needed to give effect to it.
- A warranty that the supplier has secured the same assignment from any subcontractors or freelancers they use. This is the gap most often left open.
- Clarity on when assignment takes effect. “On full payment” is normal and reasonable. “On completion of the project” is vague enough to cause a problem in a dispute.
- An explicit carve-out for the supplier’s pre-existing tools and libraries, with a perpetual, irrevocable, transferable licence to you for anything of theirs embedded in your system. A supplier reusing their own components is fine and often desirable; a supplier reusing components you cannot licence indefinitely is a trap.
- A list of open-source dependencies and their licences, with a warranty that none of them impose obligations incompatible with your intended use. Copyleft licences in a product you plan to distribute are worth knowing about before launch, not after.
Accounts in your name, from day one
The rule is simple: every account that your production system depends on should be owned by your company, paid for by your company, and have at least one administrator who works for you and is not the project’s day-to-day contact. Grant the supplier access as a user. Do not become a user of the supplier’s account.
- Source control. Repositories in your organisation, with your billing. If the supplier’s own developers are members of your organisation rather than the reverse, removing access at the end takes one minute.
- Cloud. Your AWS, Azure or GCP account, your billing relationship, your root credentials held by a director. Supplier access via a role or federated identity you can revoke.
- Domains and DNS. Registered to the company, with the registrar login held internally. Losing control of a domain is one of the few genuinely unrecoverable failures.
- Third-party services. Payment processing, email delivery, error tracking, analytics, SMS, mapping, any AI provider. These accumulate quietly and each one is a small hostage.
- App store accounts. Apple Developer and Google Play publisher accounts in your company’s name. Moving a published app between publisher accounts is genuinely painful.
- Certificates and signing keys. Code signing certificates and mobile signing keys held by you and escrowed. A lost Android signing key means users cannot upgrade; they must uninstall and reinstall.
There is a related discipline here worth insisting on regardless of ownership: no secret should exist only in a person’s password manager or a chat message. Production credentials belong in a secrets manager with access control and an audit log, and the recovery path for every one of them should be written down.
Documentation that is actually useful
Most handover documentation is worthless because it describes what the code does, which the code already describes better and which goes out of date immediately. Useful documentation records the things that are not recoverable by reading the source.
- How to get it running. A new engineer, on a clean machine, following written steps, with no access to anyone who built it. If nobody has tested that path, it does not work. Ask for it to be tested.
- Why, not what. The decisions and their alternatives. Why this database, why this queue, why the unusual thing in the middle that looks wrong. Short architecture decision records dated and left in the repository are the cheapest form of this and by far the most valuable.
- The system in one diagram. Components, data stores, external dependencies, direction of traffic. One page.
- Operational runbooks. What the alerts mean, what to check first, how to restore from backup, how to roll back a bad release, who to ring at each supplier. Written before an incident, not during one.
- The known problems. A candid list of shortcuts taken, deferred work, and parts of the system nobody is proud of. A supplier willing to write this down is telling you something about how they work.
Keep documentation in the repository, in plain text, versioned with the code. Documentation in a wiki that belongs to the supplier’s account is not documentation you own.
Reproducible deployment
The question that exposes most projects is: if the production environment were deleted tonight, what would it take to recreate it, and does anyone know? If the honest answer involves a person remembering what they configured by hand in a console eighteen months ago, you do not have a deployment process. You have an artefact nobody can rebuild.
What to require: infrastructure defined as code and committed to the repository, so environments are described rather than remembered. A pipeline that builds, tests and deploys from a commit, running on a service under your account. Environments that differ only in configuration, so testing in staging means something. Database migrations in version control and applied by the pipeline. Backups that are restored on a schedule, because a backup nobody has restored is a hypothesis.
The test is not whether a pipeline exists. It is whether someone who is not the supplier can trigger a deployment and have it work. Do that once, with your own person’s hands on the keyboard, before the engagement ends.
Dependency, and how a supplier can reduce it deliberately
Some lock-in is unavoidable. A team that has built a system for a year knows things that are not written down anywhere, and no handover fully transfers that. The difference between an honest supplier and a bad one is which direction they push.
Dependency gets manufactured through ordinary-looking choices: proprietary frameworks the supplier wrote and does not licence cleanly, deployment that only works from their environment, architecture more complicated than the problem requires, documentation always promised for the next phase, and access requests that take a fortnight. Individually each is explicable. Together they are a strategy.
Reducing it is not complicated, just deliberate. Mainstream technology unless there is a written reason not to. Client-owned accounts from the first day. Documentation as a deliverable with its own line in the plan, not goodwill at the end. Your engineers in code reviews throughout, if you have any. A defined exit: the supplier’s obligations on termination, spelled out, including a transition period at agreed rates and a list of what gets handed over.
The commercial logic works in the supplier’s favour too, which is worth saying plainly. A client who stays because leaving is hard is a client who is looking for a way out. A client who could leave next month and chooses not to is a much better business to have.
A test you can run this week
If you have an existing supplier, ask for three things and watch what happens. Administrator access to the source control organisation and the cloud account, in your name. A written list of every third-party service the system depends on and whose name each account is in. And a deployment to production performed by your own staff, following the written instructions, with the supplier watching but not typing.
How long that takes, and how the request is received, tells you where you stand more accurately than any contract clause.