App 開發費用完整指南：成本花在哪、時程怎麼抓
「做一個 App 大概要多少錢？」只要對方直接報出一個數字，你要小心的不是價格，而是他還沒搞清楚你要做什麼。
App 的費用差距，來自需求本身的差距。以下把錢實際會流去哪裡、哪些決定會大幅推高成本、時程大致怎麼走，拆開來講。
先決定技術方向：原生、跨平台、還是網頁就夠
這是第一個會影響整體費用的決定。
原生開發（Native）：分別用 iOS 與 Android 各自的官方技術開發兩套程式。優點是效能與系統功能的整合最好，缺點是兩套程式要分別寫、分別維護，人力成本最高。適合對效能要求極高、或大量使用裝置硬體功能的產品。
跨平台開發（Cross-platform）：寫一套程式碼，同時產出 iOS 與 Android 兩個版本。這是目前多數商業型 App 的主流選擇，在成本與體驗之間取得平衡。NETVANA 的 App 開發採用這類技術路線，細節見軟體服務介紹。
PWA（漸進式網頁應用）：本質是網頁，但可以被加到手機桌面、在一定程度上離線使用。不需上架、更新即時、成本最低，缺點是與系統功能的整合有限，而且使用者要自己加到桌面。
判斷方式：先問「我真的需要出現在 App Store 裡嗎？」如果核心需求是讓客人查資料、下單、預約，而且沒有非用不可的裝置功能，先做一個體驗良好的行動版網站，往往比做 App 更划算——這類網站的成本結構見網站製作費用怎麼算。
成本實際花在哪裡
多數人以為 App 的錢花在「畫面」，實際上畫面只是其中一塊。
| 項目 | 佔比感受 | 說明 |
|---|---|---|
| 需求與規格 | 常被省略，但決定後面會不會重做 | 功能範圍、使用流程、資料結構 |
| UI/UX 設計 | 可觀 | 畫面、互動、兩個平台的操作習慣差異 |
| 前端（App 本體） | 可觀 | 畫面實作、狀態管理、離線與弱網處理 |
| 後端與 API | 經常是最大宗 | 資料庫、會員、權限、推播、後台管理介面 |
| 測試 | 容易低估 | 多機型、多版本、各種網路狀況 |
| 上架 | 固定要花的工 | 商店素材、隱私政策、審核往返 |
| 上線後維運 | 持續發生 | 系統改版跟進、崩潰追蹤、功能迭代 |
後端常常是真正的成本重心。 只要 App 有登入、有資料同步、有推播，就需要一套伺服器端的服務，還要有給你自己用的管理後台。很多人在比價時只想到 App 本身，忽略了後台其實是一個完整的系統。
推播、簡訊驗證、金流這類功能不是「一個開關」。 每一項都牽涉第三方服務的申請、串接、測試與異常處理，而且多數按用量收費，屬於持續性支出。
開發時程大致的節奏
時程和費用是一體兩面——多數開發費用本質上是人力時間。一個典型的 App 專案大致會經過這幾個階段：
- 需求訪談與規格確認：把想法收斂成可執行的功能清單與優先順序。
- UI/UX 設計與原型：先做出可以點擊操作的原型，在還沒寫程式前就發現流程問題。這個階段多花一週，常常能省下後面數週的改動。
- 開發與迭代：分批交付，每個週期結束有可以實際操作的版本。NETVANA 採每兩週一個 Sprint、固定 Demo 節點的作法，流程細節見軟體開發流程。
- 測試：跨機型、跨系統版本、弱網與離線情境。
- 上架與審核：準備商店素材、隱私說明，送審後可能需要往返修正。
- 上線後觀察期：修正真實使用者遇到的問題。
NETVANA 官網對 App 專案標示的典型交付週期是六到十六週，實際長度取決於功能範圍。要特別留在行事曆上的是審核往返——送審不是按下按鈕就結束，被退回補件是常見情況，平台的審核規則也會調整。如果你有硬性的上線日（例如搭配活動檔期），務必往前抓緩衝，並以兩大平台的官方最新說明為準。
哪些需求會讓費用明顯往上走
- 即時性功能：即時聊天、即時位置更新、多人同步，牽涉的後端架構複雜度遠高於一般的讀寫。
- 離線可用：要在沒網路時也能操作並在恢復連線後同步，資料衝突處理是專門的工程課題。
- 金流與訂閱：除了串接本身，還有退款、失敗重試、發票、對帳流程。App 內購買另有平台自己的規則要遵守。
- 深度的裝置整合：藍牙裝置、背景定位、相機即時處理。
- 後台管理系統：如果客服或營運人員需要一個完整的管理介面，那等於是另一個網頁系統。
- 多角色權限：一般使用者、店家、管理員各有不同畫面與權限，等於同時做多個產品。
- 資料遷移：把既有系統的資料搬進來，通常比想像中花時間。
反過來說，有幾類需求對費用的影響其實比多數人以為的小：品牌配色與字體的調整、文案修改、增加幾個純顯示的頁面。這些屬於「內容」而非「邏輯」，只要在設計階段一次講清楚，追加成本有限。真正推高費用的是流程的分支數量——同一個功能，如果依使用者身分、付款狀態、時間條件而有不同行為，每一種組合都要實作與測試。列需求時，與其糾結顏色，不如先把「什麼情況下會發生什麼事」講清楚。
上架之後的持續成本
App 和網站最大的不同，是它幾乎不可能「做完就放著」。
作業系統每年改版。 iOS 與 Android 每年都有新版本，介面規範、隱私政策、API 都可能調整。不跟進的 App 會逐漸出現顯示異常，嚴重時甚至無法啟動。
商店規則會變。 隱私揭露、權限說明、帳號刪除機制等要求會隨時間增加，既有 App 也需要配合調整。
伺服器成本隨使用者成長。 這是好事，但要納入營運預算。
使用者回報的問題需要有人處理。 崩潰追蹤與客服回報要有固定的處理節奏，否則評分會被拖累。
所以評估 App 專案時，合理的問法不是「做這個要多少錢」，而是「做這個、加上第一年撐住它，要多少錢」。
預算有限時：用分期開發控制風險
把所有想得到的功能一次做完，是 App 專案失敗最常見的原因——錢燒完了，卻還沒有任何使用者驗證過這個產品有沒有用。
比較務實的作法是分期：
第一期：只做一條完整可用的核心流程（例如「找到服務→下單→付款→收到通知」），其他全部延後。先驗證有沒有人真的會用。
第二期：依第一期的實際使用數據，決定要加什麼、砍什麼。你會發現當初列在清單上的功能，有一部分根本沒人需要。
第三期：在需求被驗證之後，才投資效能、自動化與規模化。
這個思路的完整方法論見MVP 最小可行產品開發指南。要注意的是，分期不等於把品質分期——第一期的品質必須是完整的，只是範圍小。
另一個控制成本的角度是團隊配置：是全部外包、自己養工程師，還是外部顧問搭配小型內部團隊，各有不同的成本結構，比較方式見軟體外包 vs 自建團隊。
比價前，先準備好這幾樣東西
想拿到可比較的報價，你需要先寫出來的是：
- 使用者是誰、他要完成什麼事（一句話講清楚）
- 必要功能清單與優先順序（分成「沒有就不能上線」和「之後再說」）
- 有沒有既有系統要串接
- 預期的使用者規模
- 有沒有硬性的上線時間
- 內容與素材由誰提供
同一份清單發給不同廠商，收到的報價才有比較意義。廠商評估與合約注意事項，見如何挑選軟體開發公司。
App 專案的預算控制，關鍵不在殺價，而在把範圍講清楚、把第一版縮小、把上線後的成本一起算進來。
如果你手上有一個 App 構想，還不確定該做原生、跨平台，還是先用網頁驗證，與 NETVANA 聊聊你的需求——先釐清方向，再談報價。
延伸閱讀：網站類專案的成本結構見網站製作費用怎麼算；第一版該做什麼不做什麼，見MVP 最小可行產品開發指南；挑廠商與看合約，見如何挑選軟體開發公司；報價要準，需求得先寫到能被估算，可以看軟體需求文件怎麼寫；報價談完之後，上架送審才是最容易卡關的一段，可以看App 上架完整檢查清單；先搞懂做哪種格式才知道費用怎麼估，可以看做 App 還是網頁版。
