How Ant Insurance Scaled Low‑Code Front‑End Development for Complex Insurance Products

🙋🏻‍♀️ Editor's note: The author, a former Ant Group front‑end engineer, shares experiences and thoughts on low‑code exploration in the Ant Insurance scenario.

Preface

In October 2021 I began building low‑code solutions for Ant Insurance. After a year of development from 0 to 1, I reflect on the lessons learned, pitfalls encountered, and provide references for colleagues tackling similar technical projects.

From e‑commerce C‑end to insurance product C‑end

E‑commerce C‑end scenario

In the 1688 e‑commerce platform I worked on a guide‑shopping scene, essentially a product list. Frequent promotional events required redesigning offer cards, leading to repetitive development. By abstracting containers such as floors and tabs into low‑code components, we dramatically accelerated activity‑page creation.

Insurance product C‑end

Initially I assumed the insurance scenario would be similarly simple—few header images, some interactive forms, and a product‑image list. However, after inspecting the code, I realized the page required extensive component linkage and complex business logic, with a single generic insurance flow exceeding a thousand lines of code, not counting special‑case logic.

Thinking about platform design

Given the high complexity of insurance underwriting pages, we faced two options:

Abandon high‑complex scenarios and focus on low‑complex ones such as marketing pages.

Continue tackling high‑complex scenarios to fully support insurance underwriting.

Although the first path promises quicker ROI, data from FY21 shows that over 80% of non‑marketing commercial‑insurance scenarios are high‑complexity, making the first path insufficient.

Complexity

High

Medium

Low

Car Insurance

52

2

1

E‑commerce Insurance

10

12

14

Property Insurance

10

9

18

Life Insurance

8

13

8

Health Insurance

41

34

8

Overall Ratio

54.5%

31.5%

13.9%

商业险营销场景
营销组件基本都是低复杂组件，我们可以完整覆盖，但是由于保险业务的原因，运营主要采用图文为主进行活动页承接页搭建，新增组件量并不大。

Stakeholder concerns about future scalability reinforced the need for a platform that can handle high‑complexity scenarios.

How to improve the platform's ability to handle complex requirements

We identified two core capabilities from modern front‑end practice:

Componentization : Decompose pages into reusable components.

Module import : Leverage ES6 import (or earlier AMD/CMD) to split logic into granular modules.

We applied these principles through a material library and multi‑file optimization.

Material library : A low‑code component repository that lets developers drag‑and‑drop pre‑packaged components, making usage visual and “out‑of‑the‑box”.

To reduce the overhead of material development, we introduced an online material development workflow that connects material creation, configuration, publishing, and lightweight development in a single online pipeline.

Module import : Extended the low‑code code editor to support multi‑file handling and dynamic require statements, aligning with current front‑end development practices.

These changes lowered the entry barrier for complex pages.

Business experiments

We selected two brand‑new insurance underwriting scenarios—Savings‑type Whole Life and Student Insurance—to validate the platform.

Savings‑type Whole Life

Student Insurance

Experiment summary

Student Insurance was not launched due to business reasons, but the Savings‑type Whole Life page went live and remained in production for six months, containing roughly 1,700 lines of core logic—heavy for a low‑code page.

State sharing : Modules could not share global state. We introduced a plugin system that provides a small state‑read/write framework.

export default function xxxPlugin(ctx) {
  return {
    xxxx: 123,
    xxxxMethod: () => {
      // get state
      const state = ctx.getState();
      // update component state
      ctx.setState({name: 'pluginA'});
      // call other plugins
      ctx.call('pluginB.xxx');
    }
  }
}

Missing basic materials : Added essential picker and cascade components to the material library for insurance calculations.

These additions demonstrated that low‑code can support heavy logic when complemented by plugins and a robust material ecosystem.

Componentization of complex insurance scenarios

We split pages into three layers: a common underwriting framework, shared components, and business‑specific components. Global state and event‑driven linkage enable coordination across modules while keeping UI components lightweight.

The new architecture separates public logic from product‑specific logic, allowing developers to focus on business components while the SDK handles data fetching, state management, and extensibility.

Simple scenario usage

Beyond high‑complex insurance pages, low‑code excels in medium‑low complexity pages and card‑type UI. By embedding the low‑code editor as an SDK within the Needle editor, we achieved real‑time code generation and seamless integration.

Using D2C as a bridge, the same schema drives both H5 (React) and Cube (Vue) card products, providing a unified DSL for multi‑platform development.

Results from the second half of the year:

Total deployed assets: 101 (pages 65, components 36)

Lightweight development components: 83 (including H5 and Cube cards)

Written at the start of this year

In the B2B domain, low‑code empowers non‑technical staff, improving productivity. This year we continued exploring efficiency gains, experience improvements, and future trends such as AI‑assisted coding, while thanking all contributors who helped evolve the platform.

Low‑code is a valuable complement to traditional code, but its success depends on robust underlying capabilities and continuous investment.