What should I check before launching a SaaS?
It depends on what a failed launch would cost you. At minimum, walk the customer's first session on production infrastructure, prove paid access on the server rather than in the UI, and test workspace boundaries with real accounts. Exercise webhook retries, failed payments, expired sessions, and email delivery before customers find them. Check legal pages, support routes, analytics consent, and backups too. Pre-launch depth should match risk: a free tool can ship sooner, while anything that charges money or holds team data needs the failure paths proven first.
走一遍客戶的首次會話
在你計劃釋出的環境中建立一個全新賬戶。走完驗證或供應商回撥、過載應用、更新資料並退出登入。再用鍵盤在窄螢幕上重複一遍。你平常的開發會話可能掩蓋缺失的配置步驟與陳舊狀態。
檢查那些解釋下一步該做什麼的提示。空狀態介面應提供有用的操作。失敗的請求應說明如何重試，而不是暗示工作已成功。在這些提示中使用產品實際的語言，並確保賬戶與支援連結指向真實目的地。
每種登入方式都把這段旅程重複一遍。Google 和 GitHub 的 OAuth 回撥各有自己的重定向與失敗模式（OAuth 設定指南講了怎麼配置），供應商的測試授權頁與生產環境的表現也不一樣。
- 新賬戶建立與會話恢復可用。
- 退出登入會撤銷訪問並清除上一位使用者的介面呈現。
- 空、載入與錯誤狀態在移動端依然可理解。
- 每個 OAuth 供應商都能在真實域名上完成回撥。
- 驗證與重置郵件能送達、讀起來清楚，並且連結到正確的環境。
- 首次使用體驗能告訴新使用者下一步做什麼。
在服務端證明付費訪問
結賬只是容易的那一半。在供應商沙箱裡走完整條生命週期：購買、Webhook 收到並驗證、權益落庫、付費功能解鎖——然後是續費、取消與退款。每一次轉換都應改變服務端持有的狀態，而不只是客戶端的一個標誌位。計費指南標明瞭 supastack 把這份狀態放在哪裡。
然後測試那些你巴不得見不到的事件：投遞了兩次的 Webhook、失敗的支付、任務進行到一半時訂閱過期。權益回答的是請求時刻的“現在是否允許”；儀表盤上的徽章回答不了。
- 一次沙箱購買能完成並解鎖付費功能。
- 重複的 Webhook 投遞是安全的——處理是冪等的。
- 取消與退款在服務端邊界撤銷訪問。
- 如果提供按席位或按用量的限制，超限會被拒絕。
用真實依賴驗證邊界
用兩個獨立賬戶驗證歸屬。嘗試用一個賬戶讀取與修改另一個賬戶的記錄，包括任務狀態與恢復 URL。在服務端動作邊界檢查付費訪問，而不是隻在介面裡隱藏按鈕。
按工作區劃界的記錄是多租戶產品的脊梁——工作區邊界一文解釋了這個模型。無論你的技術棧是什麼，釋出問題都一樣：每次讀寫是否都從服務端的已認證上下文推導歸屬，而沒有任何記錄 ID 或客戶端發來的工作區被當作證據？
- 跨工作區的讀寫被拒絕。
- 恢復與任務 URL 本身不會授予訪問權。
- 列表與詳情檢視執行同樣的範圍限定。
- 如果提供 API 金鑰和 Webhook，它們也攜帶工作區範圍。
故意演練失敗路徑
後臺任務有兩種截然不同的失敗方式，每種都需要自己的測試。派發失敗會讓客戶端不確定是否有任務入隊——任務級冪等鍵與已儲存的提交讓恢復可以複用原始請求，而不是複製一份。完成失敗意味著工作跑了但結果從未到達——重試與狀態輪詢應該補上這個缺口，而不是觸發第二次生成。
同樣的思路也適用於供應商：一次 AI 供應商超時、一封被退回的郵件、一次計費 API 錯誤。每一種都應該落到一個具體、可解釋的狀態，而不是靜默的半拉子結果。任務恢復指南記錄了套件的生產路徑如何處理這些情況。
- 提交超時後的重試不會複製工作或成本。
- 失敗的完成是可見、可恢復的，而不是靜默丟失。
- 供應商錯誤以誠實的狀態到達使用者，而不是籠統的崩潰。
為第一次故障做好準備
確保有人能找到錯誤、把它關聯到相關任務，並幫助使用者恢復——同時不暴露供應商金鑰。確認存在哪些日誌與審計記錄、保留多久，以及運維如何訪問它們。
釋出前先決定“出問題了”長什麼樣：任務投遞失敗、Webhook 校驗錯誤、供應商花費突然攀升。沒人收到的告警不算監控——可觀測性設定講了這些訊號怎麼接線。
把備份當作運維演練：配置了備份不等於恢復過備份。在你需要它的那天到來之前，先在與生產相似的資料上真跑一遍恢復。
- 一個錯誤能追溯到引發它的請求、使用者與任務。
- 日誌與審計記錄有負責人、保留策略和訪問規則。
- 備份被真正恢復過，而不只是配置過。
- 失敗的任務和 Webhook 錯誤會觸發真人能收到的告警。
檢查產品周圍的介面
法務與溝通介面是釋出的一部分，不是錦上添花：描述產品實際行為的隱私政策與條款、能到達真人的支援地址，以及一個已驗證的發件域名，讓事務郵件從你擁有的地址發出。
像客戶一樣讀一遍每封自動郵件。驗證、重置、收據與完成通知都應該帶產品名、指向正確環境的連結，以及一條不是 noreply 死衚衕的回覆路徑。
- 隱私與條款頁面描述的是你實際執行的產品。
- 事務郵件從你擁有的已驗證域名發出。
- 支援與計費問題有能聯絡到的去處。
把放行與否的決定說清楚
整理好釋出記錄：構建版本、目標環境、測了什麼、怎麼測的，以及仍未驗證的部分。一份如實標註缺口的清單勝過自信的總結——缺口通常就是第一次事故藏身的地方。
在需要回滾路徑之前先定好它：怎麼回退部署、中間寫入的資料怎麼辦、由誰拍板。然後釋出你能完整支撐的最小版本，再有計劃地擴大。
常見釋出問題
釋出清單總在可預測的地方掉鏈子。這些問題能攔住其中的大多數。
- 大多數 SaaS 釋出忘了什麼？ —— 流程的末端：真正會撤銷的退出、真正移除訪問的取消，以及為紙面上存在的備份做一次恢復演練。
- 我需要幾個測試賬戶？ —— 目標環境裡至少兩個。資料隔離和邀請流程用一個賬戶是驗證不了的。
- 沙箱測試還是生產測試？ —— 都要。沙箱證明生命週期邏輯；一筆小額真實交易證明金鑰、域名和 Webhook 接對了地方。
- 什麼時候釋出才安全？ —— 當每一項保護客戶資料或資金的專案都已驗證，而未驗證的專案都寫了下來並有了負責人——而不是當功能清單看起來完整的時候。
- 釋出之後有什麼變化？ —— 保留髮布記錄、盯著你配置的失敗告警，並在認證、計費或範圍限定有任何重大改動後重跑一遍清單。