# 独立开发最大的成本，其实不是服务器

URL: https://caijiao.org/posts/145
Source: docs/posts/145.md
Description: 10015.io 50 多个工具几乎全在客户端跑，服务器成本接近零，MRR 也只有约 300 美元；terrific.tools 花 12 个月换来第一个变现月的不到 300 美元。贵的从来是每多一个组件就多出来的长期维护。

一台最便宜的云服务器，一个月几十块；一个静态站挂在 CDN 后面，可能更便宜。这个数字在独立开发的账本里几乎可以忽略——我花过最多的服务器开销，也抵不上我为一个后来删掉的功能花掉的三个周末。

10015.io 是个极端例子：50 多个工具，几乎所有工具都在客户端运行，极少请求服务端，它的服务器账单接近零。可它做到这个规模，MRR 也只有约 300 美元。

这两个数字放一起，成本到底花在哪就清楚了。

## 服务器便宜到不值得再优化

静态文件加 CDN 的方案，流量不大时几乎不花钱。就算有后端，一台入门配置的机器也足够撑住相当可观的访问量。

TinyWow 那种量级——250 多个工具、月访问 180 万到 230 万——成本控制的关键也不在机器，在工程：它承诺上传的文件 1 小时后自动删除。存储不累积，成本就不会随时间线性上涨。如果所有文件都永久留存，账单会是另一个量级。

在服务器这一项上再省，最多省下几十块，而它要花掉的时间可以用来做两个新页面。这笔交换不划算。

## 每多一个组件，就多一份按月支付的注意力

真正的成本是一份份长期订阅，付的不是钱，是注意力。

数据库：字段要迁移，大版本要演练回滚，备份要验证能恢复。

任务队列：会堆积，会重试，失败的任务要有地方看。

定时任务：最麻烦的一种——它不报错，只是某天没跑。你得专门加一条监控去确认它跑过。

用户系统：密码、邮件、找回、注销、合规，每一环都可能在凌晨出问题。

日志与监控：存多久、多少钱、什么时候该告警才不至于把你吵醒。

每一项单独看都还能应付，但它们叠加起来会占满你的注意力。一个人能做多少事，取决于他脑子里同时挂着几个这样的组件。

## Cakedesk 的账单里没有服务器这一项

Max Schmitt 的 Cakedesk 是桌面端发票应用，Electron + React + Node.js，一次性 69 欧元不订阅。

![Cakedesk 官网首页截图](/images/2026-09/cakedesk.app.png)

*Cakedesk 首页价签是 €49，划掉的原价 €69，秋季促销进行中。*

它的成本结构里根本没有运行时这一行：程序跑在用户机器上，分发靠下载，不存在扩容问题，也不存在"流量涨了账单也涨"。2024 年卖出约 170 份，2025 年 239 份新授权，每多卖一份的边际成本几乎为零。

代价是一次性工程：代码签名、自动更新通道、安装包打包。这些做完之后就不再按月收费了——这是它和订阅制服务最本质的区别。

## 时间账：terrific.tools 的 12 个月

terrific.tools 老老实实做了 12 个月，到 2025 年 11 月才迎来第一个完整变现月：广告 174.41 美元加桌面版 125 美元，不到 300 美元。同期数据是 30 天 2.6 万用户、3.4 万次会话、4.1 万次浏览。

12 个月的时间，换 300 美元。这笔账怎么算都是亏的，如果只算钱的话。但它换来的是 2.6 万个真实用户和一套跑通的流程，而服务器在这 12 个月里花掉的钱，大概是总成本的零头。

## 差距不在谁更省钱

Stripe 的统计里，独立创始人的早期收入中位数下降了 23%，而前 10% 上升了 19%，两者差距 61 倍。

这个差距不可能来自谁用了更便宜的机器。它更可能来自时间被放在哪里——放在能积累的东西上（页面、外链、产品完整性），还是放在不产生复利的事情上（换框架、调优一台访问量还很小的服务器）。

JetBrains 的调研里有个数字：90% 的专业开发者每周至少用一次 AI 编码 agent。这确实压低了写代码的时间成本，但它压不低另外两样——决定做什么，以及为已经上线的东西负责。这两样才是账单的大头。

## 最贵的开销，是还没验证就先扩展

还有一类成本不属于上面任何一项，却最常发生：访问量还很小的时候，就开始为"以后可能会大"做设计。

多实例部署、读写分离、缓存层、消息队列、微服务拆分——这些在只有几百个访客的阶段全是负债。它们不解决任何当前问题，只是把"以后万一"的焦虑变成现在就要维护的组件。

真正该做优化的信号只有一个：观测到了具体的瓶颈。某个查询慢到影响页面响应，某次发布导致磁盘写满，某个任务排队超过十分钟。有具体现象才动，没现象就不动——这条规矩帮我省掉的时间，比任何一次技术选型的优化都多。

## 那该怎么算这笔账

我现在的做法是给每个组件估一个"每年要为它花几个晚上"。数据库的备份和升级，大概四个晚上；一套用户系统，十个晚上起步；一个需要盯的任务队列，不好说，但每次出问题都是一个完整的晚上。

估完之后，很多组件就不装了。能挪到客户端的计算就挪走——图片压缩、格式转换、音视频编解码这些活，用 [WebAssembly](/webassembly/) 放进浏览器，等于直接从账单上划掉一个服务端组件。必须留在服务端的，就用 [Docker](/docker/) 把部署固定下来，让"它现在跑在哪、怎么起来的"这件事有唯一答案，省下的是每次出事时的排查时间。

服务器一年几百块，12 个月的时间没法标价。省钱的杠杆在"少装一个组件"，不在"换一家更便宜的云"——后者省下的是几十块，前者省下的是每年好几个晚上。

---

*terrific.tools 数据来自作者 2025 年 12 月在 Indie Hackers 的更新；Cakedesk 数据来自作者 Max Schmitt 的年度复盘。*