Vendor lock-in refers to a situation where the cost of switching to a different vendor (or an in-house solution) is so high that the customer is essentially stuck with the original vendor (Source).
The problem of vendor lock-in increases if:
This is a problem not only for customers but also for companies offering software (especially startups): For customers, they run the risk of being stuck with a vendor even if their service quality declines, they change their product focus, they increase their pricing - or worst case - they run out of business. As a result, startups have the problem of gaining potential customers’ trust, and therefore, have to design their software to minimise these risks. This results in lots of additional engineering costs, and sometimes, lost revenue.
This issue can be solved by providing a self-hosted version of your product which will store all the data in your customer’s database. Most apps use a SQL database, so supporting MySQL and PostgreSQL would be enough (until your product becomes fairly popular).
There are issues with this approach though:
To mitigate some of these issues, here are two ideas:
This section caters to two aspects:
One way to solve these issues is to make your product open source. However, this has major implications on your product’s business model. If that is not possible, you could consider a “source available”[2] model which converts to being open source in case your business shuts down. You could even charge users extra to provide them with a license that allows them to modify the source code. Finally, depending on how your managed service offering runs, you could allow users to modify the source code of your product, and the modified version can be hosted by you.
Other than direct source code modifications, you should design your product to have enough hooks and switches so as to meet any sort of business customisation requirements. You should also aim to provide an API-only interface to all your features/dashboards. That way, even if you do not provide a feature that a user wants, it may be possible for them to build that out “on top” of your product.
Most companies focus on making it easy to migrate into their product. To minimise vendor lock-in, you should also focus on making it easy to migrate away from your product.
At first, this may seem counterintuitive from a business perspective, the chances that a production customer will actually migrate out of your product is very low (assuming that your product and service meets their expectations). You are better off optimising for this as it gives an impression of customer prioritisation and focus, which in turn will increase the probability of getting newer customers.
To summarise, the problem of vendor lock-in can be minimised by:
Allowing users to use their own database via a self-hosted version of your product.
Allowing them to carry out complex customisations with and without modifying the code you provide.
Allowing users to move from using your managed service version to a self-hosted version of your product.
Allowing your managed service version to connect to a user’s database.
Make migration into and away from your product as easy as possible.
[1]: I am not a lawyer. Please consult one before implementing / seriously considering the ideas pointed out in this section.
[2]: The source code is viewable, but under a proprietary license - limiting the distribution and modification of the code, and usually requiring a license key to run.
Written by the Folks at SuperTokens — hope you enjoyed it! We are always available on our Discord server. Join us if you have any questions or need any help.