技术出身创业，最容易犯的错就是把「公司的技术栈」当成「我以前大厂的技术栈」来配。两次创业，同一拨人，我把这个学费完整交了两遍。
第一次：5 个人，配了 20 个微服务的家底
当时刚出来做项目，脑子里还是上一家公司的架构：微服务、注册中心、消息队列、分库分表，全套上齐。理由是「以后用户多了不用重构」。
结果：产品上线三个月，用户还没过万，一半精力花在「服务之间调不通」「链路出问题不知道查哪」上。有一次发布，改一个字段要联动五个服务，上线花了四个小时。复杂度是提前预支的，收益却要靠运气才能兑现。
这个教训我在架构反模式里写过，创业场景只是把它放大了十倍——因为创业公司没有「冗余人力」来养复杂度。
第二次：先问「这个钱现在必须花吗」
第二次组队，立了三条规矩，每一条都对应一次真实的取舍：
- 能用托管就别自建：数据库用云托管、对象存储用云服务、消息量小直接用托管队列。省下的不是那点月费，是一个「半夜三点被叫起来修集群」的值班人力。
- 单体起步，模块画好边界：代码上是单体，但模块边界按业务拆解方法论画清楚，接口先定义好。等真有一个模块需要独立扩缩容，再拆——那时候拆是有据可依的，不是拍脑袋。
- 按「人时成本」而不是「软件成本」选型：一个工具省 200 元月费但要团队花两天学，不如用团队已经会的。冷门但「看起来高级」的组件，是我见过的最贵的省钱。
结果：基础设施月成本砍掉六成，团队从「维护基础设施」里解放出来，全部时间花在产品上。复杂度被推迟了，而不是被消灭了——关键是它推迟到了你付得起的时候。
决策表：早期团队我现在的选型顺序
| 问题 | 优先答案 | 什么时候才升级 |
|---|---|---|
| 数据库 | 云托管单实例 + 备份 | 单实例扛不住，先做读写分离再说 |
| 缓存 | 进程内 + 少量 Redis（托管） | 命中率数据说话，别提前上集群 |
| 消息队列 | 托管队列 / 数据库表队列 | 积压与吞吐确实不够时 |
| 微服务 | 模块化单体 | 出现「独立扩缩容/独立发布」的真实需求 |
| CI/CD | 现成 SaaS 或轻量自建 | 构建排队影响交付时 |
收尾一句
技术选型对创业团队不是「技术决策」，是现金流决策：每引入一层复杂度，都是在赌「未来的规模会来替你还债」。赌输的代价不是钱，是团队的时间——而时间，是早期团队唯一买不回来的东西。
复盘方法本身可以套用月度复盘模板，每季度过一次「这层复杂度现在还值吗」。