至于SaaS的申请，可以看出前几年发展不是很好。其中一个关键原因是SaaS应用本身并不能很好地满足用户的个性化需求。最多提供一些简单的字段和可配置的流程能力，超出这种能力的个性化需求很难满足。因此，虽然SaaS应用本身实现了服务的统一和标准化，但也降低了其灵活性和个性化。

如果需要满足SaaS应用的所有用户定制需求，SaaS云服务提供商本身已经变回传统的应用定制开发服务提供商，失去了云平台和云服务，充分发挥长尾优势的意义。

正是因为这个原因，低代码开发平台只能作为传统SaaS应用服务和用户之间的关键桥梁。也就是说，通过低代码开发，为终端用户发布了更多可配置的功能，但都是零编码的，既满足了个性化需求，又实现了SaaS业务的统一管理。

在这种场景下，低代码开发不是一个需要解决的开发问题，而是一个基于业务需求的快速在线应用的集成交付问题。也就是说，提供低代码开发能力只是你的SaaS运营服务对用户的一个关键扩展，你的核心是提供SaaS应用服务能力。

想清楚这一关键点后，低代码平台就成了SaaS应用扩展的关键。

然而，当我们重新思考软件系统本身的复杂性时，我们可以看到，应用程序的开发和交付不能简单地通过零编码或构建块来完成。

这时候你还需要做业务抽象和建模，开发和定制规则。

如果想要进一步可配置，就必须抽象出通用的业务组件或者业务能力，也就是说，首先需要在底层建立一个抽象的通用业务模型，然后支持前端可配置开发。

这种常见的业务模型是可抽象的吗？当我们的SaaS应用集中在一个高度垂直细分的专业领域时，这个模型的本质可以抽象和提取共性。像你一样，你是一个项目管理和协作SaaS应用程序，或客户关系管理应用程序。然后就可以抽象出这种垂直应用的底层业务模型。但是如果要推广到所有的行业，所有的应用都可以抽象出大型的、完整的模型，这和我之前认为复杂系统没有银弹的观点是相反的。

正是因为这个原因，这里给出了第二类低代码开发平台的开发方向，即作为垂直细分的SaaS应用的关键扩展能力，而不是开发一个大型完整的零代码低代码平台。