App 開發由 MVP 到上架：範圍、報價與維護安排
App 開發報價差異極大，原因通常不是框架，而是要接幾多東西、上架要過幾多關、上線後邊個維護。本文列明 MVP 應包含與可延後的模組、四種技術選擇、上架前五件易忽略的事，以及報價差異的四個來源。
文章目錄（點擊展開）
App 開發報價差異極大，原因通常不在「用 React Native 定 Flutter」，而在你有幾多東西要接、上架要過幾多關、上線後邊個維護。這篇由 MVP 講到上架與維護。
決策摘要（30 秒）
MVP 階段目標是「驗證需求」，不是「功能齊全」。
常見範圍：登入、核心功能、通知、基本後台。
上架要預留時間：Apple／Google 審核、私隱政策、帳號刪除功能。
唔適合：未有明確使用場景就想做「平台」。
一、MVP 應該包含什麼
| 模組 | MVP 需要 | 可以稍後 |
|---|---|---|
| 帳號 | 電郵／電話登入、重設密碼 | 社交登入、多語系 |
| 核心功能 | 一件最主要的事做好 | 邊緣功能、報表 |
| 通知 | 推送或 WhatsApp | 個人化通知策略 |
| 後台 | 查看與管理用戶資料 | 細緻權限、審計日誌 |
| 金流 | 可先離線收款 | App 內購買、訂閱 |
二、技術選擇：先看團隊，再看潮流
- ▸React Native——一套代碼出 iOS／Android，適合 MVP 與內部工具。
- ▸Flutter——UI 一致性好，適合設計驅動的產品。
- ▸原生（Swift／Kotlin）——需要深度用相機、藍牙、健康數據等系統功能。
- ▸PWA——只需網頁版體驗、不想上架，成本最低。
三、上架前容易被忽略的五件事
- 私隱政策與資料收集說明。Apple 與 Google 都要求，缺了直接退件。
- 帳號刪除功能。兩大平台都要求 App 內可以刪除帳號。
- 審核時間。首次上架通常要預留一至兩星期，退件再審會更久。
- 開發者帳號。公司名義申請需要商業登記與 D-U-N-S（Apple）。
- 版本更新流程。上線後每次更新都要再過審，流程要事先講清楚。
四、報價為何差幾倍
四個變數：要接幾個第三方服務（金流、地圖、推送、CRM）、要不要後台、要不要與現有系統同步、交付標準（測試、文件、上架協助）。同一個「App」可以是四星期也可以是一年。
五、上線後誰維護
App 的特點是平台每年改版，iOS 與 Android 新版都可能令舊代碼出問題。所以維護不是可選項。簽約時要問清楚：保固期幾長、平台大改版是否包含、每次更新的收費方式。
下一步
想知你的想法適不適合先做 MVP？我們可以幫你砍到最小可驗證範圍，並列明上架與維護安排。討論 App 項目，或看系統與 App 開發。
三、MVP 的定義：能收錢的最小版本
「MVP」在香港常被誤解為「功能較少的完整產品」。真正的 MVP 應該符合三個條件：
- 解決一個核心問題——用戶願意為此付費或改變習慣。
- 能完成一次完整流程——由進入到得到結果，中間不需要人手介入。
- 可以量度——有辦法知道用戶是否真的用了、是否真的付費。
不符合這三條的功能，即使「應該有」，都應該放入第二版。這一點是控制預算最有效的單一決定。
四、功能取捨的優先次序
| 功能類型 | 第一版 | 原因 |
|---|---|---|
| 註冊／登入 | 必須 | 沒有身份就無法保存狀態 |
| 核心流程（下單／預約／提交） | 必須 | 這是產品存在的理由 |
| 通知（推播／電郵） | 基本版必須 | 沒有通知，用戶不知道流程完成 |
| 個人化推薦 | 可以後加 | 需要數據才有用，第一版沒有數據 |
| 社交功能／分享 | 可以後加 | 要用戶基數才有意義 |
| 多語言 | 視市場 | 架構要預留，但內容可以後補 |
| 後台報表 | 最基本必須 | 否則無法判斷產品是否有效 |
五、成本由什麼決定
App 開發報價差異可以達到五倍，原因不是「有沒有良心」，而是以下五個變數：
- ▸平台數量。只做 iOS 與 iOS＋Android 的工作量不同；跨平台框架可以減少重複，但有時要為個別平台額外處理。
- ▸後端複雜度。有沒有配對、即時通訊、支付、地圖、檔案上傳，差別很大。
- ▸整合數量。每個第三方系統（金流、CRM、ERP、物流）都是一段獨立工程與測試。
- ▸設計深度。用現成元件庫與度身設計的 UI，工作量可以差一倍以上。
- ▸上架與合規。App Store 與 Google Play 的審核要求、隱私政策、資料刪除機制，都需要工程與文件。
六、由零到上架的實際流程
第一階段：需求與範圍（一至兩週）
把想法寫成用戶流程圖與功能清單，明確標示「第一版」與「以後」。這階段最重要的產出是一份雙方都同意的範圍文件。
第二階段：介面設計（兩至四週）
由 wireframe 到高保真設計，並確認主要流程可以完成。這階段改動成本最低，之後每次改動都會倍升。
第三階段：開發與分段驗收（六至十二週）
按模組交付，每兩週可以試用一次。分段驗收的好處是問題在早期發現，而不是上線前一次過爆出來。
第四階段：測試與上架（一至兩週）
包括真機測試、帳號流程、金流沙盒測試、商店審核文件。這階段常有意外延誤，預算要留緩衝。
第五階段：上線後觀察（持續）
看留存、完成率、崩潰率。第一版的功能取捨是否正確，只有在真實用戶手上才知道。
七、常見問題
Q：可不可以先做網頁版，之後才做 App？
很多情況下這是更明智的順序。網頁版上線快、改動成本低、不需要商店審核，可以先驗證需求，再決定是否投入原生 App。
Q：跨平台框架會不會影響體驗？
對大多數業務型 App 影響很小。只有在高效能需求（例如大量動畫、影像處理、遊戲）時，原生才有明顯優勢。
Q：上架後是否就完成？
不是。系統要跟隨 iOS 與 Android 的年度更新、商店政策變動、憑證到期。這是持續成本，應該在預算內預留。
Q：怎樣判斷報價是否合理？
看報價單是否把功能、整合、設計、測試、上架分開列出。只有一個總數而沒有分項的報價，日後加價與爭議的空間最大。
八、上架審核的實際要求
很多項目延誤在上架，而不是開發。以下是最常見被退回的原因：
| 原因 | 具體要求 | 準備時間 |
|---|---|---|
| 隱私政策不完整 | 要說明收集什麼、用途、保存期、刪除方式 | 需事先撰寫 |
| 帳號刪除功能 | App 內要能直接刪除帳號，不能只提供電郵 | 需開發 |
| 截圖與描述不符 | 商店截圖必須反映實際介面 | 上架前最後一步 |
| 登入方式 | 如提供第三方登入，通常要同時提供其他選項 | 需開發 |
| 付款說明不清 | 訂閱制要清楚列明價格、週期、取消方式 | 需文案配合 |
九、第一版之後怎樣決定做什麼
上線後，功能優先次序不應該由「客戶要求」決定，而應該由數據決定。三個觀察點：
- 哪一步流失最多人？如果七成人卡在同一步，那個步驟就是第一優先，而不是最多人要求的新功能。
- 哪些功能幾乎沒有人用？可以考慮移除，減少維護負擔。
- 哪些功能用了的人留得特別久？這通常就是產品的核心價值，應該加強而不是分散資源。
沒有這三個觀察，第二版通常會變成「功能更多但更難用」。這也是很多 App 由第一版成功走向第二版失敗的原因。
ADWire 編輯團隊
ADWire Agency Limited
文章由 ADWire 團隊撰寫及審閱。團隊負責軟件開發、AI 應用與工作流程自動化、SEO／GEO 及數碼營銷項目，內容取材自實際項目經驗及公開的官方資料。
- 軟件及系統開發
- AI 應用及流程自動化
- SEO 及 GEO 搜尋優化
- 數碼營銷及成效量度
