赚钱的时候，别忘了谁还握着开关

一个小生意最舒服的时候，往往也是最不想问麻烦问题的时候。

流量稳定，订单在涨，收款正常，每周的数据都比上一周好。只要这套链路继续运转，增长看起来就像自己的能力。

最近读到一篇谈金钱、权力和时间的文章。里面有句话让我停住：有些盈利模型，只存在于别人许可的范围内。原文用了很大的比喻，我更愿意把它缩回一张业务流程图。图上每一个外部节点，都是别人握着的开关。

一个独立产品可能依赖应用商店上架、云接口调用、搜索推荐、广告账户和支付通道。它们都能提供效率，也都有自己的规则。问题不在于使用外部平台，而在于把用户、数据、分发、交付和收款全部压在同一个许可上。

假设一门生意每月收入100，其中90来自单一平台。报表会告诉我收入不错，却不会自动提醒：一旦账号审核、接口变更或结算暂停，能继续触达的用户可能只剩10对应的那部分。这里的100和10只是压力测试示例，不是某个真实项目的数据。

收入增长回答的是“现在赚了多少”，依赖结构回答的是“谁还能让它继续赚”。两个问题不能混成一个。

2026年10月21日那篇关于Apollo的稿子，讨论的是一个做了八年的产品怎样断在API政策上。今天我想往前走一步：不等开关真的关闭，先逐个把它从流程图里拿掉。

拿掉流量入口，老用户还能不能收到消息；拿掉支付通道，有没有备用收款和对账方式；拿掉云接口，核心数据能不能完整导出；拿掉平台账号，用户是否知道去哪里找你。

这不是要求每个小项目都自建全套基础设施。那样成本可能更高。压力测试只是在告诉我，哪些依赖值得接受，哪些依赖一旦变化会让业务直接归零。

我现在更愿意把“平台带来的收入”和“自己保留的能力”分开记。前者可以很大，后者不能是空白。

下一次看到收入曲线向上，我会顺手画一条反向流程：关掉一个外部节点，用户、数据、交付和钱分别还能走到哪里。赚钱值得高兴，但先看清开关在谁手里，才知道这条曲线有多少是自己的。

资料：

来源