Cabin in the (low-code) woods

With no prior experience of these platforms, the idea was to see how quickly our people with different backgrounds (some with decades worth of software development experience) could get something done with the tools (all of which have been advertised as a solution to shorten delivery times and make business users an active part in the digital development domain).

But before we get to the woods part, let’s focus on the basics first.

What are low code platforms?

Originally the term to describe these type of tools was coined in Forrester report in 2014 (as far as extensive research on the internet resulted in):

The premise is that, with these tools, there’s no longer need to rely on software development teams as the drag&drop UIs and readily available other components provided by the LCDPs make development of new digital service so easy that this work can be given to the business users instead of hiring own developers or external consultants to code the required programs "by hand".

One could argue that WYSIWYG (what-you-see-is-what-you-get) HTML tools such as the Dreamweaver fall into this category and those have been out there already for decades. Those apps have generated websites quite easily, but the code produced has not been that great for further development outside the original editor.

There’s a huge amount of these platforms out there and quite a limited amount of material is available outside the platform vendors’ own blogs and other documentation. Finding any neutral source describing different platform capabilities and sharing success stories is a mighty task on its own.

While some platforms advertise quick time-to-market for new solutions, others focus on the sheer amount of *code produced. Cherry Picking the most obnoxious claim encountered was this one platform which went especially far by claiming that their platform produced ~30k lines of code in a few seconds and created an app that would take years to complete by a human developer. They even go as far as saying:

As it turns out, such hyperbole claims might not be actually anything close to reality. Technically it was true that the platform in question produced a lot of code (yes, we tried it), but the end result was nothing usable and maintaining the amount of machine generated code would be a nightmare in the long run. You really couldn’t make any changes to it “automatically”, so anything that came out from the machine was the final deliverable. The amount of code does not translate to quality and the capabilities of the software. This was of course the worst case example, but it kind of set the bar very low for other trials.

How did the weekend hackathon play out?

As Futurice strives to be the Ultimate Learning Platform, venturing off to a mildly isolated location to learn about new technologies is nothing new. Before COVID era there were CodeCamps arranged at least yearly and people from all offices came to check out the next cool thing. Taking some learnings from those events and sprinkling on some no-code mystery made the perfect setting for the participants to engulf themselves in the unknown.

So we had ventured to the wilderness with our laptops, electricity, internet, and an undisrupted flow of coffee, soft drinks and snacks. Hacking started on Friday evening and the demos were to take place on Saturday evening. To set the mood, we also watched the movie classic Hackers (1995) to maybe learn a few tricks from their playbook.

The mission briefing was simple: Try out one or many LCDPs and create something that you can demo for other participants at the end of the hackathon. “Anything” meaning: a working UI, possibly interaction with externally hosted data, working Identity and Access Management etc.

Participants were allowed to purchase some individual licenses (e.g. a “developer account”), but no huge investments should be made to get the job done - after all the platforms one promise is to keep the costs down. As we would soon learn about the wide variety of LCDPs licencing models, this was a pretty good restriction in terms of monetary investment.

For demoing purposes, we also set up a few different databases with mock data in Azure which could be connected from the public internet (secure routing from the SaaS platforms to internal data sources is another topic entirely). This would be quite common scenario in the real world, where a custom application is required to somehow interact with the business data stored somewhere (on-premise on in cloud services)

And so the competition was on!

Which platforms were tested and how?

As the amount of different platforms is enormous, we had pre-selected a bunch of the most known brands as well as a few lesser known products. Over the course of the weekend, we tested out following products:

• Appgyver
• Appian
• Appsheet
• AWS Honeycode
• Mendix
• Microsoft Power Apps
• OutSystems
• Salesforce Lightning
• Server Gardens
• Wavemaker
• Retool (not actually a low-code platform as is)

Most of the platforms offered at least a free trial or fully free developer accounts, but those unfortunately come with some limitations we will learn a bit later. All of the mentioned platforms made it possible to start trying them out in a self-service manner.

We would have also wanted to try Visual Lansa (as it has been advertised in many places), but the only way to start working on that technology required a call with their sales and that didn’t work out so well with our hackathon schedule. As with any SaaS applications, I feel that there should be an easy try-before-you-buy approach also for these LCDPs which are sold for the “citizen developers”, as this is mandatory to validate the technology and see if it is at all usable for your use cases.

Also it should be noted that Salesforce Lighting relies purely on the Salesforce ecosystem where Microsoft Power Apps require the Microsoft Dataverse as its main source of data and piping any external content to either of these platforms would have required quite extensive work to be done in advance. These are not the platforms you just set up and start developing but, if the groundwork has been done, the experience and results would have been quite different.

As a bonus, we used the Node-Red platform to create REST APIs in a “low-code manner” in order to provide data from our Azure-bound databases for the LCDPs (for those which could only connect to external data using an API). This test was the result of several platforms lacking the possibility to connect to any external data using a native connector that could be used to access a certain type of database. This is by no means a production grade solution to the connectivity requirement in any real life use case, but we honored the LCDP mentality and tried it anyway.

General findings of the platforms

As stated earlier, most of the services offer a self-service signup where you can get to work simply by giving a few details about yourself - no credit card needed! This allows you to get the general feeling of how the platforms work and enable you to experiment with building the UI with different views etc.

Building the UI

For quick prototyping purposes, you can create simple UIs quite easily (as an alternative for designer apps like InVision, Figma and Zepplin). This would in practise mean interactive wireframes, as utilizing the off-the-shelf standard components might make visual designers lose their minds as modifying these components to look & feel like a corporate design system is not very feasible. There are themes built inside some platforms, making it possible to quickly change the main color palette etc. Basic input fields and buttons are what work well out of the box.

Data sources

But what is an UI without data? Most platforms offered some way to access external data. These native connectors varied quite a lot in their ability to work with different database products. Appgyver offered only a support to utilize REST API endpoints while OutSystems had native support for (the very enterprise-y) Oracle, IDB2, MSSQL and MySQL. Some platforms require you to purchase a license just to get access to external data sources, so be prepared to start paying in early stages of development unless you only utilize the data that is produced and consumed inside the app itself.

What comes to AWS Honeycode, you simply cannot connect any external data sources to it. Period. You have the tables created inside the app to store any data produced by the users and that’s it. Also you can’t add any images to the apps, so you are basically left with an interactive form maker to input data into a spreadsheet hosted inside the application itself.

Identity and Access Management

For user management, many platforms had this built in / included in the basic license to some level. Usually this means some set of internal users who share the same level of access to the system. For external use, platforms require extensive licenses and these license types vary a lot. With OutSystems, you need to have the Standard version (10k / month) to support any “external users”, so if you are building an end user facing product, this is the minimum level required (no matter if you have a single user or thousands). And you need to buy an extra license if the number of users is above 10k (no price available on the website).

With Appian, Salesforce & Power Apps, you’ll end up with per user based licensing that can range from 6eur/login to 15eur+/external user/month and even higher costs for internal users with more functionalities that are offered inside the platform. This will bring the total cost of ownership very high if the service you are building would be published to external users and you start measuring the number of users in hundreds or thousands.

Security and Complience

At any point during the weekend was our hacking crew not presented with options to select where to host our services. Browsing the documentation of the biggest services reveal that you can indeed influence the region where your software is deployed, but for all services this is not clear. Most platforms have been certified for HIPAA, PCI DSS etc. based on their Security & Compliance pages, but the information is scattered all over the documentation and it is not easy to get all the facts from one place.

The deployed infrastructure varies a lot. For example, in the case of OutSystems and Appian, you are actually getting an AWS VPC deployed to some AWS region with few security group rules in place. You don’t have direct access to manage the underlying security rules etc.

Platforms such as OutSystem & Appian also offer on-premise hosting for the top-tier paid plans. However, diving deep into the security documentation indicates that e.g. OutSystems requires IIS6 support enabled on your Windows server, which indicates that the core system might rely on some outdated components, which raised quite many questions from security point of view. Hosting a paid LCDP on-premise actually also "doubles the costs", as you are paying for the license AND for all the hardware and management of the service in your own data center.

The Vendor Lock

All things above considered, the most critical thing to keep in mind with any LCDP is the complete vendor lock once you've selected your platform of choice. After you’ve started to build some solution on top of a paid LCDP, that’s the platform you will be stuck with for good. The license costs etc will keep rolling in the future and all future development must be done with the technology offered by the platform vendors. This is something that requires a lot of risk assessment and calculating the lifetime costs of your service. A simple application can be set up with quite minimal costs, but depending on the features the system would utilize, the end result might be extremely high license costs in the coming years.

In case of custom, open source based development, a well thought out service can be moved from one cloud platform to another as well as the development responsibility transferred to a number of vendors quite painlessly. Also the costs of the infrastructure are usually measured in the hundreds / month rather than several thousands, even tens of thousands per month.

There are ways to “export the codebase”. E.g. for OutSystems, the “unpriced” Enterprise plan (“contact sales for quote”) is the only option offering exportability of the codebase (meaning you can technically get your application out of the platform, but only when you cancel your plan completely). The exported code is something that technically can be compiled and make work elsewhere, but any modifications to it are practically impossible due to the layers of machine generated code without any developer documentation.

Conclusion

Writing this as a representative of a custom software delivering consultancy, it might make me as biased as the platform vendors pushing their own technology as I would be pushing my custom approach. But also, as a consultancy, we at Futurice always focus first on delivering the best value for our Clients and help to select the best tools that get the job done. If that tool in some case would be an LCDP, we would surely recommend that.

Based on our few days of exploration, the main use cases for the platforms would be quite limited in scope, number of users, and focusing on a dataset that is hosted within the platform or inside the vendor ecosystem (e.g. Microsoft and Salesforce). High vendor lock-in risk combined with the inability to export and develop the services outside a selected platform possess very high business risk as many of the platforms are in early stages and might go out of business (taking the solutions built on top of them down with them).

In terms of long-term maintainability, security, and finding talent to keep the business rolling, it is quite obvious that these platforms have a long road ahead compared to productized SaaS services (one-size fits all software) or fully custom software built on top of widely used open source technologies with many vendors who can maintain those solutions long into the future.

LCDP doesn’t mean “no training needed”. To leverage the capabilities of these platforms requires to thoroughly go through the platform developer courses (e.g. OutSystems has quite extensive video training materials) and most likely participate in classroom sessions for intensive training. There are support portals with peer support available, but it will be very tricky to find solutions for problems in any company-specific use cases.

The main selling factor of LCDPs (as stated by their builders) usually focuses on the myth that “custom software takes a long time to build, a team of a dozen developers and a large sum of money”. From the point of view of long-term software developers (+myself as something between tech & business), we have mixed feelings.

If you do master your platform of choice, you can get certain types of apps done quicker than coding from scratch. This however requires a lot of training and the platforms come with quite expensive licencing models where you could end up paying 120kEur+ a year just for keeping the solution online (OutSystems Standard plan) for a system which would run as “custom code” on Azure or AWS for fraction of the cost. Besides the running license costs, you would most likely end up paying external specialists the same rate as for any custom built solution, so the total cost of ownership would be on par with the custom built one.

For highly complex apps, the platforms would struggle to provide enough flexibility and security controls to satisfy all the requirements of a business critical application. As the infrastructure is always a bit of a black box and you have very limited control on e.g. the security settings, deploying these apps in an environment where personal information or other highly confidential information is processed would be quite risky.

So at the end of the day, would we recommend a no / low code platform to our Clients in any use case?

As we consultants tend to say, “It depends”.