Thoughts about low/no code and vendor lock-in

Christoph Kappestein
2 min readJan 29, 2022

In the last months I have seen a lot low/no code solutions which provide basically a user interface to create backend logic. The idea is great that also non-developers can build solutions, there is also the term “citizen developer” which basically means that every person is able to build solutions using low/no code tools. Currently skilled developers are really rare and these tools provide a solution for companies so that also normal end users can build tools.

I am also really interested in the space since I am currently working on Fusio which is an open source API management platform which also targets a little bit such low code users since it is possible to build a simple API only through configuring specific actions.

That being said I am also a little bit sceptical about the low/no code movement. From a technical perspective I think most tools do a good job but my worries are more about the vendor lock-in problem. Lets say you have build a great solution using a specific low/no code provider, then you are basically forced to use this provider and you have no option to move your logic to a different provider. Being tied to a low/no code provider can be of course problematic in case the provider changes the pricing, is not available or you simply want to change the provider. Then you basically need to rebuild your complete solution at a different provider.

Another problem which all low/no code platforms face is the handling of versioning. In classical programming this problem is already solved by great version control systems like GIT. For low/no code platforms they all must invent such a solution so that it is possible to track every change and to be able to revert to a specific state. But this versioning problem can be solved.

From my view the biggest challenge for all low/no code provider is to solve this vendor lock-in problem. Maybe there is a way to be able to export low/no code solutions into a specific format but the landscape is currently really diverse so I am not sure whether such a portability can be achieved. In the end this would also mean that such an export is probably a dedicated programming language, where all settings and configurations are stored.

So these are just some thoughts regarding the current state of the low/no code ecosystem. Please let me know if I have missed any tools or solutions which might solve those mentioned problems.

--

--

Christoph Kappestein

I am a developer in the API space, currently working on Fusio an open source API management platform