买还是自己写：七个判据与 4,200 行计费代码的账

自建计费的理由不是省钱，是能力缺口。

一、四千二百行是怎么长出来的

他最初只想收一个月费。订阅表、支付回调、一张收据，两个周末写完，大约 900 行。第十四个月，billing 目录有 4,200 行，全库 62,400 行，占 6.7%。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

多出来的 3,300 行不是一次性写的，是十几次「顺手加一个」攒出来的：加一档按量阶梯，690 行；加发票 PDF，600 行；加三个税务地区的税率分支与税号校验，400 行；加重试与催收，800 行；加对账与沙箱脚本，810 行。每一笔单看都不大，合起来是一个人两个月的全部产出。

真正处理钱的只有 7 张表。 customers、subscriptions、invoices、invoice_lines、payments、refunds、credit_notes 承担了全部账务；剩下的行数在伺候格式、边界与地区差异。

三个月后第一次事故：7 个团队用户在 past_due 状态下重试成功，系统又触发一次续费，重复扣了两个月，合计 420 美元。修的时候他发现，问题不在支付通道，在自己写的那段状态判断里。

代码量不是成本，维护面才是。 4,200 行不会自己变贵，是它每个月要吃掉 6 小时：看对账差异、补一个税号字段、修一次按比例计费的分母。一年 72 小时，按 40 美元/小时算是 2,880 美元。

首版时间最容易被低估。 他记得自己用了 60 小时，翻提交记录才发现是 160 小时；差的 100 小时里有 40 小时在建沙箱与对账脚本，这部分不产生任何用户可见功能。

测试数量会骗人。 billing 目录有 62 个测试，看起来不少；其中迁移测试只有 9 条，正好对应 9 条合法迁移，剩下 16 格非法空间一条都没有，因为写的时候没人相信它会被触发。

二、七个判据，先排除情绪

讨论「买还是写」时，人容易从立场出发：写代码的人想写，被运维折磨过的人想买。先用七条判据把立场压下去。

每条判据只答是或否。 写「复杂度较高」没有用，要写「有几个状态、几条合法迁移、能不能穷举」；能穷举的，供应商的通用模型大概率够用。

判据要按顺序问。 先问复杂度与按量需求，这两条决定「能不能买到」；能买到，后面的税务、发票、迁移才有讨论意义。

团队规模是硬约束。 一个人写计费，等于没有代码评审、没有第二个人能接手事故；这条不是偏好，是风险敞口。

按量这条要追到接口层。 129.6 万条事件摊到每天是 43,200 条；供应商的计量接口得接受补报、迟到与去重，否则账单会在月底对不上。

故障后果决定下限，不决定路线。 多收 420 美元那次事故，用的是自建系统，但换成供应商也一样会出错；区别在于出错后谁陪你查。

三、把两条路线的账算清

把时间折成钱，两条路线的差距会比直觉大得多。

第一年差 7,577.4 美元。 按月确认收入 1,710 美元算，相当于 4.4 个月的收入；这个量级足以让一个人重新考虑路线。

按当前量级，差额只会逐年扩大。 自建每年 2,880 美元、供应商每年 102.6 美元，差 2,777.4；只有收入涨到阈值以上，抽成才可能反超维护成本。

维护工时是最难压缩的一项。 它不会因为系统稳定就归零，反而随客户数、税区与发票字段增长；这也是自建成本曲线不会下降的原因。

把维护压到 3 小时/月也翻不了盘。 3 × 12 × 40 = 1,440/年，阈值降到 7.02%，仍然比 0.5% 高出一个数量级。

抽成要算到 14.04% 才持平。 20,520 × x = 2,880，解得 x = 14.04%；供应商收 0.5%，在纯费用上压倒性便宜。任何以「抽成太贵」为由的自建，在这个量级上都不成立。

供应商的 40 小时也不是全部。 那只是把订阅与收款接上；发票模板、税号、对账报表还要各花十几个小时，实际集成往往接近 60 小时。

迁移成本只影响退出，不影响进入。 80 小时是「以后想换走」的价格，两条路线都要付；把它算进第一年，会让供应商显得更贵，但那是一次性且未必发生的支出。

四、真正该自建的三种情形

费用算完，自建仍然可能是对的，但理由必须换成能力，不是省钱。

第一种：按量计费的模型供应商不支持。 12 个客户、每月 129.6 万条事件，要 5 分钟桶聚合、24 小时迟到窗口、三道去重；如果供应商只能按「调用次数」计费，业务模型就会被压扁。

第二种：发票字段不可控。 中文抬头、统一编号、两个内部成本中心字段，如果供应商的模板改不了，财务每个月都要手工补，这笔人力比省下的抽成贵。

第三种：数据主权与迁移风险。 客户合同要求账单数据留在境内，或要求随时能导出全量账本；这一条不是技术偏好，是能不能签下这个客户的前提。

混合路线往往是最优解。 订阅、收款、重试交给供应商，按量聚合自己做，边界写清「谁持有账本」；这样既不用养 4,200 行，也不用把计量模型压扁。

自建还有一笔看不见的成本。 沙箱、演练、季度验收都要额外工时；这些不在每月 6 小时的维护预算里，却是维系这套系统运转的固定开销。

可以外包的部分要先外包。 4,200 行里有 1,800 行是可替换的：重试 800 行、发票 PDF 600 行、税计算 400 行，合计 42.9%。先把这三块换掉，自建的真实成本会立刻降一档。

决定要写下来。 记下日期、当时的月确认收入、选择路线与三条理由；六个月后收入变了、理由可能就不成立，没有记录就只能凭印象复述。

复算：

供应商 1,710 × 0.5% = 8.55/月 = 102.6/年
自建首版 160 × 40 = 6,400；维护 72 × 40 = 2,880/年
第一年 6,400 + 2,880 = 9,280 vs 1,600 + 102.6 = 1,702.6；差 7,577.4
之后每年 2,880 vs 102.6；差 2,777.4
阈值 2,880 ÷ 20,520 = 14.04%
可外包 1,800 ÷ 4,200 = 42.9%

五、行动清单与复算验收

先算账，再决定写不写；算完还写，就要写清理由。

• 把 billing 目录的行数与全库行数各统计一次，算出占比。
• 用提交记录核对首版真实工时，不靠记忆。
• 连续四周记录每月维护工时，取平均后乘 40 美元/小时。
• 向两家供应商询价，把抽成、最低月费、迁移支持写进同一张表。
• 按当前 1,710 美元月确认收入算出抽成的年成本。
• 列出「供应商做不到」的具体三条，写不出就不自建。
• 标出重试、发票 PDF、税计算三块的行数，评估外包。
• 把 80 小时迁移成本单独记账，不摊进日常成本。

验收标准：你能用一张表说明两条路线的第一年与之后每年成本，并给出 14.04% 的持平阈值；说不出阈值，说明这笔账还没算完。

使用边界与实操验收

这一篇算的是一人 SaaS 在 1,710 美元月确认收入量级上的账，换量级要重算。

边界一：量级变了，结论会翻转。 月确认收入到 20 万美元时，0.5% 抽成是每年 12,000 美元，自建的 2,880 美元维护就开始划算；阈值公式仍然成立，代入即可。

边界二：机会成本按 40 美元/小时是教学假设。 如果你的时间能卖出更高价格，自建更贵；如果当下没有别的活干，这个价格要下调。

边界三：没有算合规与审计成本。 涉及增值税登记、发票存档年限、拒付举证时，自建还要额外承担这些工作。

边界四：供应商也会迁移。 供应商改价、改 API、被收购都发生过；80 小时只是「你自己主动换走」的价格，不包含被动迁移。

边界五：这不是一篇反对自建的文章。 按量计费、发票字段、数据主权三条成立时，自建是对的；错的只是用「省钱」当理由。

关键参考与核验范围

• Stripe Billing 订阅概览 ：用于核对订阅、账单与发票的职责边界。
• Stripe 按量计费 ：用于核对计量、聚合与账单行的对应关系。
• Stripe Tax ：用于核对税务地区与税率分支的一般处理方式。
• Paddle API 概览 ：用于对照另一类商户模式（merchant of record）的能力边界。

以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。

系列导航

• 回到本组目录：一个人的计费系统：订阅状态机、按比例计费与失败重试
• 上一篇：对账与收入漏损：一百零五行结算单与 0.4% 的差异
• 下一篇：计费验收：十二项检查、四维评分与一次季度演练
• 相关：一个人的定价与付费墙