什么样的网站最适合一个人开发？
我以前对这个问题有个标准答案：功能少的。现在我认为这个答案是错的，而且错得挺离谱。
Cakedesk 是德国自由职业者 Max Schmitt 做的桌面端发票应用。它功能一点不少——发票模板、客户管理、导出、税率设置都要做，2025 年他还收到 44 个功能请求。
Cakedesk 首页价签是 €49，划掉的原价 €69，秋季促销进行中。
按"功能少"的标准，它根本不该是一个人能做的东西。但它确实是，而且 2025 年卖了 239 份新授权，按一次性 69 欧元算，毛收入约 16000 欧元。
把站分成两类的，是交付时你在不在场
分界线不在功能数量上，在用户拿到结果的那一刻，你的服务在不在链路里。
用户上传文件等你处理——你在场。用户注册账号等你同步——你在场。用户提交内容等你审核——你在场。这三类一旦出问题，用户会直接来找你，而你只有一个人的时候，找你就是灾难。
反过来，用户打开页面、输入、立刻拿到结果，你的服务器只是发了个静态文件——你不在场。这种站半夜挂掉，你第二天早上修，也没人投诉。
10015.io：把 50 多个工具都放进浏览器执行
Fatih Telis 在 2020 年上线 10015.io，现在有 50 多个工具。起因非常私人：他书签栏里那个叫 Tools 的文件夹太长了，干脆自己做个站把这些工具收拢。
技术选型是 Next.js + styled-components，不用 UI 组件库，而且几乎所有工具都在客户端运行，极少请求服务端。
不用组件库是为了让页面足够轻——这类站的首屏速度就是转化率。交互逻辑用 JavaScript 写在前端，碰上编解码这类重计算再交给 WebAssembly；服务端只剩下静态托管，所以它能靠 AdSense 的约 300 美元月收入活下去。
一个人维护 50 多个工具听起来不可思议，但如果每个工具本质上就是一个纯前端函数，维护量其实是"50 个小函数"，而不是"50 个服务"。这也是他敢把路线图排到 256 个工具的原因——第 64 个才上 Product Hunt，第 128 个才做 v2。
Cakedesk 的解法更极端：不部署服务器，直接装进用户硬盘
Cakedesk 用 Electron + React + Node.js，就是个桌面应用。发票数据写在用户自己的机器上，本地持久化，不需要数据库运维，也不需要处理用户数据的合规问题。
一次性 69 欧元、没有订阅，意味着没有计费系统、没有订阅状态机、没有续费失败的重试逻辑。2024 年卖了约 170 份，2025 年 239 份，一年发 12 个版本——这些数字加起来的工作量，一个人撑得住。
44 个功能请求只完成 13 个，用户依然买账，原因是用户拿到软件之后，绝大部分时间不需要他在场。
需要服务端的站也能做，但得寄生在别人身上
Andy Cloak 的 Data Fetcher 是 Airtable 的一个扩展，用来从外部 API 拉数据填进表格。MRR 23000 美元、600 个付费客户，他一个人在伦敦运营。
它有服务端，也要维护，但它把获客、账号、收款这三件最重的事全交给了 Airtable 的插件市场。代价是命运不由自己掌控——他公开的筛选顺序里，“确认有 API”“评估规模”"评估平台风险"占了三步，其中一步专门用来评估平台本身会不会翻脸。
逃不掉服务端时，把它压进一个容器
不是所有想法都能纯客户端实现。真需要服务端的时候，一个人的运维能力上限大概是：一个 Docker 镜像，一条部署命令，出问题就整体重启。
不要微服务，不要消息队列，不要自己维护数据库集群。这些架构在团队里是对的，在一个人这里纯粹是负债——它们吃掉的不是开发时间，是你那三个月很忙时的应急响应能力。
一句话的判断方法
把你的站画成一张数据流图：用户输入 → 处理 → 输出结果。这条链路上只要有一个环节必须由你的服务器实时参与，它就不属于"最适合一个人开发"的那一类；如果一个都没有，功能多少根本不重要。
我现在的做法是，在写第一行代码之前先画这张图。画完之后发现必须实时参与的环节超过一个，就直接放弃——不是因为它难，是因为我知道自己三个月后一定会忙。
Cakedesk 销售与版本数据来自 Max Schmitt 公开更新；10015.io 技术选型与路线图来自作者自述；Data Fetcher 数据来自 Andy Cloak 公开分享。