我们可以将低代码平台的发展过程划分为 3 个主要阶段：MVP 阶段、成熟期、超越期。
- MVP 阶段一般在 3 到 6 个月，时间比较短，主要目的是快速试错、快速闭环。这个目的之外的工作一般都“先放一放”，因此这个时候，备忘录里往往会留下许多待改进条目，但这些欠债在成熟期都要一一偿还。性能问题实际也是一种欠债。而且，性能与功能是相生相克的，功能追加到一定程度就必然要停下来专门处理性能问题，两者呈现出一种螺旋式上升关系。
- 成熟期是实现低代码平台过程中的一个比较艰难的阶段。随着 MVP 阶段的需求免疫光环褪去、天使用户开始介入，实际业务需求紧跟着也就来了。此时平台团队往往面临这些直接压力：
1. 偿还 MVP 阶段的欠债；
2. 彻底解决性能问题。
随着低代码平台的实际应用的推进，在 MVP 阶段中被有意无意忽视的业务场景逐渐显露出来，变得越来越具体。
这个状况会把低代码平台的发展道路的抉择推到风口浪尖上：先发展通用能力还是先满足业务需求？
选择什么样的发展路径？
作者的答案是:优先发展通用能力
如果不走优先发展通用能力的道路，还有其他发展道路可以走吗？
如果优先满足业务需求，每次都从头开始，在短时间解决具体问题的能力确实能迅速爬升，见效快。但由于没有通用性，在最初设定的业务问题都解决了后，自然就到达顶峰，之后基本就没下文了，每个工具都是这样。
更要命的是，这种解决问题的思路形成习惯和传统之后，你会发现无论时间多长，能力的上限基本就在那，没有任何想象空间。
坚持优先发展通用能力不动摇
MVP 阶段与其他工具相似，只是周期很短，短时间内也有能力的迅速爬升。成熟期相对漫长，而且具体业务开发能力缓慢爬升，基本处于啥都差一点的状态。这个时期注重的是发展通用能力，为未来的各种场景做架构设计和打基础、解决性能问题。但这个阶段往往很容易夭折，不仅因为这个阶段难度巨大，而且漫长的持续投入与看到的收益不成比例。
成熟期的一个显著特征是待实现的多数业务都会触及低代码平台的能力边界。所以几乎每面对一个新需求，你都要接受这样的灵魂拷问：要如何在确保平台的通用能力得到扩展的前提下顺便满足当前需求？即使通用能力无法得到拓展，至少也要避免为了实现某个业务团队需要的开发能力而将该具体业务耦合到平台中。
坚持优先发展通用能力的道路的收获季，是在场景化阶段，也就是超越期。
一旦 Low Code 模式的能力超过 Pro Code 模式之后，这个趋势终将不再回头。
如何保持优先发展通用能力呢？
- 对业务提交的任何功能需求，都按照最通用情形来考虑。即使对方只要一棵树，仍按照一座森林来考虑，我们不见得就要实际交付一座“森林”，但要为它预留足够的位置；
- 充分考虑已知场景的共同特征，暂时把它们的个性化特征丢角落里。过多考虑个性化特征只会限制你的想象力，这会牺牲掉许多易用性，但这是权衡之下必要的取舍，这是通用的代价。
- 任何业务需求，只要能采用已有的功能实现的，决不新增功能；只要保持已有功能通用性不变前提下稍微扩展就能实现的，也决不新增功能；好钢用在刀刃上，资源集中投放到开发新的通用能力上，不分散。
- 之所以我能坚持这么做，是因为我的用户群友好程度较高，主要得益于我平时注重提升他们的满意度：倾听他们的痛点，主动热心协助解决问题（编码、出方案等），帮助他们脱困；一般只要他们的自身的需求能按时交付，他们就会很高兴；记住：放低姿态。
小结
低代码平台开发过程，是不断权衡的过程，即需要满足业务需求，又要考虑低代码平台的通用性要求，同时受限于开发资源，只能在这些情况下进行权衡开发，但一旦有足够的资源和技术条件进行通用性开发时，这时总是以通用性开发为第一优先级。不一定要考虑低代码平台的100%的业务实现性，28原理告诉我们可以留下少数的极其个性化的需求通过pro code的形式进行兜底开发
