如何選軟體開發公司？7 個評估標準 + 合約必看條款（2026 完整指南）

「上一家開發公司做到一半跑路了，我現在連原始碼都拿不到。」

這是今年初一位製造業老闆找到恆遠數位時說的第一句話。他的系統做了四個月、燒了 80 萬，換來的是一個沒辦法交接、沒辦法維護、也找不到人的半成品。

這種故事我聽過不只一次。台灣的軟體開發市場很複雜——接案公司規模參差，報價方式差很多，評估標準也不透明。企業主沒有技術背景，光憑官網跟業務說詞很難判斷，等到出問題才後悔已經來不及。

這不只是個別倒楣的故事。Harvard Business Review 的研究指出，超過 70% 的軟體開發專案最終未能達到預期目標——台灣中小企業市場的情況可能更嚴峻，因為資訊不對稱更為嚴重，能核實廠商能力的管道少之又少。

這篇文章想做的，是把我自己做軟體開發多年、跟幾十家企業主打過交道後，整理出來的選廠商邏輯——你不需要懂技術，但你需要知道問哪些問題、看哪些細節、合約要注意什麼。

為什麼選錯開發公司，損失遠比你想的大

很多企業主以為選錯不過就是「換一家重做」，但實際上損失的不只是錢。

1. 時間成本難以追回

一個中型系統從需求到上線平均要 3～6 個月。如果做到一半換廠商，新廠商還需要 2～4 週的熟悉期，再加上前期重新規劃，等於又多了 2～3 個月。競爭對手可能在這段時間已經跑在你前面了。

我見過一個電商案例，零售商因為誤踩低報價陷阱，主系統做了半年還沒上線，競爭對手同期已上完整後台並開始跑行銷活動。那半年的市場空窗，後來估計損失了至少 200 萬的潛在營收——這筆帳是算不進當初那張便宜的報價單裡的。

更現實的問題是：你的員工在等。如果這個系統是用來取代人工作業的，每延遲一個月，就多一個月的人力成本繼續燒。時間，真的換算得出錢。

2. 舊廠商留下的技術債

如果前一家廠商用了特殊架構、自訂框架、或是根本沒有文件，新廠商接手的成本會非常高。有些工程師寧可全部砍掉重練，因為改壞掉的程式碼比重寫更費時。

技術債最難被看見，因為你根本看不懂程式碼。但你可以問新廠商一個問題：「你們接手後，需要多久才能開始動工？」如果對方說要 3 個月以上的評估期，幾乎可以確定前一家廠商的架構是一塌糊塗的。

常見的技術債長相是這樣：沒有版本控制（Git）、沒有測試、資料庫設計沒有正規化、所有邏輯硬寫在前端、連環境設定都靠人工記憶傳承。這種系統，接手工程師不是在開發，是在考古。

3. 原始碼與資料的歸屬問題

許多合約沒有明確寫明「驗收後原始碼歸甲方所有」，一旦合作破裂，廠商可以主張著作權。更嚴重的情況是資料還放在廠商的伺服器上，等於整個業務被人質押著。

有一個更極端的案例：某餐廳系統被廠商「出租」而非「賣斷」，每個月付的不是維護費，而是「授權費」。老闆後來才發現合約裡寫的是「廠商保有系統所有權，授予甲方使用權」，等於每個月租他自己出錢委託開發的系統。

這種合約細節看起來像法律文字，但影響是實際的。選廠商時，在第一次開會就問清楚：「驗收後系統的智慧財產權歸誰？」如果對方說「依合約規定」，就請他直接念合約上的條文給你聽。

7 個評估軟體開發公司的標準（不需要懂技術）

以下這 7 個問題，你在洽談期間都可以直接問業務或專案經理。一家好的廠商不會被這些問題問倒，反而會很樂意解釋清楚。

標準一：有沒有可以看的真實案例？

不是網站上的截圖，而是可以實際使用的系統，或是可以聯絡的前客戶。好的廠商通常都有 2～3 個願意背書的案例。如果業務說「案例保密、不方便透露」，這不一定是謊言，但你至少應該要求看到產品的 demo 環境。

怎麼問才有效

「可以給我看幾個案例嗎？」這個問法太軟，廠商可以輕鬆拿一堆截圖打發你。更有效的問法是：「你們最近三個月完成了哪些案子？能讓我實際操作看看嗎？或是聯絡一位你們的前客戶問問看？」

如果廠商說客戶保密，那問另一個方向：「你們在 Github 上有公開的 Portfolio 嗎？」或「能分享技術 blog 或案例解說嗎？」，有紮實能力的工程師團隊通常有公開紀錄。

標準二：誰在做你的案子？外包還是自有工程師？

台灣不少接案公司是接了案再找外包工程師做，這本身不是問題，但會帶來溝通成本和品質不穩定。你可以問：「實際負責這個專案的工程師是公司正式員工嗎？」以及「我能不能直接跟工程師確認需求？」

辨別外包公司的信號

外包公司的特徵通常是：業務很流暢但工程師聯絡不上、需求討論永遠要「回去再確認」、中途工程師換人但沒有交代。你可以在簽約前要求「指定工程師條款」，白紙黑字寫明負責你案子的工程師名字或職位，中途更換需要你同意。

另一個檢驗方式是請廠商安排「技術小組說明會」，讓實際做系統的工程師來開一次會。如果到場的還是業務或 PM，而工程師「太忙」沒辦法參加，你就要想想這家公司的工程師到底在哪裡。

標準三：報價包含哪些？哪些是額外收費？

軟體開發的費用陷阱很多——初期報價漂亮，後來「需求變更」、「功能追加」、「雲端費用」一項一項追加上來。建議要求廠商提供「固定報價範圍」和「追加費用的計算方式」，白紙黑字。

報價拆解怎麼看

好的報價應該能拆解成：功能清單（每個功能的工時）、設計費用（有沒有含 UI 稿）、雲端費用（是一次性還是每月？誰付？）、維護費（保固後的月費）。如果報價是一個整數，像是「前端後台系統 30 萬元，其他再議」，這種報價等於沒有報價。

追加費用的陷阱通常藏在「需求變更」的定義裡。你說「我想讓搜尋功能可以篩選日期」，廠商說「這是新需求，追加費用」。怎麼避免？在合約裡要求附上「功能需求確認清單」，把每個功能描述細到雙方都沒有詮釋空間。

標準四：如何做需求確認？會有文件嗎？

一個負責任的廠商在開發前一定會產出「需求規格書（SRS）」或「功能設計文件」，雙方簽字確認後才開始。如果業務說「我們直接做，邊做邊調整」，這通常是後來吵架的起點。

需求規格書的品質是廠商工作態度的第一個指標。一份好的 SRS 應該包含：每個功能的詳細說明、使用者流程圖（User Flow）、資料欄位定義、邊界條件說明（例如：如果輸入空白怎麼處理）。文件越詳細，後來產生爭議的機率越低。

我遇過一個案例，客戶跟廠商各自對「購物車」有不同理解——客戶以為可以儲存常買清單，廠商做的是一次性結帳購物車。兩個版本都叫「購物車」，但相差了兩週工程量。如果需求文件細一點，這種誤解根本不會發生。

延伸閱讀：系統開發流程完整解析，從需求到上線一次看懂

標準五：測試與驗收流程是什麼？

開發完成不等於完成——好的廠商會有測試計畫（UAT 使用者驗收測試），讓你實際操作後確認沒問題才算驗收。如果對方說「做完就直接上線」，遇到 bug 你就只能看對方願不願意修。

UAT 怎麼進行才有效

使用者驗收測試（UAT）不是讓 IT 人員點一遍功能，而是讓實際會用這套系統的員工操作真實情境。例如：業務人員用測試帳號走一遍完整的報價流程，倉管人員試著建立出貨單。只有真實使用情境才能揪出「功能正常但體驗糟糕」的問題。

建議在合約裡要求 UAT 期間不少於 2 週，並且由廠商準備「測試腳本」——也就是告訴你該測哪些情境、怎麼測。如果廠商說「你覺得 OK 就 OK」，這不是彈性，是不負責。

標準六：上線後的維護責任是什麼？

「保固期」一般是 3～6 個月，這段時間出現的 bug 應該免費修復。但保固期後呢？費率是多少？回應時間是多久？這些都要在合約裡寫清楚，不能只靠口頭承諾。

維護合約要問的細節

「保固期到了，維護費怎麼算？」這個問題最好在第一次報價時就問清楚。常見的收費模式是月費制（固定費用包含一定的回應時間和工時），或是工時計費（每小時 X 元，按實際工時計算）。兩種都沒有絕對好壞，但你要知道：

• 月費制：預算好控制，但可能包含很多你用不到的服務
• 工時計費：靈活，但緊急問題時工時可能燒很快，費用難控制
• 建議要求：初次報告時間（bug 回報後多久有回應）和解決時間（多久完成修復）

還有一個常常被忽略的問題：如果廠商解散了怎麼辦？可以要求合約裡加入「代碼托管條款」，把原始碼放在第三方平台（如 GitHub），確保廠商出事後你還能取得。

標準七：原始碼和資料歸屬，白紙黑字有嗎？

這是最重要、也最常被忽略的一點。合約必須明確寫明：驗收完成後，原始碼、資料庫、所有相關文件的智慧財產權歸甲方（你）所有。同時確認資料不會放在廠商控制的伺服器上，或確保你有完整的遷移權利。

原始碼交付的細節清單

光說「原始碼歸你」還不夠，要確認以下這幾點都有在合約或交付清單裡：

• 前後端原始碼（不只是編譯後的檔案）
• 資料庫結構（Schema）和初始資料
• 環境設定檔（.env 範例，不含敏感資訊）
• 部署說明文件（怎麼把系統架起來）
• 第三方服務的帳號或 API Key 轉移
• 版本控制紀錄（Git history 保留）

有廠商會說「我們交付的是執行檔，原始碼是公司資產」——這就是拒絕交付的婉轉說法。遇到這種說法，就直接拒絕合作，沒有任何迴旋的必要。

2026 台灣軟體開發費用行情參考

以下是根據市場常見報價整理的區間參考，實際費用會因系統複雜度、整合介面數量、UI 精緻程度而有所不同。

碰到比以上行情低 40% 以上的報價，通常有幾種可能：功能大幅縮水、使用開源模板套殼、或是廠商故意壓低搶案子再追加費用。

想更深入了解費用怎麼算，可以參考：客製化系統開發完整指南：費用與流程全解析

合約一定要看的 6 個條款

很多企業主看到幾十頁合約就直接跳過細看，這是非常危險的。以下 6 個條款是最容易埋地雷的地方：

合約談判的實用策略

大多數企業主不敢改合約，覺得廠商提供的版本就是標準格式。但合約本來就是雙方協商的結果，不是廠商單方面發你的指令。以下是幾個可以直接提出的修改要求：

• 要求加入：「驗收後 14 天試用期，期間發現重大功能問題免費修復」
• 要求刪除：廠商保有系統使用權或授權任何第三方條款
• 要求修改：驗收定義改為「甲方書面確認通過測試後」而非「系統上線後」
• 要求加入：「廠商不得以任何原因中斷或限制甲方對系統的存取」

如果廠商說「這些條款是固定的、不能改」，那就換一家廠商。願意客製化合約的廠商，通常也願意在專案執行時認真對待你的需求。

恆遠數位的做法：為什麼我們這樣做

我在這裡說恆遠的做法不是為了打廣告——而是把這些標準實際對照到我們自己的流程上，讓你知道一家負責任的開發公司應該長什麼樣子。

固定價格 + 需求鎖定，不追加費用

我們在專案開始前會產出詳細的需求規格書（功能清單、介面設計稿、技術架構），雙方簽字確認後才開始計費。確認範圍內的功能不追加費用，要追加功能則單獨報價，透明清楚。

自有工程師團隊，不外包核心開發

所有核心系統開發都由恆遠的工程師負責，不轉包給第三方。你的專案經理跟負責工程師都是固定班底，有問題直接溝通，不用透過層層轉達。

原始碼 100% 歸客戶，部署在客戶帳號下

驗收後，所有原始碼、資料庫、設計稿都歸你。系統也部署在你自己的雲端帳號（AWS/GCP/Azure），恆遠沒有辦法「關掉」你的服務。

完整的文件與移交，讓你不被綁死

我們交付系統時一定附帶技術文件、部署說明、API 文件。就算未來你要換其他廠商接手維護，也能做到無痛移交。這不是在說我們不希望長期合作——而是希望你是因為喜歡我們才繼續合作，而不是因為沒辦法離開。

如果你想了解恆遠的客製化開發服務，可以直接看服務頁面，或是先閱讀：SaaS vs 客製化系統：中小企業怎麼選？

一個真實的對比：恆遠跟前廠商的差異

有一位零售業客戶在找到恆遠之前，曾跟另一家開發公司合作過。那家公司的問題不是惡意，而是流程太鬆散——需求用 LINE 聊天確認、沒有文件、測試是「工程師自己點一遍」。最後上線的系統有 11 個功能缺陷，花了四個多月才修完。

同一個客戶後來跟恆遠合作，從需求討論到上線花了三個月，中途沒有追加費用，驗收時工程師陪客戶一起跑 UAT 測試腳本，修了 3 個小問題後正式通過。差異不在技術高低，而在流程是否嚴謹。

特殊情況：如果你需要的是 ERP 或大型管理系統

ERP 系統的採購跟一般網站開發有些不同，除了上面說的 7 個標準，還有幾個額外要注意的地方：

ERP 系統的特殊性在於它牽涉到企業的核心流程——財務、倉儲、採購、生產都可能整合在一起。選錯廠商，後果不只是「系統不好用」，而是可能讓整個公司的作業流程停擺。

ERP 廠商的評估要特別注意：廠商有沒有做過同行業的案例？他們的系統支援未來的資料匯出嗎？如果公司三年後規模翻倍，這套系統還能用嗎？ERP 不像一般網站可以隨時重做，換一套 ERP 的代價可能是半年的導入期加上員工重新培訓。

深入了解可以參考：客製化 ERP 系統開發指南：中小企業完整評估框架

實用的選廠商決策流程：從詢價到簽約

從第一次接觸廠商到最終簽約，整個過程通常需要 2～4 週。很多人急著要快點開工，結果花在選廠商的時間太少，反而在開發過程中浪費更多時間處理問題。

以下是一個比較完整的決策流程，你可以把它當作自己的進度追蹤表：

每個階段都要做筆記。你在第一次開會時感覺「這家業務很積極很用心」，但到了需求確認時變得敷衍、文件品質差，這就是一個警訊——開會前的積極可能是業務策略，而非公司文化。

付款里程碑的談判技巧

廠商通常希望收比較多的預付款，原因是開發前需要墊付人力成本。你理解這個需求，但你的立場是：付款應該跟驗收里程碑對齊，而不是跟「時間點」對齊。

例如，廠商說「合約簽訂後三個月付第二期款項」——但如果進度落後，你可能在功能還沒出來之前就付了錢。更好的寫法是：「需求規格書雙方簽字確認後付第二期」，這樣廠商有動力把文件做好，你也不用擔心付了錢什麼都沒有。

常見問題 FAQ

Q1：找開發公司之前，我需要先把需求整理清楚嗎？

不需要整理得非常細，但至少要說得清楚你想解決什麼問題、主要使用者是誰、大概有哪些功能。你不需要懂技術，但「我想做一個管理庫存的系統」比「我想做一個系統」好很多。廠商在初步評估時需要這些資訊才能給出合理的報價範圍。

Q2：報價差很多怎麼辦？一個說 20 萬，一個說 80 萬？

價差這麼大，通常是需求理解不同造成的。最有效的方式是找一家廠商把需求規格書做出來，再拿這份文件去問其他廠商報價——這樣才是在比同一件事的價格。如果你找的廠商要收費才肯做需求文件，這通常是業界現象，你可以把這筆費用當成選廠商的測試成本。

Q3：可以找朋友介紹的工程師來做嗎？

可以，但要注意幾件事：個人工程師沒有法人，合約的法律效力比較弱；如果工程師突然失聯，你幾乎沒有追索途徑；維護期後的支援也取決於對方的意願。如果是規模較小的系統（15 萬以下），找朋友介紹有時候是 CP 值最高的方式。如果系統重要性高、金額較大，還是建議找有正式流程的公司。

Q4：開發到一半，我覺得廠商不對勁，可以中途換掉嗎？

可以，但要做好最壞打算。中途終止合約，通常會損失已付的款項，且原始碼的歸屬可能有爭議（依合約而定）。所以最好的策略是：在合約裡預先加入「甲方有權在任何階段終止合約，廠商需交付截至該日期已完成的程式碼與文件，按比例退還剩餘款項」條款。

Q5：海外開發公司報價更便宜，值得考慮嗎？

報價便宜有時候反映的是勞工成本差異，不一定代表品質差。但有幾個實際問題要考量：跨時區溝通的延遲（一來一回可能要一天）、語言和文化對需求理解的落差、以及台灣法律對境外廠商的約束力非常有限，一旦出問題追索困難。如果你選擇海外廠商，合約最好請法律顧問確認管轄權和爭議解決機制。

最後一句話

選軟體開發公司，不是比誰說得最好聽，而是比誰能把「承諾」變成「合約條款」。

如果一家廠商在你問這些問題時表現得不耐煩、含糊其詞、或是要你「先相信他們」，那就是最好的警訊。真正有實力的公司，不怕被問。

你現在有的每一個問題，都應該在簽約前得到清楚的答案。這篇文章給你的工具，就是幫你知道該問什麼。