從 $0 到第一筆收費到 $1K MRR：軟體產品階梯式驗證 SOP，每階段該做什麼、該外包什麼

我們做過最浪費的一個案子是這樣的。客戶找上門時氣勢很足，他做台灣中部的工業設備代理，看到競爭對手在做訂閱型軟體，覺得自己也要一套 SaaS 平台。一進門就拍桌：「先把整套蓋好，會員、付款、後台、API 我全要，6 個月後我要上線開賣。」

我們報 280 萬，他簽了。整套 SaaS 蓋好上線，介面也漂亮，功能也齊。結果 6 個月只進了 14 個註冊、0 個付費。

產品本身沒壞、bug 也少，使用體驗在同業裡算前段。問題出在哪？中間少跳了一個階段。他直接從「想做」跳到「全部蓋好」，中間沒有「先驗證有沒有人會付錢」。在矽谷一個叫 Marc Lou 的 indie hacker 做過超過 20 個產品，每個從 0 到 $1K MRR 平均花了 6 週，他的方法是「先賣再做」——

我這位客戶沒走完這個階梯，280 萬就這樣燒掉了。這篇文章會把「$0 → 第一筆收費 → $1K MRR」的階梯式驗證 SOP 拆給你看。每一階段該做什麼、不該做什麼、該外包什麼、不該外包什麼，都用實際做過的案子當例子。如果你正打算做軟體產品變現，或者已經做了一半開始發現註冊數一直上不去，這篇就是你需要的劇本。

大部分軟體產品死在「想要的功能 vs. 會付錢的功能」之間

先講一個業界常被忽略的事實。

CB Insights 持續追蹤新創失敗原因，在他們匯整的 Top 12 Reasons Startups Fail 報告裡，排名第一的真正原因是 「沒有市場需求」（No Market Need），佔失敗案例的 35%。第二名才是缺資金，第三名是團隊不對。也就是說，3 成以上的軟體產品死在「我以為有人要，但其實沒有」這件事上。

「我以為有人要」的反面是什麼？是「有人會掏錢買」。這兩件事差距非常大。我把它叫做「想要的功能」和「會付錢的功能」之間的鴻溝：

• 想要的功能：用戶在訪談裡說「這個有的話我會用」，但你做出來免費送他都不會打開
• 會付錢的功能：用戶會主動付錢，付完還會抱怨價錢能不能便宜，但繼續用

階梯式驗證的核心，就是把這道鴻溝拆成 3 個可量化的關卡。沒過關不准進下一階段。$0 階段該做的是收訪談+收意向金，不是寫程式；第一筆收費階段該做的是 concierge MVP（你自己當客服跑後端），不是寫產品；$1K MRR 階段才是「這時候才該認真做產品」。

Y Combinator 的 Paul Graham 在 Do Things That Don't Scale 講過一句很多創辦人事後才懂的話：早期不該追求「可規模化的方法」，而是要做「不可規模化但能驗證需求的事」。手動拉客、手動服務、手動成交。Lenny Rachitsky 訪問過超過 100 位 PMF 達成的創辦人，他在 How the most successful B2B startups came up with their original idea 整理出一個結論——能做到 PMF 的團隊，幾乎沒有一個是「先把產品蓋好再去找用戶」。順序是反過來的。

這篇文章想幫你做的事很單純：把「順序反過來」的步驟，按照階段一個一個告訴你。如果你想看更前期的市場驗證細節，可以看我們系列裡的另一篇 軟體產品市場驗證完整指南，那篇講的是訪談技巧；這篇是把整個階梯走完的 SOP，重點在「老闆視角的決策框架」。

階段 1：$0 階段——訪談、假著陸頁、付意向金（不要寫程式）

$0 階段的目標只有一件事：確認有人會痛到願意付錢解決，而且這個痛是你做這個產品能解決的。聽起來很簡單，做的時候 9 成老闆會偷跑。

這個階段不該有任何工程師寫一行 production code。也不該有設計師畫整套介面。應該只有 3 件事：跟潛在客戶聊、放一頁假著陸頁、收意向金。我用一個我們合作過的客戶 W 來說明——他想做 B2B 排班 SaaS，目標客戶是 30 人以下的零售連鎖店長。

時間軸：4-6 週

不是 4-6 個月。4-6 週走完。超過 6 週還困在這階段，問題通常出在訪談對象抓錯人或話術抓錯，而非市場不夠。

該做什麼

• 跑 30 場 user interview：每場 30-45 分鐘，不問「你會不會用」，只問「你現在怎麼做這件事？最近一次卡住是什麼時候？怎麼解決的？花了多少時間或多少錢？」
• 做一頁假著陸頁：用 Carrd、Framer、Webflow 都行，預算 $0-$5K 台幣以內。寫清楚痛點、解法、價格區間，放一個「現在搶先預訂」按鈕
• 收意向金：意向金的功能是過濾真假興趣，並非鎖標。3,000-10,000 台幣的可退費訂金最有效。Marc Lou 的玩法是直接賣 $99 早鳥終身方案，產品還沒寫一行
• 經營一個 30 人以內的等候名單：每週寫一封進度信，告訴他們你在做什麼。回信率 < 20% 就代表這群人沒那麼痛

不該做什麼

• 寫程式。倒不是說一個小 Demo 不能寫，重點是不要把任何「要 maintain 的程式碼」寫出來
• 做完整 UI 設計稿。一頁假著陸頁的 wireframe 就夠了，不需要 Figma 系統
• 註冊公司、開公司戶頭、做合約模板。這些事在收第一筆 100 萬之前都不急
• 追求「我們的產品比競品好的功能列表」。這件事在 0 個付費用戶時是純粹自嗨

不該外包什麼

階段 2：第一筆收費——手動服務 + 半自動工具（concierge MVP）

過了 $0 階段，假著陸頁有 30 個意向金、訪談裡聽到 5 個以上的「我願意付每月 X 元」具體承諾，才能進階段 2。

這個階段的目標非常清楚——讓第一筆真實的錢進到你的銀行帳戶。

「真實的錢」三個字很重要。不是給朋友打折、不是免費試用、不是員工內測。是一個跟你沒關係的陌生人，掏出信用卡或轉帳，付了錢，繼續用。第一筆真實付款是整條階梯最有意義的訊號，比 100 個註冊重要 1000 倍。

Concierge MVP 是什麼？

Concierge MVP 直譯是「禮賓服務 MVP」，意思是 你還沒寫產品，但你用人力 + 半自動工具假裝你有產品。使用者付錢，你親自在背後處理。等你做了 5-10 個訂單，你會非常清楚產品到底要哪些功能、流程哪裡卡、定價該定多少。

Eric Ries 在 The Lean Startup 把 concierge MVP 跟 Wizard of Oz MVP（綠野仙蹤 MVP）並列為兩種最有效的早期驗證方式。差別在 concierge 是用戶知道你是手動處理；Wizard of Oz 是用戶以為是系統自動，但其實後台是你手動跑。前者適合 B2B 高客單、後者適合 B2C 量大但單筆小。

回到剛剛那個 W 老闆，他做排班 SaaS。他在這階段的具體做法是：

• 找 5 家門市店長，告訴他們「我先用 Google Sheet + LINE Bot 幫你跑排班，每月 1,500 台幣，3 個月後升級成正式系統」
• 他自己每週日晚上花 90 分鐘把每家店的排班表用 Excel 算出來，丟給 LINE Bot 推播給員工
• 做了 6 週，5 家全部續約，2 家還主動加價問能不能多上加班統計功能
• 這時候他才簽我們，請我們把這套手動流程寫成系統。需求清單變得超清楚，因為每一條都是他親手跑過的痛點

半自動工具該用什麼？

不要花時間自己組工具，這個階段燒時間是浪費。直接用現成的 SaaS 黏起來就好。我們整理了幾個最常用的組合：

整套組合每月成本壓在 5,000 台幣以內就能跑。你的時間才是最大的成本，不是工具。如果你還在這階段就花 5 萬請工程師寫工具，方向就錯了。

這階段該外包什麼

• 基本的著陸頁設計與切版（5,000-30,000 台幣外包，一週交付）
• 金流串接（如果不熟 Stripe / 綠界，找接過案的工程師串 1-2 天即可）
• LOGO 與 brand kit（5,000-15,000 台幣，避免拖太久）

這階段不該外包什麼

• 「跑流程」這件事本身。每月 1,500 台幣的服務你 outsource 給工讀生，你就失去了所有產品 sense
• 客服回覆。前 30 個客戶的對話必須老闆親自看，這是後面寫產品最重要的素材
• 產品功能規劃。還沒到 PMF 不要請 PM，老闆自己寫 spec

階段 3：$1K MRR——這時候才該認真做產品（自動化、訂閱、留存）

到了第一筆真實付款 + 連續 3-5 筆續訂，恭喜你，你已經比 60% 的軟體產品創業者活得久。但這還只是起點。

$1K MRR（Monthly Recurring Revenue，月經常性收入 1,000 美元，約台幣 32,000）是 indie hacker 圈公認的第一個有意義的里程碑。Indie Hackers 創辦人 Courtland Allen 在訪問 200+ 個過 $1K MRR 的創業者後歸納出一件事：能過這條線的產品，幾乎都已經完成了「至少一個可重複的獲客通路」+「明確的付費願意值客群」。

這階段才開始寫產品的真正原因

你會問：那階段 1、階段 2 不是已經有「產品」嗎？

差別在這裡。階段 1、2 的「產品」是 throwaway code（用完就丟）—— Google Sheet、LINE Bot 流程、Zapier 自動化都會丟掉。階段 3 才開始寫可維護、可擴張、有 SLA 的 production code。這個順序是反的，但它是有效的。SaaStr 的 Jason Lemkin 在 The Top 10 Mistakes I Made as CEO of Adobe Sign / EchoSign 裡有一段直白的話：他自己創業時最大的後悔是「太早把工程資源花在 scale 上」。MRR 沒過 $10K 之前，工程要做的是「讓現有用戶不流失」，不是「讓未來用戶能上來」。

該追的指標

這時候才需要請真正的工程師、設計師、PM，把整套架構認真蓋好。如果你需要評估這個階段該找什麼樣的開發團隊、預算大概多少，可以參考 App / 軟體開發費用比較與低預算對策，那篇我們把不同預算對應的開發路徑列得很細。

虛榮指標 vs 真實指標：老闆最容易看錯的數字

我們合作的另一個老闆 L 做付費社群 App，2026 年 1 月給我看他的「成長報表」，第一張投影片的標題是「DAU 突破 1 萬！」。我問他付費會員有多少，他說 67 個。DAU 1 萬，付費 67。這個比例是寫給投資人看的故事，不是經營者看的儀表板。

a16z 在 16 Metrics Investors Care About 點名 6 個 SaaS 圈最常被誤用的「虛榮指標」，包括註冊數、Page View、媒體曝光、Social followers。這些數字不一定假，但它們跟「能不能活下來」之間沒有因果關係。

為什麼老闆會「跳階段」、然後死掉（4 種典型症狀）

跳階段是這個劇本裡最常見的死法。業界軟體產品階梯式驗證的觀察中有 4 種典型，老闆讀者你看一下自己有沒有中。

症狀 A：超前部署管理後台

還沒有 10 個付費用戶，就在做後台帳號管理、權限分級、Audit Log。這個東西在 100 個用戶以下都沒人會用，但會吃掉 30-60 萬的開發費。正解：管理後台用 Retool / Forest Admin 接資料庫，1 週上線，等 100 個付費再考慮自己寫。

症狀 B：超前部署多語

台灣的老闆最容易犯這個。產品連 100 個繁中用戶都還沒有，就在規劃「我們要做英日韓」。多語會讓內容、客服、SEO、定價策略全部複雜化，每多一語成本至少多 30%。正解：先在一個市場做到 $5K MRR 再考慮第二語，且第二語要看訪談有沒有真實需求，不是老闆的國際夢。

症狀 C：超前部署多平台

Web 還沒做出來就要 iOS + Android + Desktop。每多一個平台是另一個 codebase、另一條維護線。Apple 上架審核 + 退費政策也是另一套規則。正解：先做 web (PWA)，validate 完了再做原生 app，順序是 web → iOS（如果是 B2C） / web → desktop（如果是專業工具）。

症狀 D：超前部署 Enterprise 功能

這個是 B2B SaaS 老闆最常出事的地方。還沒過 $1K MRR 就在規劃 SSO、SOC 2、On-premise 部署、Custom SLA。這些功能單獨做每一個都是 50-200 萬的工程量。正解：在客戶名單裡確實有 5 家以上都簽過「願意月付 $500 美元換 SSO」的承諾單，再開做。否則先做 self-serve，價錢壓在 $50-$200 美元/月，等市場反饋。

找外包時：每個階段該外包什麼、不該外包什麼（決策框架）

這是給老闆的硬核決策框架。每階段該外包什麼、不該外包什麼，差很多。看下面這張表：

這個表配合一個原則：「越早期越不能外包思考，越後期越要外包執行。」我們在 Vibe Coding 原型到正式產品中間差了 7 件事 那篇也有講過類似的概念——前期工程占比應該 < 30%，剩下都是訪談、銷售、流程跑通。

外包軟體開發時要避開的 3 個坑

• 找包整套不分階段的 vendor。一次報 280 萬把全套做完的，不會因為你的市場驗證不過就退錢
• 用「按時數計費」做不熟需求的功能。spec 不確定就按時數算，等於把風險全押在自己身上
• 找太大的軟體公司做小案子。50-100 人的公司處理 100 萬以下的案子通常 PM cost 過高，效率比 5-10 人接案團隊低很多

階梯流程總覽：每階段判定條件與時間軸

把整個階梯畫成一張流程圖，每階段都有「進入下一階段」的判定條件。沒過判定條件不要往前走。

階梯走完之後：$1K MRR → $10K MRR 下一步要做什麼

過 $1K MRR 是另一個階梯的起點，而非終點。$1K → $10K MRR 通常會花 6-18 個月，比 $0 → $1K 階段更花錢，但風險低很多。因為到這時候你已經有 PMF 了，剩下的是把獲客通路規模化。

這階段該優先做的事

• 找 1-2 個可重複的獲客通路：SEO、付費廣告、合作夥伴、出場演講。在 SaaSCapital 的 SaaS Benchmarks Report 裡，過 $1M ARR 的 SaaS 平均依賴 2-3 個主通路，不是樣樣做
• Pricing 第一次大改：到 $1K MRR 你已經知道誰付得起、誰用得多。可以開始切 3 階定價（Starter / Pro / Business），通常會讓 ARPU 上升 30-50%
• 第一個產品行銷人或 SDR：老闆從第一線銷售退到二線，把談 close 留給自己，但 outbound 要交給 SDR
• 把客服體系化：寫 SOP、做 FAQ、上 Intercom 或 HelpScout。一線回應時間目標壓在 2 小時內

這階段千萬不要做的事

• 全面開發新功能線。每月新功能 < 1 個大的，主力放優化既有功能
• 進入新市場（地區或產業）。先把現有市場吃到 30% 飽和度再開
• 募資。$10K MRR 以下募資對 valuation 很不利，能 bootstrap 撐到 $30K MRR 再募，估值會差好幾倍

如果你現在的痛點是「上線了但沒人用、沒人付錢」，建議直接看系列下一篇 軟體產品冷啟動 30 天 Playbook，那篇是專門給「過 $0 但卡在 $1K MRR 之前」的劇本。

系列文章導覽：打造會賺錢軟體產品 7 篇完整指南

這篇是「打造會賺錢軟體產品」系列的第 6 篇。建議照順序看完：階段對照很清楚，每篇處理一個老闆會卡的階段。

• #1 主軸：打造會賺錢軟體產品的 7 步驟總覽（總路線圖）
• #2 市場驗證：軟體產品市場驗證完整指南（階段 1 訪談技巧深拆）
• #4 MVP 收費：MVP 階段收費與分段付款全攻略（階段 2 收費機制）
• #5 開發費用：App / 軟體開發費用比較與低預算對策（階段 3 預算規劃）
• #6 階梯驗證：（你正在讀的這篇）
• #7 冷啟動：軟體產品冷啟動 30 天 Playbook（上線後沒人用的解法）
• 延伸閱讀：SaaS vs 客製化系統決策框架
• 延伸閱讀：中小企業導入 AI 系統的 5 個高 ROI 場景

常見問題 FAQ

下一步：照階梯走，每階段做對的事

階梯式驗證的核心精神就一句話：每階段只做能讓你進入下一階段的事，其他都是浪費。

$0 階段做訪談、$1K 階段做 production code，兩件事都對；但對調過來就會死。280 萬燒掉的那個案例，問題出在順序錯了，工程本身做得不差。

如果你正在規劃軟體產品，或你已經卡在某個階段不確定該往前還是回頭，可以聯絡我們的 軟體系統客製化開發團隊，我們會先幫你判斷現在卡在哪一階段，再決定該外包什麼、不該外包什麼。階段不對先別寫程式，找對人聊一場可能省你 100 萬。

當你跨過 $1K MRR 階段、開始考慮把獲客 scale 上去時，可以延伸閱讀 B2B SaaS 投廣告完整框架——什麼時候該開始花錢買流量、怎麼用 LTV/CAC 反推預算上限、三大平台各自的真實角色分工。