# 一个网站MVP到底应该做到什么程度？

URL: https://caijiao.org/posts/119
Source: docs/posts/119.md
Description: MVP 的边界不画在功能多少上，而画在"要不要让用户成为用户"。TinyWow 第一版只有一个 PDF 转换器且免注册，10015.io 连 UI 组件库都没装，Cakedesk 一次性 €69 卖了 239 份，砍掉注册和历史记录才算 MVP。

"MVP 就是能跑起来的最小版本"——这句话我用了好几年，后来发现它是错的，或者说它没法执行。"最小"是个没有刻度的词，你永远可以再砍一刀，也永远觉得还能再加一个功能。

真正有刻度的那条线是：**这个版本里，用户需不需要先"成为一个用户"。**

## 免注册不是体验优化，是 MVP 的边界

TinyWow 上线第一版的时候，形态是一个 PDF 转换器。不是"PDF 工具集"，一个转换器。它现在有 250 多个免费工具，但 MVP 阶段只有一个功能。

值得抄的不是"功能少"，是它同时做的另一个决定：**全部工具免注册，点开就能用，上传的文件 1 小时后自动删除。**

这两件事是一体的。一旦你要用户注册，MVP 就不只是那个转换器了——你要做账号体系、密码找回、邮箱验证、用户数据表、隐私政策、留存机制。功能只有一个，工程量翻了三倍，而且这些工程量对用户那一侧的价值是零。用户要的是把 PDF 转成 Word，不是和你建立关系。

所以 MVP 的边界应该画在这儿：**砍掉一切要求用户先"成为用户"的东西**——注册、登录、保存历史、收藏夹、个人中心、偏好设置。用户带着一个麻烦来，处理完就走，这个流程里的任何一步身份确认都是摩擦。

## 10015.io 连 UI 组件库都没装

技术选型上的 MVP 边界，10015.io 给了一个很干脆的示范：Next.js 加 styled-components，**不用任何 UI 组件库**。

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

*10015.io 首页没有价格入口，整页只讲一件事：把书签栏里那堆工具链接收进一个盒子。*

一个人做站时最容易掉进去的坑，就是花两天搭设计系统——引入组件库、配主题、调 token、统一圆角和间距。这套活在大团队里是对的，在 MVP 阶段是纯消耗，因为此时你连页面能不能被搜到都还不知道。

它把省下来的时间放在了别处：所有工具几乎都在客户端运行，极少请求服务端。这个决定比设计系统重要得多，因为它直接决定了成本曲线——工具数量从 1 涨到 50，服务器开销几乎不动。

样式方案上它选了 styled-components，这算是个折中：比手写 CSS 省事，又不引入组件库的整套规范和升级负担。一个人做站时，任何带版本号的第三方依赖都要算上一份长期维护成本。

等页面矩阵跑通、确认这个方向值得投入之后，再考虑组件化和设计系统也不迟。那时候你有真实的页面清单做依据，[React](/react/) 的组件拆分该怎么做是明摆着的事，不需要提前猜。

## 数据库也可以晚一点来

第三条线在存储上。MVP 阶段很多需求根本不需要数据库——工具站尤其明显：输入进来、算完、结果返回，中间没有任何东西需要留下。

需要持久化的时候，先上 [SQLite](/sqlite/) 就够了。它是一个文件，没有独立进程要维护，备份就是复制文件。真正需要独立数据库服务的信号很明确：出现了多机写入、或者并发写把单文件写锁顶住了。在此之前上 Postgres，等于提前背上一份运维工作。

Cakedesk 是这条线走到极端的例子：Max Schmitt 做的桌面端发票应用，Electron 加 React 加 Node.js，数据全在用户本机。一次性 €69，没有订阅，2025 年卖出 239 份新授权。它连"服务端"这个概念都不存在。

## 收费方式也在 MVP 的边界里

MVP 阶段通常不收费，但"以后怎么收"会影响现在的代码结构，值得提前想一句。

三种形态对应三种工程量：一次性买断最省事——Cakedesk 就是一个 Electron 应用、€69 一次、没有订阅系统、没有账单表、没有续费失败处理；订阅制要额外做账单周期、支付回调、宽限期、降级逻辑；免费加广告最轻，但要求流量够大才有意义——10015.io 挂 AdSense 拿到约 300 美元 MRR，terrific.tools 做了 12 个月，3.4 万次会话才换来 174.41 美元广告收入。

MVP 阶段就决定形态，能省掉一次数据结构改造。

## 什么时候这条线该被越过

边界不是永久的，它有三个明确的失效信号：

一是用户开始重复回来找上一次的结果。这时候"保存历史"才变成真需求，之前它只是你的想象。

二是你发现同一段 UI 已经手抄第三遍。这才是引入设计系统的时机，不是第一天。

三是功能数量已经多到用户找不到——10015.io 在 50 个工具时开始写文章发社媒，在 128 个时做 v2。它把"什么时候该做什么"写成了硬门槛，而不是凭感觉。

## 一条更狠的检验法

terrific.tools 做了 12 个月才拿到第一个完整变现月：广告 174.41 美元、桌面版 125 美元，加起来不到 300 美元。回头看，这 12 个月里被做出来又没带来流量的功能，就是越过 MVP 边界的部分。

检验 MVP 是否越界，我现在只问一句：这个功能砍掉之后，用户还能不能完成他来时要做的那件事？能，就砍。答案全是"能"的时候，你才真的到了 MVP。

问的时候有个前提：那件事要写成一句具体的话，比如"把 20 页 PDF 合成一个文件"。写成"处理 PDF"就没法问了——太宽，砍什么都还能完成。

顺序上也有讲究：先问砍掉，再问加上。反过来做的话，你会在一堆已经写好的功能里找哪几个能删，而那时候沉没成本会开始替你说话，删掉任何一个都像是在否定自己前几天的工作。你手上那个版本，有几个功能是砍不掉的？