An engineering approach to choosing a Low-Code tool
In the context of defining the future architecture of TheFork internal tools, I conducted a study of the various low-code platforms available on the market.
Even though this study have not yet been followed by a concrete implementation of one of those platforms, I thought it was worth sharing given the lack of“objective” literature available on the topic.
Introduction
First question you should ask yourself is “Should I build my internal tools from scratch or buy a platform to speed up development ?”.
After building our internal tools from scratch for the past 15 years, with not always the best user XP nor the best time to market, my hypothesis was that it was worth looking at the buy option.
What should you expect to improve with a low-code platform :
- It’s faster to build user interfaces, expect x5 / x7 times faster than traditional front-end development
- Most of them provide a deployment platform, your application is immediately available to your users. They usually also propose an on premise version of their platform, making it available in your private network
- They usually provide a set of integrations with third parties, making it easy to interact with Salesforce, Snowflake, Jira, Stripe, Github, Slack… Although the studied solutions propose quite divergent sets of integrations, it’s worth looking at this to pick your solution
What are the downsides of using a low-code platform :
- Vendor lock-in, once you went all in with a platform, it may be prohibitive to escape it, leaving you exposed to price increases and other undesirable changes to the platform
- It can be quite expensive depending on the size of your team, think of 20k$ / year for 100 users and 200k$ / year for 1000 users, given the price is always per user
- Building continuous integration, with good automated testing coverage is not yet a very mature feature of those tools
- Requires building custom components when the right feature is not available on the library, which can be a hassle
Study results
My criteria for a low-code platform were :
- Javascript coding, as it’s the most widely known language in our tech teams
- Focused on building web based user interfaces
- Provides a testing framework
- Custom component building is possible
In my study, I’ve considered what I thought were the main competitors in this field, leaving aside many others.
Included :
- Retool, Appsmith and Budibase : User Interface in browser studio builders that uses Javascript to customise behaviours.
- Airplane : A library of advanced React components
- Openblocks : An open source copy cat of Retool
Purposely excluded :
- Power Apps : While it seems very powerful (tons of integrations), I get stuck with the developer XP, that didn’t sustain at all the comparison with the others. Uses Power Fx as programming language.
- Quickbase, Bubble : Purely no-code platforms, that don’t seem flexible enough
- Mendix : Desktop studio app, uses Java as programming language.
- Oracle Apex : Uses PL/SQL as programming language.
- Zoho creator : Uses Deluge their homemade programming language 🤯
Below is a table summarising the study. Please note that the prices displayed hereafter are public prices, as of August 2023.
Picking a contender for a deeper study
From the table above, I pulled the following conclusions
- Airplane.dev look like a great tool, but their high public pricing was a blocker for us.
- Budibase doesn’t offer yet a way to manage users through an enterprise SSO
- Appsmith doesn’t handle yet apps versioning
- Budibase & Appsmith doesn’t offer yet a testing framework
- Openblocks was far behind the other regarding features and components, which jeopardised the benefits of using a low-platform
Which make me lean toward Retool for moving forward with a proof of concept
Deep diving on Retool
Next step was to do a thorough study of Retool solution.
For proof of concepts, I chose to build copies of internal tools we had developed internally. The initial idea was to copy three of them, each built by different teams:
- A tool that calculate the average price of restaurant based on the menu items. This needed to be embedded in Salesforce so that end users didn’t have to switch between tools. This app requires third party integration.
- Another tool that provides a view of all emails sent by our platforms, useful for customer support when someone complains about not receiving an email. Which was a plain & simple use case.
- And a last one that allows our marketing people to create geographical area on a map and make them available through our search engine. This one was not possible to build without going through the custom component framework.
I took personally care of the email viewer. It went so fast that I didn’t stop at my initial list and built two more substantial tools :
- A copy of our Diners management app, that allow our customer support to edit Diner’s account, comply with GDPR, see the list of bookings and loyalty rewards. It took me less than a day to build the copy while the original vanilla JS / HTML front-end was probably built in more than a week
- And a copy of our SEO management app, a tool where our SEO Gurus combines rules to generate sets of pages with templated contents. Probably the tool using the most complex components in our back-office, and it was possible to build it only using the standard component (here I have to confess that our Retool pre-sales engineer helped me to bootstrap), again very fast to build compared to the original React front-end
It lasted for about 6 months in dotted line, during this time the Retool product kept busy, they released features & fix every week, with some great improvements : A useful debugging console, lower prices, refactoring of their very central table component…
Conclusion
The conclusion of this study was that Retool would be our best fit if we were to use a low code platform to build our internal tools.
- 95% of our use cases were covered by the component library
- Datasources integration offering had a good synergy with our set of software
- It is possible to sync the users with an external identity provider (Auth0 in our case)
- The weak points of Retool are the testing framework and the custom component building, but they are actively working on those topics
