In early meetings almost nobody asks who will own the code. The talk is about features, timelines and figures, and ownership feels like a detail for lawyers. Then three years pass, the relationship with the supplier cools or the company changes direction, and it becomes the only question that matters.
The three possible answers
The code belongs to the supplier, you hold a licence to use it. The most common arrangement and the least often stated. It works while the relationship works. When it ends, you are left with a system nobody else is allowed to touch.
The code lives on a platform. The data is yours and exportable, the logic is not: automations, permissions, flows and reports live in a configuration that does not come out. Changing supplier means rebuilding all of it.
The code is yours. Source and database belong to you, in a repository you can reach. If one day you want to change, you take everything with you and anyone can pick up the work.
Why the third is not a favour
It can look as if a supplier handing over the code is removing their own protection. In practice it changes the nature of the tie, and for the better on both sides.
If the client is locked in, the supplier has no reason to be good: they know nobody is leaving. If the client could leave tomorrow morning, the only way to keep them is to do good work. The relationship stops being a constraint and goes back to being a choice, renewed every year.
There is a practical effect too: when the code belongs to the client, it gets written differently. It gets documented, conventions stay recognisable, and the shortcuts only the author understands get avoided. Knowing that another developer will one day open those files is the best discipline there is.
Four things to check in the contract
Ownership of the source code
It must state explicitly that source developed under the engagement belongs to the client. Watch the difference between ownership and a perpetual, irrevocable licence to use: the second sounds reassuring but does not let you transfer the system, or have it modified by a third party, unless the contract says so.
Where the code is, today
Not at the end of the project: today. A repository the client can read from day one. If the code only exists on somebody's laptop, ownership is theoretical.
Third-party components
No project is written entirely from scratch. The contract should separate commissioned code from third-party components and state their licences. A commercial component licensed to the supplier is a tie, even if everything else is yours.
What happens at the end
This gets written while relations are good: handover of up-to-date source, a database dump, credentials, documentation, and a period of support to the incoming supplier. Without this clause the handover gets negotiated at the worst possible moment.
The one-minute test
If you already have a system running, there is a test worth more than any contract review: ask your supplier today for a copy of the source and a database dump, without explaining why.
If it arrives within a couple of days, you are fine. If what arrives is a question about why you are asking, you already have your answer.