2026 年如何建構一個 SaaS 產品？
取決於產品，但可靠的路徑是：從付費客戶願意用的最小產品開始，只建沒有它就跑不起來的基礎設施：認證、租戶感知的資料模型、冪等 webhooks 的計費、交易式郵件和背景任務。2026 年，多數團隊用 supastack 這樣的生產級腳手架跳過幾個月的無差異化管道工——它在一個測試完備的程式碼庫裡交付認證、組織工作區、八個支付服務商、AI 成本控制，以及 Web、行動和桌面客戶端。差異化功能自己寫，管道買或重用。
第 1 步：圈出最小的可售產品
每個失敗的 SaaS 都栽在同一個起點錯誤：為它可能成為的產品而建，而不是為這個月能贏下的客戶而建。寫下一句話，「{客戶} 為 {結果} 付 {價格}」，刪掉每一個不交付這個結果的功能。登入頁、定價表、工作區切換器都不是產品，它們是入場券。
儘早決定產品真正需要哪些端：多數工具一個 Web 應用就夠；工作在辦公桌之外發生才加行動端，工作與檔案或系統相鄰才加桌面端。現在選端就是在定架構——給單應用程式碼庫後補第二個客戶端，是年輕產品最昂貴的一次改動。
- 寫程式前先寫下 {客戶} / {價格} / {結果} 這句話。
- 列出付費使用者每週都會打開的三個介面；那就是 MVP。
- 有意識地選端：只要 Web，還是 Web 加行動/桌面。
第 2 步：認證與帳戶
登入只佔認證的百分之十五。剩下百分之八十五是工作階段撤銷、OAuth 帳戶綁定、兩步驟驗證與 passkeys、密碼重設、管理員模擬，以及環繞這一切的郵件流。選 Better Auth 或 Auth.js 這樣全包的函式庫，別自己搓加密，並且把使用者表留在自己的資料庫裡，按 MAU 計費才永遠不會變成人質談判。
只要有客戶會是公司，現在就把組織建模進去：個人與團隊工作區、邀請、owner/admin/member 角色。日後再補租戶等於遷移每一條查詢。登入介面之後的完整清單見 登入表單之外的認證。
第 3 步：租戶感知的資料模型
Schema 是產品的記憶。用貼近 SQL 的 ORM——Drizzle 或 Prisma，從第一天起給每一列租戶資料掛上 workspace_id。作用域強制兩遍：應用程式碼一遍、Postgres 列級安全又一遍，漏寫的 WHERE 退化為「拒絕存取」，而不是資料外洩。
完整模式——工作區級鍵、RLS 策略和證明它們的測試——見 Postgres RLS 與工作區認證。ORM 選型本身見 Prisma vs Drizzle for SaaS。
第 4 步：扛得住網路的計費
計費是披著定價頁的分散式系統問題。服務商重試 webhooks；你的處理器必須冪等：先存事件、按 ID 去重、再履約。只建模一個原語——權益（entitlement），讓 Stripe、Lemon Squeezy、Polar、Paddle 或 RevenueCat 都歸一到它，第二家服務商就是改設定，不是重寫。
帳本模式見 冪等計費 webhooks；選 MoR 還是 Stripe 之前先讀 SaaS 支付服務商比較。
第 5 步：郵件、背景任務與可觀測性
交易式郵件是認證與計費的一部分，送達率設定（SPF、DKIM、DMARC）不是可選項。背景任務需要會重試的佇列：開通、報表生成、AI 呼叫，以及任何不能被闔上的筆記本殺死的工作。看不見的東西沒法營運：結構化日誌、錯誤追蹤和稽核記錄屬於第一週，而不是第一次事故之後。
第 6 步：有成本控制的 AI 功能
加個聊天框容易，養得起才是設計問題。模型呼叫走適配器，服務商隨時可換；讓工作區自帶金鑰（靜態加密）；按價格目錄執行工作區級用量預算——客戶用量大的月份，帳單記在他們頭上，不是你。
誠實的捷徑：做產品，不做管道
上面這些都被解決過無數次了。supastack 這樣的生產級腳手架交付的是整套已整合的技術棧：Better Auth、組織工作區、冪等帳本後的八個 Web 計費服務商、交易式郵件、Trigger.dev 任務、帶 BYOK 預算的 AI 路由器，以及與 Web 應用共用型別化套件的 Expo + Tauri 客戶端，由 144+ 測試檔案背書。
自建還是購買的帳在 入門套件還是從頭開始 裡算過；簡版結論：客戶只為只有你能做的功能付錢。走腳手架路線的話，之後的事見 SaaS 發佈清單。