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

(The audio version of this post can be found on the Interconnected YouTube channel):

In Part I of this two-part Low Code No Code series, I focused on the overall Low Code No Code (LCNC) landscape, major product categories, and a landscape graphic of more than 360 companies in the ecosystem.

In this Part II, I’ll share some thoughts on the driving factors behind this latest LCNC wave, a rubric for evaluating different LCNC products, and how LCNC is developing in China.

Behind the (Recent) Rise of LCNC

Low Code No Code is actually a 20-year-old concept. It’s enjoying a recent boom for a few reasons:

Imperative to Declarative Programming: Imperative programming is all about “commands”, while declarative programming describes the “end result.”

A good example would be telling some friends who are visiting you where your home is. In the imperative way, you’d say: “Get on Highway 101, exit at Fair Oaks Avenue, turn right at the post office, and second left after the 7-11.” It’s a list of commands that should get you the result you need, but doesn’t actually describe the result. In the declarative way, you’d simply declare the address of your home and offload the navigation to, say, Google Maps.

Declarative programming has its apparent advantages, where engineers can focus on what the end result should look like, rather than the messy intermediate commands to get there. SQL is one great example that embodies the declarative paradigm, thus it remains one of the most widely used query languages, even though it was created more than 45 years ago. Similar trends are emerging in different layers of the technology stacks, from frontend frameworks (ReactJS, VueJS) to infrastructure management and DevOps (Terraform).

The shift from imperative to declarative is yet another story of abstraction, which is at the essence of the LCNC movement. Recall from Part I our definition of LCNC:

LCNC abstract away one or more steps in the software development lifecycle.

LCNC, in essence, furthers the abstraction progress of declarative programming, so the act of “programming” itself is removed.

Imperative vs Declarative programming (source:

Digital Expressiveness: As more of our lives become digitized, the need to express ourselves digitally also increases significantly. From a wedding registry to an online shop selling home-made desserts, from a customized team-building exercise to a mobile game’s fansite, anyone can become a “digital builder”. You don’t need a computer science degree, you just need the right tools.

We have yet to witness the full power of this trend, as many tools still remain technically challenging and require some amount of heavy lifting. But some of the companies I mentioned in Part I, especially those in the “Rapid Builders” category, have begun to smooth out the rough edges to make “everyone a developer”.

Journey to the Cloud: Much like the “Journey to the West” (a classical Chinese fiction depicting the epic pilgrimage of a monk and his disciples to obtain sacred Buddhist texts from India), traditional enterprises are experiencing similar hardships as they transition to the cloud.

The biggest challenge comes from the lack of engineering talents. Old organizational structure and culture make attracting top talent and competing with companies like Google and Facebook difficult.

LCNC becomes a critical interface to help bridge that gap for these traditional enterprises. Moving data from offline to online, launching new cloud-based experiences, stitching data together from various systems - the latest LCNC products have made all of these engineering-heavy workloads easier and smoother than ever before.

Rule of 5: Evaluating LCNC Products

With so many different products, nibbling away at different layers of abstractions in the stack, how should you evaluate them, either as an investor, a company executive, or an engineer?

I’d like to propose the “Rule of 5”. Here’s how it works for a hypothetical Product X:


  • Does X cut down the time from planning to launching by at least 5 times?
  • Can one person build an MVP (minimal viable product) with X based on just tutorials and documentation in 5 hours?
  • Can a new employee be ramped up to become productive using X in 5 days?


  • Can existing data and processes migrate onto X within 5 months?
  • If customization is required before integration, can X deliver that within 5 weeks?


  • Compared to building a similar solution in-house, does using X cut down total cost by over 50 times in the near term?
  • If a company uses X 5 times more, or bought 5 times more seats, would the cost increase linearly by 5 times as well?

Service and Support:

  • If X goes out of service or goes bankrupt, can features and business logics built on X run normally after 5 days of migrating to something new?
  • Can questions posted on X’s community forum get answered within 5 hours?
  • When using X, are more than 5% of the problems encountered not solvable by other customers, thus must engage its support team?

From the customers’ perspective, this list of highly practical needs is what sets truly useful LCNC products from the crowd. Of course, as mentioned in Part I, LCNC products differ in their abstraction levels, so the quantity “5” should not be used rigidly.

Challenges Facing LCNC Products

As hyped as the market may be, we have yet to see clear winners or many LCNC unicorns emerge, compared to other SaaS sectors. Here are some unique challenges that the LCNC category is facing:

Selling Into Larger Enterprises: Like other SaaS offerings, most LCNC products start with a bottom-up sales strategy for good reasons: acquiring product feedback for faster iteration and using a community-driven approach to spread awareness.

That can work for a while in the beginning, but as the product and company grow, it will inevitably have to scale by acquiring bigger customers with larger purchase orders. This scaling into the enterprises can be especially hard for an LCNC product because chances are these larger enterprises already have home-grown, all-code solutions for many business use cases that work well enough.

Selling into this environment can only mean one thing: navigating a muddy pool of internal politics. Success here would require a ton of relationship-building, a slew of shiny features, and more than an ounce of luck. If the LCNC product happens to replace one or more critical business processes owned by an executive, things may get even more difficult, as that executive’s career may be on the line.

Buy vs Build and Job Security: No one likes his or her job “abstracted” or “automated” away. Few people would hesitate between saving their own jobs versus saving some money for their company by adopting some LCNC products.

Interestingly, more often than not, these are also the same technical teams making the evaluation and decision between buying or building their own all-code solution. This is especially true when the company executives are less hands-on, delegating these decisions to the appropriate tech team managers or leads.

Should the LCNC product pose a credible threat to the engineer team’s job security, the final decision is usually a “no”, followed by the comment: “Meh, we can build this stuff in a week!”

Buy vs Build and Company Growth: For a customer company, the “buy vs build" discussion is not a one-time decision, but an ongoing process that changes dynamically as that company grows.

When a customer company is young and lacking in engineering resources, “buy” is often the right, if not the only, choice. However, as this company grows, the balance slowly tilts away from buying towards building. As being a bigger company also means the need to buy more seats, incurring more usage, and signing larger contracts, allocating a few engineers to build a homegrown solution may start to look like a better use of resources. At this juncture, the LCNC product will have to pitch (and likely discount) hard to fight its customer’s urge to build.

LCNC in China

The US is not the only place where the LCNC ecosystem is red hot; China has a burgeoning ecosystem as well.

Earlier this year, Alibaba’s enterprise product DingTalk -- a hybrid of Slack, Gmail, and Atlassian -- announced its new direction of building an ecosystem for low-code applications. This announcement triggered much enthusiasm in China’s enterprise product community - some even called 2021 “the year of low code”.

That being said, China’s LCNC landscape is still significantly smaller than that of the US. Between 2016 and 2020, there’s only 59 funding events capitalizing a handful of LCNC companies in China. Most of these companies provide either collaboration tools or GUI-based site builders.

A summary of notable LCNC investments in China, 2020-21

It is a bit naive and simplistic to attribute the differences to China’s less-developed B2B enterprise market, which actually outgrew the above LCNC figures by a few orders of magnitude. I think there are two other more nuanced factors at play:

Monopolistic Ecommerce Platforms: The two main sectors that are fueling the US’s LCNC landscape are e-commerce site builders and chatbots (see more analysis in Part I). These products thrive because there’s a vast number of independent retailers, who need an online store front with custom branding and customer service functions.

None of that is necessary in China, because its e-commerce industry is dominated by a few mega platforms -- mostly Taobao, JD, and Pinduoduo. And all these monopolistic platforms already provide a complete set of end-to-end retail solutions, from payment to branding to customer service, in order to keep sellers on their platforms.

Build is Cheaper Than Buy: This reason is perhaps more obvious, but we should still put some numbers around it. According to Jobui, a popular employment data site similar to Glassdoor, an average developer in Beijing earns 164,000 RMB (25,400 USD) per year. A food delivery driver makes 120,000 RMB (18,600 USD) per year. Junior-level developers often get paid much less than the average.

Thus, the ample and comparatively cheap engineering supply makes “build” much more attractive than “buy” for most use cases. When it comes to developer tooling and automation -- a crowded LCNC domain in the US -- Chinese companies tend to “throw bodies” at the problem to build their own solutions, rather than considering buying LCNC products off the shelf that may be better. It’s an easier decision than their American counterparts.

I hope this two-part series on the world of Low Code No Code gives you a solid grasp of what the main use cases of LCNC are, why this space is growing fast recently, how to evaluate a product, and a comparative lens to how it’s evolving in the US and China, respectively. Whether you are an investor, founder, or employee working in any type of tech company, it is a space worth paying attention to. How LCNC evolves in the future can affect your investment return, how you start your next company, or simply your job security. Just like anything in tech, both the downside and upside are immense.

To read all previous posts, please check out the Archive section. New content will be delivered to your inbox every Sunday. Follow and interact with me on: Twitter, LinkedIn, Clubhouse (@kevinsxu).





编程思维变化: 一个横跨各个技术栈的趋势,是从“命令式”(Imperative)向“声明式”(Declarative)的转变。两者有何区别?命令式的核心在于“下指令”,声明式的关键在于“最终结果”。

一个简单的例子是,假如我想告诉朋友怎样来我家,使用命令式,我会说”先上101高速,从71号口下来,路过邮局向右拐,开过711以后的第二个路口左转就是“。这是一系列能够完成任务的“指令”,却并不直接表达想要的结果;用声明式,只需要发给朋友一个地址,把导航的任务交给Google Maps就行了。

‌‌ 声明式代码与命令式代码(来源:



对“全代码开发”抽象化的尽头,便是LCNC —— NC最甚,把写代码本身给抽象没了。

数字表达欲: 自从我们的生活逐渐转移线上,大众对打造个性化的数字体验需求日益增加。从一个婚礼网站,到一个卖手工艺品的网上店铺,乃至一个公司内部团建小游戏,只要使用合适的无代码工具,都可以很快实现、上线。




Rule of 5: 如何评价一款LCNC产品



  • 与原有的流程比,使用X,新功能的开发时间是否缩短了五倍以上?
  • 五小时之内,能否仅靠X的新手导引和开发文档,搭建一个简单的MVP?
  • 新员工入职,能否在五天内成为X的行家?


  • 公司内已经建好的系统,能否在五个月内完全迁移到新平台?
  • 为接入X产品而需要做的定制接口、逻辑,X公司能否在五周内交付?


  • 与聘请一个工程师团队相比,使用X的短期总成本(TCO)是否在五十分之一以内?
  • 如果使用X的人数增加五倍,或是使用量增加五倍,收到的账单会增加五倍吗?


  • 如果提供X产品的公司突然倒闭或下线,经过五天的抢救和迁移,我们基于X的业务还能正常运转吗?
  • X产品的在线社区(论坛、Slack)里,提问是否在五小时内能得到解答?
  • 使用X产品时,是否有超过5%的异常是我们自己解决不了,需要找客服的?

从使用者的角度来说,这个框架可以作为参考,区分出更为优质的LCNC产品。当然,正如上篇提到的,不同的服务对于工程流程的抽象程度不一样,套用“Rule of 5“的时候不应太死板。


尽管LCNC热火朝天,真正”跑出来“、成为独角兽的产品却并不多。大部分LCNC产品主要走to B路线,不免会遇到中小to B公司的难关,除此之外,还有一些这个领域独特的挑战。





很多时候,由于管理层通常不自己写代码,评估一款LCNC产品的职责被交到tech lead手中。如果这款LCNC产品带来强烈的竞争和危机感,很有可能过不了这个”鬼门关“。最终,这样的评估会以工程师们 “这个没啥了不起的,我能在一周内搭出来” 的结论结束。



在客户公司规模尚小,工程力量不足的时候,“购买”是很划算、甚至是唯一的选择。 然而随着公司成长到一定规模,买和造之间的博弈逐渐变得模糊。如果继续”购买“,越大的公司意味着越多的用量、用户席位,以及越高的订单价格。另一方面,分出几个工程师来完成一个小项目,不再显得那么奢侈。如上图所示,当到达某个临界点,购买总成本大于自建成本,这个LCNC产品的订单就变得岌岌可危。





  • 从2016年到2020年,只有59起LCNC公司融资事件。
  • 这其中的大部分公司,提供的都是在线协作或建站工具。