ºÚÁÏÃÅ

What’s in for you?

Low-code may appeal to enterprises that either struggle to hire the number of developers they need or face long lead times for applications to be created. Low code can help mitigate that talent gap or improve developers’ productivity by enabling them to quickly build simple applications.

In some cases, low-code platforms enable business units to quickly and cheaply create applications that meet their needs, through enabling staff with domain expertise to build their own applications.

What are the trade offs?

Once you move beyond relatively simple applications, you start running into low-code’s limitations.

One issue common with many off-the-shelf applications is what to do if the pre-built components don’t meet your exact requirements. If you start customizing the components (by writing code) you immediately run into all the risks of customization: the need to do it correctly and the risk of being off the platform’s upgrade path with all the costs and complexity that introduces. For example, if you’re not on your platform’s upgrade path, how do you keep up-to-date with vulnerabilities? Will you become reliant on a handful of key staff that know how to maintain and support your platform? Experience with packaged enterprise applications demonstrate the risks and costs of moving off the upgrade path.

You also need to be mindful of the tooling available for low-code platforms. Will you be able to support dozens of people working on a project simultaneously? How does it fit with your delivery pipelines? 

Tools for end-user development have a long history. There is a place for end-user development (spreadsheets for example) but applications built this way often suffer from quality, inadequate testing, poor design, lack of configuration management, scaling and long-term maintenance.  

For some of these ‘edge’ cases, it may be possible to get your low-code platform to output code that your developers could work on. The theory is that this gives your enterprise additional reassurance that you have some flexibility. But machine-generated code is notoriously difficult to work with — anyone relying on this capability would be well advised to test out the quality of the code before committing. You may want to consider whether low code is best used in prototypes that won’t tie developers to that code base.

In determining where and where not to use low code, you might think about three categories of applications: personal, departmental, enterprise. For an app with a single, or few, users low code can work well. For enterprise apps, not so much. For departmental apps, probably only the smaller ones.