Ownership of software is not a legal question. The contract can assign every intellectual property right to you and you can still be entirely dependent on one person, because nobody else can run the thing.
Practical ownership is a checklist. Here is ours.
The ten items
1. The source code, in a repository you control. Your organisation's account, not the developer's. With the full history, not a single commit called initial commit on the day the invoice was sent.
2. A README that works. Written so a competent developer who has never seen the project can clone it and have it running locally in under an hour. The test is literal: hand it to someone and watch. Every place they get stuck is a missing line.
3. An architecture note. Two to four pages explaining why, not what. Why this database. Why this structure. What was considered and rejected. The code says what it does; only a person can say why.
4. The data model, documented. Every table, every relationship, and — most importantly — what the ambiguous fields actually mean. A column called status with seven integer values is a hostage situation until someone writes down what 4 means.
5. Deployment instructions, tested by someone else. How code gets from a repository to production. Including rollback. A deployment process only one person can execute is a single point of failure with a salary.
6. All credentials, transferred properly. Hosting, domain, database, third-party APIs, payment providers, email, monitoring. In a password manager you own. This is the most commonly skipped item and the most damaging one.
7. The test suite, and how to run it. Along with an honest note about what is not covered. Partial coverage that is documented is useful; partial coverage that is presented as complete is worse than none.
8. A list of known issues and deferred work. Everything that was left, with a note on why. This is the item developers most dislike producing and clients most benefit from, because it converts unknown risk into a list.
9. Third-party dependency inventory. What the system relies on, which versions, what each costs, and when support ends. Including the free tier that will not be free at your next volume.
10. A recorded walkthrough. An hour of someone talking through the system on screen. It costs one hour to make and it is the item people come back to for years.
Ask for it before you sign
The time to agree the handover is at contract stage, when you have leverage, not at the end when the relationship may be strained and the developer has moved on to something else.
One clause is enough: the project is not complete until these ten items are delivered and a nominated third party has confirmed they can run the system from them.
Any developer who objects to that has told you something useful. Any developer who has them ready anyway is the one to hire.