MVP 不是把功能砍少：找外包做 MVP 的 4 階段付款與驗收節點完整指南

假設你打算找外包做一個寵物 SaaS。你心裡的 MVP 是什麼？多數老闆的答案是：「正式版要的功能砍掉一半，先做能用的。」

這個答案就是過去 15 年燒掉無數新創預算的源頭。Eric Ries 在 《精實創業》裡寫得很清楚：MVP 的目的是用最低成本驗證一個假設，而不是把功能清單砍少。差別在哪？砍少功能還是要做完整系統，只是少幾個按鈕；MVP 是只解決一個你還不確定客戶會不會付錢的問題，做完馬上去問。

這篇會拆解 MVP 的真實定義、4 階段付款驗收節點怎麼切、每階段該驗收什麼、實際合成案例怎麼用 8 萬切到 30 萬訂單，以及 3 種失敗的 MVP 長什麼樣子。讀者是準備找外包做產品的老闆，目標是讓你下次跟廠商談分期付款時有具體的籌碼，不再被「先全部報下來、簽完約再開工」綁住。

90% 老闆誤解的 MVP 定義「先做簡單版」其實是錯的

第一次跟老闆談 MVP，十個有九個會說：「就先做簡單版嘛，能跑就好。」翻譯成廠商聽到的版本是：「正式版規格我有，你估個七折報價，我們先做這個。」這種談法做出來的東西，不是 MVP，是一個 功能不全的正式版。差在哪？正式版假設你已經知道客戶要什麼，MVP 假設你還在猜。

舉個合成案例。想做寵物 SaaS 的老闆 W 第一次來談的時候，需求清單寫了 23 項：會員系統、預約系統、寵物履歷、獸醫評論、線上問診、商城、訂閱制、推播通知、後台統計、客服系統、串金流、串物流、APP iOS 版、APP Android 版、深色模式、多語系、SEO 友善網址... 你看就知道，這已經是一個成熟產品的功能表。我問他：「這 23 項裡，哪一項是你最不確定客戶會付錢的？」他想了一分鐘說：「線上問診吧，我也不知道有沒有人想付月費讓獸醫線上看診。」

那就只做這一項。連會員系統都先不要。整個 MVP 就是一頁落地頁加一個 LINE 客服窗口，文案寫「線上問診月費 990，先付 100 元預約名額」。三天後就能上線測。如果三週內收不到 30 筆預約金，問題不是功能不夠，是 這個假設根本不成立。把 23 項全做出來才發現沒人付錢，是 60 萬的學費；用一頁落地頁發現沒人付錢，是 8000 元的學費。

這個落差，Steve Blank 在 Customer Development 方法論裡稱為「離開辦公室」（Get Out of the Building）。意思是再多的需求文件、Wireframe、競品分析，都不如把一個能收錢的版本丟給真實客戶。MVP 的價值在於它逼你面對市場，而不是逼你做完整系統。

把這個觀念翻成跟外包談判的語言：不要一次發包整個產品。發包整個產品的前提是你已經知道客戶會買單，但 MVP 階段你還在猜，這時候你要的是一個能切成幾段、做完一段就停下來看數據的合作模式。怎麼切？看下面 4 階段。

真正的 MVP 標準：3 條判定線決定你做的是不是 MVP

怎麼分辨手上規劃的是真 MVP 還是「閹割版正式產品」？三條判定線，缺一條就不是 MVP：

• 可驗證假設：能明確指出這個版本要驗證什麼商業假設（誰會買、為什麼買、願意付多少）。如果做完只能說「會員系統做完了」，那不算驗證任何假設。
• 可被使用：使用者能完整走完一次核心流程，不是看到 demo 影片或 Figma 原型。Marty Cagan 在 《INSPIRED》 裡稱為 "viable"，重點是真的可用、不是看起來可用。
• 可量到反饋：埋好分析工具或人工追蹤機制，能拿到具體數據，例如轉換率、付費率、留存率，不是憑感覺說「客戶覺得不錯」。

舉例。同樣是寵物 SaaS：「做了會員註冊系統」不是 MVP，因為沒驗證任何商業假設；「做了會員註冊系統，但沒有付費機制、沒有埋追蹤」也不是 MVP，因為量不到反饋；「做了一個落地頁，能收 100 元預約金，後台能看到誰付了、付完之後的留存率」這才算 MVP。

MVP 4 階段切法每階段付 25%、過了才放下一階段

這是整篇的核心。把 MVP 從發包到上線拆成 4 個階段，每階段對應 25% 付款比例，過了驗收條件才動下一階段。這個結構解決兩個問題：一是廠商收完訂金消失（風險平攤）；二是你做到一半發現方向錯了，至少能停損（Y Combinator 的早期投資建議一直在強調這個概念）。想把每階段的規格切到可比價、可驗收，可以對照軟體 RFP 範本與 30 條 checklist裡的需求書框架，先把功能清單寫清楚再分階段。

先看一張總覽，後面每階段再展開細講。

階段 1：假著陸頁／預約頁付意向金驗證需求是否成立

這階段最常被老闆跳過：「我都已經想得很清楚了，幹嘛還要做著陸頁？」答案是 — 想得清楚跟客戶會付錢是兩件事。Buffer 的創辦人 Joel Gascoigne 寫過一篇文章，講他怎麼用一頁落地頁加 Stripe 連結驗證 Buffer 的訂閱制需求，那一頁花他不到 3 天，但讓他確定可以辭職全職做。

這階段做的事很簡單：

1. 做一頁落地頁，講清楚產品要解決什麼、會收多少錢
2. 放一個收意向金的按鈕（100-500 元的小額預約金，可全額退款）
3. 導流：FB/IG 廣告、PTT/Dcard 相關板、目標客群的 LINE 社群
4. 追蹤指標：點擊率、停留時間、按鈕點擊率、預約金完成率

驗收條件設多少？看你的目標客群和客單價。寵物 SaaS 月費 990 元，跑 1000 元廣告預算如果收不到 5 筆預約金，假設不成立。B2B 案件、客單價 5 萬以上，目標可能改成「跑 5000 元廣告，收到 3 個願意 demo 的潛在客戶」。重點是 驗收條件要在簽約前先寫進合約，不要事後吵。

這階段給外包做合理嗎？合理。著陸頁加金流的小型專案市場行情約 2-5 萬（根據複雜度、含設計或不含設計），佔 25% 預算，後續還能調整繼續用，不是丟掉的錢。

階段 2：核心功能 demo手動操作 + concierge MVP 才是真功夫

這階段是最容易被外包當成「開發階段」整碗端走的環節。老闆通常會說：「階段 1 過了，那就開發核心功能吧。」廠商開心報下去 50 萬。錯。

Concierge MVP 是 Eric Ries 在 Lean Startup 部落格 裡推廣的概念，意思是 能用人工做的事就先別寫程式。Airbnb 早期的「派人去旅館拍照」、Zappos 創辦人「客戶下單後親自跑去鞋店買」都是 concierge MVP 的經典例子。

為什麼重要？因為你還在驗證流程順不順、用戶會不會卡關。流程沒驗證好就寫程式，等於把錯的流程刻在系統裡，之後改更貴。

這階段的外包工作會比正規開發少很多，因為大部分流程都還是你親自跑。外包的角色是做「面對客戶的 minimal interface」（落地頁＋表單＋通知系統＋簡易後台），讓你的人工流程能規模化到 10-20 個客戶不會炸掉。

驗收條件：10-20 個真實用戶完整走完一次流程（從註冊或下單到拿到產品），追蹤每一步的卡關點。Marty Cagan 強調過，這階段拿到的「定性反饋」（用戶卡在哪、抱怨什麼）比任何 KPI 都重要，因為這直接告訴你階段 3 要做什麼。

階段 3：完整 MVP + 付費機制這時候才開始真正寫系統

階段 1、2 都過了，意思是你已經確定有人想要這個東西、流程也跑順了。階段 3 才是把人工流程「自動化」成系統的時候。

這階段該做的事：

• 基礎會員系統（註冊／登入／忘記密碼，不用做 SSO 不用做雙因子）
• 核心功能的前台（取代你階段 2 用的 Google Form / Notion）
• 付款金流串接（綠界、藍新、Stripe，看客單價和客群）
• 最簡單的後台（看訂單、看用戶、看金流，不用做權限系統）
• 基礎追蹤（GA4、Mixpanel 或 Amplitude，看付費漏斗）

驗收條件：至少 5-10 個真實付費用戶，付費後 7 天留存率有數字（哪怕是 30% 都好，重點是看得到）。如果這階段做完還是沒人付錢，問題很可能是 階段 1 的假設驗證做得不夠扎實，回去重做不丟臉，硬撐做完才丟臉。

階段 4：擴展功能與優化根據真實數據才能決定下一步

這階段最大的差別：你已經有付費客戶和留存數據，所以接下來做什麼，是 [數據告訴你的]，不是你拍腦袋決定的。

階段 1-3 結束你會拿到一份「真實使用報告」，裡面寫的是：哪個功能用戶用最多、哪個流程客戶卡最久、退費的人都怎麼說、來訪者沒付錢的最大原因。這份報告決定階段 4 該做什麼。

常見的階段 4 工作清單：

• 付費漏斗優化（哪一步流失最多就先補哪一步）
• 用戶要求最多的 Top 3 功能
• 效能優化（如果有 N+1 問題、首頁打開要 8 秒這類）
• APP 化（如果發現大部分用戶都在手機開）
• API 串接（如果有客戶要求整合到他們既有系統）

這階段的驗收條件就不是「做完功能」這麼簡單，要綁業務目標：留存率從 30% 升到 50%、月營收從 5 萬升到 15 萬、客單價從 990 升到 1990 之類。沒有業務目標的擴展，就只是燒錢。

整個流程畫成圖長這樣，每個分歧點都是停損點：

每階段該驗收什麼一份可下載感的驗收 Checklist

驗收最常出問題的不是「廠商沒做」，是「老闆驗收標準太模糊」。「能用」「順暢」「沒 bug」這種詞最後都會變成各說各話。下面把每階段的驗收項目拆成具體 checklist，談合約時可以直接附錄。具體的驗收項目寫法、Bug 分級、UAT 會議怎麼開，可以參考軟體驗收 SOP 與 UAT 30 點 checklist直接拿來套用。

階段 1 驗收 Checklist

• ✅ 著陸頁桌機／手機都能正常顯示，無破版
• ✅ 主視覺、文案、CTA 按鈕都依照雙方確認的稿件呈現
• ✅ 預約金或意向金按鈕能完成付款（含失敗 fallback 訊息）
• ✅ 後台或 Google Sheet 能看到所有付款者的 email、姓名、付款時間
• ✅ GA4 或 Plausible 已設定，可看到流量來源、停留時間、跳出率
• ✅ 退款流程：誰能退、怎麼退、多久內退，寫入後台 SOP
• ✅ 法律基本：隱私權政策、服務條款、退費政策三頁齊備

階段 2 驗收 Checklist

• ✅ 至少 10 位真實用戶完整走完一次核心流程，且每位都有書面或文字訪談紀錄
• ✅ Concierge 環節（人工跑的部分）有書面 SOP，新人接手能上手
• ✅ 「面對客戶的 interface」（表單、通知、簡易後台）穩定運作 2 週無重大故障
• ✅ 收集到至少 5 條具體改善建議，且分清楚哪些是「介面問題」哪些是「商業邏輯問題」
• ✅ 卡關點分析：列出每位用戶卡在哪一步、原因、是否需要改流程

階段 3 驗收 Checklist

• ✅ 完整付費流程從註冊到完成可在 5 分鐘內走完（含金流）
• ✅ 至少 5-10 位真實付費用戶，且金流入帳金額對得起來（含手續費明細）
• ✅ 退款流程實測過至少 1 次（不是假退款，是真的整個流程跑通）
• ✅ 後台能即時看到：當日訂單數、營收、用戶數、退款數
• ✅ 7 天／14 天／30 天留存率追蹤儀表板已建立
• ✅ 主要瀏覽器（Chrome、Safari、Edge）＋ iOS／Android 行動版測試報告
• ✅ 安全基線：HTTPS、密碼加密、防 SQL injection、避免敏感資料 log 外洩
• ✅ 上線前回滾計畫（出包要怎麼退回前一版）已

階段 4 驗收 Checklist

• ✅ 擴展功能直接綁定業務目標（例如：付費轉換率從 X% 提升到 Y%）
• ✅ 重大效能瓶頸排除（例如：首頁 LCP < 2.5 秒、API 平均回應 < 500ms）
• ✅ 監控告警：當錯誤率超過閾值或服務當機，能在 5 分鐘內收到通知
• ✅ 至少 1 次真實壓測（用 k6 或 Locust 模擬尖峰流量）
• ✅ 維運交接文件：架構圖、API 文件、資料庫 schema、部署流程

驗收條款可以參考 Scrum 的 Definition of Done 概念，把「完成」明確定義成可勾選的清單，廠商和你都不用猜。延伸閱讀：敏捷開發是什麼？為什麼你的外包案總是延期 跟 測試環境、正式環境差在哪。

MVP 不該做什麼把這些功能砍掉省下一半預算

MVP 階段最大的浪費，是廠商和老闆一起把「以後可能會用到」的功能塞進去。每個聽起來都很合理，加總起來就是 60 萬變 120 萬、4 個月變 9 個月。先看一張對照表：

我看過最誇張的案例是 B2B 媒合平台的創辦人 L，第一版 MVP 就要做 7 種角色權限：超級管理員、區域管理員、業務主管、業務、客戶管理員、客戶、訪客。報價 90 萬、做 6 個月。我問他：「上線第一個月你預計有幾個客戶？」他說：「3 個。」3 個客戶要做 7 種角色權限。我建議他改成：先做一個 admin 帳號（你自己用）和一個客戶帳號（不分角色），90 萬砍到 25 萬，4 個月縮到 6 週。半年後客戶到了 30 個再加角色。

用 8 萬切到 30 萬訂單的階段拆法一個合成案例完整拆解

這是把幾個真實案例拼起來的合成版本，化名為「做寵物 SaaS 的老闆 W」。原始版本他帶著 80 萬預算找廠商，廠商報 75 萬做完整系統，6 個月。後來改用 4 階段方式，第一波只花 8 萬，2 個月內就拿到 30 萬訂單回來。

階段 1：花 6 萬做著陸頁＋意向金

做了三件事：

1. 一頁繁中落地頁，主打「線上獸醫問診月費 990，名額有限預約 100 元抵」
2. 收 100 元意向金（之後可全額抵月費）
3. FB 廣告投 15,000 元，鎖定北部養貓族群

結果：兩週內收到 47 筆 100 元預約金、共 4,700 元，但更重要的是 — 47 個願意付錢的真實客戶名單。轉換率算下來大約是 1.2%，落在他原本估的 0.8-2% 區間。假設成立。

學到的事：47 個客戶裡，有 31 個跑來問「能不能不要月費，每次問診單獨付費」。這個訊號改變了他階段 2 的設計。

階段 2：花不到 2 萬做 Concierge MVP

沒寫程式。做了這些：

• LINE 官方帳號，自動回覆引導加好友
• Google Form 收問診預約（含寵物資料、症狀、想諮詢的時間）
• LINE 群組（用戶＋3 位合作獸醫＋老闆 W）
• Google Meet 跑視訊，問診結束開立付款連結（綠界小額串接）
• Notion 共用病歷簿，每位寵物一個 page

跑了 4 週，做了 28 場問診，平均單次 850 元（不是月費，是單次計費）。客戶留下來的反饋裡，最常出現的三件事：

• 「能不能影片錄下來、之後我自己看」（→ 階段 3 要做錄影回放）
• 「能不能查歷史病歷」（→ 階段 3 要做病歷時間軸）
• 「夜診才是我最需要的」（→ 階段 4 要做夜診排班）

階段 3：花 22 萬做完整 MVP，2 個月後 30 萬訂單

根據階段 1、2 拿到的數據和反饋，重新規劃功能優先序：

結果：上線 2 個月，付費單次 354 筆，平均單價 850 元，月營收約 15 萬，第二個月做到 30 萬。總投入 30 萬（6+2+22）拿到 45 萬營收，最重要的是已經有 200 多個付過費的真實客戶名單，可以開始談月訂閱方案。

如果你想看更多 MVP 完成後怎麼從 0 走到 MRR 的階梯，可以參考 SaaS 產品驗證階段與 MRR 指南 這篇（系列 #6）。階段 4 之後的擴展和定價策略還有很多細節要談。

失敗的 MVP 是什麼樣子3 個你絕對要避開的常見模式

看完成功案例，再看反例。下面三種失敗模式我每個月至少遇到一次：

失敗模式 A：功能完整但沒人用的「閹割版正式產品」

特徵：花了 3-6 個月做出來、功能很多、UI 很漂亮、但上線一個月只有 5 個註冊用戶、3 個付費用戶。問題是 沒有經過任何假設驗證就直接全做，做完才開始想「怎麼推」。a16z 的 Andrew Chen 寫過，這種狀況最痛苦的不是「沒人用」，是「不知道為什麼沒人用」 — 因為一次做太多，沒辦法歸因到具體某個假設錯了。

怎麼避：嚴格走 4 階段、不要跳過階段 1 和 2。「老闆覺得這市場很大」不算驗證，要看到真實付錢才算。

失敗模式 B：只有一個漂亮 demo 影片、實際做不出來

特徵：用 Figma 做了超漂亮的原型、拍了 3 分鐘 demo 影片、上 ProductHunt 拿了一堆 upvote、但沒有一行可運作的代碼。客戶來問「什麼時候能用」就只能說「快了快了」。這違反 MVP 三條判定線中的「可被使用」— IDEO 的 design thinking 流程 也強調 prototype 必須是 "functional"（可運作的）而不是 "presentational"（給人看的）。

怎麼避：階段 2 用 Concierge MVP 跑真流程，不要只做漂亮影片。寧可流程醜但能完成交易，也不要好看但實際無法購買。

失敗模式 C：沒有付費機制、永遠在「免費 beta」

特徵：上線一年都還是 free beta、有 5000 個免費用戶、所有人都跟你說「等收費我會付」、真的開收費時 90% 流失。免費用戶數不是商業假設，「願意付錢的人數」才是。

怎麼避：階段 1 就要收意向金，階段 3 一定要有真實付費機制。免費用戶量再大都不算市場驗證，付費用戶才是。延伸閱讀：找外包做軟體 9 大雷區檢核清單 裡面有講到怎麼把分階段付款條款寫進合約。

關於 MVP 分階段付款驗收常見問題

把 MVP 階段切對下一步該找誰談

這篇講的是「老闆視角的 MVP 拆解」，但真正開始走的時候，你還需要一個願意配合分階段付款、驗收條件具體可量化、不會在你決定停損時翻臉的廠商。我們做客製化網站和 SaaS 開發超過 8 年，所有專案都採 4 階段付款，每階段驗收條件寫進合約附錄。如果你正在規劃一個產品，先聊聊你的想法，我們會跟你一起把 4 階段切清楚、預算和時程怎麼分配、驗收條件怎麼寫，再決定要不要往下走。如果你的產品有大量需要 UX 驗收的環節（例如 B2C 消費端），可以 直接看 UI/UX 設計服務。

打造會賺錢軟體產品系列文章導覽

• #1 打造會賺錢軟體產品的完整路線圖（系列總覽）
• #2 軟體產品市場驗證指南（先驗證再做 MVP）
• #3 找外包做軟體 9 大雷區檢核清單（分階段付款合約怎麼寫）
• #4 MVP 4 階段付款與驗收節點完整指南（本篇）
• #5 App 開發費用比較：低預算如何切（MVP 預算範圍）
• #6 SaaS 產品驗證階段與 MRR 指南（MVP 完成後下一步）

如果你的 MVP 是從 vibe coding 原型開始改寫，下面兩篇也很值得搭著讀：

• Vibe Coding 原型到正式產品，中間差了這 7 件事（原型升級成產品）
• Vibe Coding 做出來的 App 能直接上線嗎？（原型上線評估）