KISS 或死亡：为什么资深工程师在初创公司失败

我的第一家初创公司失败了，周围的几家初创公司也失败了。我们拥有：10万美元的GCP积分、一位曾在企业中构建系统的创始工程师，以及上市策略。我们失败了，不是因为我们构建得不好，而是因为我们构建得太好了。这就是问题所在。

当我们花时间与看似"不理想"的技术栈搏斗时，我们失去了最重要的东西：时间、动力和战略机会。

这个故事不是关于缺乏常识的人。我有常识，我们知道应该保持简单。但当你的心智模型不适合当前情况时，所有常识都会被冲走。你做出"正确"的决定，却最终害了自己。

这也不是关于糟糕工程的故事。而是关于优秀的工程如何扼杀初创公司。关于让你成为资深工程师的经验如何变成你最大的负担。关于"做对"甚至"做简单"往往是做错了。

本文提供心智模型，帮助你做出正确决策，避免我犯过的错误。

:::tip 适合人群： 正在创办或加入早期初创公司的资深工程师。如果你在企业或大型科技公司工作超过5年，这是给你的警告。

:::

\

心智模型#1 - "免费"基础设施是最昂贵的

10万美元的GCP积分看似礼物，实则陷阱。它推动你过度工程化，因为"已经付费了"。你获得计算实例、负载均衡器、容器注册表和需要企业级设置的企业工具。你真正需要的是什么？一个"推送部署"按钮。

当然，你可以在GCP/AWS/Azure上构建"从GitHub部署到VM"的工作流。一些产品接近这一点。但它需要额外步骤：配置Cloud Build、设置IAM角色、编写部署脚本、管理密钥和配置健康检查。在部署实际产品之前，你就在构建部署基础设施上浪费时间。

同时，像Railway或Fly.io 这样的平台提供初创公司真正需要的：一个持久VM，可从GitHub一键部署。简单至极：你推送代码，它就部署。现成可用的VM，带环境变量、SSL、负载均衡器、日志等。它不是"免费"的，但它已准备就绪。

免费积分推动你过度工程化，因为"已经付费了"。你说服自己在省钱，却在消耗最宝贵的资源：时间。

\

心智模型#2 - "最小化"≠"简单化"

传统的KISS原则告诉我们保持软件简单。但在初创公司，这是错误的目标。你不应该保持软件简单；你应该保持解决方案简单。

真正的简单应该通过总体努力来衡量，而非代码复杂性：

总体努力 = 初始构建 + 维护 + 调试 + 功能添加 + 安全更新 + 扩展变更

当你从头构建时，你永远拥有所有这些责任。当你使用服务时，大部分变为零。"臃肿"的第三方服务实际上是简单解决方案，因为它最小化了总体努力。

我的OAuth示例

我们的创始工程师决定从头构建OAuth，而不使用"未知库"。一周后，他提交了PR：干净的OAuth实现，带JWT令牌、刷新令牌轮换、会话管理和基于角色的访问控制。没有依赖，没有供应商锁定，只有我们控制的代码。

我没有拒绝这个PR。这是个错误。丢弃一周的工作会打击士气。但它创造了代码复杂性，并走上了错误的轨道。此外，事先不讨论方法是我们真正的错误。我们让工程师的自尊心做了战略决策。

然后，客户需要Microsoft OAuth和Google OAuth。自定义实现意味着数天的重构、刷新令牌轮换、边缘情况、RBA和其他事情。每个"简单"的添加都需要深入理解我们的自定义认证。每个安全更新都需要我们实现。每个新需求都需要我们编码。

原则

资深工程师的典型错误：优化控制而非结果。在初创公司，现实需要完全颠覆资深工程师的思维方式：

1. 停止思考："这只是几天的编码" \n 开始思考："这是几天没有编写我的实际产品"
2. 停止思考："我可以简单地构建这个" \n 开始思考："通过不构建，我可以简单地解决这个"
3. 停止思考："第三方服务增加复杂性" \n 开始思考："第三方服务吸收复杂性"

\

\

心智模型#3 - 舒适区选择

我们选择Angular是因为我们的创始工程师深入了解它。聪明的决定，对吧？利用你的优势，交付高质量代码。框架没问题，但问题在于它的生态系统。

生态系统陷阱

Angular很出色，我们的工程师可以用它构建任何东西。

但"任何东西"仅仅开始就需要时间。 设置部署、认证和基本UI组件意味着在编写单个功能前进行无尽配置。当我们调试Angular Material主题时，竞争对手使用Next.js + Vercel已经在吸引用户了。

比较一下Next.js + Vercel路径：第一天用npx create-next-app部署骨架应用，添加Clerk认证和shadcn/ui组件，第一天就交付实际功能。相同目的地，完全不同的旅程。

为什么会这样？

区别不在于框架质量，而在于生态系统优化。Next.js/React周围有风投支持的初创公司为其他初创公司构建工具：

• UI：shadcn/ui - 复制、粘贴、交付
• 认证：Clerk/Supabase - 几分钟内配置
• 部署：Vercel - git push等于生产
• 其他一切：如果初创公司需要，有人已经构建了服务

Angular的生态系统服务于企业：强大、灵活、无限可定制。对50人团队完美(?)，对3人团队却是毒药。

\

心智模型#4 - 构建核心，租用上下文

即使有正确的工具，还有最后一个陷阱：因为能做而不是应该做而构建东西的冲动。这个陷阱杀死了技术强大的团队和比我们想象更多的初创公司：构建没人要求的东西，因为你能做，而不是因为你应该做。

我们总共至少花了一个月时间在没人需要的功能上。当Auth0存在时构建自定义OAuth。当Redis + Celery存在时构建基于Postgres的作业队列。从第一天就使用Terraform，而控制台工作得很好。每个决定感觉很有成效，但每个都是自我破坏，无法面对真正的挑战，如与客户交谈或进行其他客户开发。

模式很简单：如果客户不会因此选择你，就不要构建它。

我的50美元规则

如果SaaS每月费用低于50美元，你负担不起自己构建它。你的时间太昂贵了。

构建自定义OAuth总共需要1-2周的维护时间和添加不同OAuth提供商。按初创公司烧钱率计算，工程时间成本为5,000-15,000美元，或者说是机会时间损失。Auth0对最多25,000活跃用户免费，之后每月35美元。你可以用构建一次的成本为Auth0付费35年。

所以，这不是关于金钱，而是关于优先级和机会成本。

例外

我认为，只有在不构建就无法了解用户的情况下才构建。一个简单例子是当你需要测试用户是否愿意为AI生成的报告付费。构建最简单的版本来证明需求。其他一切都试图偷懒。是的，跳过基础设施，跳过"做对"，跳过不交付功能的最佳实践，跳过测试。再次强调，编写代码时尽可能懒惰。

我实际使用的工具

• 认证：Clerk（React-native，更好的DX）或Auth0（B2B导向，企业就绪）
• 电子邮件：Resend（开发者优先）或SendGrid（经过考验）
• 分析：PostHog（免费直到规模化）
• 监控：Sentry（错误处理无与伦比）
• 托管：Cloudflare或Vercel（如果全面使用Next.js）

这些不是背书，而是我为速度优化的选择。我猜你的技术栈会不同，但这个原则不会改变。

\

\

结论

LLM已经使构建变得商品化。任何初级工程师使用Claude都能创建你引以为豪的自定义认证系统。你的价值不再在于你能构建什么，而在于知道不应该构建什么。

领导力是区分信号和噪音的能力。真正的资深意味着有纪律地忽略90%你所知道的，并交付今天的解决方案，而不是明天的架构。