MVP 开发原则
做 MVP 时该坚持的原则和该避免的坑
MVP 的重点不是"最小可用"，而是"最小可验证"。只要它能帮你验证一个关键假设，就已经完成了第一版的任务，不需要一开始就做得很完整。
三个核心原则
1. 只做核心功能
所有不能帮助你验证核心价值的功能，都先砍掉。
好的例子：
- Airbnb 最早只是一个静态页面 + 邮件沟通
- Dropbox 最早只是一个演示视频
- Stripe 最早只支持 7 种货币
坏的例子：
- 第一版就做多语言支持
- 第一版就做完整的用户权限系统
- 第一版就做数据导出功能
2. 代码不需要优雅
第一版先让它能跑。重构是有用户之后的事。
可以接受的做法：
- 把配置写死在代码里
- 复制粘贴代码
- 用最简单的数据结构
- 不写单元测试
不可接受的做法：
- 完全不能运行
- 改一个地方要改十个文件
- 没有任何错误处理
3. 时间分配：开发 10%，设计测试 30%，营销 60%
很多技术人会把 90% 的时间花在开发上，但这通常不是 MVP 阶段最划算的分配。
正确的时间分配：
- 开发核心功能：1-2 周
- 设计和测试：3-5 天
- 准备营销内容：1-2 周
- 找第一批用户：持续进行
4. 先跑流程，后写代码
萨希尔·拉文吉亚在《小而美》里自创了一个词：「流程化」（processize）。意思是：在写代码之前，先手动帮几个真实用户解决问题，把每一步记录下来。
Gumroad 最早就是一份 2700 行的 Python 脚本。萨希尔手动收集每个人的 PayPal 信息，月底一个一个转账。丑得不行，但能跑，而且有人付钱。等验证了需求，他才把流程自动化。
这个顺序很多人搞反了：直接跳到写代码，结果做出来的东西没人要。正确的是：先人工跑通 → 记录成流程 → 最后才自动化。
每次你想加新功能时，用这四个问题拦住自己：
- 能用一个周末做完并交付吗？
- 能让客户的生活变好一点吗？
- 有客户愿意为此付费吗？
- 能快速得到反馈吗？
四个问题里有一个答案是「不能」，就先别做。它们在逼你做一件事：克制。克制在早期就是竞争力。
常见的过度设计
不要一开始就做的事
- 不要：微服务架构
- 不要：完整的 CI/CD 流程
- 不要：性能优化
- 不要：国际化
- 不要：完整的错误监控
- 不要：数据库读写分离
- 不要：缓存层
- 不要：负载均衡
可以等有用户再做的事
- 用户权限系统（先只做管理员）
- 数据导出功能
- 批量操作
- 高级搜索
- 数据统计面板
- 邮件通知（先手动发）
技术选型原则
优先选成熟稳定的方案
MVP 阶段不适合顺手练新技术。你要验证的是需求，不是证明自己会用某个新框架。
推荐：
- React / Vue（不要用刚出的框架）
- PostgreSQL / SQLite（不要用新数据库）
- Cloudflare / Vercel（不要自己搭服务器）
不推荐：
- 刚发布的框架
- 小众的数据库
- 自己搭建的基础设施
借鉴现有模板和开源项目
别一上来就从零开始写。模板和开源项目不是偷懒，它们能帮你少踩很多基础坑。
推荐做法：
- 找一个接近的开源项目
- 找一个 SaaS 模板
- 找一个 Starter Kit
不推荐做法：
- 自己设计整个架构
- 自己写所有组件
- 自己实现所有功能
模板、免费额度和现成工具只是加速器，不是产品竞争力。它们帮你更快补齐登录、支付、部署、统计、邮件、存储这些底座，但真正让用户留下来的，还是你的核心场景、交付结果和对目标人群的理解。
选模板时可以用一个更朴素的标准：24 小时内能不能去掉演示内容，跑通一个真实用户流程。如果第一天都卡在环境、文档和陌生抽象里，它就不适合当前这个 MVP。
不要纠结语言和框架
能跑就行。Rust 和 Go 的性能差异，在 MVP 阶段通常没那么重要。
竞争力来自窄而深
独立开发者很难靠功能数量和大公司竞争。更现实的竞争力来自这几件事：
- 更窄的人群：只服务一个明确角色，而不是所有用户。
- 更深的场景：理解这个人群的语言、流程、禁忌和预算。
- 更快的反馈：用户一句话，你当天就能改。
- 更清晰的取舍：知道哪些功能不做，避免产品被需求拖散。
- 更强的内容资产：用教程、案例、模板和公开构建不断解释你的产品。
所以第一版不需要证明你能做很多功能。它要证明：你能不能把一个具体问题解决得足够顺手，让目标用户愿意回来。
什么时候该重构
只有在这些情况下才考虑重构：
- 有付费用户了：说明产品方向对了
- 代码改不动了：改一个功能要花一周
- 性能真的有问题：用户抱怨慢
- 安全问题：有明确的安全风险
记住这句话
老板说"能用就行"，很多时候是对的。程序员一上来就想"要考虑扩展性"，反而容易把第一版做重。
在 MVP 阶段，扩展性不是问题。没有用户才是问题。