客户是一家围绕“政府客户提供软硬件整体解决方案”的深圳主版上市公司。客户不希望公开真实公司姓名，协商后使用“DS公司”。DS公司人数规模大约在800人左右，2021年的营收规模8个亿。在文章发布之日前，与红迅已经有了2期的合作，正准备进入第3期。接下来，我们将分几期来介绍与DS公司的合作。
一开始，DS公司找上红迅，是希望定制一套CRM系统。在沟通的开始阶段，红迅并不认为自己是合适的选择，因为市面上已经有了大量成熟的CRM解决方案。红迅带着这样的疑问，与DS公司展开交流，因为如果不提前推敲清楚其背后动因，可能谈到最后才发现，我们并不是最合适的选择，这样对大家都是时间的浪费。沟通后，我们发现，DS公司在与我们交流之前，一些主流的“SaaS CRM”和“传统CRM”都已经考察过一轮。甚至，在2018年就已经上过一套CRM，只是没用起来，根据他们本次的项目负责人（化名Ben哥）描述：其实，2018年的那一套CRM已经能满足我们80%以上的功能，但恰恰是那20%的不适配，让整个CRM经历了3年的挣扎，仍然无法全面上线。
是的，红迅10几年的信息化经验也越发能体会到：所以，Ben哥对此次选型的要求很明确：如果只是第1点，其实也不一定需要基于低代码平台来开发，毕竟低代码平台还需要额外花钱购买，直接找个软件开发公司可能更省事。但因为有了第2点要求，加上DS公司只有2个开发人员，工作量几乎满负荷，因此低代码平台似乎是一个不二的选择了。沟通到了这里，事态就很明朗了，对方就是奔着选型一个低代码平台来做CRM项目，对方非常关注低代码平台的能力。在此阶段，我们要做的事情就转换成：证明我们是一个优质的低代码平台。
这就落入到我们的强势领域了。但话说回来，市面上如此多的低代码平台，红迅的JPaaS与它们有何区别？又有何优势？红迅总经理老陈和笔者老黄，在低代码领域已经有10多年经验了，我们深知：所以，我们不敢说我们比别人厉害，只能对DS公司清晰传递红迅的几大定位特性，看看双方是否真是匹配。
那红迅有哪几大特性？低代码平台，其实是一个抽象的概念，它介乎于“零代码”和“完全代码”之间。
越倾向“零代码”，它就越是“面向非技术人员”。
越倾向“完全代码”，它就越是“面向技术人员”。
面向非技术人员，优点是易用，缺点是无法实现复杂业务逻辑。面向技术人员，缺点是需要技术人员参与，优点是能实现复杂业务逻辑。而红迅，是一个面向技术人员的低代码平台：
所以红迅在成立之初，就一直很关注自己面向技术的开发能力，它体现在3个方面：（1）我们采用零代码、可视化脚本、源代码扩展三层的开发体系。
既能尽可能在简单业务场景中保证易用，也能兼顾复杂业务场景的适配。（2）选用主流的、最新的技术栈。
而且我们还在持续不断更新。
这里要插入一个话题：——为什么红迅要坚持把架构从单体的Spring Boot转到Spring Cloud微服务呢？因为，单体架构各个组件都采用“紧耦合”的方式，很难对单一组件进行迭代，这也是10年几来，单体的低代码平台给客户诟病最多的地方。而转变成微服务架构以后，各个开发组件通过标准的接口相互调用，组件间的耦合变得更合理与有序，组件终于可以实现异步进化。但这一点对于“非技术选型”，其实对方并不关注，这也进一步夯实了我们“面向技术”的定位。
而对面向技术更彻底的一点是，我们全方位、无死角地开放源代码。这对于许多大型甲方客户具有极大的吸引力，加上我们对源代码的标准知识转移程序，使其没有后顾之忧。最终，我们给DS公司呈现出一幅与其它产品的“对比定位图”：
（公开资料，不方便把友商直接呈现，如有需要了解的读者，可以添加微信号“Redxun-Software”获取资料。）
在若干轮交流之后，DS公司最终选择了我们作为他的低代码平台提供商。但是！CRM呢？DS公司不是要开发CRM吗？是的，DS公司虽然在低代码方面选择了红迅，但CRM项目可以有以下3个选择：1、DS公司用JPaaS自己开发。2、外包给红迅开发。3、找红迅的生态伙伴开发。他们究竟怎么选择？这是下篇文章的内容。下一次，才是高潮！
