KISS 或死亡：為什麼資深工程師在新創公司失敗

我的第一家新創公司失敗了，幾家鄰近的新創公司也失敗了。我們擁有：10萬美元的 GCP 額度、一位曾在企業中建立系統的創始工程師，以及上市策略。我們失敗了，不是因為我們建造得不好，而是因為我們建造得太好。這就是問題所在。

當我們花時間與看似「不理想」的技術堆疊搏鬥時，我們失去了最重要的東西：時間、動力和戰略性機會。

這個故事不是關於缺乏常識的人。我有常識，我們知道應該保持簡單。但當你的心智模型不適合當前情況時，所有常識都會被沖走。你做出「正確」的決定，卻讓自己走向滅亡。

這也不是關於糟糕工程的故事。而是關於優秀的工程如何扼殺新創公司。關於讓你成為資深工程師的經驗如何成為你最大的負擔。關於「做對」甚至「做簡單」往往是做錯了。

本文提供心智模型，幫助你做出正確決策，避免我犯過的錯誤。

:::tip 適合對象： 正在創立或加入早期新創公司的資深工程師。如果你在企業或大型科技公司待了5年以上，這是給你的警告。

:::

\

心智模型 #1 - 「免費」基礎設施是最昂貴的

10萬美元的 GCP 額度看似禮物，但其實是陷阱。它推動你過度工程化，因為「已經付費了」。你獲得計算實例、負載平衡器、容器註冊表和需要企業級設置的企業工具。你真正需要的是什麼？一個「推送部署」按鈕。

當然，你可以在 GCP/AWS/Azure 上建立「從 GitHub 部署到虛擬機」的工作流程。有些產品接近這個目標。但它需要額外步驟：配置 Cloud Build、設置 IAM 角色、編寫部署腳本、管理密鑰和配置健康檢查。在部署實際產品之前，你就在建立部署基礎設施上燒掉了時間。

同時，像 Railway 或 Fly.io 這樣的平台提供新創公司真正需要的：具有即開即用 GitHub 部署功能的持久虛擬機。簡單到極致：你推送代碼，它就部署。只需使用已準備好的虛擬機，帶環境變量、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%，並交付今天的解決方案，而不是明天的架構。