Addressing the Elephant in the Room: Disinformation and “Vendor Lock-In” in No-Code Platforms

It’s time we address the elephant in the room. The vast amount of disinformation on the Internet, occasionally bordering on outright lies, does a huge disservice to end users. It’s disappointing to see many no-code vendors use FUD (Fear, Uncertainty, and Doubt) to scare uninformed and less technical citizen developers with the dreaded “vendor lock-in” buzzword. The motivation is clear: seeding doubt about a competitor may seem like a reasonable strategy, especially when you cannot win on technical merits. In this post, I aim to dispel the uncertainty and clarify this topic for those who have taken the time to research this subject.

So, what is “Vendor Lock-In”? Let’s start with a summary I received from ChatGPT:

“Vendor lock-in” refers to a situation where a customer becomes dependent on a vendor for products and services, unable to easily switch to another vendor without substantial costs, effort, or both. This dependency often results from proprietary technologies, unique service models, or other mechanisms not easily compatible with competitors.

There are several ways vendor lock-in can occur:

1. Proprietary Technology: If a vendor offers unique technology incompatible with other vendors, customers may find it difficult to switch services or products without overhauling their systems.
2. Data Portability: If a service stores customer data in a format that is not easily transferable to another platform, migrating to a new vendor can be challenging without losing data or facing significant conversion obstacles.
3. Cost of Change: Even if technically feasible alternatives exist, the cost (in terms of time, money, and disruption) of switching to another vendor can be prohibitive.
4. Long-term Contracts: Contracts that tie a customer to a vendor for a long period can create a form of lock-in, especially if there are substantial penalties for early termination.
5. Custom Solutions: Custom-built solutions tailored to a vendor’s specific technology or service offerings can increase dependency, as these solutions may not work with other vendors’ offerings.

Let’s apply these concepts to projects and apps built with no-code platforms and examine how the “lock-in” concept applies. From this perspective, the last two items can often be eliminated since the customer usually controls those aspects (in most cases).

Even without diving into the details, the conclusion for the remaining items (the first three) is straightforward: when you build an app with an external platform vendor, lock-in is inevitable. It will manifest in one or more of the following ways:

• The vendor stores your data and does not allow you to export it and/or
• You will use their SDKs/APIs over which you have no control and/or
• Your application will be generated with obfuscated, unreadable, or inaccessible code, which you cannot modify outside of the platform.

Nevertheless, let’s delve into the details of the top three methods of vendor lock-in:

Proprietary Technology

In the days of “Service-Oriented Architectures” and “Enterprise Application Servers,” a significant part of industry involvement was through standards bodies tasked with developing standards all participating vendors had an interest in conforming to. Standards bodies made it possible, at least in theory, for organizations to easily switch between vendors. Unlike those times, no such standards currently exist for no-code app development platforms. Without standards, you are subject to vendor lock-in.

What does “Proprietary Technology” mean? It means the product you build your app with, even if marketed as “free,” would require you to come to the vendor for changes, support, training, bug fixes, or, at the very minimum, a license that grants you the right to use it. Let me tell you a secret: every no-code platform is proprietary. The only exception would be a genuinely open-source product. How can you ensure it is truly open-source? At a minimum, perform two checks: there should be no “Pricing” associated with the product, and there must be a public source code repository. Of course, thorough due diligence requires additional checks, such as examining the source code license to ensure you can use it in your specific scenario and verifying that you can build the product from the repository.

Data Portability

Suppose you build an app with a no-code platform that provides a way to export data. But then you discover that the exported data is some encrypted blob that can only be processed by the platform itself. In that case, you do not truly own your data; the platform is the gatekeeper. On the contrary, if another platform’s data export allows you to access all your data, which you can import into Excel, your own database instance, or any other tool you control, congratulations, you are not locked in. However, the question of how easily you can import this data into another platform remains crucial. If it can be done relatively simply, be thankful to the vendor; they respect your right to access your data in a usable format.

Cost of Change

As it typically happens, questions of portability and changing vendors arise at a time when your investment in the current vendor is sizable. Unfortunately, that’s the reality. As such, you will be very sensitive to the cost of migrating your app to another vendor or opting for a DIY approach. Again, as with the discussion on standards, the cost of change will be proportional to the size of your app due to the lack of standards in most cases. If you have X number of screens, you will spend X * T hours, where T is the time-to-change/screen. The same applies to any backend logic you build with a vendor. But the biggest challenge comes with the functionality offered intrinsically by the platform you’re switching from. You will either have to implement it yourself or find a way to integrate your app with the new vendor’s alternative functionality. This is rarely simple and will cost you time and money.

Conclusion

The most important point I want to convey is that when you see a no-code vendor claiming no vendor lock-in with their platform, take it with a grain of salt. In my research, all of them are guilty of not telling the full truth.