This post comes in response to a flurry of posts about the emerging use of low code platforms in parts of UK local government.

At FutureGov, we try to remain technology agnostic when working with councils, because we realise that one size does not fit all. Though, we advocate strongly for open source and open standards wherever possible.

We recognise that many of the proprietary software providers and their commercial off-the-shelf solutions (COTS) are widespread across local government, playing important roles in the foundation of running our public services. Yet, that isn’t to say that all COTS solutions are born equal. There is an emerging breed of solution referred to as ‘low code’. Over the last year we’ve had the opportunity to try three of these platforms.

The benefits of low code

From the outside looking in, the benefits of low code sound appealing:

  • You don’t need to hire expensive developers. Anyone can learn the drag and drop functionality and stand up a new app within minutes.
  • You don’t need to hire interaction designers. Designs are straight out of the box; just pick your favourite colour and deploy it across all apps in seconds.
  • You can build apps across a range of interfaces making use of all the native functionality.

If it sounds too good to be true, then it generally is

The biggest problem we see with low code is the age old challenge of vendor lock-in. This makes you, the customer, dependent on a single vendor for all services. Generally accompanied by an inability or substantial costs to switch. And if a chosen vendor goes under or stops supporting a platform, users run the risk of being stuck without the ability or affordable option to convert to another platform. When advocating for open standards, these lock-ins create market barriers.

You may not need to be a developer to use it, but you definitely need to learn how it works. The data modelling and workflow behind the myriad of applications has the potential to become a tangled mess. It’s also going to take quite a lot of time to understand what functionality actually exists. In our own research, we’ve found that documentation is generally unavailable, or of poor quality.

Most low code platforms also have their own cloud version control which is somewhat scary. It’s easier to break things and means you can say goodbye to using tools like Github to work in the open to the benefit of the wider community.

Function-first over user-first

The low code platforms we’ve tried place a big emphasis on making the lives of developers simpler (or redundant). Unfortunately, we notice this is at the expense of user experience. Low code makes it harder to take a user-centred, design-led approach.

When creating, you have to follow the platforms’ chosen UI components and design out of a prescribed box. Once completed, you can then tweak to meet your users needs. As the platform uses its own functionality, you are also restricted by what’s been created so far. It’s a world of functionality first and user needs later, which never ever ends well.

For a practical example, FutureGov spoke to a low code platform developer about displaying dates in a sentence. We desired to implement ordinal indicators (character/s that usually follow a number), so users would find it more natural. Unfortunately, there was no ability to add this function, which most coding languages offer.

Just because you can, doesn’t mean you should

One of the hardest things a product owner has to do is learn how to get good at saying no. One concern is that with accessibility to a low code platform, the answer to any problem becomes ‘let’s build an app’. Which is very rarely the right answer.

With low code platforms full of shiny tools, it becomes far too easy to grow lazy in our approach to innovative and creative solutions. And if you do choose to create an app, the drag and drop functionality makes it easy to even further complicate the task. Just because it’s available and because you can, doesn’t mean it’s needed. We run the constant risk of doing something because you can do it, not because it’s the right thing to do for the end user.

Our front end developer Chris, makes a good point:

“Low code reminds me of when I used to build WordPress websites. My clients were often people who tried to make a WordPress (or other CMS) website from a template or were sold a very cheap website. They found the template website, with all its widgets and plugins stacking up, became unwieldy and messy. Most of all, the website couldn’t do what was actually needed, and users hated it. It would become another generic website like a thousand others. That’s when they would realised the real need to spend a bit of money to get the custom built website that will do the job right.”

One argument in favour of low code platforms is that they are cheaper than bringing in skilled development teams. We’d love to be able to give you a proper cost analysis, but it’s pretty difficult to find out how these low code platforms pricing structures work (warning sign!). Offers vary from a wide range of flat monthly costs to tiers of licensing for different use types, something for all your different apps. From what we’ve seen, you get all the same cost issues as you would with any other vendor lock-in, plus more confusion.

We’ve spoken to a couple of councils currently prototyping low code platforms. And both those councils are now moving away from the platforms due to the expense.

I can understand the approach to low code of using it as a tool to aid the design of new digital tools and testing with users.

I get that it’s relatively quick to stand up a creation that might look better than existing interfaces.

But we aren’t convinced that you wouldn’t be better off investing in the right UX or UI designer, who could create the right platforms your users need.

A very wise front end-dev at FutureGov said of low code, “In an effort to make complicated things simple, it’s actually made simple things more complicated”.


When low code may not be the right code was originally published in FutureGov on Medium, where people are continuing the conversation by highlighting and responding to this story.

Original source – FutureGov

Comments closed