Low Code No Code, Part II: How to Ride This Wave

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.

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.

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