This post is a guest contribution from Shawn Xu (no relations). Shawn is one of the early engineers at Ascend.io, 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: https://medium.com/@vincentbacalso/imperative-vs-declarative-programming-f886d3b65595

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:

Efficiency:

  • 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?

Migration:

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

Cost:

  • 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).

本篇文章是徐晟洋(和我没有亲戚关系,纯属凑巧哈)在《互联》上的“嘉宾专栏”。他是创业公司Ascend.io的早期工程师之一,在卡内基梅隆大学获得了人机交互的硕士学位,并写一个与SaaS行业有关的干货很足的微信公众号《硅谷成长攻略》。


在低代码、无代码(LCNC)系列的上篇中,我们聚焦在这个赛道的整体版图、具体的分类,以及一张包含360家LCNC的版图。下篇中,我们将讨论这个浪潮的背后推动因素、分析一款LCNC的框架,以及LCNC在中国的发展。

LCNC兴起的背后

尽管不是新概念,这两年LCNC关键词出现频率越来越高,颇有”出科技圈”的架势。究其原因,主要有几点:

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

一个简单的例子是,假如我想告诉朋友怎样来我家,使用命令式,我会说”先上101高速,从71号口下来,路过邮局向右拐,开过711以后的第二个路口左转就是“。这是一系列能够完成任务的“指令”,却并不直接表达想要的结果;用声明式,只需要发给朋友一个地址,把导航的任务交给Google Maps就行了。
声明式的好处显而易见,工程师不用管理繁杂的中间过程,而是专注于”这段代码应该实现这个功能“。SQL是“声明式”编程类型最广为人知的例子之一,尽管已有45年历史,直至今天依然被广泛应用、拓展。著名的前端框架,比如ReactJS、VueJS,凭借着简洁易用的声明式API,快速取代了命令式的jQuery。同样的故事也发生在运维领域(Terraform)。

‌‌ 声明式代码与命令式代码(来源:https://medium.com/@vincentbacalso/imperative-vs-declarative-programming-f886d3b65595

从命令式到声明式的转变,正是“抽象化”的一个绝佳体现,也是LCNC运动的精髓。如果你还记得上篇中我们对LCNC的定义:

“LCNC将产品开发流程中一个或多个步骤封装起来,可以更简单抽象地完成”

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

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

当然,“我也可以搭XXX”的理念还未深入人心,现在依旧是对科技敏感的一批人“先富起来”。同时,许多LCNC工具还没能做到足够易用。但像上篇中所言,“快速建站”类产品的出现,上手难度的逐渐降低,“人人都是程序员”的一天终将到来。

坎坷的“云游记”:许多传统企业的“上云”之旅,几乎和唐僧西游一样艰辛。最大的困难莫过于技术人才的缺失。在科技行业的头部效应(薪资、光环、平台)愈加明显的今天,传统企业陈旧的组织框架很难笼络各地的技术精英。

LCNC无疑是这些企业最佳的“上云桥梁”。无论是数据云端化,还是打造个性化数字体验,是连通线上线下系统,还是流程自动化,这些公司无需雇佣昂贵的工程团队,反而可以依赖熟悉业务的已有团队,搭建合适的方案。

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

衡量一个LCNC产品,无论你是投资人,公司高管,还是技术负责人,都有一些共同的问题值得考虑。以下是我用来评价一款LCNC产品(下用X代替)的思路。

效率:

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

迁移:

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

成本:

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

服务与支持:

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

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

LCNC面临的挑战

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

向上销售的瓶颈:一款企业级LCNC产品,在竞争激烈的今天,很有可能选择“自下而上”的销售策略:定位小团队中的个人和一线工程师,快速获得产品反馈,通过廉价的口碑传播,达到一定规模后再雇佣昂贵的销售团队,争取大公司的大额订单。

向上销售是必要的,但对LCNC产品来说,这显得额外困难。大公司由于资源充足,很可能已经有工程团队搭建了”还凑合“的全代码方案。即使新产品的体验、效率更佳,在试图取代原有方案的销售过程中,很容易陷入内部政治斗争的泥沼。

这意味着大量的精力需要用于建立个人关系、允诺并实现各种定制,还得祈祷好运。另外,一旦涉及公司的核心业务或敏感数据,手握裁量权的管理者会格外慎重地评估,因为其绩效甚至前途都可能与之挂钩。

“买or造”与饭碗危机:没有人喜欢自己的工作被“抽象”或者“优化”掉——在公司成本和自己的饭碗之间,不会有人犹豫,这为LCNC产品(尤其是LC)带来巨大的进入阻力。

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

这样的LCNC产品,在营销和定位时,如同走钢丝:一方面,过于雄心勃勃的愿景容易引发工程团队的警惕;另一方面,过于低调谦和的姿态难以说服管理者其价值。

买or造”与客户公司成长:在衡量是否继续订阅某个LCNC服务时,客户需要比较“买”和“造”的成本和利弊,这是一个长期、动态的博弈。

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

LCNC在中国的状况

从全球范围来看,LCNC的迅速发展并不局限在美国,中国也有正在崛起的LCNC生态。

今年年初,钉钉宣布了打造低代码生态圈的新方向,让LCNC这一话题在企业服务圈子里火了一把,以至于有人将2021年称为“低代码年”

然而,当我们继续深挖,并且参考实际数据,会发现中国的LCNC版图比美国来的小得多:

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

当然,我们不能简单地将其归因为中国尚未成熟的B2B市场环境——毕竟,企业服务大赛道的发展速率是LCNC的好多倍。我认为,最重要的两个原因是:

垄断性的大型电商平台:如果回去参考美国的LCNC版图,会发现电商建站工具以及聊天机器人,占有很大比重。这些LCNC工具的发展,得益于美国大量的独立商家。这些商家有着从建站,到营销,到客户服务的多样需求。

而在中国,这样的需求并不常见——众所周知,几大电商平台占据了绝大部分线上购物的空间。而这些平台所提供的服务极其完整,已经涵盖商家销售过程中的方方面面,从上线店铺到营销,从支付到客户服务。

“买”比“造”便宜:根据职友集统计,北京程序员平均年工资为16.4万人民币,而外卖骑手的平均年工资则为12万人民币。更别提,许多应届程序员的年工资还不到10万元。

如此充足、相较美国廉价得多的技术资源供应,使得前文所描述的买、造天平,在中国大幅偏向“造”。同样,在美国相当火热的程序员工具、自动化工具领域,难以在中国吃得开——有工程问题?多安排几个程序员就行。

希望这个上下篇系列的LCNC介绍,能加深你对这个领域的了解,并且解答诸如“有哪些主要应用”、“为什么发展如此迅速”、“如何评价一款LCNC产品”的问题。无论你是投资人、创业者,还是在科技公司工作的工程师,LCNC都是不可忽视的新风口,可能会影响投资回报、创业和招聘的重心,或是饭碗的稳固。如同科技圈发生的任何事,机遇与挑战共存,积极应对永远优于苟安一角。

如果您喜欢所读的内容,请用email订阅加入“互联”。要想读以前的文章,请查阅《互联档案》。每周一次,新的文章将会直接送达您的邮箱。请在TwitterLinkedIn、Clubhouse(@kevinsxu)上给个follow,和我交流互动!