如果今天重新做这个网站，我会删掉哪些功能？
44 个功能请求，完成 13 个。
这是 Cakedesk 2025 年的公开数字——Max Schmitt 一个人做的桌面端发票应用，一年发了 12 个版本，收到 44 个功能请求，只做了 13 个。
Cakedesk 首页的应用预览里能看到 Overview、Clients、Invoices、Proposals 几个模块和月度柱状图。
同一年它的销量从 2024 年的约 170 份涨到 239 份，毛收入约 16000 欧元，而流量基本持平。
13/44 不是效率问题，是筛选标准问题
一开始我把这组数字读成"作者做不过来"。后来发现顺序反了：不是做不过来，是那 31 个本来就不该做。
证据就是流量持平、销量上涨。如果未完成的请求里藏着大量强需求，销量不会被拖着涨四成。功能请求的数量和转化的相关性，比我们以为的低得多——提请求的人往往是最活跃的用户，他们的需求未必是新用户的需求。
重来一遍的话，我会先删掉"按请求数量排优先级"这个机制本身，换成按"多少潜在用户在付钱前会卡在这个环节"排。前者是计数，后者才是判断。
还有个更省事的做法：把请求按"提了几次"而不是"有多少人提"来排。44 个请求如果分散在 44 个人身上，那它代表的可能是 44 种个人偏好；如果其中某个被 8 个人分别提过，那才是真需求。这个分组做一次只要十分钟，比重排整个路线图便宜得多。
第一类该删的：需要服务端状态的功能
从架构角度，我会先砍掉所有需要我为用户保存状态的功能。
这不是保守。Cakedesk 是买断制，一次性 69 欧元，没有续费收入来覆盖持续成本——任何"我得为你存点东西"的功能，都是把一次性收入换成了永久性负债。它跑在 Electron + React + Node.js 上，数据存在用户本地，这个选择是对的，但当初我应该把这条线画得更死：只要是需要账号、需要云端同步、需要定时任务的功能，一律不做。
10015.io 的取舍更彻底：几乎所有工具都在客户端运行，极少请求服务端，50 多个工具几乎没有后端成本。这套约束看着限制了功能上限，实际上帮作者挡掉了绝大多数"听起来很美"的请求——因为那些请求的第一句话通常是"能不能帮我保存历史记录"。
一旦开了这个口子，后面跟着的必然是同步、多设备、账号找回、数据导出，一整套后端系统从一句轻描淡写的请求里长出来。架构约束的价值不在于省事，在于它让"不"这个答案有据可依，不用每次都靠意志力拒绝。
第二类该删的：被提前的推广动作
10015.io 的路线图里有个安排我很认同：50 个工具之后才开始写文章、发社媒，64 个之后才上 Product Hunt。
我以前做站是反过来的——功能做到七八个就急着发。Product Hunt 每天约 668 次发布，feature 率约 2.8%，即使命中，两三天后流量也归零。带着半成品去冲这个 2.8%，是把最稀缺的一次曝光用在最不该用的时候。
重来一遍，我会把"推广"这个功能从早期版本里整个删掉，只保留一个计数：工具数量。推广不是功能，它是功能足够多之后的自然结果。
第三类该删的：为了对称而存在的功能
第三类最难识别，因为它看起来很合理。
工具站做到十几个功能时，很容易产生"这里缺一个图片类""那里缺一个视频类"的想法，于是为了目录整齐去补功能。TinyWow 现在有 250 多个工具，看起来什么都有，但它是从 2019 年一个 PDF 转换器长出来的——250 个是五年后的结果，不是第一年的目标。
为了对称补出来的功能，通常是全站最没人用的那几个，却占着同等的维护成本。Cakedesk 那 31 个未完成的请求里，我猜有相当一部分属于这类——用户提的时候是"既然有 A 了，是不是该有 B"，而不是"我做不到某件事"。
区分这两句话，是我在筛选需求时唯一想加的一道闸：说得出"我做不到什么"的才排进路线图，说得出"你该有什么"的一律往后放。
我会留下什么
留下能让用户完成一次完整任务的最小集合，以及能让这个集合长期不塌的工程约束：计算尽量放在客户端、状态尽量不进服务器、页面可以静态托管。
技术上的取舍值得说一句：不做服务端状态不等于技术简单。React 的组件化能让 50 个工具页保持一致性，本地存储配合 SQLite 这类轻量方案能撑起大部分"离线也要能用"的需求，而真正需要服务端的少数任务，用 Docker 单独容器化隔离，坏了不影响主站。这些都不是新功能，但它们决定了剩下那些功能能不能长期稳定。
下一次我会把功能清单砍到原来的一半再上线，剩下的那一半，等第一批用户真的来抱怨缺什么的时候再补——而且要等抱怨出现三次以上才动手。删掉的那部分不用归档，两周后想不起来是什么，就说明它本来就不该存在。
砍完之后还要留一条自查：每个月挑一个已经上线的功能，问它过去 30 天有没有被人用过。没人用的功能不是"以后可能会有用"，它是下个月要修的 bug 的来源。这条自查不需要数据埋点，看一眼客服邮件和反馈里有没有提到它就够了。
Cakedesk 数据来自作者 Max Schmitt 的公开更新；10015.io 路线图来自作者 Fatih Telis 的公开分享；Product Hunt 发布量与 feature 率为公开统计。