如何建立 SaaS MVP：帳戶、收費及一項核心功能

要建立 SaaS MVP，請選定你的產品為某位特定客戶所做的唯一一項工作，把這項工作完整建構出來，背後以註冊與資料庫支援；待你想測試用戶是否願意付費時，再加入簡單的付款方式；並盡早把產品放到真實用戶面前，只要你覺得它拿得出手。AI 應用程式生成器能讓你從描述走到一個可運作、已託管的產品，只需數日。最困難、也最有價值的部分，是決定什麼應該暫時不做。

什麼令它成為 MVP，而不是小型 SaaS

MVP（最小可行產品）的存在，是為了用最少的建構工夫回答一個問題，通常是「這些人會不會使用這個產品，並且願意為它付費？」。其中每項功能都應服務於這個問題。如果你對這個詞還不熟悉，請參閱什麼是 MVP。

這就引出一個適用於每項功能的測試：**第一位客戶若沒有這項功能，會否拒絕使用這個產品？**如果不會，它就應該等待。

團隊與角色值得特別留意：它們會牽涉到每張資料表及每項權限檢查。如果你早期的客戶是個人或小團隊，就先用單人帳戶，待有人要求邀請同事時，再加入團隊功能。

建構之前：先寫一句話

「[產品] 協助 [特定客戶] 完成 [特定工作]，而不必忍受 [現有的痛點]。」

例如：「Proposly 協助自由接案設計師在十分鐘內，把探索性通話轉化為附報價的建議書，無需從空白文件開始。」

如果你寫不出這句話，請在建構前先花一節時間規劃。如何驗證應用程式構想一文介紹了在建構前先與潛在客戶溝通的方法，這是整個過程中成本最低的一步。

SaaS MVP 需要什麼

帳戶與資料隔離

每筆資料都屬於某位用戶（日後可能屬於某個團隊）。每次查詢都必須在伺服器端依據已登入的用戶進行篩選。如果這一點出錯，多用戶應用程式便會出現最具破壞性的漏洞之一：用戶 A 只需更改網址中的 ID，就能打開用戶 B 的記錄。要明確要求資料隔離，然後用兩個帳戶進行測試。

登入方式有幾種：把（經雜湊處理的）電郵與密碼存於你自己的資料庫、以電郵發送魔術連結，或使用託管的身份驗證供應商。每種都可行；託管供應商會替你處理密碼重設及安全細節，代價是多一項服務。參見如何為應用程式加入登入功能。

收費

如要收取訂閱費，Stripe 是常見的選擇。標準做法如下：

1. 用戶按下升級；你的伺服器建立採用訂閱模式的 Stripe Checkout 工作階段。
2. 用戶在 Stripe 的託管頁面上付款。
3. 當訂閱開始、續期、失敗或取消時，Stripe 會發送 webhook。你的應用程式把該用戶帳戶的狀態記錄下來。
4. 在允許使用付費功能之前，你的應用程式會在伺服器端檢查這個狀態。
5. Stripe 的託管客戶入口網站讓用戶更新信用卡、查看帳單及取消訂閱，因此你無需建構收費設定頁面。

Stripe 的標準收費是每筆交易一個百分比加一個固定費用，沒有月費（截至 2026 年 9 月）；負責管理訂閱的 Stripe Billing，在其按量收費方案下另加收少量帳單金額的百分比。費率各異，請在 Stripe 的定價頁面查看你所在國家的費率。推出前先定好價格，如何為 SaaS 產品定價可以協助你，並且先在測試模式下完成所有建構。我們的如何加入付款功能指南涵蓋了設定步驟。

核心功能

這正是你的時間應該投放的地方。建構它的完整循環：建立、列出、編輯、刪除，以及「價值時刻」所在之處，例如匯出、生成的結果或發出的訊息。讓空白狀態提供幫助：新用戶在沒有任何資料時，應清楚知道第一步該做什麼。

基本必備功能

• 透過 Resend 或 Postmark 等供應商發送的交易電郵（歡迎信、重設密碼、收據）
• 私隱政策及服務條款
• 讓用戶刪除帳戶的方法
• 基本分析，讓你知道用戶會否回來

有效的第一個提示

建立一個名為 Proposly 的 SaaS MVP，服務對象為自由接案的設計師。登陸頁：標題、三項優點、一個收費區塊（只有一個每月 $19 的方案），以及一個註冊按鈕。應用程式（登入後）：一個列出用戶所有建議書的儀表板；一個「新建建議書」表格，包括客戶名稱、專案類型、工作範圍要點及每小時費率；一個已生成的建議書頁面，顯示工作範圍表格及總價，用戶可以編輯並匯出為 PDF。每位用戶只能看到自己的建議書，並在伺服器端強制執行。所有資料儲存於資料庫。目前使用簡單的佔位登入畫面；我們稍後會加入真正的身份驗證及 Stripe 收費。設計簡潔專業。

這個提示描述了客戶、循環及資料界線，並刻意把登入與收費延後處理，讓第一個結果專注於真正重要的功能。

建構步驟

1. **以範例資料建構核心功能。**反覆修改，直至主要循環感覺順暢。
2. **資料庫。**確保資料在重新整理及新工作階段後仍然保留。
3. **真正的帳戶。**註冊、登入、重設密碼。然後用兩個瀏覽器、兩個帳戶測試資料隔離。
4. **登陸頁。**解釋那一句話，並把註冊按鈕放在首屏可見的位置。
5. **收費。**Stripe Checkout、webhook、伺服器端的付費狀態檢查，以及客戶入口網站。測試成功付款、信用卡被拒及取消訂閱。
6. **電郵。**歡迎信、重設密碼及收據。
7. **安全檢查。**我們的AI 建立應用程式安全清單是很好的檢查清單。
8. 使用你自己的網域發布，並親自邀請首批十位用戶。

常見錯誤

• 為「所有人」而建構。「小型商戶」這類產品比「獨立簿記員」難建構，也難銷售。
• **在有客戶之前就先建管理後台。**一段時間內，你可以直接查看資料庫。
• **信任瀏覽器來決定存取權。**隱藏按鈕並不能阻止請求。應在伺服器端檢查方案與擁有權。
• 在成功頁面上授予付費權限，而不是在 Stripe webhook 中授予。
• **等待產品「完美」才發布。**第一個版本應該有點不好意思。如何推出應用程式並獲得首批用戶提供了建構之後的建議。

衡量是否有效

在推出前先決定「有效」的定義，否則每個結果都會看起來令人鼓舞。對大多數 SaaS MVP 來說，三個數字已經足夠：

• **啟用率：**有多少註冊用戶完成過一次核心循環，例如建立第一份建議書，或執行第一份報告。
• **回頭率：**有多少人在接下來一週回來，並再次完成該操作。
• **付費率：**有多少活躍用戶付費，或在你詢問時表示願意付費。

用簡單的分析工具，或在你自己的資料庫上寫幾條查詢來追蹤這些數字，並與流失的用戶交談。他們的原因比任何儀表板都更有價值。

何時不應建構

如果產品主要只是現有工具之上的一層薄薄包裝，例如一張表格、一份試算表或一份電子報，就先用那個工具測試構想。一個 Typeform 加上一個 Stripe 付款連結，已足以在建構任何東西之前驗證需求。只有當價值在於工作流程本身，而現有工具無法提供時，才值得建構 MVP。

在 Mythex 建構

在 Mythex，你描述產品，代理人便會在即時預覽中同時建構登陸頁與應用程式；當你要求儲存資料時，它會加入專用的 Postgres 資料庫。文件中的 SaaS MVP 使用案例遵循與本指南相同的「薄切片」順序。如果你仍在塑造構想，首次建構前使用計劃模式會很有用。

你需要自行負責的部分包括：你的應用程式用戶的登入，須使用你選擇的身份驗證方式或供應商（加入身份驗證）；訂閱則使用你自己的 Stripe 帳戶，金鑰以專案機密形式儲存。Mythex 不為你的客戶提供內建的 SaaS 收費、用量計量或團隊 SSO。在 Pro 方案下，你可以連接自訂網域，並匯出程式碼或同步至 GitHub，日後開發人員便能接手。如需起始提示，可瀏覽應用程式範本或 SaaS 儀表板範本。

常見問題