Why Low Code Sucks

Traditional low-code vendors sell closed platforms. This is bad for a variety of reasons including (per user) licensing fees, restrictions and dependencies on the vendor, lack of source code control, and technical debt via non-standard, proprietary code. All this adds up to a risk that you might paint yourself into a corner. This is a primary reason why major enterprise projects always insist on full source-code control.

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.

Our favorite tech blogger Hosking agrees with us: low-code technical debt , and low-code potential crash . And a couple more bloggers chime in: hands-tied, and why low-code sucks, whose title was the inspiration for this blog post.

Fortunately, Splicer offers a solution for the low-code conundrum by unlocking low-code productivity on open-source stacks.