軟體外包做完了、合約卻沒寫清楚：當驗收卡在「沒人能證明」的最後一關

做完了,為什麼還不算完?

國際軟體開發顧問公司 Saigon Technology 在 2026 年 3 月發布的合約管理指南中指出:「大多數外包糾紛來自不明確的假設,而不是惡意。」這句話,道出了台灣許多中小企業主心中的痛。

您找了外包團隊或自由工程師,說好做一套系統。幾個月過去,對方說「做完了」,但您打開來看,總覺得哪裡不對——功能不完整、資料庫結構看不懂、後台操作卡頓、手機版畫面跑版。您說這不能算完成,對方卻拿出合約說:「規格書上沒寫要做手機版。」

這時您才發現,當初簽的合約只有兩頁,「驗收標準」四個字底下,什麼都沒寫。

三個合約條款,決定您能不能安全收尾

軟體外包合約不只是法律文件,更是決定成本、風險與責任歸屬的框架。根據 Saigon Technology 實務經驗,有三個條款最常被忽略,卻最容易引發爭議:

1. 驗收標準(Acceptance Criteria)必須可測試、可拒收
合約裡如果只寫「功能正常運作」,就等於沒寫。實務上應該包含:

• 功能測試清單(哪些頁面、哪些按鈕、哪些流程)
• 效能基準(例如:首頁載入時間 < 2 秒)
• Bug 嚴重度分級標準(Critical / Major / Minor)
• 明確的拒收權:若未通過測試,業主可拒絕驗收並要求修正

如果合約寫的是「雙方協商驗收」或「以甲方滿意為準」,這在法律上幾乎不可執行,因為標準太模糊。

2. 交付物清單(Deliverables)要具體到檔案層級
程式碼交付不是「寄一個壓縮檔」就算數。合約應該明列:

• 完整原始碼(包含前後端、資料庫 schema)
• 部署文件與環境設定檔
• 第三方服務金鑰、API 憑證
• 操作手冊與技術文件
• 測試案例與測試報告

如果這些沒寫進合約,工程師可以主張「合約只要求交付程式碼,文件不在範圍內」,屆時您可能連系統怎麼部署都不知道。

3. 終止條款(Termination Clause)要包含「知識移交」義務
很多外包合約會寫終止條款,但只寫「提前 30 天通知」或「已完成部分按比例付款」。真正該寫的是:

• 終止後供應商必須提供的移交協助(時數、項目)
• 必須交付的文件與憑證清單
• 資料刪除或返還的時程與方式
• 是否提供過渡期技術支援(例如 30 天內可諮詢)

如果沒有這些,您可能會遇到「工程師已讀不回、系統出問題沒人能修」的窘境,而合約上找不到任何可以要求對方協助的依據。

合約寫得再好,也要有人看得懂系統

合約條款可以降低爭議風險,但它無法解決一個更根本的問題:如果交付的系統只有原開發者看得懂,您就永遠受制於人。

實務上,建議您在專案執行期間就要求:

• 每次交付都附上該階段的程式碼與文件,不要等到最後才一次給
• 定期檢視程式碼註解與架構文件,確保有人能接手
• 在正式驗收前,找第三方技術顧問做程式碼健診,確認可維護性

AI 上線專家的客戶中,有不少是拿到外包團隊交付的系統後,才發現「能跑,但不知道為什麼能跑;壞了,也不知道為什麼壞」。這時即使合約寫得再完整,您仍然得花一筆錢重新理解、重新整理,甚至部分重寫。

下一步:讓合約成為您的保護傘,而不是裝飾品

如果您正準備簽一份軟體外包合約,建議至少做到:

✓ 在簽約前,要求對方提供詳細的驗收標準清單
✓ 確認合約中有明確的交付物項目,不只是「程式碼」兩個字
✓ 加入知識移交與過渡支援條款,即使合作順利也要寫
✓ 保留階段性驗收與付款機制,不要一次付清再驗收

如果您已經拿到交付的系統,但不確定能不能安全上線,或擔心日後維護會卡關,免費 AI 程式碼健診可以幫您在驗收前,用技術角度檢視系統的可維護性、安全性與文件完整度,讓您在簽收前多一層保障。

──
AI 上線專家 ｜ 陪您把想上線的系統,安穩送到正式環境。不只看合約,更看程式碼能不能真正交接。