The short answer
Paying for a build does not automatically mean you can take it elsewhere. Ownership is a set of practical things, and each one needs establishing rather than assuming.
Do it in the contract, because the moment you need it is the moment you have least leverage.
What ownership actually covers
| Item | What to establish |
|---|---|
| Source code | Assigned to you, in your repository |
| Domain | Registered to you, not the supplier |
| Hosting accounts | In your name, you hold billing |
| Third party services | Your accounts, supplier invited |
| Documentation | Enough for another team to continue |
The domain row is the one that causes the worst situations. A domain registered to a supplier is leverage over your whole business, not just the project.
Check it during the build
- Confirm you can log in to every account yourself.
- Confirm you can clone the repository without asking.
- Confirm you can see the hosting bill.
- Confirm someone other than the supplier can deploy.
- Do these before the final payment, not after.
Point five is the practical lever. Making the final payment conditional on a verified handover is entirely reasonable and rarely objected to by good suppliers.
Documentation that is worth something
- How to run it locally, tested by someone who did not build it
- How it is deployed and where
- What external services it depends on
- Which decisions were made and why
- Known problems and anything fragile
The first point is the test. Documentation that has never been followed by anyone else is usually incomplete in ways the author cannot see.
Licensed components are normal
Most builds include open source and third party components you do not own outright, and that is fine. What matters is knowing what they are and under what terms.
Ask for a list. A supplier who cannot produce one does not know what is in the software they built for you.