開發一個 MVP 要花多少錢？一份實用的成本拆解

「做這個要多少錢？」幾乎是每個創業者問的第一個問題，而誠實的回答——「看情況」——本身毫無用處。這篇文章把它換成你能真正用起來的東西：真正影響價格的幾個因素、用工時估算自己 MVP 的方法，以及在不降低品質的前提下省錢的決策。

MVP 是什麼（不是什麼）

最小可行產品（MVP）是能讓真實使用者獲得真實價值的最小版本，目的是驗證這個想法是否成立。它不是「少幾種顏色的 1.0 版本」。判斷每個功能的標準很簡單：如果去掉它，我們還能學到需要學到的東西嗎？

這個定義直接關係到成本，因為大多數超支都來自開發那些回答不了任何問題的功能。

決定成本的五個因素

1. 獨立使用者流程的數量

價格跟著流程走，而不是頁面數。「註冊、建立專案、邀請同事、付款」是四個流程，每一個都需要設計、前端、後端、邊界情況處理和測試。一個十頁、無需登入的官網，可能比一個三屏、帶帳戶系統的應用更便宜。

2. 使用者類型

只有一種使用者是最便宜的情況。雙邊平台——買家和賣家、學生和老師、客戶和管理員——大約會讓工作量翻倍：每一方都需要獨立的後台、權限、通知和引導流程。

3. 第三方整合

支付、郵件、地圖、日曆、CRM、AI 模型。每個整合起步都不難，但要做好很貴：webhook、重試、失敗狀態、測試帳號，還有服務商改 API 的那一天。每個整合都要單獨預算。

4. 內容和資料

文案誰來寫？有沒有資料要匯入？上線後需要後台來編輯內容嗎？「內容以後再說」是專案延期最常見的原因。

5. 平台

響應式 Web 應用用一套程式碼覆蓋所有人。原生 iOS 和 Android 應用會讓開發量翻倍，還要過應用程式商店審核。對大多數 MVP 來說，一個快速的 Web 應用（可選做成可安裝的 PWA）是正確的第一步。

自己用工時來估算

工時比價格更有參考價值：不同國家、不同資歷的費率差別很大，但工作量本身不會變。下面是一位有經驗的全端開發兼設計師的典型工時範圍，乘以你拿到的報價費率即可。

一個典型的單邊 SaaS MVP——落地頁、帳戶、兩三個核心流程、支付、一個簡單後台——通常在 150–350 小時左右。有兩種使用者的雙邊平台通常在 300–600 小時。

這些範圍故意給得比較寬。下限假設決策清晰、內容齊備；上限假設開發過程中範圍在變。

錢真正花在了哪裡

• 開發中途改主意。 這本身不是問題——學習就是 MVP 的目的——但功能做完後再改，成本是在紙面上改的好幾倍。在流程和線框圖上多花時間，開發就會更便宜。
• 所有東西都客製。 客製設計系統、客製登入、客製 CMS，很少是 MVP 成功的原因。成熟的元件（託管的認證服務、Stripe、無頭 CMS 或純 Markdown）更快也更可靠。
• 現在根本沒人會遇到的邊界情況。 多幣種、十種使用者角色、離線模式——先記下來，以後再做。
• 甲方沒有負責人。 如果一天之內沒人能拍板，專案就只能等，而等待同樣是要計費的。

在不降低品質的前提下省錢

1. 用一句話定義成功。 比如：「第二個月底前有十個付費團隊每週使用。」所有功能都用它來衡量。
2. 先只做一種使用者。 先上線賣家端，買家那邊用人工服務撐著，反過來也行。
3. 後台先「假裝」。 頭幾個月，管理後台可以就是一張表格加幾個腳本。
4. 只把核心頁面設計好。 使用者每天用的那三個頁面體驗好，遠比一個精緻的設定頁重要。
5. 選下一個開發者也能接手的技術棧。 TypeScript、React 或 Next.js、託管資料庫和主流部署平台，能給你留足後路。

固定總價還是按時計費？

固定總價適合範圍真正固定的專案：需求清晰、設計已完成、沒有未知的整合。按時計費或按周包月更適合你預計會邊學邊改的情況——對 MVP 來說通常就是這樣。常見的折中方案是：需求和設計階段固定總價，開發階段按估算執行並設定每週上限。

詢價前的快速檢查清單

• 一句話描述使用者和問題
• 前三個月的成功指標
• 按重要性排序的使用者流程清單
• 已知需要的第三方整合
• 內容由誰提供、何時提供
• 預算範圍和上線時間

把這六點寫下來，各家報價就能放在一起比較，也會準確得多。如果你需要一份這樣的文件範本，可以看如何寫一份能拿到準確報價的網站需求說明。

總結

MVP 的成本由流程、使用者類型、整合、內容和平台決定，而不是頁面數量。用工時來估算，先只做一種使用者、只定一個成功指標，使用成熟的元件，並且快速決策。這樣，有限的預算才能變成真正有人用的產品。

如果你想讓人幫你看看需求範圍，歡迎聯絡我。