You commission a software system. You pay for it in full. It runs your business. And then one day, you try to move to a different development company — and you discover that you cannot take the software with you. Not easily, anyway.
This situation is more common than most business owners expect. Paying for software development does not automatically mean you own the software. Understanding the difference between ownership and licensing, and knowing what questions to ask before you sign a contract, can save you from a very expensive lesson.
The difference between owning software and licensing it
When you buy a piece of furniture, you own it outright. You can move it, modify it, sell it, or throw it away. Software does not work the same way — at least not by default.
There are two broad situations:
You license the software. This means the developer (or their company) retains ownership of the underlying code. You have the right to use it, possibly for a specific period or under certain conditions, but you cannot take the code somewhere else, modify it freely, or transfer it without permission. Most off-the-shelf SaaS products work this way by design — and that is fine, because you know what you are buying.
You own the software. This means the intellectual property in the code has been formally transferred to you. The developer wrote it, but you hold the rights. You can do with it whatever you like — give it to a different developer, modify it, resell it as a product, or lock it in a drawer.
When you commission custom software — software built specifically for your business — you will probably assume you are in the second category. You might be. But only if the contract says so explicitly.
Why the default position may not be what you think
In many jurisdictions, including across most of Europe, the creator of a work holds copyright by default unless they have explicitly transferred it. That means if your contract with a developer does not include a clear intellectual property assignment clause, the developer may retain ownership of the code even after you have paid for it.
This is not a technicality that only matters in disputes. It has real, practical consequences:
- If you want to switch development partners, the new team cannot legally modify or extend the original code without the previous owner's permission
- If the original developer goes out of business or becomes unresponsive, you may have no legal recourse to maintain your own system
- If you want to sell your business, the acquirer will want to see proof that the software assets are actually yours
None of this means developers are trying to trap you. Most are acting in good faith. The issue is usually that neither party thought carefully about IP at the time the contract was written.
What to ask for and what to look for in a contract
Before you sign any software development agreement, these are the points that deserve your attention.
Intellectual property assignment. The contract should state clearly that all intellectual property created in the course of the project is assigned to you upon payment. "Work for hire" clauses or similar language can achieve this depending on the jurisdiction.
Access to source code. You should receive the actual source code — the human-readable files that a developer writes — not just a deployed application. An application running on a server without access to its source code is like a building you cannot enter. If the contractor disappears tomorrow, you need to be able to hand the code to someone else.
Code repository access. Most professional development teams use version control systems (like Git) to manage code changes. Make sure you have ongoing access to the repository where your project lives, and that access does not depend on the developer's good will.
Third-party components and licences. Most software is built on a foundation of open-source libraries and frameworks. Your contract should include a list of any significant third-party components and their licence terms. Some open-source licences impose conditions on how the software can be used or distributed.
Ongoing code ownership during development. Some contracts specify that IP transfers only upon final payment. That can be reasonable — but make sure you understand the timeline and that milestone-based transfers are defined.
The vendor lock-in risk
Even when IP is properly assigned, there is a related risk worth understanding: vendor lock-in through technology choices.
Some development teams build on proprietary platforms, closed frameworks, or custom tooling that they control. Even if you own the code, finding another team willing and able to work with an unusual technology stack can be difficult and expensive. This is less about legal rights and more about practical dependency.
A good development partner will make choices that keep your options open — using widely adopted technologies, documenting their architecture, and building in a way that another competent team could pick up if needed. When evaluating a partner, it is worth asking directly: "If we had to move to a different development team, how easy would that be?"
What good practice looks like
At reputable software development companies, IP assignment is standard practice, not a negotiation point. They expect you to own the code you paid to build. They document their work. They deliver source code at every milestone or make it available on demand. And they choose technology stacks that serve your long-term interests, not just the project at hand.
Signs that a development partner takes this seriously:
- They include a clear IP assignment clause in their standard contract
- They provide repository access from the start of the project
- They deliver source code alongside deployed software
- They document what third-party components they have used
- They are comfortable with the question: "What would happen if we needed to work with a different team in the future?"
If a potential partner avoids these topics or brushes them off, treat that as a warning sign.
A practical checklist before you sign
Before committing to a software development engagement, run through these questions:
- Does the contract include an explicit IP assignment to my company?
- Will I receive the full source code, and when?
- Will I have direct access to the code repository?
- Are there any third-party licences I need to be aware of?
- Is the technology stack one that other development teams commonly work with?
- What happens to my code and data if this development company closes or changes ownership?
You do not need to be a lawyer or a developer to ask these questions. You just need to ask them before you sign.
The bottom line
Custom software can be one of the most valuable assets your business owns. But only if it is actually yours. The investment you make in getting the contract right — ideally with a solicitor's review — is small compared to the cost of discovering three years in that you do not fully control a system your business depends on.
Own your code. Insist on it from the beginning. A development partner worth working with will not only agree — they will have thought about it already.
Thinking through a software project and want to make sure you are protected from the start? Talk to us — we will walk you through what a sound agreement looks like and why it matters for your business.