我准备长期观察的30个小网站，它们有什么共同点？

我在一张表上列了 30 个小站，打算每月记一次数字。挑的时候没有固定标准，基本是"看着有意思、数据愿意公开"的都收进来。

列完回头看，这 30 个站的品类五花八门——文件处理、尺寸估算、装修报价、发票、Airtable 扩展、网页接域名——但技术形态上高度一致。

第一个共同点：能放客户端的都放了客户端

10015.io 是最典型的。作者 Fatih Telis 是伊斯坦布尔的前端开发者，2020 年上线，Next.js + styled-components，不用任何 UI 组件库，50 多个工具几乎全部在客户端运行，极少请求服务端。靠 AdSense 变现，MRR 约 300 美元。

TinyWow 也是这个思路：250 多个工具，图片压缩、格式转换这类任务用编解码器在浏览器里跑，只有大文件和视频转码才走服务端队列。它敢承诺"上传的文件 1 小时后自动删除"，是因为文件压根不需要长期落盘。

这不是巧合。小站没有预算养服务器，把计算推到浏览器是唯一能让成本脱离流量的办法——也顺手解决了隐私顾虑。前端这一层，输入解析、格式化、即时反馈交给 JavaScript 就够了。

这个选择还带来一个意外好处：工具可以离线用。网络断开时页面照样能算，用户不会遇到"转圈然后失败"。对一个主要靠口碑传播的小站来说，这种"从来没掉过链子"的印象比任何功能都值钱。需要联网才能跑的工具，在体验上天然矮一截。

第二个共同点：一个人能发版

Cakedesk 是 Max Schmitt 一个人做的桌面端发票应用，Electron + React + Node.js，2025 年发了 12 个版本。Data Fetcher 是 Andy Cloak 一个人在伦敦做的 Airtable 扩展，600 个付费客户、23000 美元 MRR。

Cakedesk 首页把 Watch demo 放在评价旁边，没装过的用户先看演示再下单。

"一个人能发版"听起来是团队规模的描述，实际是架构约束的结果。Data Fetcher 寄生在 Airtable 生态里，账号、权限、工作流都不用自己做；Cakedesk 数据存在本地，没有服务端要运维。它们的共同做法是把状态尽量留在用户侧——需要存的话，SQLite 这种单文件方案比一套数据库省心得多；真要跑服务，容器化起来 Docker 一两条命令的事，不会变成长期负担。

反过来，我表里那几个明显跑不动的站，几乎都栽在同一件事上：早期为了省事引入了一个需要长期维护的中间件。它当初只花了一下午，之后每个月都要花一天去升级、排错、打补丁。一个人做站，"少一个要养的组件"比"多一个好用的组件"重要得多。

第三个共同点：收入不高，成本更低

把这批站的收入摆一起看，数字都不惊人：10015.io 约 300 美元 MRR，terrific.tools 第一个完整变现月广告 174.41 加桌面版 125 美元，Cakedesk 一年毛收入约 16000 欧元。

真正共同的是成本那一栏接近零。客户端架构让服务器账单不随流量涨，一个人维护让人力成本不计入。以 10015.io 为例，50 多个工具的 MRR 300 美元如果换成服务端架构，账单可能先把利润吃掉。

这也是我表格里一定会记的一列：不是"月收入多少"，是"月收入减去月成本之后还剩多少，以及这个差额会不会随流量变化"。后者比前者更能预测这个站三年后还在不在。

第三列我记的是"作者每周投入多少小时"。terrific.tools 做了 12 个月才拿到第一个完整变现月，Cakedesk 一年发了 12 个版本——这些数字背后的投入量不写出来，单看收入会得出完全错误的结论。一个每月 300 美元、每周只花两小时的站，和一个每月 300 美元、每天花四小时的站，是两种完全不同的生意。

第四个共同点：页面数远多于功能数

Inch Calculator 只做尺寸和工程量估算，459 万月访问；Homewyse 只做装修报价，把材料费、人工费、总价拆开呈现，42.885 万月访问；Omni Calculator 几千个页面、30 多种语言，1429 万月访问。

三个站都不是靠"功能多"取胜，是靠"一个页面对应一个问句"取胜。页面由配置和模板生成，加一个页面接近零成本，这才是小站能跟大站抢长尾的原因。

有意思的是这三个站的流量差了三十多倍，但页面组织方式几乎一样。差别在问句的可枚举程度——尺寸和工程量能拆出几千种问法，装修报价只能拆出几百种。功能数看起来差不多，页面数差了一个量级。

我每月要记的三个数

第一个是每千次会话收入。terrific.tools 是 6.89 美元，作者目标是 10 美元，这个差值是工具站变现效率的体温计。

第二个是直接访问占比。TinyWow 47.29%、搜索 33.83%，这个比例决定了它在算法更新时的存活率。

第三个是发布频率。Cakedesk 一年 12 个版本、44 个请求完成 13 个，这种节奏对一个人意味着什么，得连续看两年才知道。

第四个我还在犹豫要不要记：直接访问占比。TinyWow 的 47.29% 是个很好的锚，但多数小站公开数据时不会拆这么细，只有自己做的站才拿得到。这一列可能会大面积空缺，不过它恰恰是我想观察一年之后最想回答的那个问题——这 30 个站里，有几个能长出自己的 47%？

30 个站里现在有公开数据的不到一半，剩下那些我只能先记着域名。等这张表攒满一年，我大概能说清一件事：459 万和 42.885 万这两个数之间，到底隔着多少个 6.89。

10015.io、Cakedesk、Data Fetcher 数据来自各自作者的公开分享；Inch Calculator 459 万、Homewyse 42.885 万、Omni Calculator 1429 万为 2026 年 6 月第三方流量估算。