The short answer
Owning the code legally and being able to change it are different things. The contract handles the first. The second is earned during the engagement, through review by your people and documentation written as the work proceeds.
The test is simple: could someone on your team make a non-trivial change to this next month without asking the person who wrote it? If not, you have the code and not the ownership.
The legal part, briefly
Assignment should be explicit, cover everything produced, and confirm the supplier has the right to assign it. Where they bring pre-existing components, know which parts you own outright and which you hold under licence.
This is general guidance rather than legal advice, and it is worth having your own adviser read anything you sign. Our note on contract terms goes through the clauses.
Practical ownership is built, not bought
- Your people review every significant change, not as a formality.
- Pair on anything that would otherwise be understood by one person.
- Require documentation as part of the work rather than at the end.
- Rotate who presents at reviews, so understanding is demonstrated.
- Ask periodically what would be lost if this person stopped tomorrow.
Review is the highest-value item and the first to be dropped when things are busy. A review that is a rubber stamp transfers nothing.
Signs you do not have practical ownership
- Nobody internal has read most of it
- Questions about it are routed to the supplier by reflex
- There is an area your team avoids changing
- The deployment or infrastructure is understood by one external person
- Documentation is a folder nobody has opened since it was delivered
The fourth is the most dangerous, because it usually surfaces during an incident rather than in a planning meeting.
Conventions do a lot of the work
Code written to your existing patterns is readable by your team by default. Code written to someone else's preferences is a translation exercise every time.
That is an argument for having conventions written down, and for enforcing them in review even when the alternative is defensible. Consistency is worth more than any individual preference.
What to require at handover
| Deliverable | What it prevents |
|---|---|
| Architecture overview with reasoning | Rediscovering why things are as they are |
| Anything running outside the repository | Orphaned jobs and forgotten services |
| Credentials in company accounts | Access leaving with a person |
| Known issues and unfinished work | Unknown debt |
| A live change made by your developer | A handover that was never tested |
The last row is the only one that proves the rest worked.