每一单都从零开始，是最贵的隐形开支：把定制沉淀成产品

早期项目最怕的往往不是没客户，而是每个客户都要一套不一样的东西。第一个客户要电商后台，第二个要预约系统，第三个要内部审批——每一单都接了，每一单都从零开始建表、写登录、做后台列表。年底一算账，营收涨了，人效没涨，团队却越来越累。这不是在做产品，是按项目计件的手艺活。

定制本身不是坏生意，它常常是早期唯一真实的收入来源。真正的问题只有一句：做完这一单之后，下一单有没有因此变得更容易。如果没有，你赚的是一次性的辛苦钱，而且交付成本会跟着客户数量一路线性上涨。

三笔没人记在账上的成本

• 重复劳动。登录、权限、文件上传、消息通知、后台列表、导出表格，这些几乎每个项目都要有。在我们自己的交付里，这类通用底座通常要占到工作量的三到五成，做十单就等于写了十遍。
• 维护分裂。十个客户十套代码分支，第三单修掉的一个问题，要回过头在另外九套里各修一次。改，收不到钱；不改，被客户投诉。行业里常被引用的一组数字是，软件整个生命周期里维护要占总成本的六成以上，分支一多，这个比例只会更高。
• 人的依赖。每套定制只有写它的那个人看得懂，团队既没法扩容，也没法交接。一个人生病，交付就停在那里。

可复用不是提前设计出来的

很多团队的第一反应是「先把架构做通用」，结果第一个客户还没交付，就先花掉两个月去做没人验证过的抽象。顺序反了。真正能复用的模块是从真实交付里长出来的：同一个东西做到第三遍，才值得抽出来；没到第三遍之前，先按最省事的方式做，把重复的次数记下来。

有三件事可以这周就开始做：

• 每一单结束做一次复用盘点，半天就够。把这次写的代码分成三类：只有这家客户会用、改改能给别人用、本来就该是底座。第三类当天进基础库，第二类等它第二次出现再抽，第一类留在客户自己的分支里。
• 把定制范围写进合同。明确哪些是标准能力（不额外收费、会跟着版本持续升级），哪些是定制（单独计费、客户独占）。大多数客户能接受这个划分，接受不了的是以为自己买的是产品、拿到手的却是一次性工程。
• 盯住一个数字：每单新增代码量占多少。每做一单，这个比例应该往下走。如果做了五单它还没动，说明你只是在把自己卖得更贵，并没有把生意做大。

51kaifa.app 在交付早期项目时，合同里固定有一栏叫「标准能力与客户定制」，需求表里也固定有一栏叫「沉淀项」：这一单里哪些东西要进公共底座，交付验收时一起过。对预算有限的团队来说，这是最便宜的一笔投资——它不增加这一单的成本，只决定你下一单还能不能轻松一点。