低代码不是"能不能用"的问题，而是"用到哪一步就该换手"的问题。把它当工具，比把它当方案更合适。
一、低代码真正擅长的三件事
- 表单与台账：把纸上的表格搬到线上，增删改查加导入导出
- 审批流：多级审批、条件分支、抄送、催办——这类需求高度模式化
- 快速验证：用两三天做出一个能点的原型，让业务方在真东西上提意见
这些场景下，低代码的速度优势是真实的：同样的需求，可能比定制开发快 3～5 倍。
二、到了哪一步就撑不住
| 需求类型 | 低代码 | 定制开发 |
|---|---|---|
| 普通表单台账 | 很合适 | 也能做，但没必要 |
| 复杂数据权限（按部门/区域/角色交叉） | 吃力，常靠"变通"实现 | 合适 |
| 大数据量报表与统计 | 慢，容易超时 | 合适，可针对性优化 |
| 与外部系统深度对接 | 受限，往往要写自定义代码 | 合适 |
| 高并发对外服务 | 通常不适合 | 合适 |
| 特殊交互或算法 | 做不了或极难维护 | 合适 |
三、成本要算总账
低代码的便宜是"前期便宜"。算账时要加上两块：按人/按量的年费，以及将来迁出时的成本（数据能不能完整导出、流程能不能复现）。
- 20 人以内、需求固定 → 低代码通常更划算
- 50 人以上、要对接多个系统 → 定制开发总成本往往更低
- 业务模式还在摸索 → 先用低代码跑通，再决定是否定制
四、一条务实的分工路线
摸底期用低代码
快速搭出原型，验证流程是否走得通
稳定后固化核心
把跑通的部分用定制开发实现，拿到完整数据与代码
长期用低代码补边角
临时的、小范围的、变动频繁的台账继续用低代码
一句话判据：如果你的需求里出现"权限交叉""要和某某系统对接""一天几万次访问"这三类词，就该考虑定制了。