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.

A screenshot for part of the HireLN Worksheet

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.

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.

A few example challenges of building HireLN with best-in-class LCNC tools

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!

Building a Lego Hogwarts with a Lego Death Star

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.


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.


低代码、无代码(三): 用Notion, Retool, Bubble, Yida搭招聘应用程序








在本系列的第二篇中,我提出了评测LCNC产品的“Rule of 5”。这个评价体系足够快捷,却不够细致,难以在重要的购买决策时提供有力支持。

在前端工程领域,我们最常用来评估一个代码框架的方式,是用这个框架搭一个TodoMVC——一个迷你、但功能齐全的待办事项应用(Todo list)。




原因很简单:所有公司都有招聘的流程,但通常不愿意倾斜宝贵的工程师资源,打造一个全新的内部招聘系统。在此基础上,每个公司的招聘流程和偏好,都有些许不同,很难通过定制市面上的第三方工具,来满足所有需求。用招聘这个各个科技公司都需要,但又与核心业务无关的use case来评估LCNC工具很合适,因为绝大部分LCNC厂商都会以这种use case来宣传和体现自己工具的价值。





  • Retool,一款主攻企业内部应用的低代码(LC)工具
  • Bubble,一款主打无代码(NC)建站的工具
  • Notion,一款无代码的通用协作类工具
  • 钉钉宜搭,一款来自阿里的无代码建站工具





在我们用代码写一个新项目时,通常会采用一个流行的“工程脚手架”。这个脚手架包含了常用库、初始代码、构建流程、静态分析,等等。像Create React App这样维护良好的工具,还可以让工程师自定义想要的功能和模板。













在软件的扩展性上,有经验的开发者通过适当的抽象化,避免复制粘贴代码,使得代码更容易维护。最常见的方法例如定义标准化接口,确保可预期的输入和输出变量。很明显,可视化组件很难做到同样的事,LCNC在这方面也还差得远。在搭建HireLN的过程中,我经常得Ctrl C + Ctrl V十几个文本框组件,回头来一个一个地修改他们的某个属性。