Imagine investing countless hours and resources into a technology platform, only to find out later that escaping it would cost you even more. This is the perilous reality of lock-in, a pervasive issue in the tech world where dependency on a single supplier or technology becomes a costly and difficult trap. Particularly prevalent in software and cloud computing, lock-in ensnares customers in proprietary formats and protocols, creating a barrier to freedom and flexibility across various tech sectors.
Lock-in is a particular danger in the low-code world. There are many platforms in the low-code or no-code space that promise their customers the ability to create practical software systems with much reduced software development costs. However, these platforms often cause significant lock-in for the customers.
This is because the intellectual property that customers use to create products on low-code platforms cannot easily be migrated away from those platforms. For example, there are several "site-builder" technologies that produce pleasing web pages without requiring the user to understand HTML or CSS. Instead, the user arranges the display components (dropdowns, panels, text, tables, etc) as desired, using a point-and-click user interface. While this process does not require coding, it still requires effort and learning.
The result of this activity has two products. The first is the web site itself, which is shown to the user. The second is the backend configuration or code, that the platform uses to generate the site; this is typically not shown to the user. The key issue is that the backend configuration is not portable. It will only run on the low-code platform. You cannot download it and install it on your own servers. Thus, your investment of time and learning that was required to create the site, is now locked-in to the platform.
What's So Bad about Lock-In?
Lock-in has a number of consequences, none of which are good for the end user.
The obvious danger is simply that the platform company might raise their prices. This often happens with Venture Capital funded companies. In their early days, they are happy to give the product away for cheap, as a way of building market share. But eventually the VCs want to show a return on their investment, so they force the platform company to raise prices.
A second danger, less obvious but still very real, is that the quality of the product declines over time. For various reasons, technology products do not always get better over time; sometimes the reverse happens (in my mind, Facebook is great example of this; it was a quite clean and simple experience in the early days, now it is cluttered with garbage). Sometimes this decline is quality is caused by the departure of key personnel from the company; other times it is due to the company simply failing to maintain and update the product to keep up with the evolution of the surrounding ecosystem.
A third danger is particularly relevant to the low-code world. One scenario that low-code developers can imagine is that the application becomes very successful. Perhaps it gains more and more users over time; perhaps the data volumes explode exponentially; or perhaps it become mission-critical to the organization. In this scenario, it may become necessary to migrate the application away from the low-code environment where it originated. In this scenario, for the majority of low-code platforms, it will be impossible to salvage any of the initial investment: the application will need to be rebuilt from scratch.
How Does WWIO Protect Me Safe From Lockin?
The WebWidgets.io platform offers unique protections against lock-in that most other low-code offerings do not. The protection is based on the following factors:- Standards-based development
- Ownership of Data and Schema
- Open Core Offering
- Simplicity of API
Standards-based development means that the code you create when building WWIO apps is all based on open technologies like JavaScript, HTML, and CSS. These are some of the most widely supported software products in the world. Millions of developers are proficient in them, they are built into every web browser, and their evolution is governed by open consortiums of industry leaders.
Ownership of Data and Schema means that you own not just your data, but also the schema that is used to express that data. WWIO apps save their data in SQLite databases using a schema that is controlled by the developer (you). Since you control the schema, you can organize the data to make it maximally portable and interoperable with other systems you might want to use. Many other software services allow you to obtain your data, but it is often organized in a way that makes it hard to work with.
Open Core Offering - we are proud to make available an open-core version of our software, that includes all of the core features. This provides our users with a strong guarantee against lock-in. If you become dissatisfied with the WebWidgets.io hosting platform, you are free to install the open core version on your own servers and never pay us another dime.
Simplicity of API is the most powerful defense against lock-in, because it even protects you against lock-in to the low-code WWIO architecture (this is particularly relevant to danger #3 mentioned above). Suppose that after a couple of years, your application becomes incredibly successful and important to your company. However, this success is causing some problems, because the business stakeholders are pushing for the application to do some operations that are difficult to achieve in the low-code WWIO environment. In this scenario, you retain a powerful option: you can implement the simple REST API that WWIO provides on your own architecture. Once you do that, all of your front-end code will work seamlessly in the new environment. And once you accomplish that migration, you will be able to implement any kind of additional features or optimizations you desire. In other words, your system will now be a fully-fledged web application.