Should I use a starter kit or build my SaaS from scratch?
It depends on what you want to own. Build from scratch when the product's differentiation depends on a narrow stack, you have time, and you want no inherited assumptions. Choose a starter kit when authentication, teams, billing, jobs, and email are repeated infrastructure rather than your advantage. Compare total cost, inspect the code you will inherit, and run the kit before buying. A kit is cheaper only when its boundaries match your product; otherwise you will spend more removing opinions than you saved. supastack is aimed at TypeScript products spanning web, mobile, and desktop.
把產品工作與重複的基礎設施分開
先列出讓你的產品有用的功能，再列出它運轉所需的基礎設施。研究工作流可能是獨特的；會話處理、客戶擁有的記錄與訂閱訪問通常不是。這份清單比數腳手架首頁上有多少功能更能幫你做評估。
第二張清單比看起來長得多。大多數 SaaS 產品都在重複實現同樣的一打部件，而且每一個都必須與其他部件正確整合，產品才能開始做任何事情。
從零開始讓你直接掌控這些選擇，但也要自己負責整合與維護。腳手架改變的是起點。你仍需要理解它的程式碼，並驗證它對你的產品、團隊與部署所作的假設。
- 身份：登入方式、會話、賬戶找回。
- 工作區：記錄歸屬、邀請、成員角色。
- 計費：結賬、Webhook、權益、取消。
- 後臺任務：佇列、重試、定時、狀態跟蹤。
- 交付：事務郵件、檔案儲存、部署。
比較總成本，而不是標價
腳手架的價格一目瞭然；從零開始的成本攤在幾個月裡。誠實地算一遍：組裝認證、計費、任務和部署花掉的幾週；這些組裝自帶的整合 bug；以及之後每次供應商更新觸發的維護。
腳手架的成本是學習和改造別人寫的程式碼：讀它的約定、替換示例內容、偶爾掰彎它畫的邊界。如果下面的檢查進行順利，這筆交換通常比重造同樣的管道便宜；如果進行得糟糕，那是一個不該忽視的警告——今天讀不懂的邊界，就是明年的生產事故。
評估你將繼承的程式碼
跑一遍安裝說明，跟著一條記錄從介面走到持久化。檢查授權是否位於服務端邊界、配置是否經過校驗、供應商憑證是否留在客戶端包之外。讀一個失敗路徑的測試，而不只是演示介面。
留意示例產品與基礎設施變得不可分的地方。如果移除一個演示功能需要改動認證或計費行為，未來的產品工作可能比初始安裝看起來更困難。在 supastack 中，使用方產品把領域邏輯留在 Starter Core 之外，通過配置與契約連線——專案結構指南標出了這條線的位置。
- 每一個沒有檔案、只能自己摸索出來的安裝步驟。
- 授權在哪裡執行，是逐路由還是系統性的。
- 是否存在反向測試——跨工作區讀取、重放的 Webhook——以及它證明瞭什麼。
- 金鑰放在哪裡，以及是否有任何一個進了客戶端包。
- 當你試圖刪掉一個演示功能時，基礎設施會發生什麼。
先做決定前先跑起來
在承諾之前，先到倉庫裡待上一天。在 supastack 裡這意味著 corepack pnpm install、一份配置好的 apps/web/.env.local，以及本地參考流程：登入、檢視許可權、提交任務、讀取結果。然後 pnpm verify:local 會在 fake 供應商上跑完黃金路徑，不需要任何憑證——本地設定指南走查了整個順序。
然後故意弄壞點什麼。同一個任務提交兩遍。用錯誤的工作區調一個 API 路由。重放一個 Webhook。能把普通失敗處理得漂亮的 starter，比功能清單更長的值錢——因為在你機器上都弄不壞的東西，遲早要在生產環境裡除錯。
把取捨說清楚
當腳手架的既有邊界符合你的需求、且你能講清將要依賴的流程時，就選腳手架；當產品約束會迫使腳手架的假設被反覆修改時，就自建基礎。兩種選擇都可以是合理的；關鍵問題是你的團隊扛得住哪種維護負擔。
為替換示例內容、配置整合、審查資料歸屬與測試部署預留時間。一個能編譯的倉庫只是生產驗收的起點。釋出前，請在客戶將要使用的環境中驗證真實的登入路徑、計費生命週期與恢復行為——釋出檢查清單逐條列了出來。如果底層技術棧也還沒定，如何選擇 SaaS 技術棧覆蓋了逐層評估；這兩個決定互為參照。
| 從零構建 | 採用腳手架 | |
|---|---|---|
| 你擁有 | 每一條約定、整合與失敗模式 | 產品程式碼；管道是有人維護的 |
| 早期速度 | 慢——得先鋪管道 | 快——第一天就能做功能 |
| 風險藏在 | 你還沒發現的接縫裡 | 你還沒檢查的邊界裡 |
| 何時是正確選擇 | 你的約束打破了常見假設 | 它的邊界符合你的產品需求 |
關於腳手架的常見問題
買還是造的爭論總能激起強烈的觀點。這些問題才真正推動決定。
- 正經產品用腳手架有風險嗎？ —— 大量生產環境的 SaaS 跑在買來的地基上。風險不在腳手架本身，而在繼承你從沒檢查過的程式碼。在依賴邊界之前先把它們讀一遍。
- 怎麼判斷一個樣板還在被維護？ —— 看最近的提交、檔案化的更新路徑、覆蓋失敗場景的測試，以及用細節而非路線圖承諾來回答的 issue。
- 如果腳手架的選擇和我不一致怎麼辦？ —— 先分清偏好和約束。給 UI 換皮很便宜；與會話模型或租戶邊界較勁可不便宜。結構性錯配就是自建的理由。
- 以後還能離開腳手架嗎？ —— 程式碼歸你所有，沒有什麼可遷出的——真正的問題是，當你不斷修改時它的管道還是不是資產，這正是產品程式碼與基礎設施程式碼可分離之所以重要。
- 腳手架到底能省多少時間？ —— 大致等於認證、計費、任務和部署本會花掉的那幾週，減去學習和改造所繼承程式碼需要的那幾天。