找外包做 APP / 軟體前必踩的 9 個雷：真實故事、避雷 checklist 與維運條款怎麼看

找外包做軟體真正的成本，往往要等到簽約那一刻之後才會慢慢冒出來。我們經手過的案子裡，最棘手的客戶都長一個樣：手上抱著半成品、被前一家外包搞砸、來尋求救援。九成的死法雷同——卡在同樣的 9 個雷上。

這篇要做的事很直接——把我們親眼看過的 9 個雷一個一個拆開給你看，附上避雷 checklist、合約必看條款、以及一個多數老闆從來沒想過的維運陷阱。如果你想先看評估外包公司的 7 個系統性指標，可以搭配閱讀我們之前的這篇深度指南：如何選軟體開發公司？7 個評估標準 + 合約必看條款。讀完這兩篇，下一次你跟外包談合約時，至少知道哪些地方要堅持、哪些地方要簽下去之前先停一下。

Stack Overflow 2024 年的 Developer Survey 顯示，全球有 65% 的軟體專案會在預算或時程上 overrun，外包專案的失敗率更比內部團隊高出將近一倍。CB Insights 整理的 Top Reasons Startups Fail 報告裡，「跟外包協作出問題」直接被列在 Top 20，順位甚至排在「沒人想用產品」前面。雷區的存在屬於常態，不屬於個案。

為什麼老闆找外包做產品最後變成財務黑洞

我們把過去 5 年經手的失敗外包案做了個粗略統計，發現有 3 種典型的「死法」幾乎涵蓋了 80% 的場景。第一種是「報價陷阱型」——對方報得很漂亮，做到 60% 開始追加，總價膨脹 30% 到 80%，老闆半路下車要付違約金，繼續做又看不到終點。

第二種是「人間蒸發型」——簽約付了 50% 訂金，做到一半接案者去做別的案子、回訊息頻率從一天一次變成一週一次，最後直接消失。經濟部中小企業處 中小企業白皮書 提到，台灣中小企業在數位轉型過程中，「找錯協力廠商」是前三大痛點之一。

第三種是「孤兒系統型」——系統做完了、老闆收貨了，三個月後出 bug，原本的接案者已經接了下家、回訊息變成週末才回，新增需求叫他改、他開的價是當初開發費的兩倍。系統能用但走不動，等於擺在那邊發霉的資產。

上面這 3 種劇本你看了不會陌生，因為網路上每隔一段時間就會有人在 PTT、Dcard 工作板貼類似的求救文。很多老闆會以為「我下次找便宜一點的」「我下次規格寫清楚一點」就能避開——這個想法本身就是第 1 個雷。真正的問題出在你跟外包之間的「資訊不對稱」沒有機制去對齊，價格只是表象。

規格沒寫清楚，後期被加價 30%-80%

這是所有外包失敗的母湯。規格書寫得越模糊，外包公司之後的議價空間就越大。一個典型場景：你在第一次會議講了「希望系統能讓客戶自助下單」，外包報你 80 萬。簽約之後做到一半，他們說「自助下單原來需要金流串接、會員系統、發票模組、訂單通知」——這些都不在原本的報價裡。每一個追加項目開個 8-15 萬，加完總價變 130 萬。想避開這個母湯，可以從一份完整的 RFP 開始：軟體 RFP 範本與 30 條 checklist。

你會覺得「他當初應該要問清楚啊」，但合約上白紙黑字寫的是「自助下單功能」——四個字。誰對？合約上他對。

我們的做法是：簽約前先做一份「功能規格書（SRS, Software Requirements Specification）」，把每一個功能拆成 user story、欄位列表、欄位驗證規則、權限矩陣、邊界情境。IEEE 830 是業界用了 30 年的 SRS 標準，雖然有點老派，但它把「需求應該被寫到什麼程度」講得很清楚。如果外包公司報價時連 SRS 都不肯寫，那就是準備好要在後段宰你。

怎麼判斷規格書寫得夠不夠？教你 3 個檢核點：

• 功能模組是不是有「輸入欄位 / 輸出結果 / 邊界條件」三段式描述？ 例如「會員註冊」要寫到欄位（手機、信箱、密碼長度限制、密碼複雜度規則）、輸出（驗證信寄送、自動登入）、邊界（重複註冊處理、信箱格式錯誤）。

• 有沒有「不在這次範圍內」的明確排除清單？ 一份好的 SRS 不只寫「會做什麼」，還要寫「不會做什麼」。沒寫排除項，事後外包說「這原本就不在範圍裡」，你只能認。

• 驗收標準是不是可以被測試？ 「系統要好用」不是驗收標準。「下單流程從點購買到完成付款不超過 5 個步驟、平均完成時間在 2 分鐘內」才是。更完整的驗收標準寫法跟 UAT 檢核清單，可參考：軟體驗收 SOP 與 UAT 30 點 checklist。

一次付清，做到一半人間蒸發

報價低的接案者最常開出的條件是「一次付清打 8 折」。表面上看你省了錢，實際上你把所有風險都吞了。錢付出去之後，對方有什麼動機準時交付？特別是個人接案者或 3-5 人小工作室，現金流一緊張，你的案子排在後面，到時候訊息越來越慢、進度越來越糊，等你回神已經人間蒸發。

比較合理的付款結構是「分階段付款 + 驗收掛勾」。我們在 MVP 分階段付款驗收指南 裡有更完整的拆解，這裡先給你一張對比表：

這裡有個反直覺的觀念：付款結構越保護你的，外包公司接受的意願就越低；接受最爽快的付款條件，通常背後藏的是最不利你的合約。一個願意接受階段式付款 + 中期驗收門檻的團隊，代表他對自己的交付有信心；一個堅持要一次付清才肯接的，多半是現金流出了問題、或是在你身上看到了下一個獵物。

延伸提醒一個容易忽略的點：發票與稅務。境內接案者要請款，是開二聯式 / 三聯式發票還是個人勞務報酬單？金額是否含 5% 營業稅？跨境接案還要確認匯率基準日跟誰負擔匯款手續費。這些細節在 50 萬以上的案子裡會差到幾萬塊，簽約前先寫清楚比事後補救輕鬆。

源碼不在你手上，做完被技術綁架

這是台灣中小企業最常踩、卻最少在合約上寫清楚的雷。系統做完之後，台灣資訊軟體協會 TASA 業界統計顯示有將近 4 成的客戶實際上沒拿到原始碼——可能是放在外包公司的 GitLab 私有倉、可能是壓在他們的伺服器、可能是「給你了但沒給 commit history」。等到你想換廠商或內部接手，才發現你拿到的其實是一個你看不懂的黑盒子，根本算不上是可維護的「程式碼」。

源碼歸屬條款應該寫到多細？至少要包含這 4 個層面：

• 著作權歸屬：「本專案所有原始碼、設計稿、文件之著作財產權於完整付款後歸甲方（業主）所有」

• 交付範圍：「應交付完整 git 版控紀錄（含 commit history）、技術文件、API 文件、部署文件、第三方授權清單」

• 授權清單：「乙方使用之第三方套件、字型、圖庫均應列示授權條款，確保甲方後續使用無侵權風險」

• 禁止保留：「乙方不得於專案結束後保留任何可獨立執行之原始碼副本，但可保留 portfolio 截圖供作品展示」

上面這 4 條缺一不可。實務上，缺第 4 條最容易出事——很多外包公司會把你的程式碼當成「樣板」，下個案子直接複製貼上。如果你的產品有商業機密或競爭壁壘，這條沒寫等於把祕方送人。完整的著作權與交付條款拆解，可參考：軟體著作權與 source code 歸屬陷阱。

技術細節提醒：git repo 一定要放在「業主帳號底下」，外包以協作者身份加入。專案結束就把協作權移除，整個 repo 留在自己手上。反過來放在外包帳號下、業主只「被加入觀看」，當外包不配合時你連 source code 都拿不到。

沒做市場驗證就直接全功能開發

這個雷比較特別：原因要從老闆自己身上找——外包公司其實沒做錯什麼。很多老闆找外包之前，會先在 Excel 上把所有想到的功能列出來，然後直接拿去報價。300 萬報價單一打開，看了第三頁——「會員系統、後台管理、推播通知、優惠券模組、訂閱制方案、客服中心、分潤系統、第三方串接 5 個」——每個都覺得不能砍，全部簽下去。

9 個月後系統上線，3 個月用戶不到 200 個。功能一大半沒人用，每個月雲端費用 + bug 修復照樣燒錢。技術部分都做出來了，問題出在更上游——「沒先驗證需求」就一口氣做完整版，這才是燒錢的根因。

Y Combinator 創辦人 Paul Graham 那篇經典的 Do Things That Don't Scale，講的就是早期創業者要先用「不規模化的方式」測需求——可能是 Google 表單、可能是 LINE 群組手動處理訂單、可能是用 Notion + Zapier 串個簡易流程。先確定有人願意付錢，再開模做正式產品。

我們在 軟體產品市場驗證實戰指南 裡有一份完整的「先驗證再開發」流程，建議你先看完那篇再決定要不要找外包。如果連 MVP 都還沒驗證、就直接花 200 萬做完整版產品，外包做得再好都救不回來。

報價超低的接案者，為什麼便宜反而更貴

Dcard 工作板上每隔幾個月就會有貼文：「找了 PTT 上一個接案的，報價只有外包公司的 1/3，做到第三個月對方說要加錢，後來人就消失了。」這種故事的結尾通常是：「我又找了另一家補洞，補的錢比原本省下的多」。

為什麼便宜反而更貴？因為軟體開發的真實成本結構是這樣：

如果你想看完整的客製化系統報價拆解，我們有寫過一篇 系統開發費用完整拆解：從報價單看懂隱藏成本，把每一項成本都拆給你看。報價之間的差距 90% 來自上面這 5 個項目的「省略」，不是「技術差異」。

另一個現實：低價接案者通常同時手上有 3-5 個案子在跑。你以為你買了一個工程師全心投入 3 個月，實際上他每個案子分配到的時間可能只有 20-30%。APP 開發費用比較：低預算方案的真實成本 那篇我們做過一個對比——同樣 50 萬預算，找個人 vs 找小型工作室 vs 找正規公司，6 個月後的可維護性差異是質的不同。至於什麼時候該選 WordPress 套版、什麼時候該客製化，可以對照：WordPress vs 客製化判斷指南。

識別「便宜的真實面貌」有個簡單測試：請對方列出「目前手上有幾個案子、預計什麼時候能正式投入」。誠實的接案者會跟你說「我手上 1-2 個案子、要等 6 月才能接你的」；自信滿滿說「同時做 5 個都很順」的，數學上就有問題——要嘛品質很糟、要嘛其中一些案子已經爛尾。

用過時技術棧，2 年後沒人能接手

如果報價特別便宜的接案者跟你說「我用 PHP 5 / 老 jQuery / 沒框架的 Bootstrap 3 寫」，當下你可能不會多想——「能跑就好」。問題是這套系統 2 年後要找人接手時，市場上願意改老 PHP 的工程師比熊貓還珍貴，找到了開的價也比新技術貴 50% 以上。

Stack Overflow Developer Survey 2024 的數據很值得拿出來看：

想搞清楚前端後端到底差在哪、不同技術棧各自的優劣勢，可以參考 前端、後端、全端差在哪？老闆和 PM 一定要懂的軟體開發分工。這篇會幫你建立基本判斷力——下次外包跟你講技術選型時，你不會只是點頭。

另一個常被忽略的：「有沒有正式的測試環境」。我們碰過一個案子，外包公司直接在「正式環境」改 code，每改一次就要冒風險把線上系統打掛。測試環境、正式環境差在哪？從開發到上線的完整流程拆解 這篇有完整講解——一個專業的開發團隊一定會給你 3 個環境（dev / staging / production）。如果外包跟你說「直接在正式環境改比較快」，那就是省成本省到你頭上了。

沒有 PM，老闆自己被當成免費 PM 用

「我只是想花錢買一個系統，怎麼最後變成我每天追進度、開會、寫文件？」這是被外包搞死的老闆最常說的話。原因很簡單：低價接案者通常沒有專職 PM，所有原本 PM 該做的事——寫會議紀錄、跟進度、整理變更、協調第三方串接、提醒風險——全部丟給你。你白天經營公司，晚上下班還要當免費 PM。

好的外包關係應該長這樣：你只需要在每週一次的進度會議上看週報、確認方向、決策變更——其他時間都是 PM 的事。如果外包公司沒有 PM、老闆自己被當 PM 用，那你付的錢買到的不只是「軟體開發」，還包含了「你自己的時間」。

敏捷開發（Agile / Scrum）的核心精神就是「讓 PM 把溝通成本壓低、讓老闆只看結果」。我們在 敏捷開發是什麼？為什麼你的外包案總是延期 那篇有完整講解——一個會跑 Scrum 的團隊，每兩週給你一次「可驗收的可運行版本」，你的時間投入會降到每週 2-3 小時。

怎麼測試對方有沒有 PM 文化？簽約前約一場 60 分鐘的 kick-off 會議，看對方派出幾個人、誰主導會議。如果只有「老闆 + 一個工程師」，PM 角色就是由老闆自己兼——後續溝通成本你要自己吞。有 PM 文化的團隊，會議裡至少有 PM 主持流程、工程主管講可行性，分工明確、溝通效率自然高。

外包公司同時兼產品設計（屁股決定腦袋）

這個雷比較隱晦，但傷害很大。當你完全沒有產品概念、把「做什麼功能」也丟給外包決定，會發生什麼事？外包會傾向做「對他開發最方便、利潤最高」的設計，而不是「對你的客戶最有用」的設計。

舉個真實案子：一家做美妝電商的客戶，前一家外包幫他設計了一套「會員等級積分系統」，理由是「這樣回購率會提高」。系統做了 3 個月、花了 60 萬。上線之後客戶完全沒人用——因為這個品牌的客單價是 800 元、復購週期是 6 個月，會員等級系統需要每月消費才有意義。外包其實心知肚明，真正的理由是「做這個模組好賺、技術門檻低、可以當 portfolio」。屁股決定腦袋。

解法是「產品設計與開發角色分開」。你可以：

• 自己當產品經理：如果你對產品有強烈的方向感，把規格、優先序、使用者旅程自己定，外包只負責執行。

• 找獨立 UX / 產品顧問：找一個跟外包公司無利害關係的第三方，幫你做使用者研究、線框圖、優先序排定。費用大概是開發費的 10-15%，但能省下 30%-50% 的功能浪費。

• 選擇有產品思維的外包：這種比較少，但確實存在——他們會願意質疑你的需求、提出替代方案、不會你說什麼就做什麼。識別這種團隊最快的方法：看他們第一次會議時問你的問題深不深。

上線就結案，沒寫維運條款

這是壓軸雷，也是最容易被忽略的一個。合約簽的時候大家都聚焦「開發完成」這個 milestone——驗收、付尾款、合約結束。然後呢？三個月後出 bug、半年後想加功能、一年後想升級主機，原本的接案者已經不知道飛去哪了。

經濟部中小企業處在 台灣中小企業數位轉型現況調查 裡有提到，企業導入軟體系統後 3 年內的「持續維運成本」通常是初始開發費的 100%-150%——也就是你花 100 萬做的系統，3 年內還要再花 100-150 萬維運。如果合約沒寫維運條款，這筆錢會被外包公司自由報價，你只能任宰。

維運合約必須寫進去的條款有哪些？我們整理了一張對照表：

上面這 5 條缺一不可，實務上爭議最大的是「Bug 修復責任期」——什麼算「程式錯誤」、什麼算「新需求」？建議寫成「修復凡屬於『與規格書描述不符之行為』者，於 6 個月內免費」，把規格書當作仲裁標準，避免事後吵架。

找外包前的 7 點 checklist（簽約前最後一道防線）

上面 9 個雷講完了，這裡給你一份濃縮版的「簽約前 checklist」。每一項都是上面 9 個雷的反向操作——簽約前每一條都打勾，至少能擋掉 80% 的災難。

這份 checklist 可以直接印出來、簽約前對著合約一條條打勾。如果有任何一條外包不肯加進合約、或解釋得很模糊——那就是訊號。我們建議的做法是：寧可花一週重新評估、找下一家，也不要僥倖簽下去。簽約之前你還有選擇，簽下去之後你就只有被綁架的份。

進階技巧：在第一次面試時故意丟一個「不該答應的需求」——例如「3 個月內做出 Uber + Airbnb + Instagram」。好的外包會直接說「這個時程不可能、我們先聊優先序」；壞的外包會說「沒問題」並報你一個漂亮的價格，後面的故事你已經知道了。

把外包當「合夥關係」、不是當「供應商」

我們經手過好的外包案，老闆和外包之間的關係更像是「事業合夥人」——對方會主動提醒你哪些功能可能浪費、會在你想砸錢做沒人用的東西時直接擋你、會在系統上線後主動跟你聊下一階段該做什麼。這種關係能成立，靠的不是合約有多細——靠的是雙方從一開始就用「對等的合作」來看這件事。

把外包當成單純的「供應商」——你給錢、他交貨、合約結束——這種心態會吸引到的就是「便宜接、做完跑」的乙方。你想要對方為你的長期事業負責，自己就要先把外包當成 3 年以上的合作對象來挑、來談、來簽。價格的重要性永遠應該排在「對方有沒有產品 sense、會不會幫你想長遠、合約寫得夠不夠保護你」之後。

我們最常遇到的問題其實是這個：老闆同時跟 5 家報價，挑「最便宜的那一家」簽下去。回頭看上面 9 個雷你會發現，報價只是冰山一角，水面下藏的合約結構、付款風險、源碼歸屬、技術選型、PM 文化、維運條款——每一個都會讓「便宜」最後變成「貴 2-3 倍」。挑外包要從合約細節挑，不要只從報價挑。

找外包做產品真正的勝負點，從來都在花完這筆錢以後——你的事業是不是還能繼續往前走、產品是不是還能不斷迭代、團隊是不是還相信「找外包」這條路。9 個雷講完了，希望下一次你跟外包談合約時，能夠少踩幾個。

延伸閱讀：打造會賺錢軟體產品 7 篇系列

這篇是系列 #3，整個系列從「老闆的視角」出發，把找外包做軟體產品的每個階段拆給你看：

• #1 打造會賺錢軟體產品的完整路線圖（總覽）

• #2 軟體產品市場驗證實戰指南（先驗證再開發）

• #3 找外包做 APP / 軟體前必踩的 9 個雷（你正在看的這篇）

• #4 MVP 分階段付款驗收指南（怎麼付錢才安全）

• #5 APP 開發費用比較：低預算方案的真實成本（報價迷思破解）

• 如何選軟體開發公司？7 個評估標準 + 合約必看條款（評估外包公司的系統性指標）

如果你正在找外包、或正被前一家卡住

找外包做產品這件事，最大的成本其實是「踩雷之後修補的時間」，金錢反而是其次。一個專案被搞砸，不只是錢沒了，更是市場時機沒了、團隊士氣沒了、老闆對「找外包」這件事的信心也沒了。

我們做軟體開發外包這件事很久了，看過太多老闆抱著被前一家做壞的半成品來找我們。如果你正準備找外包做新產品、或正被前一家卡在某個進退兩難的處境，可以 預約一次免費 30 分鐘需求 / 合約檢視諮詢——把你手上的需求書、報價單、合約拿出來，我們陪你看一遍。我們不一定是接你案的最佳選擇，但至少讓你知道你現在簽的東西有沒有埋雷。

把外包當合夥關係，而非當供應商——這條心法送你，希望下一次你能直接做出對的產品，省下事後救援的力氣。