When I have custom software developed, am I then in a vendor lock-in?
This question comes up fairly regularly in conversations with potential clients. This often stems from previous negative experiences, or the foresight that a vendor lock-in can lead to limitations in the future. But what is a vendor lock-in? And how do you ensure that you don't end up in one?
What is a vendor lock-in?
Vendor lock-in is also known as supplier dependency. This is a situation where a client becomes completely dependent on a supplier for products and services, making it difficult or costly to switch to a different supplier.
In the world of software, this can arise by using a technical solution for which the intellectual property is owned by the supplier. When the software, or a core component of your software, is not actually yours, you are dependent on and tied to a supplier. This is what we call a vendor lock-in.
Can custom software also lead to a vendor lock-in?
The simplest answer is: yes, that can be possible in practice. It depends on how you have arranged things with your software partner. Here's a practical example. A software company has developed its own CMS or platform that they reuse for their clients and also deploy for you. As a rule, you do not become the owner of that as a customer, unless you make very explicit agreements about it in advance.
If this software company then develops a piece of custom work for you, the ownership of that specific piece will most likely also lie with them. And even if you were the owner, in practice, you can't really do anything with it if you would want to part ways with them. After all, it is a piece of development on top of the CMS or platform that you do not own. So then you find yourself in a situation where you have become completely dependent on them and cannot just part ways without facing substantial redevelopment costs.
Is vendor lock-in a bad thing?
It certainly doesn't have to be. You might be using a standard ERP package, and as a company, you have hopefully made a conscious choice in this. In relation to custom software, it's important to inquire about this when selecting the right software partner. Validate where the ownership lies and document it. Discuss if the entire codebase can be transferred, should you want to, to another party and make arrangements for documentation.
How does this work at SST?
We do not engage in vendor lock-in. At SST, we prioritize that the full ownership of what we develop lies with the client (which is often forgotten by clients). Sometimes we use Open Source libraries, but this does not pose any restrictions for another developer or software company.
By using stable versions and widely supported techniques, we ensure that a codebase is easily transferable to other parties who have experience with the technologies we choose. Of course, should you want that!
The soft side
However, there is one caveat, namely knowledge build-up. We can develop technology as objectively as possible, but the knowledge build-up that occurs in a relationship with a project is something that is difficult to transfer. That's why we make sure to document our projects thoroughly and guide any potential handover, although this fortunately almost never happens.
So do you have a technical vendor lock-in when you have something made by us? No! In fact, in terms of ownership and technology, you are always free to go wherever you want. It is precisely this principle that provides trust in the collaboration.
Curious how we can help you, or not sure if you're in a vendor lock-in with your current custom software? Feel free to contact me at [email protected]