Traditional Low-Code vendors rely on closed platforms. This is very bad for a variety of reasons including (per user) licensing fees, risk via lack of source code control, and accumulative technical debt.
We definitely understand the motivation for low-code, but sacrificing source-code control is a mistake. In my mind, its simply about permutations — no low-code vendor can anticipate all the possible permutations that a system will require.
Also, the current low code platforms rely on NoSQL. Since NoSQL does not support data normalization, it seems beyond the scope of NoSQL to build general applications with it; this seems to be a major deficiency and a major source of technical debt. Citizen developers can get out of the gate very quickly with solutions like bubble.io, but as a client shared recently with me, the more the application grows beyond a very simple application — the number of entities grow — unanticipated and essentially unpredictable bugs start to appear due to the lack of normalization. Apparently, the fix for this is to handle the normalization at the application layer — all without access to the underlying source code.
And a couple more bloggers chime in: https://rebeccabilbro.github.io/low-code-no-code/ , https://medium.com/alexander-ilg/low-code-no-code-solutions-for-sap-or-why-low-code-sucks-70e0610c79e2 .
Fortunately, we have a solution for the low-code conundrum at: https://splicer.io .
I’ll post here as I find more insights, so check back or post your comments below.