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 the 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 user's 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: