Owning the software you paid for

A surprising number of businesses discover, years into a relationship, that they cannot leave their software vendor. Not because the software is irreplaceable, but because they never actually got the keys.

What ownership should mean

If you commissioned custom software, you should have all of the following without asking:

• The source code, in a repository your organisation controls
• The full commit history, not a single squashed drop
• Infrastructure running in your own cloud accounts
• Your own domain and DNS control
• Documentation sufficient for another team to continue

If any of those live only with your vendor, you have a dependency you did not negotiate.

Warning signs at signing

Watch for contracts where IP transfers only on completion of an open-ended engagement, where the vendor hosts everything under their own accounts, or where documentation is scoped as an optional extra.

None of these are automatically bad faith. Some are simply how a small shop has always worked. But each one raises the cost of ever leaving, and that cost is worth pricing in while you still have leverage.

Why good vendors offer it anyway

We deliver into the client's repository from day one and transfer IP on final payment. It sounds like giving up leverage. In practice it does the opposite.

Clients who know they could leave stay for the right reason: the work is good. And a vendor confident enough to hand over the keys is signalling something about the quality of what is behind the door.

The test question

Ask any prospective vendor: "If we wanted to bring this in-house in a year, what would that take?"

A good answer is specific and unbothered. A vague or defensive one tells you what you needed to know.