MVP 开发原则

MVP 的重点不是“最小可用”，而是“最小可验证”。只要它能帮你验证一个关键假设，就已经完成了第一版的任务，不需要一开始就做得很完整。

三个核心原则

1. 只做核心功能

所有不能帮助你验证核心价值的功能，都先砍掉。

好的例子：

• Airbnb 最早只是一个静态页面 + 邮件沟通
• Dropbox 最早只是一个演示视频
• Stripe 最早只支持 7 种货币

坏的例子：

• 第一版就做多语言支持
• 第一版就做完整的用户权限系统
• 第一版就做数据导出功能

2. 代码不需要优雅

第一版先让它能跑。重构是有用户之后的事。

可以接受的做法：

• 把配置写死在代码里
• 复制粘贴代码
• 用最简单的数据结构
• 不写单元测试

不可接受的做法：

• 完全不能运行
• 改一个地方要改十个文件
• 没有任何错误处理

3. 时间分配：开发 10%，设计测试 30%，营销 60%

很多技术人会把 90% 的时间花在开发上，但这通常不是 MVP 阶段最划算的分配。

正确的时间分配：

• 开发核心功能：1-2 周
• 设计和测试：3-5 天
• 准备营销内容：1-2 周
• 找第一批用户：持续进行

常见的过度设计

不要一开始就做的事

• ❌ 微服务架构
• ❌ 完整的 CI/CD 流程
• ❌ 性能优化
• ❌ 国际化
• ❌ 完整的错误监控
• ❌ 数据库读写分离
• ❌ 缓存层
• ❌ 负载均衡

可以等有用户再做的事

• 用户权限系统（先只做管理员）
• 数据导出功能
• 批量操作
• 高级搜索
• 数据统计面板
• 邮件通知（先手动发）

技术选型原则

优先选成熟稳定的方案

MVP 阶段不适合顺手练新技术。你要验证的是需求，不是证明自己会用某个新框架。

推荐：

• React / Vue（不要用刚出的框架）
• PostgreSQL / SQLite（不要用新数据库）
• Cloudflare / Vercel（不要自己搭服务器）

不推荐：

• 刚发布的框架
• 小众的数据库
• 自己搭建的基础设施

借鉴现有模板和开源项目

别一上来就从零开始写。模板和开源项目不是偷懒，它们能帮你少踩很多基础坑。

推荐做法：

• 找一个接近的开源项目
• 找一个 SaaS 模板
• 找一个 Starter Kit

不推荐做法：

• 自己设计整个架构
• 自己写所有组件
• 自己实现所有功能

不要纠结语言和框架

能跑就行。Rust 和 Go 的性能差异，在 MVP 阶段通常没那么重要。

什么时候该重构

只有在这些情况下才考虑重构：

1. 有付费用户了：说明产品方向对了
2. 代码改不动了：改一个功能要花一周
3. 性能真的有问题：用户抱怨慢
4. 安全问题：有明确的安全风险

记住这句话

老板说“能用就行”，很多时候是对的。程序员一上来就想“要考虑扩展性”，反而容易把第一版做重。

在 MVP 阶段，扩展性不是问题。没有用户才是问题。