Heck, they even held a webinar with some analyst at Forrester to talk all about it.

Clearly, they thought Low-Code was about to shake things up, and they weren’t alone. Countless businesses, writers, and journalists fell for the hype. Yet you’d be forgiven if you’d never heard of Low-Code at all.

What happened?

What is Low-Code?

Imagine you’re in charge of building an app to solve a particular business need.

You’d need to determine all the functionality and design ahead of time, then set about building it all more-or-less from the ground up. Even if you want something commonplace in apps, like a hamburger menu, you’d have to build it. And sure, maybe that would go quickly if your developers had done it more than once, but it’s still time they would have to spend writing new code for something that’s been coded a million times before.

Low-Code frameworks (e.g. Zoho Creator or OutSystems) include all the basic functionality that apps are likely to use along with easy drag-and-drop builders that anyone can use. The idea is that non-developers could use Low-Code systems to build out their applications, and developers could focus on the unique parts that need custom code.

It’s kind of like WordPress, Squarespace, or Wix, which are website-building platforms that anyone can use to create fully-functioning websites without knowing a thing about HTML, CSS, or Javascript.

Anyone can buy a Low-Code platform (and they can be pretty cheap, though there are enterprise variants that can be very expensive) and build their app…so why aren’t we seeing mass adoption of this technology? Where’s the revolution?

There are a few things holding Low-Code back:

Lack of Customization

With WordPress, anyone can buy an inexpensive domain and build a website using themes and templates, many of which are free. They can even extend that website with additional functionality, like custom forms or e-commerce storefronts, through the multitude of available plugins. Some of the functionality that non-developers can add would be pretty complex to build, but WordPress makes it easy.

Yet the ease of that functionality comes at a price, which is namely an absence of customization.

Sure, you can add the WooCommerce plug-in to your WordPress site and pretty quickly begin selling things, but you can’t make it look the way you might prefer without customizing the plugin’s base code. You might even find that some things you’d assume the plugin would do (like changing the product image when a user hovers over it) aren’t possible out of the box and would require development knowledge and time.

If everyone simply used WooCommerce on their WordPress sites, every e-store would look functionally the same and share the same limitations.

For very small companies, that might not be a problem, but once you have any kind of a budget, you’re going to want to customize your e-store so that it works the way you want it to, in order to sell your unique product as effectively as possible.

And that’s the same problem with Low-Code.

You can use the drag-and-drop builder to put together your app, and you might be able to customize some colors or take advantage of a few options, but ultimately, your app will look a whole lot like everyone else using that platform.

As soon as a company decides it wants something a little more original or sophisticated, they’re going to have to bring in a developer. But if a company has to bring on a developer (or a team of them) to work on the parts of the application that they had hoped would be covered by the Low-Code platform, the advantage of using Low-Code in the first place diminishes.

And that brings us to the next disadvantage:

Learning Curve and Hurdles for Developers

If a company uses a Low-Code platform to build some of their app, but needs development help to finish it, they run into a problem. A developer can’t just jump right in and develop code to work within the Low-Code framework — they need to learn that framework first. That means that, for many developers who haven’t worked with Low-Code frameworks before, there are hurdles keeping them from doing something that, to them, would be far simpler without the framework.

For example, an experienced developer who needs to build a hamburger menu could do it pretty quickly. Future customizations, like adjusting how the submenu opens up, would be easier because that developer would have intimate knowledge of the code operating the hamburger menu itself.

On a Low-Code platform, that same developer doesn’t know how the hamburger menu component works. They would need to study that code first, then figure out a way to get it to do what they need it to do.

For an experienced developer, and particularly one with their own design system, that’s an unnecessary frustration and headache. So if it was up to developers, they wouldn’t use Low-Code platforms, and that gets in the way of Low-Code’s adoption.

But there’s another reason developers frown on Low-Code…

Tools Don’t Build Apps, People Do

You can give a person a canvas and paintbrushes, but it would be unrealistic to expect them to paint the Mona Lisa on their first attempt.

Similarly with app development, you can give non-developers all the tools to create apps in a Low-Code platform, but if they don’t have the experience to think through an ideal user experience, viable functionality, and system architecture, how effective can their apps really be?

In very simple use cases, maybe that doesn’t matter so much, but most non-developers probably don’t even have the knowledge or experience to know whether or not their use case is one of the simple ones.

Say you want to start a business selling knick-knacks and you think your customers will want an app. You could probably build a simple e-commerce app with a Low-Code platform, but how will it scale if your business grows and you increase your product line? Will it be able to intelligently recommend add-on products based on previous purchases? Will it load new pages quickly enough to keep users interested? Is its payment system secure, and will it manage out-of-state taxes for you?

These are all the considerations that a seasoned developer could think through and implement in a custom product, but a non-developer might not know to consider. Any application with any level of sophistication can’t be most-effectively built by a non-developer on a Low-Code platform, so again, the value of Low-Code is diminished as developers have to come in and perform custom work.

Where do Design Systems Fit In?

You may have heard of Design Systems, as they’re something of a hot topic among designers and developers right now.

Basically, the idea of a Design System is to write components in a way that makes it possible to re-use them in future apps with similar functionality. If that sounds like what a Low-Code system attempts to do, you’re right — you might say that a Design System is an internal Low-Code framework, though it’s one that still requires a developer and tends to be specific to a single organization.

Design Systems are what developers and designers have come up with that respond to the same issue that Low-Code frameworks try to solve: the inefficiency of writing new code for something that’s been coded up a million times before. They have all the most impactful advantages of Low-Code without the cost or frustration, so they’re likely to continue growing in adoption while Low-Code may not.

---

The promise of Low-Code seems to have been overly optimistic, but some platforms have managed to find their niches.

As noted previously, Low-Code may be all you need if you’re building a small app with limited functionality or an example of what a future, custom-produced app might look like, and that’s where something like Zoho Creator excels. Enterprise-level Low-Code platforms like Outsystems have found success in accelerating development, but they don’t follow through with the promise of Low-Code to enable non-developers to build apps.

For most development teams and medium-to-enterprise companies, Low-Code hasn’t caught on like the experts thought because the current system, where developers build almost everything from the ground up, use open source code, or their own Designs Systems whenever they start a new project, has some distinct advantages that they would prefer not to give up, and Low-Code ultimately doesn’t save a lot of time and/or money due to a lack of customizability.

That doesn’t mean that Low-Code won’t eventually take off. If the platforms can prove their value to developers and convince them that they’ll be able to make customizations painlessly, they may become more viable. But we won’t see that switch happen until more developers and businesses feel like Low-Code consistently saves time, money, and effort.