# 一个网站如何从免费工具变成商业产品？

URL: https://caijiao.org/posts/230
Source: docs/posts/230.md
Description: TinyWow 的付费墙是每月 5.99 美元的 Pro，Cloakist 卖的是"给网页接自定义域名"。两条路指向同一条分界线：工具的结果要不要离开用户本人、落到服务器上。

免费工具变成商业产品，通常不是从定价页开始的，是从某个用户说"我希望能保存这次算出来的东西"开始的。

这句话听起来普通，但它触发的成本变化是结构性的：工具一旦要为某人记住结果，就必须有账号、有存储、有备份策略，而这三项不会出现在无状态工具的成本里。付费点几乎总是在这个转折之后才成立。

## 分界线画在数据落地的位置

判断一个功能该免费还是该收费，最省事的尺度是**它是否需要服务器记住东西**。

压缩一张图片、换算一次汇率、给 PDF 排个版，结果用完即弃，浏览器本地就能跑完——这类功能放到 [WebAssembly](/webassembly/) 里由客户端执行，每多一个用户增加的成本只有一点点带宽。它适合免费，因为免费带来的边际成本趋近于零。

反过来：历史记录、跨设备同步、团队协作、批量配额。这些功能一旦上线，你的账单上就多出了一张数据库表和一份备份任务，而且它们的开销随用户数持续增长。这个位置就该设门槛。

Cakedesk 提供了一个反方向的例子。它是 Electron + React + Node.js 写的桌面开票应用，数据留在用户自己的机器上，连的发生同步都不需要——所以它卖一次性 69 欧元，从头到尾没有订阅。2024 年约 170 份授权，2025 年 239 份，毛收入约 16000 欧元。

![Cakedesk 官网首页截图](/images/2026-09/cakedesk.app.png)

*Cakedesk 首页把 Watch demo 放在评价旁边，没装过的用户先看演示再下单。*

同样是"Data 落地"，落在用户机器上是一次买断，落在你的服务器上是按月订阅。这不是定价偏好，是成本结构推出来的结果。

## 三个能真的收到钱的时刻

看几个具体位置。

**结果要交给别人看的那一刻。** Cloakist 和 Sotion 做的是给任意网页接自定义域名，Bruce McLachlan 买下 Cloakist 时它约 2000 美元 MRR，和 Sotion 合计现在超过 12000 美元 MRR，2025 年 7 月转成全职。这个产品免费的用法是"给自己做一个页面"，付费的用法是"把它作为正式成果提交给客户"。同一个人、同一个功能，场景从自娱切换到交付，付费意愿就出现了。

**用户开始频繁使用、不再愿意等待的那一刻。** TinyWow 挂着 250 多个免费工具，付费层是每月 5.99 美元的 Pro。这种低价位的会员卖的往往不是某个独家功能，而是不受限、不排队、不被额度数字打断。

**工具进入别人的工作流程那一刻。** Data Fetcher 按工作区收费，客单价约 38 美元一个月，600 个付费客户撑起 23000 美元 MRR。个人的临时需求可以免费，一旦变成办公室的日常流程，付钱的人就不再是"要不要买"，而是"这笔钱谁报销"。

这三个位置的共同点是：**用户开始需要一个能被别人认可的结果，或者一条稳定的工作流**，而这两件事都发生在工具之外。

想验证付费点找得对不对，有个简易办法——看能不能用一句话说清楚"谁在什么情况下非付钱不可"。说不出来，说明位置还没找到，这时候继续加功能也不会带来转化。

转化比例通常很低，所以免费部分的量必须足够大。TinyWow 敢把 Pro 定在每月 5.99 美元，是因为它有两百多个免费工具在前面铺着；同样的低价放在一个只有三个工具的站上，算出来的收入撑不起日常维护。

## 免费版该限制什么，这里有个清晰的边界

免费版必须有限制，否则不会有人升级。但限制的对象选错，会同时毁掉免费版的传播和付费版的口碑。

不要限制的是核心结果本身。给免费用户输出带水印、低分辨率、或者缺一半字段的结果，等于让每个第一次来的人得到一个坏印象，而工具站的新用户几乎全靠第一次。

可以限制的是超越个人零星使用的那部分：超出某个频次、需要保存历史、需要协作、需要接口调用额度。这些限制对一个"今天只需要算一次"的人完全无感，对一个"每天都在用"的人则非常具体。

Cakedesk 在这个位置上的处理值得看：一次性 69 欧元买断，试用期结束只是不能继续创建发票，已有的数据仍然在自己机器上。用户不会因为到期而失去历史痕迹，这种设计让"付费"这件事变得没有敌意。

## 把计费开关做成一层，而不是散落在各处

技术上最容易埋雷的地方，是满代码库乱写判断语句。

更稳的做法是把授权当成独立的一层：客户表和订阅表里记录内部 user_id 与付款平台返回的标识，业务代码统一向这一层提问，而不是在各处判断某人是否有权限。这样换支付服务商时，改动范围只有这一层。

配额的执行放在 [Nginx](/nginx/) 那一层，免费用户超额返回 429，调整额度不需要重新构建发布。这里同样讲的是分离：配额与限流在边缘，业务逻辑在后端容器里，谁改动都不牵动另一个。客户表和用法数据放在 [SQLite](/sqlite/) 里足够用，导出也是复制一个文件的事。

这样做的好处，是定价实验变得廉价。想试两个套餐版本，改的是配置和一条 SQL，而不需要动业务代码。

---

*TinyWow 定价引自其官网；Cloakist / Sotion 数据来自 Bruce McLachlan 的公开分享；Data Fetcher 数据来自 Andy Cloak；Cakedesk 数据来自 Max Schmitt 2025 年度自述。*
