App 開發及內部工具：香港企業成本結構與流程指南

「寫個 App 要幾錢？」是我們最常收到的查詢，也是最難一句話回答的問題。同一個功能清單，報價可以由幾萬到幾百萬。這篇文章不給籠統數字，而是把成本結構、開發流程、平台選擇與失敗風險逐項拆開，讓你在收報價之前，先知道錢花在哪裡。

以下內容由 ADWire Agency 團隊整理，結合香港本地實戰經驗與最新行業數據。

一、不同類型的「App」成本差異極大

第一次接觸開發項目的客戶，通常會把三種東西統稱為「App」：原生手機 App（要上 App Store／Google Play）、跨平台手機 App、以及內部用的網頁應用（web app，只需瀏覽器就能用）。三者的成本結構、開發時間與維護方式都不同。先弄清楚你要哪一種，報價才有比較基礎。

值得注意的是，如果你的受眾是「公司內部同事」或「經常用電腦工作的客戶」，網頁應用往往比手機 App 更實際：更新即時生效、不必等 App Store 審批、也不必強迫用戶下載。很多公司一開始就指定要「做個 App」，結果花了額外成本處理上架與審批，實際上卻只需要一個手機可以開啟的網頁。

所以「有相機或推送就一定要做手機 App」的說法並不準確。真正需要考慮的是：功能是否需要背景運作、離線、特定 OS API、跨平台瀏覽器支援，以及安全需求。把這些寫清楚，再決定形態。

來源：MDN — getUserMedia、WebKit — Web Push for Web Apps on iOS and iPadOS、web.dev — Progressive Web Apps

二、成本主要由這幾個因素決定

明白以下六項，你就明白為何同一份功能清單會有截然不同的報價。

1. 功能範圍

影響最大的一項。單純顯示內容的 App，與需要帳號系統、付款、即時通知、後台權限的 App，工作量可以相差數倍。功能清單每加一項，都牽涉介面、邏輯、測試與後續維護。

2. 平台數量

iOS 與 Android 各自需要上架、審批與測試。原生開發要做兩套，跨平台可以共用大部分程式碼。這一項的差異通常在報價上直接反映。

3. 後端與資料庫

是否需要伺服器、資料庫、用戶認證、第三方 API 整合（付款、地圖、WhatsApp）？後端往往佔整個項目相當比例的工作量，卻最容易被低估。

4. 設計要求

沿用現成設計元件，與完全度身訂造的介面設計，投入差別很大。若品牌對視覺有明確要求，設計階段的時間必須計入。

5. 整合與權限

要接上現有的 CRM、ERP、會計系統或內部資料庫嗎？舊系統有沒有可用的 API？這一項經常是項目中期才發現的隱藏工作量。

6. 維護年期

作業系統每年更新，App Store 與 Google Play 的審批政策亦會調整。上線之後仍有持續的工作，這一項必須在預算階段就預留。

三、為何我們不在此列出「標準價格」

你可能正在找一個數字，例如「香港做個 App 大概幾錢」。我們刻意不提供，原因有兩個，而且都是為了保護你的判斷。

第一，沒有可靠的公開來源可以支撐一組香港 App 開發的標準價格。市面上的數字多數來自個別公司的宣傳或部落格文章，樣本、範圍與假設都不透明，無法代表你的項目。

第二，用一個籠統數字開始討論，通常會導致後期爭議。客戶記住了「大概幾十萬」，承辦方按實際功能報出更高金額，雙方就會陷入談判而不是解決問題。與其如此，不如先把範圍寫清楚。

真正有用的做法是：準備一份需求文件，讓承辦方按你的實際範圍報價。這樣拿到的幾個報價才有可比性。若你只是想有一個預算概念，以下是我們為三個示意情境列出的自家示意預算，並非市場統計，數字背後的假設都寫得很清楚，僅供內部規劃參考。

上表為示意情境，用以說明「範圍決定成本」，不代表任何市場價格或報價。實際報價須按你提供的需求文件計算。

四、功能的優先次序：先做核心，後做附加

不少項目超支，不是因為報價不合理，而是因為範圍在過程中不斷擴大。避免的方法是在開始前就分好三層。

必須有（核心）

沒有這些功能，App 就無法運作，或無法驗證商業假設。例如用戶登入、核心資料輸入、最基本的流程閉環。

應該有（第二階段）

能明顯提升體驗，但第一版可以先不做。例如報表、通知、批次操作。

可以之後再加

錦上添花的功能。例如主題切換、複雜的權限分層、進階數據分析。

把清單寫下來、標明層級，並在合約中列明第一版的範圍，是控制成本最有效的一步。第一版上線、收到真實用戶回饋之後，才知道第二階段最值得做什麼。

五、開發流程：一個項目會經過哪些階段

標準的開發流程通常包含以下階段。每個階段都有具體產出，這些產出是日後驗收的依據。

要留意第 6 階段。提交上架不是即時完成的動作，審批需要時間，而且可能被要求修改。把審批時間計入項目時間表，可以避免上線日期失準。另外，使用者角色與權限（RBAC）、稽核日誌（audit log）、資料遷移、以及測試／UAT 的驗收準則，往往被留到「第二期」才處理；這些其實屬於核心需求的一部分，最好在第一版就一併納入討論，否則日後補做成本更高。

六、行業失敗數據的正確讀法

在投入資金之前，值得先參考行業的實際情況。以下數字均附來源，並註明其性質與適用範圍。要特別強調：這三組數據來自三個不同研究範疇，不能拼湊成「香港 App 項目失敗率」。

RAND：AI 項目失敗率（轉引估計）

RAND《The Root Causes of Failure for AI Projects》（2024）指出，據部分估算，逾 80% 的 AI 項目失敗，是為非 AI 資訊科技項目失敗率的兩倍。要留意三點：一是這個數字是 RAND 轉引「some estimates」，並非 RAND 自行量度；二是它針對的是 AI 項目，不能推出非 AI App 的失敗概率；三是 RAND 明確排除只使用預訓練大型語言模型／prompt engineering 的項目。因此它不宜被套成「API 整合 App 的普遍失敗率」。RAND 指出失敗主因往往不是技術，而是對問題的理解、數據準備與範圍界定。

Gartner：生成式 AI 項目被放棄的預測

Gartner 於 2024 年 7 月 29 日的新聞稿預測，到 2025 年底，至少 30% 的生成式 AI 項目會在概念驗證（PoC）後被放棄，主因包括數據質素差、風險控制不足、成本上升與商業價值不明確。要清楚這是一個帶明確期限的預測，不是 2026 年已觀測到的實際失敗率，也未經本次核實確認是否已實現。它提醒我們：概念驗證通過不等於可以落地。

Andrew Chen：用戶流失的常態（歷史 Android 數據）

a16z 的 Andrew Chen 引用 Quettra 的數據指出，平均 App 在安裝後 首 3 天流失 77% 的日活躍用戶（DAU），首 30 天流失 90%，首 90 天超過 95%；標題所述的「80%」是約數。要注意這是歷史 Android 安裝 cohort 的日活留存，反映「用戶不再每日打開」，並不等於「永久流失」，也不等於企業內部工具，更不能等同「項目失敗」。內部工具的使用頻率本來就與消費型 App 不同。

來源：RAND 報告、Gartner 新聞稿（2024 年 7 月 29 日）、Andrew Chen（a16z，Quettra 數據）

七、完整擁有成本（TCO）：被漏算的部分

開發費只是開始。把以下項目一併估算，才是完整的擁有成本，也才能公平比較不同方案。

來源：Apple Developer Program、Google Play 開發者註冊費。關於本地數據保存與敏感資料的具體法律要求，建議另做香港法規的專業核查，本文不提供法律結論。

至於「維護費通常是開發費的百分之幾」，並無可靠公開依據。維護成本取決於支援 SLA、雲端與 API 用量、作業系統更新頻率與安全需要，可以相差很遠。若要在預算中預留一個數額，應把它標明為假設性的年度預留，並將雲端、API 與維護工時分開估算，而不是用一個固定百分比套用。

八、香港公司常見的具體問題

以下是我們在實際項目中經常遇到的情況，也是很多香港公司決定開發內部工具的原因。

1. 資料散落在 Excel、電郵與 WhatsApp

同一個客戶的資料存在三四個地方，同事要人手複製貼上。這類問題通常不需要手機 App，而是一個共用的內部系統加基本的權限管理。

2. 報價、訂單、發票靠人手處理

重複輸入容易出錯，月底對數費時。這類流程往往可以先做局部自動化，再考慮是否要開發完整系統。

3. 各有各的舊系統，資料不通

會計用一套、庫存用一套、客戶資料又一套。這種情況需要的是系統整合（API 對接），而不是從頭再寫一個新系統。

4. 想試一個商業構思，但不想一次投入太多

這種情況適合先做最小可行產品（MVP）：只用核心功能驗證市場反應，確認有需求再擴充。這比一次做完所有功能、結果發現方向錯誤要划算得多。「用兩成成本驗證八成需求」這類說法並無可靠依據，MVP 的價值在於縮短學習週期，而不是一個固定的成本比例。

九、PoC 到 MVP 到正式上線的驗證指標

把項目分成三個關卡，並為每關設定明確的成功條件與退出標準，可以及早發現方向錯誤，避免投入持續擴大。

上表為實務建議，並非官方標準。

十、如何準備一份讓報價準確的需求文件

一份好的需求文件不需要寫得漂亮，只需要具體。以下六項是最基本的要求。

一、使用者是誰：內部同事、現有客戶，還是公眾？人數大約多少？

二、核心流程

用戶由進入到完成目標，會經過哪幾步？用文字或簡單流程圖寫出來。

三、必須有的功能：按第四節的層級方法，只列第一版必須的項目。

四、要接的系統：現時用什麼系統？有沒有 API？這部分要事先查清楚。

五、平台要求：一定要手機 App，還是網頁也可接受？

六、時間與預算範圍

期望何時上線？預算大約落在哪個區間？寫明「尚未確定」也可以，但不要留空。

若項目需要 AI 功能或流程自動化，可參考 AI Agent 完整指南；若以招徠客戶為目標，網站設計與報價 亦同樣關鍵。

十一、常見問題

十二、總結

「寫個 App 要幾錢」之所以難答，是因為答案取決於你要解決什麼問題，而不是取決於你要做什麼形態的產品。功能範圍、平台數量、後端需求、設計要求、系統整合與維護年期，這六項決定了成本的大半。

比起急著比較報價，更值得先做三件事：寫清楚需求文件、把功能分成三層、以及確認內部工具是否真的需要手機 App。這三步花的時間不多，卻能直接減少後期的爭議與追加費用。

最後提醒一點：行業數據顯示，項目失敗的主要成因是需求定位與範圍控制，而不是技術；但引用時要分清每個數字的來源與適用範圍，不要把 AI 項目、生成式 AI 預測與消費型 App 留存混為一談。

如果你正在考慮開發內部系統、App 或 MVP，可以參考我們的 系統開發服務，或了解 工作流程自動化 如何先解決重複工序的問題。我們的做法是先協助你寫清楚需求與範圍，再提出分階段的方案，而不是一開始就報一個大數。

主要來源及查核日期（2026 年 10 月 3 日）：RAND — AI 項目失敗成因、Gartner 新聞稿（2024-07-29）、Andrew Chen — App 留存、MDN getUserMedia、WebKit Web Push、Apple Developer Program、Google Play 註冊費。