Which SaaS stack is best for a new product?
It depends on your constraints, not on a universal ranking. A team selling to businesses usually needs Postgres, typed end-to-end code, team workspaces, and reliable billing; a solo founder validating a consumer idea may need speed and a single platform more than breadth. Evaluate the seams between auth, payments, jobs, and email, count the maintenance each choice creates, and build one vertical slice before committing. supastack fits TypeScript products that need web, mobile, and desktop on shared infrastructure. If you only need a landing page and a payment link, a smaller stack is the better answer.
圍繞產品約束做選擇
在比較框架名字之前，先寫下產品需要什麼。Web 控制台、離線移動工具與長時執行的研究工作流有著不同的約束。確定你需要哪些客戶端、哪些資料屬於每位客戶，以及哪些操作必須在瀏覽器標籤頁關閉後繼續。
把團隊經驗與功能清單放在一起考量。邊界清晰的熟悉技術棧可能比更新潮的組合更易維護——後者要求同時學習認證、部署與持久化約定。要計算升級與除錯的持續成本，而不只是首次安裝。
- 第一天就需要哪些客戶端形態——只要 Web，還是也要移動端和桌面端。
- 哪些資料屬於每位客戶，以及團隊是否共享工作區。
- 哪些操作必須比瀏覽器標籤頁活得更久：排隊任務、定時工作、長時執行的任務。
- 你要按什麼收費——訂閱、席位、用量——以及由誰付費。
- 團隊實際上扛得住多大的運維面：資料庫、佇列、供應商。
評估框架之下的各層
框架的名字只描述了表面。底下的各層才決定產品能否立得住。逐層走一遍，對每一層問同一個問題：誰擁有這個決定，它在哪裡被執行？
技術棧留白的任何一層，都是你簽約認領的工作。“自帶認證”是正當的設計——它只意味著你要自己負責會話語義、供應商整合，以及隨之而來的每個失敗場景。留白是選擇；看不見的層是負債。套件的模組檔案是理解“被擁有的層”長什麼樣的好參考。
| 層 | 要回答的問題 |
|---|---|
| 身份 | 誰在每個端面上籤發並驗證會話？ |
| 資料 | 每條記錄如何限定在所屬客戶之內？ |
| 計費 | 支付事件在哪裡變成訪問許可權，誰又負責撤銷？ |
| 後臺任務 | 任務失敗、重試或跑了兩遍時會發生什麼？ |
| AI 與供應商 | 誰擁有金鑰、模型選擇和支出上限？ |
| 運維 | 金鑰、日誌、備份與升級實際怎麼跑？ |
檢查工具之間的接縫
技術棧是一系列整合決策。弄清誰擁有會話、記錄如何劃定邊界、支付事件在哪裡變成訪問許可權，以及介面如何取得後臺任務的結果。正是這些連線決定了請求失敗或重複到達時，正常路徑是否仍然正確。
supastack 在 Web 端使用 Next.js、移動端使用 Expo，底層是共享的 TypeScript 包。Better Auth 負責身份，Postgres 與 Drizzle 負責持久化，Trigger.dev 負責顯式的工作流行為。這些是本倉庫的選擇，並非主張每個產品都應使用同樣的工具——技術棧指南記錄了每個選擇及其理由；即使你選了別的工具，這些問題依然適用。
無論用什麼工具，檢驗都一樣：挑一條記錄，跟著它從介面穿過服務端邊界進入持久化再走回來。如果任何一跳只是約定而不是被強制的規則，未來的某位貢獻者遲早會打破它。
把持續執行的成本算進去
技術棧決策也是運維決策。Postgres 需要備份和遷移紀律。任務執行器需要一個真有人開啟的儀表盤。每個供應商金鑰都需要輪換機制和客戶端包之外的家。在功能清單把你征服之前，先把這些條目加進對比。
趁還有選擇時檢查升級路徑。一個鎖死依賴、有檔案化更新流程的 monorepo——套件為此專門維護了一份更新指南——比由各持一套版本假設的教程拼出來的技術棧更經得起時間。
- 依賴與安全更新：多久來一次，由誰應用。
- 供應商憑證：存放在哪裡，誰能輪換。
- 資料：備份計劃、恢復演練和保留策略。
- 可觀測性：什麼會響著地壞掉，什麼會悄悄壞到客戶來報。
構建一條小的垂直切片
在承諾採用某套技術棧之前，先跑通一條切片：讓使用者登入、寫一條歸屬記錄、啟動一項工作並取回結果。然後故意嘗試錯誤的工作區、過期會話與失敗的任務。評估這些普通場景需要多少自定義膠水程式碼。
留一份簡短的決策記錄：該棧支援什麼、你選擇推遲什麼、什麼情況會觸發重新評估。原生購買、真實供應商驗收與部署運維應是明確列出的專案，而不是藏在一次成功本地構建背後的假設。合適的技術棧會給團隊留出足夠的注意力做產品。
如果這條切片在某個 starter 的倉庫裡跑得順利，接下來的問題就是是否採用它——用腳手架還是從零開始走查了那個決定。
- 登入，然後在重新整理後恢復會話。
- 寫一條限定在某個工作區的記錄並讀回來。
- 啟動一個後臺任務，稍後取回結果。
- 用錯誤的工作區和過期的會話重複同樣的呼叫。
關於選擇技術棧的常見問題
技術棧決策總能引來一堆自信的建議。這些才是值得為自己的產品回答的問題。
- 應該選自己已經熟悉的技術棧嗎？ —— 通常是的，只要它能表達產品的約束。邊界清晰的熟悉棧，勝過要花幾個月去學的時髦棧——除非產品確實需要它沒有的東西，比如原生移動端。
- 前端框架最重要嗎？ —— 不如它周圍的各層重要。框架塑造的是 UI；身份、範圍、計費和後臺任務才決定產品能否保持正確。
- 技術棧評估應該花多久？ —— 以天計而不是以周計：寫下約束、檢查接縫、跑一條垂直切片。如果普通的失敗都要靠自定義膠水，就繼續找。
- 什麼時候換棧才算合理？ —— 當核心約束變化時——比如必需的平臺、規模門檻——而不是新版本看起來更漂亮時。切換成本在認證和資料裡，不在元件裡。