Commissioning bespoke software creates a dependency on whoever writes it. That is not a criticism of suppliers, most of whom behave well. It is a structural fact: they hold the knowledge, and often the accounts, and the arrangements that determine what happens if the relationship ends are usually made when nobody is thinking about the relationship ending.
Your leverage is highest before you sign and declines steadily from there. What follows is worth settling at that point, and worth retrofitting if you are already past it.
Source control in your name
The repository should sit in an organisation your business owns, with your people holding administrative access from the first commit. The supplier is added to it as a contributor.
The alternative arrangement, where the code lives in the supplier's account and is transferred at the end, sounds equivalent and is not. It means you cannot see progress, cannot hand the code to anyone for a second opinion, and are relying on a transfer happening smoothly in exactly the circumstances where things stop happening smoothly.
The same applies to the history. A repository handed over as one large commit at the end has lost the record of why anything was done, which is a substantial part of what you paid for.
Infrastructure and credentials in your accounts
Hosting, domains, DNS, certificates, error tracking, and any third-party API keys should be registered to your business and billed to your business, with the supplier holding delegated access.
Where these sit in a supplier's account, an ordinary commercial disagreement becomes an outage, and even an entirely amicable ending involves a migration nobody scoped. It also means the running costs are invisible to you, which makes them impossible to plan for and easy to be surprised by.
Documentation that is worth having
Most handover documentation describes what the software does, which is the part you can determine by using it. What you need is the part you cannot recover: why.
Specifically, the decisions and their reasons. Why this integration polls rather than subscribes. Which behaviours look like defects and are deliberate. What the customer-specific rules are and who asked for them. What was considered and rejected. A short document covering that is worth more than two hundred pages of generated API reference, and it has to be written by the people who made the decisions while they still remember.
Ask for it as the build progresses. Requested at the end, it is written by someone whose attention has already moved to their next engagement.
Licences and components
Establish who owns the intellectual property in what has been written, in the contract, in plain terms. Suppliers reasonably retain rights to their own reusable frameworks, and that is workable as long as you know it and hold a licence that survives the relationship.
Alongside that, a list of third-party components and their licences. Open-source terms vary in what they require of you, and finding out after the fact that a component obliges you to publish something is an unpleasant discovery. Commercial components need to be licensed to your business rather than to the supplier's.
The handover test
The only reliable way to know whether you could take the software elsewhere is to try a small piece of it while the relationship is still good.
Have somebody outside the supplier clone the repository, get the application running locally, make a trivial change and deploy it. If that takes an afternoon, you are in good shape. If it takes a fortnight and three conversations, you have found out something important at a point where you can still do something about it.
This is also the strongest argument for having someone technical on your side of the table during a build. The questions above are ordinary if you know to ask them and invisible if you do not.
If you are already past that point
Most businesses reading this have software that was built years ago under none of these arrangements. The position is recoverable, and the order matters.
Start with access, because it is the fastest to fix and the most damaging to lack: get administrative rights to the repository and the hosting, and confirm you can reach them without the supplier. Then commission an independent review of what you own, which tells you how far the code is from something another team could pick up. Then work through the documentation gap while the original people are still reachable, which is the item with an expiry date.
An independent technical audit is the usual route to the second of those, and technical assurance covers the ongoing version once you have a position worth holding. For the wider question of what ownership costs once you have it, see what custom software actually costs to own, or get in touch.
