什么时候 Wavect 是合适之选
- 你想要一套为你的业务而选、而非为作品集而选的技术栈。
- 你需要在数周内抵达生产，之后还要持续迭代。
- 你的产品有一个真实的前沿需求，AI 或链上，需要真本事。
- 你想保留日后基于这套技术栈自建团队的选项。
选择怎么构建
如何为 MVP 选择技术栈
选那套让你改主意最快、招得到人、而且两年后还有人能维护的技术栈。新潮不是一个优点。对大多数 MVP 来说，对的答案是一套朴素、流行、能找到十个工程师的技术栈，而不是上个月刚上热搜的那个框架。
预约三十分钟通话简短回答
为迭代速度、招聘池和长期可维护性选技术栈，而不是为新潮，而对大多数 MVP 来说，这意味着一套朴素流行的技术栈。
适合
- 需要尽快上线和迭代、而不是赢一场架构辩论的创始人
- 风险在于市场契合、而非纯技术规模的产品
- 日后会基于这套技术栈招工程师的团队
- 头 12 个月里必须保持改起来便宜的 MVP
不适合
- 把 MVP 当成简历驱动的框架实验的团队
- 真有、且已被验证的第一天就要极端规模的产品
- 还没有一个用户就想推倒重写的创始人
// 01
比较各个选项
大多数 MVP 技术栈决策，归根结底是朴素流行的技术栈对阵最前沿的技术栈。下面是它们在真正决定结果的几件事上的对比。
真正重要的是
流行的朴素技术栈
最前沿的技术栈
招聘池
深。你能很快招到或替换工程师。
浅。你在一个小池子里抢人，还得付溢价。
早期迭代速度
快。库成熟，答案早已存在。
慢。你会撞上没文档的边界，更多东西得自己写。
长期可维护性
高。下一支团队认得它。
有风险。工具可能在你扩张前就被弃用。
招聘成本与风险
较低。技能常见，入职可预期。
较高。技能小众，交接更难。
它实际何时胜出
几乎每一个 MVP。
当这项新技术解决一个真实、已验证的瓶颈时。
// 02
Wavect 的立场
技术栈远没有创始人想的那么重要，而它出问题的方式几乎总是同一种：一个聪明的选择，让未来每一次改动都很贵。我们交付过 75+ 个产品，跑得最快的那些，都跑在朴素、广为人知、任何称职工程师都能上手的工具上。
按这个顺序优化三件事。你能多快改主意。你能多容易地招到人。在你之后还有人能维护它吗。新潮在这三点上全都不及格。一个最前沿的框架，是在赌你将成为把它扩张起来的那支团队，而你都还没证明有人想要这个产品。
确实有新技术配得上它位置的真实场景，链上系统、AI 原生的数据流、真正的实时规模。这些我们都做。但你采用那个新部件，是因为它解决了一个你确实有的问题，而不是因为它在提案里好看。围绕它的其他一切，都刻意保持朴素。
// 03
成本、风险与周期
成本
探索 EUR 3,500 起一段短期探索阶段，在你为之投入构建预算之前，把技术栈决策钉死。
风险
重写风险昂贵的错误是选了一套你会长大超出、或招不到人的技术栈，逼得你在有起色时中途重写。
时间
从 0 到生产用 6 weeks一套聚焦的技术栈，能让一支小团队快速抵达生产，正如 PromptID 和 LivLive。
// 04
这里通常会出什么问题
- 因为一个框架新就选它，然后成了它没拿钱的 bug 报告员。
- 选了本地没人招得到的技术，于是创始人成了唯一能改任何东西的人。
- 为你还没有的规模做优化，今天却为此付出迭代变慢的代价。
- 堆三个实验性工具，让每个问题都变成一个研究课题。
- 把 MVP 的技术栈当成永久的，第一天就过度工程。
- 任由一个外包者挑他个人接下来想学的东西。
// 05
检查清单
在你提交一行代码之前，让候选技术栈过一遍这些。
- 在你的市场或远程，你能为这套技术栈招到至少五名工程师吗？
- 它对你的核心需求是否有成熟、有维护的库？
- 一名新工程师能在一周内上手干活吗？
- 迭代回路（从改动到运行）够快到能每天验证想法吗？
- 如果某个关键工具明天被弃用，你能迁移走吗？
- 任何新潮的部件，是否解决了你今天真实存在的问题，而不是一个假想的？
- 两年后，除了原作者，还有别人能维护它吗？
// 06
在我们的工作中是什么样子
我们在该朴素的地方用朴素技术栈来快速交付，在新技术配得上时才用前沿技术栈，当产品确实需要它的时候。
// 07
什么时候适用，什么时候不适用
什么时候我们并不合适
- 你想找人为一个简历驱动的框架选择背书。
- 你坚信自己在有用户之前就需要重写。
- 你只想要最便宜的外包者，不管可维护性。
- 你只需要一个一次性、没有生产前途的演示。
如果你想让技术栈决策为你的业务而做、而不是为一个潮流，一段短期探索阶段能很快把它定下来。
// 08
相关服务与阅读
// 09
常见问题
最近审阅:
审阅人Kevin Riedl
wiki ↗