# 一个网站什么时候应该开始考虑商业化？

URL: https://caijiao.org/posts/225
Source: docs/posts/225.md
Description: terrific.tools 做了 12 个月才有第一个变现月（约 300 美元），Bruce 买下 Cloakist 时它只有 2000 美元 MRR。时机在于能否认出付费用户。

商业化开始得太早，最常见的结果不是提前赚到钱，是提前把自己做成了一个必须长期维护的产品。

terrific.tools 的作者老实做了 12 个月，到 2025 年 11 月才迎来第一个完整变现月：展示广告 174.41 美元，加上桌面版应用 125 美元，合计不到 300 美元。

如果他在第 3 个月就把收款接进去，会多收多少？大概率是零——那时候网站的会话量级还撑不起任何付费转化。但代价是实打实的：他得提前维护一套账单逻辑、一套退款流程、一套解释计费规则的页面，而这些东西会吃掉他本来用于增加工具数量的时间。

## 我在等的三件小事

所以我的判断标准不是访问量到了某个数，是三件很具体的事能不能做到。

**第一件，能不能把一个付费用户认出来。** 这不是"加个登录"那么简单。你要决定用什么做主键——邮箱、License Key、还是第三方支付平台返回的 customer id。这个选择会落进数据库表设计里，后面改起来的代价远高于一开始就选对。用 [SQLite](/sqlite/) 存客户和授权记录时，把 customer_id 设成唯一索引、并让业务代码一律通过它去关联而不是邮箱，能省掉未来一整类合并账号的麻烦。

**第二件，能不能把"超额"做成一行配置。** 免费用户每天十次，付费用户不限。如果这个限制硬编码在业务逻辑里，你每调一次额度就要发一次版。放在 [Nginx](/nginx/) 那一层做限流，改配额就是改配置加 reload。这件事看起来很小，但它决定了你愿不愿意去做各种定价实验——改一次价格要发版的商业模式，最后一定会演化成一个从来不改的价格。

**第三件，能不能在不重写核心表的前提下收第一笔钱。** 如果接入收款要动的是订单表和凭证表这种根基结构，说明数据表一开始就设计得太紧。能加一张中间表、加一个可选字段就搞定的，才叫"准备好"。

这三件事的共同点是：它们都不是关于钱的设计，而是关于**数据怎么组织**的设计。定价策略改十次都不需要重构，用户标识和配额层级一旦弄错，改的时候就是全表迁移。一个人精力有限，把它花在后者上，比提前半个月放出收款按钮划算得多。

## 2000 美元 MRR 就已经值得建机器了

Bruce McLachlan 买下 Cloakist 的时候，它的 MRR 大约 2000 美元。他和 Sotion 合计现在超过 12000 美元 MRR，2025 年 7 月正式转为全职。

![Cloakist 官网首页截图](/images/2026-09/cloak.ist.png)

*Cloakist 首页列了 30 多个可接域名的平台，Notion、Airtable、Calendly、Linktree 都在里面。*

Cloakist 和 Sotion 做的是同一件事：给任意网页接上自定义域名。这个功能是典型的"免费版不必要、付费版无法绕过"——用户要么是个人项目用免费二级域名，要么就是要给客户交付一个正式域名，没有中间状态。

2000 美元 MRR 折算年化约 24000 美元。在这个量级上，值得花几周把账打通、把配额系统做起来，因为这套机器会在接下来翻几倍的过程中一直用下去。反过来，一个月几十美元收入时就动手，你会把有限的精力花在一台全年产出几百美元的机器上。

这条线的高低取决于客单价。Data Fetcher 的客单价约 38 美元一个月，600 个客户就是 23000 美元 MRR；而 TinyWow 的 Pro 会员每月 5.99 美元，要撑起同样的 MRR 需要接近 4000 个会员。客单价越低，商业化的门槛越高，因为你需要的既是更大的用户基数，也是更自动化的整套流程。

## 先把自然流量扶起来，别指望付费渠道

Cakedesk 的作者 Max Schmitt 有过一段很具体的经历：2024 年有效的付费获客渠道，到 2025 年完全失效了，最后是靠 Google 自然流量把缺口补上的。

这段经历对商业化时机的提示是直接的——如果你的免费用户主要来自买量，那么"什么时候开始收费"这个问题根本轮不到你决定，渠道成本会替你决定，而且通常是在你没有准备的时候。付费渠道的转化门槛一旦抬高，你既拿不到新用户，也没来得及建立收费。

自然流量的另一个作用是给商业化的试错留出空间。上线一个 Pro 版本后发现转化率太低、需要调整功能划分，这种调整在自然流量为主的站上可以慢慢做两个月；在买量的站上，每一周的转化损失都是现金。

判断时机时我还会看另一个比例：2025 年 Cakedesk 收到 44 个功能请求，只完成了 13 个。这个数字反映的不是作者偷懒，而是需求永远多于产能。当开始有人主动向你提出"如果做成 XXX 我就付费"时，说明这个工具已经越过了"用完就走"的边界——这通常比任何流量阈值都更接近真正的商业化起点。

## 一句话版的检查项

访问量到了多少不必纠结，真正要确认的是：下次有人愿意为这个工具付钱时，你现有的系统能不能在当天把他标记成付费用户、给他开通配额、并且不需要改一行业务代码。

能，就可以开始谈钱了。不能，要补的那部分通常比想象的少——一张客户表、一层限流、一个回调地址，两三周的工作量，之后才是定价和测试。

急着把收款按钮放上去之前，先把这三件事做完，剩下的就是流量什么时候来的问题。

---

*terrific.tools 数据来自作者 2025 年 12 月在 Indie Hackers 的自述更新；Cloakist / Sotion 数据来自 Bruce McLachlan 的公开分享；Data Fetcher 数据来自 Andy Cloak。*