APP 開發外包完整指南：報價區間、外包 vs 自建 vs No-code 與 7 道驗收關卡

先把結論放前面：一個 APP 該不該外包，決定權在「這個 APP 是不是你公司未來三年的核心資產」。是核心資產，就要想辦法把長期維護的能力留在公司裡；只是一個階段性的通路或工具，外包幾乎永遠比較划算。這篇要處理的是發包這件事本身，也就是外包前該準備什麼、報價單怎麼看、驗收怎麼驗、原始碼歸誰。

我們在需求訪談裡最常聽到的第一句話是「我想做一個 APP，大概要多少錢」。這句話沒辦法回答，原因在於報價的變數幾乎全部藏在對方還沒講的那些事情裡：要不要會員系統、要不要串金流、後台誰在用、上架帳號誰的名字、資料存在哪裡。同一份功能清單，把這五件事講清楚跟沒講清楚，報價可以差三倍以上，而且差的那三倍通常在專案第四個月才會現形。

這不是台灣獨有的現象。Standish Group 的 CHAOS 系列調查長期追蹤軟體專案結果，成功率一直卡在三成上下，超過六成的專案有明顯的時程或預算超支，而規模愈大的專案失敗率愈高。這件事對中小企業的意義很直接：把一個 APP 拆小、把第一版做窄，比談贏一個好價錢重要得多。

下面的內容假設你是老闆或採購決策者，不是工程師。所以我們不談框架怎麼選（那部分放在 客製化 APP 開發框架選型完整指南），只談你在簽約桌上要拍板的事。

外包、自建團隊、No-code 三條路的真實成本對照

多數比較文只比第一年的開發費，這是報價單上最誤導人的一件事。APP 的錢有一半以上花在上線之後：雙平台的系統版本更新、上架帳號續費、閃退追蹤、後端主機、以及每次 iOS 大改版之後的相容性修補。所以下面這張表比的是 24 個月總持有成本（TCO），假設是一個含會員、推播、後台管理的中型 APP。

看這張表要抓的重點只有一個：自建團隊在 24 個月的尺度上是外包的兩到五倍，而且這個數字還沒算招募失敗的空轉成本。台灣中小企業真的適合自建 APP 團隊的情況很少，大致只有兩種——APP 本身就是公司的營收主體（也就是你賣的就是這個 APP），或者你已經有三個以上的產品線要長期共用同一批工程師。除此之外，外包加上一位懂技術的內部窗口，通常是成本效率最高的組合。

No-code 這一欄不要因為便宜就直接排除，也不要因為聽起來低階就看不起。它最合理的用法是拿來驗證需求：先用兩個月做出一個能收到真實使用者回饋的版本，確認這個 APP 真的有人用，再拿驗證過的需求去發包。這樣做等於把最貴的那筆錢延後到需求確定之後才花。

五個訊號告訴你該外包，還是該把能力留在公司

與其糾結成本，先回答五個問題。答案偏右邊愈多，愈該把開發能力留在內部；偏左邊愈多，外包就是正解。

第三列值得多說一句。很多老闆以為外包就可以完全不管技術，這是最常見也最貴的誤解。外包專案裡有一個角色沒辦法外包，就是「替公司做決定的人」——當廠商問你「這個欄位要不要必填」「這個流程要不要加審核」的時候，需要有人在你這邊當天給答案。這個人不需要會寫程式，但要真的懂你的業務，而且要有拍板權。這個角色缺席，是專案延期的第一大原因，遠比技術難度重要。

三個報價區間各自買到什麼，以及哪些工項最常被漏掉

台灣市場的 APP 開發報價大致落在三段。這裡講的都是雙平台（iOS 加 Android）加上一套後台管理的價格，不含後續年度維護費。

報價單上最常被漏掉的，永遠是那些不長在畫面上的工項。這五項如果對方的報價單沒有列，你要主動問，因為它們最後一定會發生，差別只在於誰付錢。

要把這幾項變成報價單上的白紙黑字，最有效的方法是在詢價階段就給廠商一份規格書，而不是讓每家自由發揮。這樣三家的報價才有得比。怎麼寫可以直接抄 軟體 RFP 怎麼寫？老闆版需求書範本與 30 條必備欄位 那份範本，把上面五項直接放進必填欄位。若你想先理解報價本身是怎麼被墊高的，APP 開發報價 8 萬 vs 80 萬差在哪 那篇拆得更細，可以跟這篇搭配著看：那篇談功能怎麼砍，這篇談發包怎麼發。

發包前一定要先備好的四份東西

廠商報價不準，多數時候是因為拿到的資訊不完整。你在詢價前先備好這四份東西，報價的落差會從三倍收斂到三成以內。

一份寫得出「不做什麼」的功能清單

功能清單人人會寫，難的是寫出範圍邊界。一份能拿去比價的清單，每一條功能後面都要標註「這一版做」或「下一版做」，而且下一版那些也要寫進文件裡。原因很現實：廠商在報價時看到的是你的野心，如果沒有邊界，保守的廠商會把價格報高以自保，激進的廠商會低報然後在期中追加。兩種你都不想遇到。

一張使用者流程圖，哪怕是手畫的

把使用者從打開 APP 到完成一次核心動作的每一步畫出來，包含失敗的分支（沒網路、付款失敗、驗證碼收不到）。這張圖不需要漂亮，需要的是完整。工程上的成本大多藏在分支裡，主流程反而簡單。

既有系統的清單與串接方式

如果 APP 要跟你現有的 ERP、POS 或會員系統對接，先確認三件事：那套系統有沒有 API、API 文件在誰手上、原廠願不願意配合。這三件事只要有一件是否定的，串接成本可能翻倍，而且這個風險應該在報價前就揭露，不是簽約後才討論。相關的整合難點在 客製化系統開發完整指南 裡有比較完整的展開。

一份你能接受的付款節點

業界常見的分期是簽約 30%、設計定稿 20%、開發完成 30%、驗收通過 20%。這個結構的重點在最後那 20% 必須綁驗收，不能綁上線日期。差別在於：綁上線日的話，廠商只要把東西丟上去就可以請款，品質好壞跟尾款無關；綁驗收條件的話，你手上才有籌碼。

驗收怎麼驗、原始碼歸誰，這兩題決定你三年後的處境

這是整篇最重要的一段。前面談的錢都是一次性的，這兩件事談不好，代價會跟著你好幾年。

驗收要驗的七件事

驗收不是打開 APP 點一點覺得能用就簽字。至少要有這七道關卡，而且每一道都要有客觀標準寫進合約，不能寫「運作正常」這種主觀字眼。

最後一列最容易被跳過，也最容易在兩年後咬人。完整的驗收流程與會議議程可以照 軟體驗收 SOP 與 UAT 測試清單 那份 30 點清單跑一遍；上架這一關的實務細節，包含審核被退的常見原因與抽成規則，在 App Store vs Google Play 上架完整指南 有完整拆解。

原始碼歸屬：合約沒寫，法律預設不站在你這邊

台灣著作權法的預設是，出資聘人完成的著作，著作權歸受聘人（也就是廠商）所有，除非契約另有約定。很多老闆以為「我付錢做的東西當然是我的」，這個直覺在法律上不成立。所以合約裡一定要有明確的著作權讓與條款，而且要區分三種東西：你的專案程式碼、廠商的既有套件、第三方開源元件。三者的權利狀態不同，一句「所有程式碼歸甲方」反而可能讓廠商簽不下去。

除了著作權，還要一併談交付與存取。實務上最容易出事的三個地方是：開發者帳號開在誰名下、程式碼倉庫誰有管理權、正式環境的主機帳號誰握著。這三樣只要有一樣在廠商手上而合約沒寫返還條件，換廠商的時候你會非常被動。這一整套的談法在 軟體著作權與 source code 歸屬陷阱 講得最完整，簽約前建議整篇看過。

如果你連該找哪一家、怎麼判斷對方技術力都還沒把握，軟體開發公司怎麼選？發包前必問的 12 個問題 那份問題清單可以直接印出來帶去開會；已經吃過虧、想知道別人踩在哪的話，找外包做 APP / 軟體前必踩的 9 個雷 收了九個真實情境。

我們對「先做完整版再上線」這件事的判斷

業界有個很流行的做法：既然都要花錢開發，就一次做到位，免得上線後還要再花一筆。我們的判斷跟這個做法相反，而且相反得滿徹底：APP 第一版該做的功能，通常比老闆想的少一半，做多的那一半有相當比例會在半年內被砍掉或重做。

理由不是省錢，是資訊不對稱。在還沒有任何真實使用者的階段，功能清單其實是一份猜測；猜測寫得再詳細也還是猜測。等到有一千個人用過之後，你會發現當初以為最重要的那個功能沒人點，而某個順手加的小功能被用爆了。這時候如果預算已經花光，你就只能守著一個沒人用的完整版。

我們在自己的產品上就是這樣做的。恆遠內部每天跑 20 多個 AI 流程，多數的第一版都是先做窄、只解決一段最痛的流程，跑一陣子再決定要不要擴。像 秒發報價Pro 一開始只處理報價這一段，生產力管理系統 一開始只讓現場數字每天看得到，兩個都是後來才長出其他模組。這個順序在客戶的專案上一樣適用，差別只在於要把「第二期做什麼」寫進第一期的合約附件，讓廠商知道你不是做完就跑，他也才願意在第一期把架構留活。

看完之後，你的下一步是哪一個

找到你現在的狀態那一列，右邊就是接下來 30 天該做的事。

如果你卡在第二列或第四列，那正是最值得花時間的地方，因為這兩步做對，後面八成的糾紛都不會發生。想找人幫你看一遍功能清單合不合理、報價有沒有藏東西，可以把資料丟過來，我們很樂意 陪你一起看一遍，直接告訴你這個規模該落在哪個區間。想先了解客製化系統的做法與報價邏輯，也可以從 客製化系統開發服務 這邊開始。

APP 外包常見問題