MVP 开发原则

先说结论：MVP 的核心是"最小可验证"，不是"最小可用"。能验证假设就够了，不需要完美。

三个核心原则

1. 只做核心功能

砍掉一切不影响核心价值验证的功能。

好的例子：

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

坏的例子：

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

2. 代码不需要优雅

能跑就行。重构是有用户之后的事。

可以接受的做法：

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

不可接受的做法：

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

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

很多技术人的误区是把 90% 时间花在开发上。

正确的时间分配：

• 开发核心功能：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 阶段，扩展性不是问题。没有用户才是问题。