# 如果只允许做一个网站，我会如何设计它的商业模式？

URL: https://caijiao.org/posts/235
Source: docs/posts/235.md
Description: 先决定哪些计算永远不上服务器，再谈收费。免费层去接 wage calculator 那 17000 次月搜索，收费点只留保存和交付，涉及金额的计算一律不用浮点。

只允许做一个站，我不会从定价开始想。第一步是画一条线：**哪些计算永远不上服务器。**

这条线决定了之后所有事情的形状——它决定成本随规模怎么变化、决定这个站能不能在我出差的一周里照常运转、也决定三年后它有没有可能被别人买走。

## 免费的部分，全部丢进浏览器

布局的前半部分是几十个免费工具，全部在客户端算完。

图片处理、格式转换、单位换算、本地文件合并，编解码逻辑打包后用 [WebAssembly](/webassembly/) 加载，服务器只负责发静态文件和 CDN 回源。这种结构的可变成本几乎为零，访问翻十倍，"机器"那边也不会有余线性回归以外的开销。

10015.io 是这个结构的实证：几乎全部工具在客户端运行，服务器成本极低，它能靠每月约 300 美元的 AdSense 长期存在——换成每次处理都要上传文件的方案，同样的收入连机器都养不起。

![10015.io 官网首页截图](/images/2026-09/10015.io.png)

*10015.io 首页配图是插画风格：一个人在电脑前干活，脚边趴着一只猫。*

## 免费层去接的是哪些词

免费层的作用是当一个入口，所以挑入口词有个很具体的标准：**搜这个词的人，身后站着一个有付费习惯的人群。**

Gusto 的免费时薪计算器是个现成的例子。wage calculator 这个词月搜索量 17000，它那个页面拿到约 17776 的月访问，几乎吃下了整个查询池——而来的人全都是正在核算员工薪资的小企业主。这个词的价值不在搜索量本身，在于每个访问都能对应到一个迟早要为 payroll 掏钱的人。

如果我把工具选在一个"谁都在算、算完毫无下文"的场景上，即使流量到同样的量级，商业模式也接不起来。

入口确定之后，技术上还有一个必须守住的约束：每个工具是一个独立 URL，且服务端就把 HTML 骨架渲染好。这不是为了好看，而是让每一个具体查询都有对应的落地页——用户从搜索进来就该直接落在能用的页面上，而不是先看首页再找功能。这一条决定了整套站必须用静态生成，而不是把工具塞在一个单页应用里。

## 收费点只留两个：保存，交付

结算设计我会做得很克制——只保留两个点。

第一个是保存。历史记录、跨设备同步、团队协作，这些需要服务器记住东西，所以用得上账号体系和一张订单表、一张用量表，放在 [SQLite](/sqlite/) 里足够用，备份就是复制文件。

第二个是交付。Cloakist 和 Sotion 做的是给任意网页接自定义域名，Bruce McLachlan 买下 Cloakist 时约 2000 美元 MRR，两者合计现在超过 12000 美元 MRR。它的免费用法是"给自己做个页面"，付费用法是"把这个页面作为成果交给客户"——同一个功能，一旦从自用切换到对外交付，付款就不再需要理由。

保存这一点还有个副作用值得提前接受：一旦答应为用户记住东西，就等于承诺了备份和恢复。数据弄丢一次，之前积累的信任会一次性清空。所以导出功能要和它同时做出来，让用户随时能把自己那份数据带走——这降低了这边的保管责任，也让"放在这里"不至于变成太重的承诺。

这两个点之外的功能一律免费，工具数量堆得再多也不收费。免费层从不参与定价，它只负责把人带到那两个点前面——TinyWow 挂着 250 多个免费工具，付费层只是每月 5.99 美元的 Pro，逻辑是同样的。 

## 涉及金额的计算，一律不用浮点数

这一条算不上商业模式，但它是这类站能长期信任的前提。

金额、汇率、税率、分期累计，凡是涉及钱的累加，都不能直接使用 IEEE 754 双精度浮点：0.1 加 0.2 不等于 0.3，误差在逐笔累加后会放大到肉眼可见的分位。发票和利息类的工具一旦出现这种差额，用户不会认为是浮点问题，只会认为这个站算错了。

处理办法是用定点数或者十进制库处理业务金额，只在最后展示环节做四舍五入，并且把取整规则写在页面上。[Decimal.js](/decimaljs/) 那一栏讲的就是这件事。

## 订阅还是一次性，看一年发几个版本

最后一件事是付款节奏。两个现成的样例：

Cakedesk 卖一次性 69 欧元，2025 年卖出 239 份新授权，毛收入约 16000 欧元；Data Fetcher 按工作区收费，客单价约 38 美元一个月，600 个客户撑起 23000 美元 MRR。

差别不在产品形态而在更新频率。每年只发几次版本、客户关系不需要持续经营的，一次性买断更省事——它省掉的不只是计费系统，还有向每个客户解释续费的沟通成本。而月月都在交付新能力的产品，订阅才有理由成立，否则用户会觉得自己是在为已经用过的版本重复付费。

我这个站一年下来集中在几个较大的版本上，所以偏向一次性买断，外加一层可选的低价会员：既避开每月扣款带来的客服量，也不至于在新版本发布后颗粒无收。

先决定哪些东西不用付费也能跑完，其余部分该怎么收费，答案通常自己会浮出来。

---

*Gusto 免费计算器数据为第三方流量估算工具 2026 年上半年取数；10015.io、Cloakist / Sotion、Cakedesk、Data Fetcher 数据均来自各自作者的公开分享。*