Nick Scialli

Why I'm skeptical of low-code

I’m skeptical of low-code.

When I was doing some software consulting, I would get clients who had been drawn to low-code all the time for the promise of fast development time and low maintenance cost. The client ended up not being happy for one of a few reasons:

They wanted truly custom functionality that the low-code solution could not handle. A lot of low-code solutions seem to hit about 80% of a company’s requirement. But then there’s 20% the tool cannot do out of the box. Low-code tool marketers are pretty good at convincing executives that the tool can knock out the remaining 20% with ease (usually just by saying "the tool can knock out the remaining 20% with ease"). The reality ends up being that the remaining 20% requires significant and potentially-impossible customization. Companies are then forced to choose: is the tool’s out-of-the-box functionality close enough, or are we going to try to hack the tool up to make it fit our exact use case?

They implemented a bunch of custom functionality in a product-specific or even proprietary language and now their pool of potential developer talent is tiny. Often, companies will opt to try to hack a low-code tool up to match 100% of its requirements. What they end up with is a bunch of custom code in a bespoke language that a very small number of people understand. Now, rather than being to recruit from a large pool of ubiquitous, open-source language developers, the company has to find maintainers who are very specialized in this tool.

Upgrades to the low-code platform would break their custom implementation. Upgrading software without breaking things that interface with it is hard. Low-code tools have to do this with arbitrary code accomplishing use cases for which the low-code tool was never designed. This should be doable by having a strict API contract, but in practice I have seen a lot of tools that just kind of let the custom code do all sorts of shenanigans under the hood.

The underlying database structure was an absolute mess, especially after a bunch of incremental modifications. I have seen companies use low-code tools for processes where precise analytics of the underlying data is critical. But then, when viewing the underlying data model, come to find that it’s inscrutable: what does user_attribute_47 mean? I moved a field from page 1 to page 2 of the application and now the data are in separate fields?

This is not a "low-code bad" article but rather a recommendation to treat these tools with a healthy amount of skepticism. Anecdotally I have heard they can work great for the right use cases, but empirically I have found them to have a lot of "gotchas."

If you enjoyed this article, consider subscribing on Feedly or your favorite RSS consumer. If you'd like to chat, I'm most active on Bluesky.