# 我拆了一个靠订阅收费的工具网站

URL: https://caijiao.org/posts/78
Source: docs/posts/78.md
Description: Data Fetcher 有 600 个付费客户、23000 美元 MRR，团队是伦敦一个人 Andy Cloak。订阅收不收得上来，跟它有没有嵌进用户的工作流关系极大。

如果让我猜一个 23000 美元 MRR 的 SaaS 有多少人，我会猜至少十来个，还要有客服和运维。

Data Fetcher 不是。它是 Andy Cloak 一个人在伦敦做的产品，一个给 Airtable 拉数据的扩展，600 个付费客户，MRR 23000 美元。

![Data Fetcher 官网首页截图](/images/2026-09/datafetcher.com.jpg)

*Data Fetcher 首页的演示是真实操作界面：Airtable 订单表旁开着 GET 请求面板，URL 填的是 ShipStation 的 API。*

我猜错了两次——第一次错在人数，第二次错在我以为"订阅制必须靠功能数量撑"。

## 600 个付费客户，一个人怎么维护

支撑这件事的不是自动化程度有多高，是产品形态。Data Fetcher 不是独立网站，它是 Airtable 生态里的一个扩展：用户在 Airtable 里配好表和字段，它负责把外部数据按计划拉进来。

这意味着它不需要自建账号体系、不需要自建权限、不需要自己设计工作流——这些 Airtable 已经做好了。它只需要解决一件事：把数据准确按时地搬进来。

对一个人维护的产品来说，这个取舍的价值被严重低估了。寄生在别人平台上会失去定价自由度，但换来的东西很实在——不用做用户系统，不用做组织架构，不用做通知体系。一个人能撑起 600 个付费客户，不是因为他效率高十倍，是因为他要维护的代码面小十倍。

算一下客单价：23000 除以 600，约合每个客户每月 38 美元。这个价位不需要销售、不需要客服坐席，客户自助完成配置就够——这也是"一个人运营"能成立的前提之一。

反过来说，38 美元这个价位也锁死了服务方式：不能承诺一对一支持，只能把文档和错误提示写得足够好。很多人以为"定价低所以要少做服务"，实际是"定价低所以必须把服务写进产品里"——报错信息要能指出是哪张表、哪个字段、哪次请求出了问题，否则一封封邮件回下来，一个人的时间立刻见底。

## 订阅收得上来，是因为它嵌在工作流里

订阅和买断的分野不在支付方式，在于用户是不是每天都要经过你。

Data Fetcher 拉数据是按计划执行的——用户配一次，它每天跑。这种产品天然适合订阅，因为价值是持续发生的，停掉订阅数据就断了。反过来看那些"想起来才用一次"的工具，用户付了一次费之后会觉得自己吃亏，续费率一定难看。

这也是它和 Bruce McLachlan 那组产品可以对照的地方。他买下 Cloakist 和 Sotion 的时候，两个站合计约 2000 美元 MRR，现在合计超过 12000 美元，2025 年 7 月他转成全职。这两个产品的功能一句话就能说完：给任意网页接上自定义域名。看起来比 Data Fetcher 还薄，但用户一旦接上就不会摘下来——域名一直要用，订阅就一直续。

从 2000 涨到 12000，翻了六倍。这段增长不太可能来自加功能，更可能来自两个动作：把已有客户的续费做扎实，以及让产品出现在更多潜在用户面前。当产品薄到一句话能说清时，增长瓶颈通常也不在产品里。

## 技术上的分野：成本随不随用户增长

订阅制和买断制对架构的要求是反着的。

订阅制产品通常要维护用户状态：谁订阅了、用到哪个额度、数据同步到哪一步。这部分状态存哪都行，但对一个小产品来说，[SQLite](/sqlite/) 这类轻量方案比起一套完整的数据库要省心得多——单文件、备份就是复制、迁移几乎不用运维。Data Fetcher 这种规模，用重型数据库才是真正的浪费。

定时任务本身也有坑。拉取外部数据一定会遇到限额、超时、字段变更，失败重试和告警必须在一开始就做进去，否则客户会在某天早上发现数据停了三天而你已经失去信任。这类"看不见的可靠性"才是订阅制真正要付的成本。

做扩展而不是独立站，还有一层取舍：分发渠道现成，但规则不由你定。平台的 API 限额、审核政策、定价抽成，任何一项变动都会直接打到收入上。一个人做订阅产品时这个风险容易被忽略——它不体现在代码里，但体现在合同里。

"给任意网页接自定义域名"这件事，实现上就是一个反向代理层：用户访问自己的域名，请求转到你托管的服务上，TLS 证书自动签发和续期。这层用 [Nginx](/nginx/) 做转发很直接，麻烦的是证书管理和多租户路由，容器化之后用 [Docker](/docker/) 起一批实例比手工配更可控。

买断制则相反——它要求成本尽量不随用户增长，因为收的是一次性的钱。10015.io 那种"几乎全部计算在客户端跑"的架构，本质上就是为这个目标服务的：多一个用户几乎不多一分钱服务器成本。

## 该抄的那部分

订阅制能不能跑通，我在动手之前会先问一句：用户停掉订阅之后，他的生活会缺一块，还是只是少了个方便？

缺一块的产品，订阅是合理定价方式；只是少了个方便的产品，用户会在第二个月取消。600 个付费客户付了不止一个月，说明 Data Fetcher 属于前者。

另一个更硬的判断依据是客户数的天花板。窄到"Airtable 用户里需要定时拉外部数据的人"，600 个付费客户可能已经接近这个池子的规模。要往上走，要么扩平台，要么涨价，没有第三条路——这也是一个人做的订阅产品迟早要面对的墙。

---

*Data Fetcher 与 Cloakist / Sotion 数据来自作者在 Indie Hackers 的公开更新（2025 年）。*