Intellectual property without lock-in
If you pay for custom software, you should not still end up trapped when a collaboration changes. That is why we define intellectual property, access, and transferability explicitly.
Developed code transfers to the client
Freedom for internal development or another supplier
Accounts and infrastructure preferably in the client's name
What this covers
Ownership also has to work in practice
Intellectual property is more than a neat contract sentence about code. It is also about access to repositories, documentation, infrastructure, and external services. If those parts remain scattered across supplier-controlled accounts, dependency still exists even when the legal wording on paper looks fine.
That is why we prefer a setup in which the client has direct access to source code, accounts, and hosting. The client should be able to continue with the software, internally or with another party.
What we define explicitly
From ownership to transferability
We transfer the developed code for the project fully and without reservation to the client.
For hosting, monitoring, and tooling, we prefer registration in the client's name wherever possible. That makes ownership tangible.
The client should be able to continue with the same software, whether that is with an internal team or another supplier.
Transferability requires more than source code alone. Documentation, release information, and access also need to be in order during the project itself.
We assume good work keeps clients with us, not making departure difficult.
Code does not stay behind
Intellectual property transfers to the client
We transfer the developed code for the project fully and without reservation to the client.
Why this matters
Freedom of choice is not a side issue
With custom software, lock-in often only starts to feel like a problem late in the game, namely when priorities shift, a team changes, or a handover becomes necessary. That is when it suddenly becomes clear how important it is that code, accounts, and infrastructure were not implicitly left with the supplier.
You can also see that in projects such as Zetprofiel, where Glossary · In briefinfrastructure as codeInfrastructure as code (IaC) is a practice in which infrastructure is described in configuration files and created and managed using software.Read more in the client's name matters precisely because of transferability and clear ownership. This is not about distrust, but about a healthy collaboration that still holds when circumstances change.
What this gives you
Code and intellectual property with the client
More freedom to switch team or supplier later
Less operational dependence on one party
Transferability that does not begin only at the end
Frequently asked questions
The client does. We fully transfer the intellectual property of the developed code.
No. In practice, we also look at accounts, infrastructure, documentation, and other elements that determine transferability.
That is our preference for external services such as hosting, monitoring, and tooling, precisely because it keeps ownership and continuity clear.
Because freedom of choice only really exists if you can also switch or continue yourself in practice, without barriers around access or ownership.
Is your question not listed here?
Get in touch