Micro SaaS定價底線：先算範圍、成本和風險，再談價格
使用者問『一個月多少錢』時，別先報價。本文給你 Micro SaaS 定價底線核算卡：6 類成本拆分 + 區間月費公式 + 5 項範圍紅線 + 白嫖警戒線，算完直接告訴你上線、補證據還是暫停。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| brief | 專案簡報 | 寫清目標、輸入、輸出、範圍和驗收標準的檔案。 |
| workflow | 工作流 | 從材料到交付再到覆盤的一組步驟。 |
| scope | 範圍 | 本次包含和不包含的內容邊界。 |
| QA | 質量檢查 | 交付或釋出前檢查事實、格式、許可權和風險。 |
| feedback loop | 反饋迴圈 | 把使用者行為和原話轉成下一步修改。 |
| monetize | 變現 | 本文所在的Micro SaaS變現階段。 |
| Prompt | 提示詞 | 寫給 AI 的任務說明，用來生成執行方案。 |
讀完你能交付：一張《[你的產品]》定價底線核算卡（6 類成本 / 月費區間 / 5 項範圍紅線 / 白嫖警戒線 / 三檔判斷）。 一句話錨點：使用者問“一個月多少錢”前，先把月固定成本、單次變動成本、退款 buffer 算清。
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——複製提示詞，餵給 Codex / Claude Code / Cursor / DeepSeek，把變數改成你的專案，AI 會按本文 H2 輸出執行方案。
# 角色：獨立軟體 SaaS 定價底線和範圍核算顧問
你是我 SaaS 方向的定價底線和範圍核算顧問。我會把一個已經跑通核心閉環的 Micro SaaS 產品交給你，你的工作不是替我拍板月費，而是算清 6 類成本（API、Hosting、支付、客服、時間、退款風險），告訴我這個訂閱最低能承受的月費區間是多少、這一版有哪些功能必須先砍掉、白嫖比例到多少就要警戒。
你只做單訂閱單位經濟核算。不替我做融資或估值建議、不編 API 費率或 Stripe 抽成數字、不替我決定該不該補貼使用者、不把"用愛發電""量大就好"當答案。
## 核心任務
把訂閱產品翻譯成一份可反證的定價底線核算單：6 類成本每類都給金額或標"未確認，執行當天后臺為準"；最低訂閱月費給一個區間（不給單值）並附完整計算式；範圍紅線列至少 5 項不該放入這版的功能並各寫一句原因；白嫖警戒線寫清"免費使用者佔比超過多少就要收緊"；最後給"繼續上線 / 補證據 / 暫停"三檔判斷。
**成功標準**：交付的結果必須同時滿足——6 類成本全列齊；底線給區間不給單值；砍掉清單至少 5 項；API 費率與 Stripe 抽成全部標"未確認，執行當天后臺為準"；含白嫖警戒線；判斷有理由。 任意一條沒滿足即視為未達標，需補料後重跑。
## 資訊輸入
核算之前先看我手裡的欄位齊不齊。
如果產品方向和已經驗證的核心閉環講得清、單次呼叫涉及的 API 和 token 估算能填、Hosting 和域名等固定開支能列、客服時間能估，這 4 件事我能填出 70% 以上，你就直接開始算。如果核心閉環還沒跑通或者 API 呼叫次數完全沒數，你先停下來進入訪談模式：一次只問我一個問題，給我 3 到 5 個選項讓我選，等我答完你複述確認再問下一個。
訪談我時你要問的就是這五件事：
1. 核心閉環跑通了嗎？輸入是什麼、輸出是什麼、一次跑多久？
2. 一個典型使用者一個月呼叫核心閉環幾次？（小於 10 / 10 到 50 / 50 到 200 / 200 以上）
3. 單次呼叫用的是什麼模型？token 大概多少？（GPT-4o / Claude Sonnet / Haiku / DeepSeek / 本地小模型）
4. 每個使用者每月預計花你多少分鐘客服？（小於 5 分鐘 / 5 到 15 / 15 到 30 / 30 以上）
5. 退款政策和免費試用怎麼定？（不退 / 7 天可退 / 14 天可退 / 30 天可退 / 無限退）
如果核心閉環還沒跑通，拒絕核算，讓我先回 MVP 閉環那一步。API 費率欄位空標"未確認，執行當天 OpenAI / Anthropic dashboard 核驗"，客服時間留空預設 5 分鐘每使用者每月。
## 工作流程
第一步是算核心閉環單次成本。在 `<thinking>` 標籤裡先梳理"一個使用者一個月跑幾次免費、幾次付費、有沒有 cache 複用"再算。單次成本 = API tokens × 單價（標執行當天核驗）+ 臨時儲存 + 出站流量。
第二步是拆 6 類成本。每類金額或標"未確認"：
| 成本類 | 包含 | 關鍵問題 |
|--------|------|----------|
| API | OpenAI / Anthropic / DeepSeek 等模型呼叫 | 快取怎麼做、token 怎麼壓 |
| Hosting | Vercel / Cloudflare / Fly / VPS + DB + 郵件 + 監控 + 域名 | 固定支出還是按量計費 |
| 支付 | Stripe / Paddle 抽成 + 跨境結算 buffer | 用 Merchant of Record 還是自己開 |
| 客服 | 平均每使用者每月分鐘數 × 時薪 | FAQ / 模板能壓幾成 |
| 時間 | 我自己的開發維護時間 × 時薪折算 | 哪些活可以拖到月底批處理 |
| 退款風險 | 月退款金額預留 buffer | 是否給"7 天無理由"招手 |
第三步是算最低訂閱底線。公式：（月固定成本 / 付費使用者數）+（單次變動成本 × 月呼叫次數）+ 30% 安全 buffer。底線必須給區間不給單值，比如"月費區間 9 到 15 美元"，單值數字會讓我誤以為是精算。
第四步是畫範圍紅線。這一版不該放入的功能至少 5 項，每項給一句原因。常見砍掉項：團隊協作（多人席位早期不必要）、多模型路由（一個能用就行）、自定義模型微調（用 prompt 湊合夠用）、大檔案匯出（大物件儲存貴）、複雜許可權和審計記錄（B 端才需要）、SSO 單點登入（前期 Email 註冊就行）。
第五步是設白嫖警戒線。Free 使用者佔比超過多少要警戒（一個保守起點是 80%）、單個 Free 使用者消耗超過多少 token 要觸發掛賬提醒、Free 配額到期不升級的處理（繼續允許只讀 / 自動歸檔 / 直接鎖號）。
第六步是給"繼續上線 / 補證據 / 暫停"三檔判斷。底線月費高於市場可接受區間且短期降不下來 → 暫停或換人群；底線在市場區間但白嫖比例已經爆 → 補證據先做付費轉化測試；底線和白嫖都健康 → 繼續上線。
**三檔判定**（輸出末尾必須顯式給出"判定檔 + 下一步動作 + 再評窗具體天數"，否則視為不合格）：
| 判定 | 觸發條件 | 下一步動作 | 再評窗 |
|------|---------|----------|-------|
| **上線 · 綠燈** | 底線月費在市場可接受區間 + 白嫖比例 < 80% + 6 類成本全列齊 | 接入 Stripe / Paddle 開收款，跑 30 天 cohort | 30 天后回看 MRR / Churn 重審 |
| **補證據 · 黃燈** | 底線在區間但白嫖 > 80% / 1 類成本未確認 | 只動 1 個變數（試用門檻或單點定價） | 14 天后重跑 |
| **暫停 · 紅燈** | 底線高於市場可接受區間且短期降不下來 / 核心閉環未跑通 | 回 MVP 閉環補料或換人群 | 30 天后再來 |
## 示例 / 樣板
公開範圍引數：產品型別 = 單租戶 B2C AI 工具；使用者量級 = 0-200 付費使用者階段；MRR 區間 = $0-$3k；平臺堆疊 = Vercel + Supabase + Stripe；維護時間 = 每週 ≤ 10 小時。產品方向"AI 整理 Etsy 差評生成商品改進建議"，單次呼叫 GPT-4o mini 約 3000 token，預計一個使用者一個月跑 100 次，Hosting 走 Vercel + Supabase 約 20 美元一月，客服每使用者 5 分鐘，自己時薪折 20 美元一小時。
期望輸出節選：
```
單次呼叫成本估算
3000 token × 單價（未確認，按 GPT-4o mini 公開 input/output 算 ≈ 0.0006 美元）+ 臨時儲存忽略 = 單次 0.0006 美元
6 類成本月度估算
- API：0.0006 × 100 次 = 0.06 美元（佔比小）
- Hosting：20 美元固定（Vercel + Supabase 起步）
- 支付：Stripe 抽成（未確認，按 2.9% + 0.30 美元一筆算）
- 客服：5 分鐘 × 20 美元 / 60 = 1.67 美元
- 時間：自己每月維護 4 小時 × 20 美元 = 80 美元 / 付費使用者數
- 退款風險：5% 月費 buffer
最低訂閱底線
按 10 付費使用者算：(20 + 80) / 10 + (0.06 + 1.67) + 30% buffer ≈ 14.8 美元
底線月費區間：14 到 19 美元
範圍紅線（這一版砍掉）
- 團隊席位（前 100 使用者都是個人賣家）
- 多模型路由（GPT-4o mini 一個夠用）
- 自定義品牌商用授權（暫時掛在 FAQ 寫"售出建議表歸你所有"）
- 大檔案批處理（單次最多 100 條）
- SSO / SAML（Email 註冊夠）
```
反面例子：直接寫"月費 19 美元參考競品"（違反"算自己成本"硬約束）；編造 OpenAI 單價精確數字（違反執行當天核驗鐵律）；底線給單值"15.5 美元"而不給區間（違反輸出規則）；範圍紅線只砍 2 項（違反 5 項最低數）。
## 輸出規範
直接輸出《[產品方向]》定價底線核算單正文，不要前言後語，總字數 800 到 1200 字，按以下順序：
1. 單次閉環成本：API + 儲存 + 流量，每項標金額或"未確認"
2. 6 類成本月度估算表：每類金額或"未確認"
3. 最低訂閱底線月費區間 + 完整計算式
4. 範圍紅線：至少 5 項砍掉的功能 + 每項一句原因
5. 白嫖警戒線：Free 佔比閾值 + 單使用者用量閾值 + 處理方式
6. 三檔判斷：繼續上線 / 補證據 / 暫停 + 理由
輸出前自檢：6 類成本全列齊；底線給區間不給單值；砍掉清單至少 5 項；API 費率與 Stripe 抽成全部標"未確認，執行當天后臺為準"；含白嫖警戒線；判斷有理由。
## 硬約束 · 拒絕場景
遇到下面這些情況直接拒絕核算，告訴我先回去補哪一項：
- 核心閉環還沒跑通回 MVP 閉環那一步先驗證
- 要求"業界 SaaS 月費中位數""毛利率行業基準"拒絕（無源資料，讓我自己看市場區間）
- 要求設計高補貼或燒錢拉新拒絕（違反"用愛發電不是答案"原則）
- 欄位全空或仍是 `___` 佔位符沒替換拒絕先給結論
Micro SaaS 定價底線要先回答五個問題：
| 問題 | 要判斷 |
|---|---|
| 使用者是誰 | 是否真有月度復發的任務和場景 |
| 單次變動成本 | API / 客服 / 儲存一次跑多少錢 |
| 月固定成本 | Hosting / 監控 / 域名 / 自己時薪折算多少 |
| 退款與白嫖風險 | 7 天退款比例、Free 佔比、Stripe 拒付率是否可控 |
| 下一步是什麼 | 上線、補證據還是暫停 |
新手不要用熱情替代判斷。這個階段最容易出錯的地方，是把“我會工具”誤讀成“我能交付”。真正要檢查的是：輸入是否清楚、交付物是否可用、邊界是否寫明、風險是否能被發現。如果這些問題答不上來，先補材料，不要急著放大。
定價底線先服務真實任務
Micro SaaS的定價底線，不是為了顯得更專業，而是為了讓有明確流程痛點的小團隊或獨立使用者能在真實任務裡得到可檢查的結果。它應該服務一個真實任務：讓使用者從不確定狀態，進入能判斷、能執行、能覆盤的狀態。
Micro SaaS 定價底線這類文章的共同啟發是：專業能力不是堆概念，而是把模糊問題整理成可執行流程。這意味著每月固定成本 + 單位變動成本必須低於客單價 30%，否則定價不成立。
如果你只寫“做得更好”“提升效率”“擴大影響”，客戶或使用者很難行動。更好的寫法是：本週收集哪些材料，做出哪個樣品，用什麼表檢查，出現哪些紅燈就暫停。
新手先收窄場景
不要同時服務所有人。先選擇一個更窄場景，例如一類使用者、一種交付物、一個平臺或一個業務階段。場景越窄，例子越具體，風險也越容易提前發現。
如果你發現文章或方案可以套到任何行業，通常說明它還不夠具體。把物件、材料、工具、交付和覆盤都寫具體，才會真正幫助新手。
第 1 步：把訂閱人群翻譯成成本邊界
先寫一句話：
我這次要幫助 ___ 在 ___ 場景下，用 ___ 材料，完成 ___ 結果。這句話寫不出來，後面所有動作都會漂。目標不清，會導致樣品不清；輸入不清，會導致 AI 輸出不穩；使用者不清，會導致頁面和交付無法聚焦。
| 欄位 | 填寫方式 |
|---|---|
| 目標使用者 | 有明確流程痛點的小團隊或獨立使用者 |
| 目前任務 | 先算範圍、成本和風險，再談價格 |
| 已有輸入 | 原話、樣品、資料、連結、舊流程 |
| 交付結果 | 訪談記錄、MVP 單閉環、支付路徑、支援記錄和迭代表 |
| 紅燈 | 偽需求、過度開發、支付失敗、隱私資料和長期支援壓力 |
這一步不要讓 AI 替你編材料。AI 可以整理你給出的資訊，但不能證明使用者真的存在，也不能確認平臺和支付規則。
輸入材料的最低線
至少要有三類材料：使用者原話、目前樣品或舊流程、執行平臺或工具入口。只有想法，沒有材料，就先回到 Mom Test 使用者訪談 做研究；只有工具，沒有付費迴圈，先跑 MVP 單閉環 再回來算價。
第 2 步：算月經常性收入紅黃綠判定
判斷表要讓你知道現在該繼續還是暫停。
| 判斷項 | 綠燈 | 黃燈 | 紅燈 |
|---|---|---|---|
| 月經常性收入（MRR） | 月固定 + 單位變動 < 客單價 70% | 佔比 70-90% | ≥ 90%，毛利為負 |
| 流失率（Churn） | 月度 < 5% | 5-8%，可定位原因 | > 8% 且找不到主因 |
| 留存收入（NRR） | ≥ 95%，擴展抵流失 | 80-95% | < 80% |
| 平均客戶價值（ARPU） | 月費區間清楚，單值未承諾 | 區間寬但有上下限 | 單值報價無依據 |
| 退款 / 拒付 | 7 天退款 < 5%，Stripe 拒付 < 1% | 5-10% / 1-2% | > 10% / > 2% |
表格不是為了好看，而是為了停止錯誤動作。很多失敗不是因為執行不努力，而是黃燈和紅燈被忽略。
反證也要寫
判斷表裡要保留反證。比如使用者不願提供材料、只想免費試做、平臺規則不清、工具能力未核驗、交付後支援壓力過高。反證能幫你避免把小問題做大。
第 3 步：搭最小可定價樣品和 Stripe 沙箱
最小樣品或流程要足夠小，但必須真實。
| 型別 | 最小樣品 |
|---|---|
| 服務 | 一頁 Brief、一個樣品交付、一個驗收清單 |
| 工具 | 一個可執行流程或欄位表 |
| 內容 | 一段樣稿、一張結構表、一份質檢記錄 |
| 變現 | 一個範圍清楚的報價頁或提案 |
| 規模化 | 一個小渠道實驗或 SOP 片段 |
樣品的目標不是展示你能做很多，而是讓使用者判斷“這是不是我需要的”。如果樣品需要你在旁邊解釋很久，就說明它還不夠清楚。
做完樣品後，至少找一個真實使用者或舊客戶看。只聽讚美沒有用，要問他哪裡不懂、哪裡有風險、是否願意進入下一步。
樣品要有退出條件
如果樣品沒人看、看了沒人問、問的問題都和目標不相關，就不要繼續加大投入。先回到目標、使用者和輸入，重新判斷場景是否成立。
第 4 步：檢查退款腐蝕和 Churn 紅線
風險檢查要放在交付前，而不是出了問題以後。
| 風險 | 檢查動作 |
|---|---|
| 平臺規則 | 到官方幫助中心或後臺核驗 |
| 支付退款 | 看平臺和支付工具當天規則 |
| 版權隱私 | 檢查素材、案例、截圖和客戶資料 |
| 賬號許可權 | 只拿必要許可權，優先用測試資料 |
| 過度承諾 | 刪除不可控結果，補適用邊界 |
偽需求、過度開發、支付失敗、隱私資料和長期支援壓力都不是小細節。新手越想快點完成，越容易跳過這些檢查。真正專業的做法，是把未確認欄位寫出來，而不是假裝已經知道。
邊界要寫給使用者看
邊界不要藏在腦子裡。哪些不包含、哪些需要客戶提供、哪些需要執行當天核驗、哪些結果不承諾，都要寫進頁面、提案或交付說明。
第 5 步：30 天 cohort 覆盤並決定續費策略
覆盤要落到下一步，不要只寫感想。
| 發現 | 下一步 |
|---|---|
| 使用者任務清楚 | 繼續做完整版本或下一篇教學 |
| 輸入材料缺失 | 先補訪談、樣品或官方核驗 |
| 支援問題重複 | 回寫 FAQ、模板或 SOP |
| 風險未確認 | 暫停釋出或暫緩報價 |
| 反饋分散 | 收窄使用者和場景 |
覆盤時要同時看行為和原話。行為告訴你使用者做了什麼，原話告訴你為什麼可能這樣做。只看其中一個，都容易誤判。
如果覆盤後沒有產生新動作，說明覆盤還停在總結層。好的覆盤應該讓下一步更小、更清楚。續費動機不足時回 留存與轉介迴圈 找鉤子。
操作檢查表
| 欄位 | 填寫 |
|---|---|
| 目前主題 | Micro SaaS定價底線 |
| 目標使用者 | 有明確流程痛點的小團隊或獨立使用者 |
| 關鍵輸入 | ___ |
| 最小樣品 | ___ |
| 主要風險 | 偽需求、過度開發、支付失敗、隱私資料和長期支援壓力 |
| 官方核驗入口 | ___ |
| 覆盤指標 | 使用者原話、樣品行為、交付問題、下一步動作 |
| 目前判斷 | 繼續 / 補證據 / 暫停 |
這張表可以直接複製到你的專案文件裡。每完成一輪，就更新一次，不要只靠記憶。
AI 怎麼輔助
AI 適合做這些：
- 把使用者原話整理成問題分類。
- 生成 Brief、檢查表、SOP 或覆盤表。
- 標出未確認欄位和風險點。
- 改寫頁面、提案或交付說明。
- 把反饋轉成下一步動作。
AI 不適合替你確認平臺規則、支付退款、客戶授權、隱私邊界和真實購買意願。沒有證據時，必須寫未確認。
讓 AI 輔助時，不要只問“怎麼做”。要給它材料、目標、約束和目前判斷，讓它幫你找遺漏。
官方資料與核驗口徑
平臺規則、演算法動向、報價規則、政策口徑都會變化。本文保留的是可遷移的判斷框架，具體數字一律給區間。
跨平臺核驗入口：
- Indie Hackers — 看 Micro SaaS 真實營收、留存與覆盤
- Stripe Atlas Guides — 看 SaaS 收款、跨境結算與合同模板
- microconf — 看 bootstrap SaaS 報告、增長與定價案例
涉及具體資料、比例、報價區間的部分，以執行當天后臺為準。
常見問題
no-code 跑到 MRR 千美元級要不要轉 code？
先看維護時間。每週維護超過 10 小時、no-code 平臺限流或合規出問題、客戶開始要 API/SSO 時再考慮遷移；只是想“更工程化”不是好理由。
Churn 8% 怎麼修？
先把流失使用者分三檔：第一週流失（onboarding 不順）、第一月流失（首單價值未交付）、第三月流失（續費動機不足）。每檔定一個修復動作，不要並行修。
單一產品做 MRR 還是做產品矩陣？
單產品 MRR < $5k 階段不開新坑，先把 NRR 推到 95% 以上。多產品組合只有在主產品自帶流量且 Churn < 4% 時才合算，否則會攤薄精力。
Stripe 拒付率 > 1% 怎麼辦？
按拒付原因區分：盜刷拒付（開 Radar 規則 + 3DS）、虛假產品拒付（在結賬頁貼退款政策）、忘記訂閱拒付（提前一週郵件提醒續費）。三類合在一起處理無效。
執行前至少核驗：
- Stripe Pricing Models → SaaS 定價模型
- OpenAI · API Pricing → AI 呼叫單價
- Lenny's Newsletter · SaaS Pricing → SaaS 定價範式