Choosing a developer for your website, webshop, app, or software is often compared to getting married—be it with a freelancer or a full-service development company, it’s a relationship that you just don’t rush into.
Software development in itself tends to be a long process already, and the partnership doesn’t stop once the system is finished and deployed. Ongoing maintenance and future updates all need to be taken into consideration, and the best person to do it is usually the original developer or team who built it in the first place.
Needless to say, a customer-vendor relationship in IT is, much like a marriage, difficult and costly to separate once established—even more so if you find out that you’ve been locked in.
What is vendor lock-in?
Vendor lock-in is often talked about in the context of cloud services, but it’s a prevalent reality in IT development, too. It’s also sometimes called “customer lock-in” or “proprietary lock-in”— either way, it refers to a situation where a customer gets unwittingly stuck with their current supplier because the alternative of switching to another one involves unreasonably high costs or some significant interruption in the business operations.
It’s not that switching suppliers is an everyday thing in IT development. Ideally, the development team you chose to work with right from the initial planning to the development of your system would also be your stable partner for your future needs, and you shouldn’t have to worry about getting locked in.
But what if you get in a position where the only way to save your project is by switching suppliers?
At 1902 Software, we’ve seen our fair share of companies who wanted to replace their developers due to various reasons—like slow response to small jobs, too many errors in the system, underperformance, too-often ignored emails, etc.—but found themselves unable to turn their project over to us without first going through a grueling process to get a full copy of their system (including the source code), disrupting their business, and sometimes also having to pay a hefty unexpected fee because of some form of lock-in.
In IT development, vendor lock-in can look like one or more of these scenarios:
Sometimes, it’s only when the customer is ready to switch to another IT supplier that they find out that the copyright for the source code and other project materials are actually owned by the developer. Even if they are given a copy of the source code, the lack of ownership can limit, and sometimes even prevent, them from further development or modification of their system—as a result, they will eventually have to start all over again with the new supplier.
If the website or webshop is built on a proprietary system that’s owned by the development company, the customer is completely dependent on this company for any modifications, upgrades, or fixes—no matter how small they may be. And in case the customer needs to change to another developer, they will have to start from scratch with another system as well.
This problem can manifest on a smaller scale, too, with proprietary modules installed in otherwise open-source systems. For example, even if your webshop is developed with Magento Open Source, it will still take some effort to switch to another developer if the webshop uses modules that are proprietary to your developer. In these cases, the customer will then be required to pay for the modules either in full, or through a monthly subscription. Alternatively, the new developer will have to find a different module or custom-develop modules with the same functionality.
Modified open source
In another variation of the previous scenario, a system may be open source, but the developer may still refuse to share the source code because they claim to have made significant modifications to it, and now consider it proprietary software.
In some more petty scenarios, the developer may promise to provide a copy of the website but in reality it’s just a copy of the database, some XML files, and some images. That will not be enough for the new supplier to take over the continued support of the system. In this scenario, the customer will either have to stay with their current supplier or more or less start all over again with the new supplier.
We have also experienced how a supplier deliberately sent an incomplete system (with missing source-code files) just to add hassle and to further delay the migration process.
How to protect your IT project from lock-in
To be clear, switching to another developer or IT supplier will never be as simple as a single file transfer. There will always be some time and effort involved in the coordination and passing on of project knowledge from the old to the new supplier. However, it shouldn’t bring such trouble for the parties involved and there shouldn’t be unnecessary costs or delays from the supplier’s end.
You should of course be vigilant in choosing an IT supplier for your project in the first place, so that you don’t find yourself in a difficult situation later. At the same time, however, it wouldn’t hurt to prepare yourself for the worst-case scenarios—right from the start of your collaboration with your developer, here are the things that you need to consider:
Contracts or terms and conditions
Carefully read your project contract or your supplier’s terms and conditions before starting the project. It should be clear that you as the customer have full ownership of the source code and project materials, and that you get the original decompiled source code in case you decide to change suppliers. All these should be made available to you within seven working days upon your request to minimize business disruption as much as possible.
It often happens that customers with non-technical backgrounds leave everything up to their developer, including domain registration, hosting setup, etc. While your developer can certainly assist you with these things, make sure that at the end of the day, all credentials are with you and that all services, modules etc. are registered under your company name. This avoids complications with transferring account ownership down the road (not to mention the complications you might have if you are selling your company, your website, or webshop, when the buyer finds out that you do not have full ownership to all the digital assets).
Modules, plugins, or extensions
Make sure that your developer informs you in case there are modules that need to be installed on your website or webshop to extend its functionalities. As much as possible, it’s better if the module is purchased by you (in your name) from a third-party vendor than if you use a proprietary module from your current developer. In case your developer has to build a custom module not available as a commercial version you can license, make sure that you retain ownership of that module even when you switch suppliers.
Note that when IT companies build software, websites, or webshops, they often reuse the same set of modules or libraries to save time. You cannot expect to get full ownership of these modules or libraries because the IT company would then have to redevelop these components again from scratch each time they do a new project.
Instead, make sure that you have the right:
- To use the modules or libraries;
- To modify the modules or libraries (by yourself or any third-party developer or freelancer appointed by you);
- To include the modules/libraries, i.e. if you sell a website or webshop; and
- To transfer these rights to anyone who buys your website or webshop, or your entire company for that matter.
If an IT company does not agree to these, get out of the door as fast as possible because you are heading for a lock-in!
No lock-in with 1902 Software
At 1902 Software, you will always get full rights to the source code and related materials resulting from the development of your project. Right from the project planning stage, we already list all modules to be used in your website or webshop for your approval. We also ask customers to purchase all third-party products, modules, or services needed for the project under their names and simply grant us developer access so that we can work with them.
As mentioned above, we do have a set of modules and libraries that we reuse in our projects—but our customers retain the right to use, modify, and include these modules or libraries if they develop or change the website or webshop, either on their own or through another company or freelancer. They also have the right to transfer these rights to anyone who buys the system or company.
Although most of our customers tend to stay with us for a long time, the ones that do switch to other suppliers find it easy due to our seamless turnover process that’s designed to provide the least hassle to our customers.
At 1902 Software there’s no lock-in!
If you’re looking for a stable IT supplier, or a development team to take over a stalled IT project, contact us today and see how we can help.