老闆指南：從 0 到上線打造會賺錢軟體產品的完整路線圖

會賺錢的軟體產品有 3 個共通點：開發前已經驗證有人會付錢、MVP 只解一個明確問題、上線後 30 天內就有第一個付費客戶。少了任何一個，就算把產品做出來也只是個漂亮的負債。下面是讓你身為老闆，逐步達成這 3 件事的完整路線圖——從第一張需求草圖到第一筆收入入帳，6 個階段、20 個檢核點、所有踩過的坑。

這篇寫給找外包做產品的老闆看，目標是讓你用創業者的思維管專案——把每一塊預算花在驗證假設上。CB Insights 統計過 101 個新創失敗案例，第一名死因是「市場根本不需要這個產品」（佔 35%），第二名是「錢燒光」（佔 38%，多數因為太早把錢倒給工程）。換句話說，老闆的最大風險來自「做出來沒人買」，工程能不能寫出來反而是其次。

接下來會帶你走完從 0 到上線的完整路線——市場驗證、找外包、MVP 設計、報價判讀、階梯式驗證、冷啟動 30 天 SOP，每個階段都有「該做什麼」「不該做什麼」「進到下一階段的判定條件」，配上 4 張對照表跟 1 張流程圖。看完這篇你會知道：手上這個想法值不值得開案，以及如果要開，第一個 30 萬該怎麼花。

為什麼 7 成軟體產品做完就死掉

先承認一件事：台灣中小企業老闆做的軟體產品，多數活不過上線後 12 個月。我服務過的客戶裡，有人砸了 200 萬做完一套訂閱制 SaaS，上線半年只有 3 個付費用戶；有人把外包預算 80% 花在「後台管理介面」上，結果連一個真實使用者都還沒接觸過；也有人 MVP 上線一週後改 11 次方向，工程師被改到離職。這些案子都不是工程做爛，是「決策」做爛。

Statista 統計 2025 年全球 SaaS 死亡率落在 65% 到 75%（看你怎麼定義「死亡」），其中超過一半是在上線後 18 個月內熄火。McKinsey 在 Why most digital initiatives fail 的調查裡點出更尖銳的事實：70% 的數位產品專案沒有達成原定商業目標，原因往往出在「需求定義階段就走偏了」，跟工程能力無關。

3 種典型死法

我把過去 5 年看過的軟體產品失敗案例歸成 3 類，幾乎涵蓋 9 成情境：

這 3 種死法的共同點是：老闆把軟體開發當成「工程交付」，而不是「商業驗證」。a16z 的 Marc Andreessen 在著名的 PMF 文章 裡寫過一句被引用 20 年的話：「The only thing that matters is getting to product/market fit。」翻成老闆語言就是——做出有人願意付錢的東西，比做出技術上很厲害的東西重要 100 倍。

階段一：開發前——市場驗證 vs. 自我感覺良好

這個階段的核心問題只有一個：有沒有人會掏錢買這個東西？注意——是「掏錢」，不是「覺得不錯」「願意試用」「答應幫你介紹朋友」。我看過太多老闆把「身邊朋友都說讚」當成市場需求，結果上線後才發現朋友不會付錢、付錢的人根本不是朋友圈。Y Combinator 的 Paul Graham 寫過一篇 Do Things That Don't Scale，他強調創業前期最珍貴的證據是「有人掏錢付」，註冊量跟按讚數都只是表面數字。

驗證的最低標準：3 個付費 LOI 或 3 筆預付款

具體怎麼做？我給每個來找我做產品開發的客戶都會問同一句話：「你能不能在開發前，找到 3 個願意先付訂金的潛在客戶？」做 B2B SaaS 的創辦人 L 一開始很抗拒，他說「東西都還沒做出來怎麼收訂金」。我請他去跟前 20 個目標客戶聊聊，結果他發現 18 個人說「需求很真實但你的解法跟我想的不一樣」——這 18 個 NO 比 3 筆訂金更有價值，因為他省下了 60 萬把錯方向做出來的成本。

驗證手段不一定要做出原型，下面是按成本由低到高的排序：

做寵物用品電商的老闆 W 想做一個「寵物保健 SaaS」，本來預算 80 萬要直接開做。我建議他先用著陸頁＋3 萬塊 Meta 廣告測試三組 messaging，2 週後他發現「自動提醒寵物驅蟲時間」這個賣點轉換率 3.8%，遠高於另外兩組（0.4%、0.9%）。他把 MVP 範圍從原本的 12 個功能砍到只做「驅蟲提醒 + 一鍵下單」2 個功能，預算降到 25 萬，3 個月就上線並拿到第一筆 NT$199/月訂閱。

關於市場驗證的具體執行手法（訪談腳本、廣告測試模板、LOI 範本），我寫了一篇深度延伸：軟體產品市場驗證指南：開發前 30 天用 5 萬塊蒐集第一批付費證據，裡面有完整的訪談題目、著陸頁文案結構、預售頁範本，建議你跟這篇一起看。

階段二：找對外包夥伴——避開 9 大雷區

驗證有付費訊號之後，接下來就要決定一件事：自己組團隊？還是找外包？除非你的產品是公司未來 5 年的核心競爭力（例如演算法本身就是商業 moat），否則找外包做 MVP 幾乎都是正解。理由很簡單：自己組 3 人團隊一個月人事成本 30-45 萬，外包同樣 3 個月 MVP 大概 50-100 萬，但風險完全不一樣——外包做爛你只損失幾十萬，自組團隊做爛你損失人才招募成本＋遣散費＋商譽。

找外包最常踩的 9 個雷

• 1. 用報價單當需求書：報價單是金額協議，不是需求協議。一份只有「會員系統 8 萬、後台 12 萬、金流串接 6 萬」的報價，等於沒講需求，吵架機率 99%。（延伸閱讀：軟體 RFP 範本與 30 條 checklist）

• 2. 不簽 SOW（工作說明書）：合約附件要有 SOW，把每個模組的功能點、驗收標準、不包含項目寫清楚。沒有 SOW 就是把吵架權交給對方。

• 3. 跳過原型確認直接開發：沒看過 wireframe / mockup 就讓工程師寫 code，等於要對方憑空猜你的腦袋。修一次 UI 要比修一次後端便宜 10 倍。

• 4. 一次性付清：所有錢付完外包就沒動力修 bug。標準做法是 30/30/30/10 分四期，最後 10% 押在驗收後 30 天無重大 bug。（驗收門檻怎麼設、bug 嚴重度怎麼分類，詳見：軟體驗收 SOP 與 UAT 30 點 checklist）

• 5. 把客製當 SaaS 用：要求外包做 N 種角色權限、可開無限子帳號、支援 100 種報表客製——這已經跨進 SaaS 平台等級的工程量，預算會 x10。

• 6. 不留原始碼跟帳號：合約要寫清楚原始碼歸誰、Git repo 帳號是不是你的、所有第三方服務（資料庫、CDN、金流）帳號註冊在誰名下。我看過老闆把 30 萬付清才發現工程師連 GitHub 都是用自己 Gmail 註冊的。（延伸閱讀：source code 歸屬與著作權合約陷阱完整拆解）

• 7. 沒設定變更管理流程：「再加一個小功能」這句話是預算殺手。所有需求變更要走變更單，估工時、估費用、雙方簽字才動工。

• 8. 找超出能力的對象：3 人小工作室硬接 200 萬複雜專案，做到一半人力斷裂；30 人系統商接 30 萬 MVP，最便宜的 PM 給你管，品質保證掉鏈子。要找「對你來說剛好」的對象。

• 9. 沒測過合作節奏就簽長約：先簽一個 8-15 萬的小範圍 phase 0（規劃 + 原型），確認 PM 溝通順暢、文件齊全、報價誠實再簽 MVP 主合約。

關於合約條款細節（智慧財產權、保固期、bug 修復責任、第三方服務帳號歸屬），我已經整理過一份完整檢核清單：如何選軟體開發公司？7 個評估標準 + 合約必看條款。這篇 pillar 著重在策略思維，那篇是執行 checklist。

9 大雷的更深入版本（含每個雷的真實案例 + 預防 SOP），我寫在 spoke #3：外包軟體開發 9 大雷區檢核清單：合約怎麼簽、付款怎麼分、原始碼怎麼拿，建議你在跟外包簽約前 1 週把那篇完整看完。

階段三：MVP 不是把功能砍少、是驗證單一假設

台灣老闆對 MVP 最大的誤解是「把功能砍少版」。錯——MVP 的 M 是 Minimum 沒錯，但 V 是 Viable（能跑），P 是 Product（驗證假設的工具）。把一個 50 個功能的產品砍成 20 個功能不叫 MVP，那叫半成品。真正的 MVP 是回答一個明確的商業假設，每多做一個跟假設無關的功能都是浪費。

Eric Ries 在 精實創業 The Lean Startup 提出 Build-Measure-Learn 循環時，特別強調：「If you cannot fail, you cannot learn。」你的 MVP 第一個版本應該醜到讓你覺得不好意思上線，但能讓你學到「商業假設成立或不成立」這個關鍵資訊。

一個假設、一個指標、一個版本

我建議的 MVP 收斂方法：把你的產品想法寫成一句假設句，配一個可衡量的指標，然後 MVP 只做能驗證這個假設的功能。例如：

• 假設：在台灣經營餐廳的老闆，會願意付月費 $499，換取自動化追討熟客回流。

• 指標：上線 30 天內，發送 100 封試用邀請信，至少 5 家餐廳轉付費（5% 轉換率）。

• MVP 範圍：只做「會員資料匯入 + 流失提醒 + 一鍵發優惠券」3 個功能。其他要等驗證成立才做。

反例：另一個客戶想做「中小企業全方位數位轉型平台」，第一版預算就要做 12 個模組（CRM、ERP、HR、打卡、財務、進銷存…）。我問他：「你的核心假設是什麼？」他答不出來。改成「中小企業老闆會付 1,999/月換取『手機就能看公司今日營收』的儀表板」這個單點假設後，MVP 範圍砍到只剩 3 個畫面，6 週上線，第一個月拿到 11 個付費客戶。

MVP 的階段性付款設計（怎麼分期、怎麼設驗收、什麼算合理保固），我寫在 spoke #4：MVP 階段性付款 ＆ 驗收完整指南：8 萬到 80 萬，老闆怎麼分批給錢不被卡。如果你正在跟外包談付款條件，那篇可以直接當談判模板。

階段四：8 萬 vs. 80 萬報價，差在哪

「同樣是會員系統，為什麼 A 報 8 萬、B 報 80 萬、C 報 280 萬？」這是我每週都被問的問題。先說結論：差別在『會員系統』背後的隱含需求——資料量、權限層級、安全等級、可擴充性、SLA、客製深度。一個能撐 100 人的會員系統跟能撐 10 萬人的會員系統，工程量差 30 倍。——這個價差背後其實是「開發路徑」的選擇，詳見：WordPress vs 客製化開發判斷指南。

看懂報價單的 4 個關鍵欄位

報價金額不重要，拆解結構 才是真相所在。要看 4 個欄位：

• 1. 人天 / 人月單價：台灣 2026 行情，初級工程師 4,500-7,000/天、中級 7,000-12,000/天、資深 12,000-20,000/天、PM 8,000-15,000/天。報價低到離譜代表派初級人力給你。

• 2. 各模組工時拆解：好報價會列「會員系統：6 人天」「後台：4 人天」「金流串接：3 人天」。只給總價的報價是黑盒子，不能簽。

• 3. 不包含項目：明確寫「不含主機費、不含金流手續費、不含 SSL 憑證、不含 SEO 優化、不含 App 上架費」，越誠實的廠商寫越多不包含。

• 4. 保固範圍與例外：「驗收後 90 天內免費修 bug」是基本，但要寫清楚「不包含因第三方服務變更導致的問題、不包含使用者操作錯誤導致的資料異常」。

關於各種報價背後的隱藏成本（伺服器費、金流手續費、SSL、後續維護費），我做過一份完整拆解：系統開發費用完整拆解：從報價單看懂隱藏成本，建議你在收到第一份報價前先看完，避免簽了才發現額外要再花 30 萬主機費。

如果你的 MVP 預算只有 30 萬甚至更少，不代表你做不出能賣錢的軟體——但你必須學會「砍範圍」「跟外包談折扣」「用 SaaS 工具補齊功能」這幾招。我寫在 spoke #5：APP 開發費用比較指南：30 萬以下預算怎麼做出能賣錢的產品，裡面有 3 個真實的低預算成功案例可以參考。

階段五：階梯式驗證——從 $0 到第一筆收費到 $1K MRR

MVP 上線只是開始，收到第一筆錢、累積到 $1K MRR（每月經常性收入）、建立可預測的成長飛輪，才是這個階段真正的目標。我把這個過程拆成 4 個階梯，每個階梯有明確的判定條件，達成才能往下一階走。

a16z 的 Andrew Chen 寫過 Cold Start Problem（也是同名暢銷書），他認為新產品從 0 到 1 最關鍵的事情，是找到第一個小到能突破的市場原子，而功能多寡反而排在後面。Atomic Network 的概念翻譯成老闆語言就是：不要想著贏全世界，先贏一條街。先在你最能影響的小圈子裡做到「100% 都用」，然後複製這個模式。

CAC、LTV 不是 SaaS 創辦人才要懂

無論你做的是 B2B SaaS、C2C 訂閱、還是企業客製專案，2 個指標一定要盯住：

• CAC（獲客成本）：拿到一個付費客戶花的所有錢，包含廣告費、業務人事費、CRM 工具費。簡單算法：本月所有行銷業務花費 ÷ 本月新增付費客戶數。

• LTV（客戶終身價值）：一個客戶從第一次付錢到流失，總共會付多少錢。SaaS 算法：月費 ÷ 月流失率。例如月費 $500、月流失率 5% → LTV = $10,000。

健康的 SaaS 模型 LTV/CAC > 3，且回收期 < 12 個月。你的數字算出來如果連 1.5 都不到，繼續花錢拉客戶等於繼續放血，要先回頭看「客戶為什麼留不住」「為什麼客單價拉不上去」「廣告為什麼這麼貴」這 3 個問題。

關於 SaaS 階梯式驗證的具體執行手法（付費門檻怎麼設、留存怎麼提升、$1K MRR 後該招誰），我寫在 spoke #6：SaaS 產品階梯式驗證指南：從 $0 到 $1K MRR 的 4 個關鍵階梯，裡面有完整的指標模板跟階梯轉換 checklist。

階段六：上線後沒人用怎麼辦——冷啟動 30 天 SOP

「我上線了但沒人用」是新產品最常見的第一個危機。Failory 整理 100 個新創失敗案例 發現，超過 4 成的失敗案例都在「上線後 90 天內找不到用戶」。冷啟動不是 PR 一篇就能解決的事——它需要有計畫、有節奏地連續執行。

冷啟動 30 天 SOP（每天都要做）

Y Combinator 的 Sam Altman 在 Startup Playbook 強調，前 100 個用戶絕對不能靠廣告——必須是創辦人親手一個一個找來的，因為這 100 個人的回饋是調整 PMF 最重要的養分。等你連 100 個真實付費用戶都還沒抓到就開始燒廣告，等於在「還沒對齊產品時拿錢去買用戶失望」。

具體 30 天每日執行 checklist、社群選擇邏輯、KOL 找尋方法，我寫在 spoke #7：軟體產品冷啟動 30 天行動手冊：上線後沒人用的標準解法。如果你產品已經上線但流量為 0，那篇可以當救命包。

6 階段路線圖總覽

老闆最容易踩的 3 個思維錯誤

走完 6 個階段後再回頭看，台灣中小企業老闆做軟體產品最常踩的 3 個思維錯誤其實是同一根：把開發當成『一次完美交付』，而不是『持續驗證』。這個錯誤會分裂成 3 種具體症狀：

錯誤一：為了開發而開發

典型症狀是「我們公司應該要有一個自己的系統」「同行都做了我們也要做」。問題是——你還沒回答「為什麼是現在做」「做了之後誰會用」「不做會死嗎」。Bessemer 的 State of the Cloud Report 統計，B2B SaaS 公司前 5 年存活率 25%，主要死因第一名就是「做了沒人需要的工具」。如果你要做的東西不能直接連到公司營收或核心競爭力，就先問自己：用 SaaS 工具能不能頂著？通常 80% 的情境答案是「可以」。

錯誤二：為了功能而功能

看到競品有什麼就想做什麼。但你的競品有 50 個工程師、6 年累積、千萬使用者數據——他做這個功能的決策邏輯跟你完全不一樣。產品策略大師 Marty Cagan 在 INSPIRED 一書 寫過：「Building features that customers ask for is not product management。」聽客戶要什麼就做什麼不叫產品管理，那叫拷問外包。真正的產品判斷是「拒絕 90% 的功能請求，把資源 all-in 在能驅動商業指標的 10%」。

錯誤三：為了上線而上線

把「上線當天」當成終點。慶祝、發新聞稿、然後就沒有然後了。這是最浪費的死法——前面 6 個月投入的所有錢、所有時間、所有 LOI 名單，都在上線後第 30 天歸零。要記住：上線只是讓你開始有資格收集真實數據，真正的工作這時候才剛開始。我看過最有紀律的客戶，是上線前就把「上線後 90 天迭代計畫」一起寫好，每個禮拜都有具體要驗證的事情。這種老闆做的產品，活下來機率比一般高 3-4 倍。

如果你想看「持續驗證」這套思維怎麼從原型階段一路用到正式產品，可以看：Vibe Coding 原型到正式產品，中間差了這 7 件事，那篇從技術角度補完了這個轉換的細節。如果你還在猶豫該選 SaaS 還是客製化，SaaS vs 客製化系統：中小企業到底該選哪一個 跟 客製化系統開發完整指南 是另外兩篇必讀的決策框架。

結論：把開發當成「持續驗證」、不是「一次交付」

整篇路線圖背後只有一個核心心法：用創業者的思維管外包專案。具體來說就是 4 個動作：

• 動作一：開發前花至少 1 個月驗證有人付錢，這 1 個月省下來的錢是你後面所有預算的避震器。

• 動作二：選外包前先簽小額試水合約，phase 0 規劃階段花 8-15 萬測試合作節奏。

• 動作三：MVP 只做能驗證單一假設的功能，其他想法寫在 backlog 等驗證成立才放行。

• 動作四：上線是中點不是終點，預留 30% 預算做上線後的冷啟動 + 迭代。

做寵物用品電商的老闆 W 後來告訴我，他做這個 SaaS 副業最大的感想是「以前以為做產品是工程問題，後來才發現是商業問題」。光是把驗證這一步做完，就讓他從原本要花 80 萬變成 25 萬就上線；上線 4 個月做到 $1.2K MRR，已經 cover 掉伺服器費跟外包維護費，淨現金流為正。關鍵在於他改用「驗證」的角度看每一塊預算，每花一塊錢都要對應一個能被檢核的商業假設，而工程交付只是達成假設的副產品。

如果你正準備啟動第一個軟體產品專案，把這篇收藏起來，每進到一個新階段就回來對一次。創業比的是學習速度，工程能力只是其中一個面向。願你的下一個產品，是會賺錢的那一個。

常見問題

如果你正在規劃第一個軟體產品專案

路線圖看完了，但每個專案的細節都不一樣——你的產業、你的預算、你手上有的資源、你能投入的時間，都會影響「下一步該做什麼」的答案。如果你需要有人陪你看一次：這個想法值不值得開案？預算該怎麼分配？要找哪一個級距的外包？，我們有兩個服務可以對應你的需求：

• 軟體 / APP / 網站客製化開發：從需求釐清、原型設計、MVP 開發到上線後維運，按里程碑分期付款，含完整 SOW 跟保固。預算 30 萬以上適用。

• AI / 軟體產品顧問諮詢：1 對 1 諮詢方案，幫你檢視「想法值不值得開案」「報價單該怎麼判讀」「跟外包談判的策略」，諮詢費 NT$3,500/小時。預算還沒確定、想先聽中立第三方意見的老闆適用。

不管你最後選哪個服務、或是自己摸索都可以，我建議的下一步是：把這篇路線圖列印出來，把你目前卡在哪一個階段圈起來，找出你最缺的那塊資訊，然後去把它補齊。創業是學習速度的競賽——願你做的下一個產品，是會賺錢的那一個。

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

這篇是 7 篇系列文的主軸文（你正在看的這篇），下面 6 篇是各階段的深度延伸，建議照順序服用，或挑你目前卡關的那一篇先看：

• #1（本篇） 打造會賺錢軟體產品的完整路線圖：6 階段全圖

• #2 軟體產品市場驗證指南：開發前 30 天蒐集付費證據

• #3 外包軟體開發 9 大雷區檢核清單：合約、付款、原始碼歸屬

• #4 MVP 階段性付款 ＆ 驗收完整指南：8 萬到 80 萬怎麼分批付

• #5 APP 開發費用比較指南：低預算也能做出會賺錢產品

• #6 SaaS 產品階梯式驗證指南：從 $0 到 $1K MRR

• #7 軟體產品冷啟動 30 天行動手冊：上線後沒人用的解法

當你的軟體產品已經有付費客戶、開始想用付費廣告 scale 時，可以參考 B2B SaaS 投廣告完整框架——整套廣告投放決策框架，從 LTV/CAC 預算反推到漏斗設計、避坑指南。