Low Code No Code, Part III: Hands-on Experience with Notion, Retool, Bubble, Yida

This post is a guest contribution from Shawn Xu (no relations). Shawn is a software engineer at TikTok, got his Masters in Human Computer Interaction at Carnegie Mellon, and writes an informative WeChat public account on SaaS called 硅谷成长攻略.

In Part I and Part II of our comprehensive Low Code No Code (LCNC) series, we explored the category’s landscape and various factors contributing to its growth. In this Part III, we will share our hands-on experience of using some best-in-class tools to build a real application for a real world use case, in order to build an evaluation framework for all these LCNC tools. We hope this lens will be valuable for potential buyers of these tools and investors alike.

If you want the TL;DR version: the maturity of LCNC tools to build applications is similar to the early days of self-driving. We are still at the L2 self-driving stage, as in you still need engineering knowledge to make things work and the experience is by no means “automated”. The industry still has ways to go before reaching the L3 stage, as in “citizen developers” with little engineering background can build useful applications.

Is reaching the “L2” equivalent for LCNC valuable? Absolutely! It offers experienced “drivers” (in our case, app developers) a much better operating experience and boosts productivity.

Website builder v.s. Application builder

Before we share our evaluation findings and takeaways, it’s important to distinguish between “website builders” and “application builders”, because people often conflate a website with an application. Websites are usually static, focusing more on layout and content, while applications are highly interactive, addressing complex business logics and processes. As the shortage of skilled developers continues to grow, especially in expensive western countries, LCNC tools that support application building will see growth opportunities.

HireLN: an app for evaluating LCNC application builders

In Part II of this series, I proposed the Rule of 5 – a simple set of rules of thumbs to evaluate whether a LCNC product is worth adopting. While those rules are useful as a quick proxy, they are not detailed enough to examine a LCNC application builder from a developer’s perspective.

In front-end engineering, a common way to evaluate a front-end framework's performance and usability is to build a TodoMVC – a minimal but functional todo list application with a view, data model, and controller layer.

Borrowing from this idea, I decided to build HireLN – a hiring application built using only Low Code No Code tools to see how useful these tools are. HireLN consists of a public-facing application form and a review portal for a hypothetical HR team. After a “candidate” successfully submits her application, this app should enable the HR team to schedule interviews, interviewers can enter feedback, and eventually, the HR team can send out offers or rejection letters via email.

Why build an app for hiring?

It’s a common use case that every tech company needs, but typically doesn’t want to assign engineering resources to build in-house (engineers should be building products!). Each company also has somewhat different hiring processes and preferences, so a level of customization is needed and off-the-shelf solutions can’t always satisfy all the requirements. It’s a great use case to test the value of LCNC tools, most of which tout their ability to boost productivity for non-core but essential business needs, like hiring.

I built a worksheet on this Notion page to evaluate a list of requirements that this HireLN app should have and their relative importance.

Building HireLN with four best-in-class LCNC tools

I built several versions of our HireLN app, using four of the best-in-class LCNC application builders across the US and China tech market, to test out their strengths and weaknesses:

• Retool, a Low Code tool for building internal tools
• Bubble, a No Code tool for building any application
• Notion, a No Code tool for solving common business needs
• DingDing Yida (宜搭), a No Code tool for building any application, created by Alibaba

I’ve listed below all the different versions of HireLN I have tried to build. The ones with links have a functional prototype you can play with. The ones that do not have a link either did not work or took too long to build, thus defeating the whole purpose of using LCNC tools and failing our evaluation.

• Application Form with Retool (Stack: Retool, MongoDB)
• Review Portal with Retool (Stack: Retool, MongoDB, SendGrid)
• Application Form with Bubble.io (Stack: Bubble)
• Review Portal with Bubble.io (Stack: Bubble)
• Application Form with TypeForm + Notion (Stack: TypeForm, Notion, Integromat)
• Review Portal with Notion - Incomplete (Stack: Notion)
• Application Form with Yida - Complete, no public link available (Stack: Yida)
• Review Portal with Yida - Incomplete (Stack: Yida)

Long story short, I had the best overall experience building HireLN with Retool, though the initial learning curve was steep and dealing with UI responsiveness was frustrating. Bubble’s ambitious pure No Code approach is laudable, but the ambiguity of its natural language options makes some operations extra hard. While it was quite easy to build the public-facing application form with Notion (plus TypeForm) and Yida, they both struggled big time with the complexity of the review portal side of HireLN app, thus was not adequate enough to build a functional prototype.

Cold Start Problem

When developers jumpstart a new project with a full-code approach, a popular option is to adopt a bootstrapping toolkit. This toolkit would contain a minimum yet complete setup, with essential libraries installed, linters enabled, build and test processes pre-configured. Well-maintained toolkits such as Create React App also allow a great variety of customizations featuring different language flavors and community templates.

This same bootstrapping experience unfortunately is quite nascent in LCNC land. Sure, the LNCN builders provide functional templates: A PostgreSQL admin panel, an Amazon-like marketplace, an internationalized CMS, etc. However, starting a new project with these templates is like building a Lego Hogwarts with a Lego Death Star: good luck tearing down the Death Star and finding all the pieces you want to start building Hogwarts!

As I tried building HireLN’s candidate review portal, Retool’s PostgreSQL admin panel template felt like a good starting point - until I started demolishing pretty much the entire UI, picking only four out of the 27 built-in queries, and fixing all the broken connections, before building anything that specifically speaks to HireLN’s requirements.

More thoughtful approaches should be borrowed from full-code bootstrap toolkits, such as generating dynamic, user-specified starter projects (see conversational design below). This would, of course, require a much higher level of flexibility from LCNC products.

State Management Paradox

“States” dictate the current look and feel of an application. They can be as prominent as the current page’s URL, or as trivial as a dropdown menu opening or closing. They are hard to manage - questions like “where to store them” and “how to mutate them” can easily trip up a junior-level engineer.

LCNC builders get away with this complexity by largely hiding them completely. Users are presented with packaged “building blocks”, like a paginated table or a checkbox, without ever having to think about dealing with their internal states.

Simplifying “state management” may be well-intentioned, but unfortunately fails to meet the expectations of modern applications. The simplest example is “autocomplete input”, where users can type in something, and get suggestions from a remote source (think about the Google search bar). As common as this use case is, I wasn’t quite able to accomplish it with any LCNC builder (without crazy hacks), since the internal workings of text boxes and drop-downs are not exposed.

Modern applications are by nature rich in interaction. It calls for finer-grain control of states and allows modules to talk to each other. Providing such an ability to micro-manage, however, defeats the main appeal of building with LCNC. This paradox casts an impression that apps built with LCNC are subpar in user experience and for “internal use” only – a big limiting factor of LCNC’s adoption and expansion.

Painful to Scale

In software engineering, scaling has two major flavors: scaling the software itself (as it grows in features and complexity), and scaling the development process (as more developers collaborate to build this piece of software).

LCNC tools are still a bit young, compared to their full-code counterparts, to provide an answer to either of these two scaling challenges.

On the scaling of software, seasoned developers would make good use of abstraction and avoid frantic copy-pasting, in order to scale long-term maintainability. They are able to do so via declaring clear interfaces, and providing strict definitions of input and output -- something LCNC simply cannot provide with pure visual “building blocks”. When I worked on building HireLN, it was quite a pain to copy-paste ten text boxes, and then later have to go back to each one to modify the same attributes over and over again.

On the scaling of developer collaboration, no LCNC tool is able to provide an experience anywhere near Git -- the most widely-used version control scheme. After all, the difference between two code snippets is so much easier to examine than the difference between two built applications.

These two issues combined present unique challenges for LCNC users today, if they want to scale and maintain their applications. New development and version control patterns will eventually have to emerge to support LCNC startups’ future growth.

Absence of “Friends”

As a developer myself, “recreating the wheel” is something I rarely do unless for purely educational purposes (learning about a new tool, framework, algorithm, etc.). It’s essential these days for a developer to build in an open source community, full of “friends” who have already built something similar and whose knowledge (and code) you can leverage without worry.

Building in the LCNC ecosystem feels much more closed, where one can only build with a limited pool of building blocks. Let’s say we want a UI component to load data as user scrolls (an “infinite scroll” experience) – there is an abundance of full-code options available on GitHub, but none of them can be ported into a LCNC tool’s workspace.

Bubble ventured on this problem by allowing developers to create “plugins”, and make money from people’s adoption. However, most plugins are either too poorly maintained or too expensive (no free trial!). In the end, it’s the official, free plugins that are most reliable, so might as well make them built-in options.

Summary

In Part I and Part II of our LCNC deep dives, we presented a pretty rosy picture of this vast and growing category (see 2021 LCNC landscape below). This Part III post balances our analysis by describing more challenges, discovered from our own hands-on experience using some best-in-class tools.

As daunting as these challenges may be, the LCNC ecosystem is still in a great position to meet the demand caused by the ever-growing developer shortage crisis. More and more startup founders are turning to these LCNC tools to accelerate their own companies, which drives the entire ecosystem’s growth trajectory and market validation.

Adjacent to LCNC’s growth is the massive wave of API-centric products that are eating large industries, one API request at a time. Machine learning, crypto, finance, payment, healthcare, and many other once-complex domains are being broken down to just a few API calls.

The holy grail for LCNC application builders is no different from any full-code tools or frameworks – make application development of all sorts and flavors easy for as many developers (experienced and novice) as possible. This category is young and will need more time to mature. But just like automating self-driving, as adoption increases, more resources will pour in, competition will intensify, and the pace of improvement will accelerate towards maturity.