一個只講清楚「我們解決什麼問題」的 SaaS 網站，最多能拿到詢盤，拿不到註冊使用者。真正讓 SaaS 成立的是四層能力疊加：行銷層讓人看懂並願意試用；帳號層確認「你是誰」；計費層確認「你付了多少錢、買到什麼」；應用與管理層把承諾兌現成日常使用。缺任何一層，網站就退化成宣傳冊。
對創業者和小型軟體團隊來說，改造順序建議是先補帳號體系，再補訂閱計費，最後補後台與權限。三者存在強依賴：沒有帳號就沒有歸屬主體，沒有計費就沒有可區分的權益，沒有後台就沒有手動保底的手段。
SaaS 官網和實際產品介面到底差在哪
這兩類頁面的使用者、目標和技術要求完全不同，混在一起做是很多專案卡住的第一步。
| 對比維度 | 行銷層（首頁、價格頁） | 產品層（工作台、後台） |
|---|---|---|
| 訪問者 | 公開訪客、搜尋引擎與 AI 搜尋爬蟲 | 已登入的試用或付費使用者 |
| 核心目標 | 解釋價值、建立信任、推動註冊 | 完成任務、管理資料與帳單 |
| 驗證要求 | 無需登入 | 必須登入並校驗角色 |
| 內容 | 少變，需要被索引 | 高頻變化，不能被擷取收錄 |
| 優化重點 | 標題、結構化內容、可被引用 | 權限、效能、資料隔離 |
一個常見錯誤是把工作台也交給搜尋引擎抓取，或者把價格頁鎖在登入牆裡。前者洩露產品結構、稀釋站點主題；後者讓潛在客戶在決策前看不到定價，直接流失。正確做法是在路由層就分開：公開路由輸出可索引內容，應用路由強制驗證並禁止收錄。
一個能運作起來的 SaaS 網站需要哪些模組
按層拆功能，比按頁面拆功能更容易排期。
| 層級 | 必備模組 | 判斷標準 |
|---|---|---|
| 行銷層 | 首頁、功能頁、價格頁、文件或部落格、隱私與條款 | 不看文件也能理解價格與價值 |
| 帳號層 | 註冊、電子郵件驗證、登入、找回密碼、帳戶設定 | 使用者能自助完成全流程 |
| 計費層 | 結帳頁、訂閱、發票、支付回調、額度 | 付款狀態可被系統讀出並執行 |
| 應用層 | 使用者工作台、核心業務資料 | 登入後能看到「自己的」資料 |
| 管理層 | 使用者、訂閱、訂單、內容、權限、操作日誌 | 營運無需改資料庫就能處理問題 |
如果時間只夠做一半，優先做帳號層、計費層和最小的可用工作台，最後再補管理層。管理後台可以先用最笨的表格實現，但一定要有，否則第一批付費使用者出問題時只能手動改資料庫。
使用者註冊、電子郵件驗證和登入怎麼實現
實現路徑可以壓縮成五步：
- 選擇登入方式：以電子郵件密碼為主，加上 Google、GitHub 這類 OAuth 作為快捷入口，能明顯降低註冊摩擦。
- 寫入帳號並寄送驗證郵件：註冊成功後立即產生一次性驗證 token，綁定帳號並設定過期時間；未驗證帳號標記為待驗證，不授予任何付費權益。
- 驗證與重寄限流：驗證連結只能使用一次；同一電子郵件的重寄要限頻，否則會變成轟炸別人信箱的工具。
- 維持工作階段：使用伺服器端工作階段或帶簽章的權杖，配合 HttpOnly、Secure 的 Cookie，前端不要長期保存可被指令碼讀取的憑證。
- 找回密碼與解除綁定：忘記密碼走一次性連結重設；第三方登入要允許綁定與解除綁定，避免使用者換電子郵件後永久遺失帳號。
安全細節上不要自研加密與雜湊，使用成熟框架的密碼雜湊與工作階段機制。電子郵件驗證、Google / GitHub 登入和基礎帳戶體系屬於通用基礎設施，We0 的全端生成能力已把這類能力納入生成範圍（We0 全端程式碼生成），團隊可以把精力放在業務欄位與權限規則上。
免費使用者和付費使用者怎麼區分
最容易被忽略的一點：權益判斷必須發生在伺服器端，前端只做展示。前端隱藏按鈕不等於限制，API 被直接呼叫時照樣會執行。
推薦模型是三張表加一個伺服器端函式：方案表定義每個方案的權益標識；訂閱表記錄帳號目前狀態、週期與外部訂閱 ID；權益表記錄帳號級額度餘量。
canUse(user, feature):
if user.status != "active": return false # 未驗證或被封鎖
plan = plans[user.plan_id]
if not plan.features.contains(feature): return false
if plan.quota > 0 and user.used >= plan.quota: return false
return true
免費與付費的差別通常落在三處：功能開關（進階報表、多人協作）、數量額度（專案數、成員數、生成次數）、資料保留期。用額度做分層比用「禁用」做分層更平滑——免費使用者能真實用出價值，才會主動升級。
Stripe 訂閱付款如何接入
訂閱接入的核心不是按鈕，而是「誰說了算」。原則只有一條：以支付平台的訂閱狀態為唯一事實來源，自己資料庫裡的欄位只是副本。
- 建立價格物件：為月付與年付各建立一個價格，把價格 ID 寫進環境變數，不要把金額硬編碼在前端。
- 發起結帳：由伺服器端建立結帳工作階段，把帳號 ID 寫進 metadata，使用者跳轉離開站點完成付款。
- 接收回調：設定 Webhook 端點，訂閱建立、續費成功、付款失敗、訂閱取消等事件都要處理，回調是開通權益的唯一觸發點。
- 回調可重放：同一事件可能重複投遞，處理邏輯必須冪等，按事件 ID 或訂閱 ID 去重；回應要快速返回，耗時動作非同步執行。
- 狀態映射：把外部訂閱狀態映射成內部狀態，業務程式碼只認內部狀態，不直接讀外部欄位。
- 提供帳單入口：跳轉到支付平台自帶的客戶入口管理發票與卡片，比自研帳單頁省下大量維護成本。
| 事件類型 | 系統應做的事 |
|---|---|
| 結帳完成 | 寫入訂閱記錄，設為試用或有效，記錄週期 |
| 續費成功 | 延長有效期，重設週期內額度 |
| 付款失敗 | 設為逾期，保留唯讀權限並提示更新支付方式 |
| 訂閱取消 | 不立即降級，等週期結束再降權 |
| 退款或爭議 | 記錄狀態，暫停高風險權益並人工複核 |
付款成功之後如何開放功能
這一段最容易出事故：使用者在支付成功頁看到「歡迎使用」，但權益還沒寫進資料庫，進來後看到的是空工作台或再次付款提示。
正確做法是把「支付成功」和「權益生效」當作兩個獨立事件。回調到達並校驗成功後，才寫入訂閱、重新整理權益、寄送歡迎郵件；支付成功頁只負責輪詢自己的 API 等待權益可用，逾時則提示「付款處理中，稍後以電子郵件通知」，而不是直接放行。
降級同樣要設計。到期、欠費、退款都該走統一的降權流程：先保留唯讀存取一段時間，再逐步關閉寫入與匯出。突然斷掉全部權限會激怒使用者，無限期保留全部權限等於免費送產品。
使用者在哪裡管理帳戶和方案
幾分鐘搭建展示站並增長獲客
輸入一句想法，We0 AI 即可生成展示站、頁面與 CMS。發佈上線後並幫你獲取客戶和流量。
用戶註冊贈送一次完整項目生成
適合先體驗一次完整生成流程，快速看到專案初稿。
一個資訊完整的帳戶頁能減少大量客服工單。至少包含：個人資料與密碼、電子郵件修改（需重新驗證）、目前方案與續費日期、用量與額度餘量、發票歷史與下載、升級降級取消入口、登出所有裝置與帳號註銷。
方案變更要區分方向：升級即時生效並按比例計費，降級排到下個週期，避免使用者反覆切換造成結算混亂。取消訂閱時不必做連擊式挽留彈窗，一次清楚確認加一句「權益保留到 X 月 X 日」比十層彈窗有效得多。
管理員後台該管理什麼
後台不是「給老闆看的儀表板」，而是例外處理工具。
| 對象 | 常見操作 | 關鍵約束 |
|---|---|---|
| 使用者 | 查詢、重設密碼、封鎖、備註 | 不允許直接改明文密碼，操作留痕 |
| 訂閱 | 查看狀態、手動延期、補開發票 | 與支付平台側核對後再改 |
| 訂單 | 查詢、退款標記、對帳匯出 | 退款必須記錄原因與操作人 |
| 內容 | 文件、文章、說明中心 | 與公開站點同源，避免兩套內容 |
| 權限 | 指派管理員角色 | 最小權限，敏感操作二次確認 |
後台最常見的錯誤是把管理員帳號做成萬能鑰匙。建議至少分三檔：唯讀營運、可處理訂單與使用者、可修改計費與權限。所有敏感操作寫入稽核日誌，出問題時能追溯誰在什麼時候改了什麼。
官網和後台該放進一個專案，還是拆成兩套
早期團隊幾乎都該選單一專案：共享網域與工作階段，使用者在首頁註冊後直接進入工作台，不需要在多個系統間做單一登入；內容、SEO 與產品更新在同一套路由和部署裡，維運成本最低。公開的 SaaS 驗證與帳戶管理範例也採用這種一體化形態，驗證、角色權限、訂閱、網域與部署都在同一個應用內完成（SaaS Auth Dashboard 範例）。
當團隊已經分工明確、流量大到需要獨立擴容時再拆成官網、前台應用與後台服務。代價是要維護跨網域工作階段、統一驗證與內容同步。判斷標準可以看三條：官網是否每週多次更新而應用半年才發一版；是否已有多人分別負責行銷與產品開發；應用是否有獨立的伸縮與資料庫隔離要求。三條都成立再拆，否則先合併。
單一專案內部也要有清楚邊界：行銷路由不做驗證但必須可索引，應用路由強制驗證且禁止收錄，API 層統一校驗權益，後台路由加上額外角色校驗。We0 把頁面結構、驗證、訂閱與點數、CMS 與後台、多語言、SEO 與部署放在同一條生成鏈路裡（We0 全端程式碼生成），適合希望用一個專案承接官網與產品入口的團隊；具體業務規則與權限邊界仍需按產品需求定義。
用專案管理 SaaS 走一遍完整鏈路
假設做一個給小團隊用的專案管理 SaaS，免費版 3 個專案，專業版不限專案並支援成員協作。
- 首頁：說清「誰在什麼場景下用它」，給出免費註冊入口，不要求信用卡。
- 價格頁：三個方案並列，標明月付與年付差額，寫明額度與限制。
- 註冊與驗證：以電子郵件註冊後立即收到驗證郵件，驗證完成才允許建立專案。
- 訂閱付款：在工作台內點擊升級，跳轉託管結帳頁，選擇月付或年付。
- 權益開通：回調寫入訂閱狀態，工作台重新整理後專案上限解除，顯示目前方案與續費日期。
- 使用者工作台：只展示該帳號自己的專案，成員邀請按席位校驗。
- 管理後台：客服可查詢使用者、查看訂閱，為逾期使用者手動延期一天做緩衝。
這條鏈路裡真正花時間的不是頁面，而是第 5 步的狀態一致性，以及第 7 步的例外處理。很多團隊把八成時間花在首頁視覺上，上線後卻靠人工處理欠費與退款。
上線前的檢查清單
- 未驗證電子郵件的帳號是否被攔在付費權益之外？
- 每一處權益判斷是否都在伺服器端執行？
- 支付回調是否冪等，是否只認平台狀態？
- 支付成功頁是否等待權益寫入資料庫，而不是直接放行？
- 逾期、取消、退款是否都有對應降級路徑？
- 應用路由是否禁止收錄，公開頁面是否可被索引？
- 管理員操作是否有稽核日誌與最小權限？
- 官網內容與說明文件是否同源，避免長期分叉？
常見問題（FAQ）
SaaS 網站可以只做產品介紹頁嗎？
可以作為階段性落地頁，但它只能承擔獲客，無法承載註冊、試用與付費。使用者點「免費開始」後無處可去，流量就浪費了。
不會寫程式碼能做 SaaS 嗎？
帳號、訂閱、後台與部署這類通用基礎設施可以借助成熟平台或 AI 生成能力快速搭起來，但計費規則、權限邊界與資料模型仍需人來設計並驗證。工具減少重複工程，不能替代產品決策。
訂閱付款必須用 Stripe 嗎？
不是，但選型要看目標市場與結算週期。Stripe 的訂閱、發票與客戶入口相對完整；面向國內使用者還需考慮本地支付方式。無論用哪家，都要遵守「外部狀態為唯一事實來源」的原則。
免費使用者和付費使用者怎麼區分最省事？
方案表、權益表加一個伺服器端判斷函式。不要在各個頁面散布條件判斷，否則新增一個方案就要改十幾處程式碼。
官網和後台要不要放在同一個專案裡？
早期放在同一個專案，共享網域與工作階段，維運成本最低；等團隊與流量都需要獨立迭代時再拆。
付款成功但功能沒開通怎麼辦？
先查回調是否到達、簽章是否校驗通過、冪等去重是否誤判，再查權益是否寫入。使用者側要給出「處理中」的明確回饋與人工保底管道，而不是讓使用者重複付款。
相關工具（Related Tools）
- Stripe 官方文件：訂閱、結帳與回調機制的原始說明
- React + Shadcn UI 等元件庫：快速搭建工作台表格、圖表與分頁互動（實現參考）
- 設計稿轉程式碼工具：把後台介面設計直接轉成可執行頁面
- We0.ai：在一個專案內組合驗證、支付、CMS 後台與部署
相關連結（Related Links）
摘要（Summary）
只做產品介紹頁的 SaaS 網站解決的是「讓人相信」，而登入、訂閱付款和後台管理解決的是「讓人真正用起來並持續付費」。落地順序建議是帳號體系、訂閱計費、最小可用工作台、管理後台；技術上有三條硬性約束：權益判斷放在伺服器端、支付平台狀態是唯一事實來源、支付成功與權益生效分開處理。官網與後台在早期可以放在同一個專案裡共享網域與工作階段，等團隊和流量都需要獨立迭代時再拆分。
