低代码开发公司（及to B企业服务公司）发展贯穿这5个阶段的则是4条主线。
低代码公司发展5个阶段分别是：
● 阶段1，产品创意与商业模式选择
● 阶段2，产品打磨和商业模式初步验证
● 阶段3，创造销售打法和验证销售团队毛利模型
● 阶段4，扩张期的组织发展
● 阶段5，效率提升
其中每个阶段都有明确的任务。
所有低代码公司（及toB公司）不可能跳过这些阶段。而4条主线分别是：
● 产品和模式
● 业务
● 团队和文化
● 融资
每个阶段的关键任务和每个阶段之间都存在依赖关系。违背这些逻辑关系很危险，可能会事倍功半，更可能会一事无成。
给低代码公司的分类：
1.通用低代码vs行业低代码
● 通用低代码：跨行业的通用产品。
● 行业低代码：在某个行业内使用的产品
2.工具低代码vs商业低代码
工具低代码的主要特点是：为客户企业提供了一个提高管理效率的工具。与传统软件相比，工具低代码有很大优势，主要是“按年续费”有产品及服务进化机制上的优势
商业低代码的特点是：除了提供一部分“工具”价值外，还能为客户企业提供提高效率之外的增值价值，包括增加营收、获得资金等。
说白了，工具低代码通过提高效率帮助客户省钱，而商业低代码帮客户多挣钱。
从商业低代码角度分析，是打造产业互联网：
低代码公司有可能参与某些行业或领域的产业互联网改造。
这些改造肯定要用到低代码公司的数据或IT能力。
有些供应链、价值链的改造可能是低代码公司主导的，当然也可能是行业或领域的寡头企业主导的。
现在，国内的低代码公司有不少都在做PaaS，但目前大多还在较早期的阶段。
（1）低代码产品提供了二次开发接口，允许客户自有研发团队或其系统集成商在上面做项目级定制开发。
（2）能够让公司内部低代码团队在内部PaaS上开发。但在可用性、易动性、健壮性、可扩展性等方面应该都还有很大的提升空间。
能够走PaaS路径的一定是通用低代码产品。
对于行业低代码来说，做PaaS有点儿小题大做，做好数据库设计和可复用组件更靠谱些。
当然，如果为了让市场易于理解，把自己叫作PaaS为其他应用提供服务也未尝不可。只是心里要清楚一点，真别按PaaS的规格要求来做。
“PaaS路径”在中国能否走通、是否还有时间窗，目前依然还是业内争议较大的问题。
我个人认为，国内的通用低代码公司需要先完成自己商业上的闭环，也就是说先实现盈利，这更重要一些。
因为只有那些市场能快速检验的产品，才有机会快速迭代出真正市场需要的产品。
而快速完成小闭环，然后在其基础上不断做成更大的闭环，才是产品人应该具有的思维方式。
3.行业低代码从“工具”向“商业”转变
行业低代码公司的创始团队大多来自该行业，甚至投资方就是该行业的头部企业，拥有深厚的行业资源和深度的行业认知。
他们在完成了“工具”价值化后，在低代码功能和“数据”的基础上，有机会帮助客户企业获得更多客户、增加商业增长点、提供新的产品，甚至介入整个供应链和价值链的再造过程。
4.通用低代码增加“场景”价值
做通用低代码的公司，我觉得不能轻易放弃原有阵地转向“行业低代码”。
因为转“行业”需要有该行业的基因。我的建议是要设法找到多个行业中较常见的、能给客户带来增值价值的“场景”。
其实现在的通用低代码中就有不少这样的“场景”，这些低代码产品解决的是某种特定场景的业务管理需求。
相对“通用+工具低代码”而言，“通用+商业低代码”的使用场景更具体，业务边界也更清晰。
场景具体了、产品价值大了，营销环节才容易突破。
