軟體外包合約怎麼談：避免報價翻倍的 5 個條款

預算做到一半翻倍不是意外，是結構性問題。模糊需求 + 驗收不清 + 追加沒上限 = 付了錢拿到的是帳單不是產品。本文拆解合約裡 5 個真正重要的條款，給沒經驗的老闆看得懂的版本。

TL;DR

軟體案件超支率業界約 45-60%（Standish Group Chaos Report, 2020-2024）— 多數不是工程問題，是合約結構問題
報價翻倍的源頭永遠是需求模糊。寫不清楚的範圍，做到一半雙方想的不一樣 → 每一次「對齊」都是追加工時
5 個條款必須寫進合約：功能範圍、驗收標準、追加工時計算、付款里程碑、保固與離場
台灣合約另加注意：統一發票、統一編號、合約印花稅、爭議條款寫台灣法院（不要寫香港 / 新加坡仲裁）
BotsUP 提供正式合約範本 — 透過矽基崛起有限公司簽約，可開立統一發票

先講結論：5 個條款的核心

#	條款	壞例子	好例子
1	功能範圍	「開發一個電商 App」	3 個角色 × 每角色 X 個功能，列 flow
2	驗收標準	「雙方確認即完成」	具體 pass / fail test cases
3	追加工時	無	原範圍外功能 NT$X/h，超過 Y% 需重新合約
4	付款里程碑	「完成後付款」	簽約 30% / 階段驗收 40% / 上線 30%
5	保固與離場	無	交付後 30 天保固 + 原始碼交付 + 帳號權限交接

下面一個一個拆。

條款 1：功能範圍（Scope）— 追加爭議的源頭

模糊需求 = 合約漏洞。所有後續追加爭議的源頭幾乎都在這裡。

壞例子（實際看過的報價單原文）

「開發一個電商 App，包含商品展示、購物車、結帳、會員系統、後台管理。報價 NT$500,000。」

這段話每個名詞都是陷阱：

「商品展示」— 有多少商品？有 SKU 分類嗎？有篩選嗎？
「購物車」— 支援多幣別？優惠券？運費計算？
「結帳」— 哪家金流（綠界 / 藍新 / Stripe）？支援信用卡 / ATM / 超商？
「會員系統」— 有分級？VIP？積點？
「後台管理」— admin 能做什麼？商品上架？訂單管理？財報？

每個未定義的細節，做到一半都會變成「這不在原範圍」。

好例子（BotsUP 的實際合約範本）

範圍會分三層：

① 使用者角色

訪客：瀏覽商品、註冊
會員：購物、歷史訂單、個人資料
Admin：商品 CRUD、訂單管理、基本財報

② 每個角色的功能 flow 訪客購物流程：進入首頁 → 瀏覽商品（列表 / 分類 / 搜尋）→ 商品詳情 → 加入購物車 → 結帳（含金流：綠界信用卡 + ATM） → 訂單確認

③ 明確標示「本次交付」vs「未來擴充」

✅ 本次：基礎商品、購物車、綠界金流
❌ 未來：多幣別、優惠券、VIP 分級、訂閱制

這種寫法對雙方都有保護。開發方知道做到哪裡結束，甲方知道付了 50 萬買到什麼。

我的實戰建議

如果報價單沒有這三層結構，直接要求對方補。不補就換一家。這不是刁難，是保護你自己 200 萬的預算。

條款 2：驗收標準（Acceptance Criteria）

為什麼這條最多人踩

多數合約裡寫「雙方確認即為完成」 — 這等於沒寫。實際爭議永遠在這裡發生：

開發方：我覺得完成了，bug 都是新需求。甲方：我覺得還沒完，這些 bug 讓我不能驗收。

沒有具體驗收標準，兩邊都對。

好合約應該寫

① 每個功能的 test case

不是「購物車功能」— 而是「使用者 A 加 3 個商品到購物車，修改其中 1 個數量，結帳後顯示正確總金額含運費」
至少每個主要 flow 要有 3-5 個 test case

② 性能閾值

App 啟動時間 < 3 秒
關鍵 API 回應 < 500ms
支援 100 concurrent users 不當機

③ Bug 嚴重度分級

Blocker：無法上架或使用核心功能 → 不驗收
Major：特定場景失敗 → 開發方需在 N 工作日修復
Minor：視覺瑕疵 / 邊緣案例 → 列入 backlog，不影響驗收

④ 驗收時限

甲方收到交付後有幾天（通常 7-14 天）內需提出驗收意見
未在期限內提意見視為驗收通過
防止無限期 QA 拖住付款

實戰經驗

水滴發票從 0 到 196 萬用戶的 3 年裡，我們寫的 test case 累積到幾千條。這些 case 變成一個真實的品質網 — 新 PR 進來前自動跑過一次，保證不破壞既有功能。驗收標準不只是保護合約，也是保護長期維運。

條款 3：追加工時（Change Order）

為什麼必須寫

預算翻倍 90% 發生在這裡。沒寫 change order 條款 = 你付的是開放式支票。

三種合法寫法

① 時費制（Time & Materials）

原範圍外的任何新需求按時計費（例：NT$2,500 / 工時）
每次追加要開 change order 文件，雙方簽字才生效
適合：需求還在探索、彈性高的客戶

② 套餐制（Fixed Change Packages）

預先定義幾種「小追加」（如增加一個畫面、多一個角色）的固定價格
超出套餐範圍回到時費制
適合：中型案件，甲乙方都想要可預測性

③ 階段門檻制（Phase Gates）

每個階段結束時重新檢視範圍，若變化 > 20%，走新合約流程
範圍變化 < 20% 包含在階段預算內（等於 buffer）
適合：大案、長期合作

警訊合約

看到這幾種寫法的都要警惕：

「追加工時按實際花費收費」 — 沒有單價。等於開放式支票
「追加需求協商處理」 — 沒有機制。爭議時沒有依據
「甲方同意所有必要追加費用」 — 開發方單方定義必要。荒謬條款

實戰：BotsUP 怎麼寫

我們用時費制 + 20% 門檻的組合：

原範圍外 < 20% 追加：算 NT$2,500 / h（透明單價），有 change order 簽字紀錄
20% 追加：走新合約流程

這讓我們在間歇健走 5 小時上架後的改版 / 水滴發票 3 年無數次迭代中，都沒發生過追加爭議。

條款 4：付款里程碑

為什麼這條保護甲方也保護乙方

一次付清對雙方都是高風險：

甲方預付 = 開發方沒交付動機
甲方尾付 = 開發方墊資金 3-6 個月會死

合理的分期

小案（< 30 萬）

簽約 50% / 交付 50%
適合 2-4 週的小項目

中案（30 – 150 萬） — 最常見

簽約 30% / 階段驗收 40% / 上線 30%
階段驗收可以再拆（3 階段則每階段 15-20%）

大案（150 萬+）

簽約 20% / 每階段驗收 15-20% × N / 上線 10% / 3 個月保固期後 10%
保留最後 10% 讓開發方有維運動機

警訊

「完成後一次付款」 — 開發方要墊資金，但不是代表更好，代表「可能自己也不確定」
「所有費用簽約時付清」 — 甲方拿不回來

條款 5：保固與離場（Warranty & Exit）

多數合約的死角。交付完開發方就失聯的案件，90% 是這條沒寫。

必須寫進合約

① 保固期

正式交付後 30 天為保固期
保固期內發現的 bug 免費修復（除非是新需求）
保固期結束後，進入月維運合約（另計）或個案計費

② 原始碼與資產交付

完整 Git repo 所有權轉移給甲方
雲端服務帳號（Firebase / AWS / 第三方 API key）轉移
密碼 / secrets 安全交接文件

③ 維運文件

部署文件（怎麼 build、怎麼 deploy）
環境變數清單
第三方服務依賴清單（含授權到期日）

④ 離場條款

如果乙方需要終止合作（公司關門、方向調整），需提前 30 天書面通知並協助交接
甲方可隨時終止合約，按已完成里程碑結算

實戰：為什麼這條最重要

我們接手維運服務接到的案子，90% 是因為原開發方沒留這幾樣：

沒有完整原始碼（只交付了最後版本的 build）
雲端帳號用原開發方的 Google 帳號（對方消失 = 系統下線）
沒文件（每次新人上手要重看一個月）
第三方 SDK 授權到期沒人知道

一紙合約寫完這條，可以省未來 50 萬以上的接手費。

台灣合約另加注意

如果你是台灣公司跟台灣軟體公司簽約：

① 發票

必須開立統一發票（二聯或三聯）
金額 = 合約金額 × 1.05（5% 營業稅）
預收款也要開發票（不能等交付才開）

② 統一編號

合約雙方都要寫公司全名 + 統編
不要用個人身份簽（沒有法人保護）

③ 印花稅

合約金額 > NT$10,000 要貼印花稅票（萬分之一，通常由乙方支付）
2026 年電子簽名如 JoinPack / CloudSign 可免貼印花稅

④ 爭議條款

寫「管轄法院：台灣台北地方法院」
不要寫香港 / 新加坡仲裁 — 小案跑不了，等於沒救濟
不要寫英美法 — 除非國際案且金額超過 500 萬

常見問題（FAQ）

Q: 我沒有正式 RFC，開發方怎麼報價？

不可能準確報價，但可以報「範圍區間」。BotsUP 的 AI 導入健檢（NT$9,800）就是解這個問題 — 90 分鐘訪談後給你三個選項：極簡範圍 / 完整範圍 / 理想範圍，對應三個預算區間。有了這個，你再去談合約就會有具體基礎。

Q: 簽約到交付之間，我可以隨時改需求嗎？

可以但會算錢。這就是 change order 條款的意義。小幅改動（佈局調整、文案修改、顏色）通常免費，但功能層級的新增 / 刪減都要寫 change order。

Q: 開發方要求先簽 NDA 才報價正常嗎？

正常。我們自己也會主動要求簽 NDA，特別是涉及機敏商業邏輯的案件。但NDA 不是 work agreement — NDA 只保護保密，真正的工作合約還是要另簽。

Q: 合約裡的 IP（智慧財產權）歸誰？

台灣標準做法：合約價金結清後，IP 歸甲方。但乙方保留重用「通用元件」（如 Flutter UI kit、內部工具）的權利 — 這些不是客製的部分。這是合理的，畢竟乙方不可能每個案子從零重寫基礎元件。要明文寫清楚。

Q: 報價單和合約是同一份嗎？

不是。報價單 = 商業意向書，合約 = 法律文件。好的流程：

報價單（含範圍摘要、金額、時程）
需求書 / SOW（Statement of Work，詳細規格）
合約（含法律條款、付款、驗收、離場）

BotsUP 這三份都有範本，簽約時會一起提供。

Q: 如果做到一半開發方消失怎麼辦？

這是台灣外包最常見悲劇。預防勝於治療：

合約裡寫離場條款（30 天通知）
付款分期，不要預付超過 50%
堅持階段性交付原始碼到你的 repo，不要等最後一次交付

如果真的發生了，我們接手維運有做過 App Store 下架危機 24 小時重新上架的案例，但成本不便宜（因為要重建原廠失聯的所有文件和權限）。

參考資料

Standish Group Chaos Report 2020-2024 — 軟體案件成功 / 失敗統計
台灣智慧財產權法 — 軟體著作權 — 著作權與 IP 基礎
公司法第 369 條 — 合約效力
電子簽章法 — 2022 後電子簽合約法律效力

BotsUP 是新型態軟體顧問公司。需要合約範本或想先看看我們怎麼談？30 分鐘需求診斷 — 我們透過矽基崛起有限公司簽約，開立統一發票、ISO 27001 對齊。

TL;DR

軟體案件超支率業界約 45-60%（Standish Group Chaos Report, 2020-2024）— 多數不是工程問題，是合約結構問題
報價翻倍的源頭永遠是需求模糊。寫不清楚的範圍，做到一半雙方想的不一樣 → 每一次「對齊」都是追加工時
5 個條款必須寫進合約：功能範圍、驗收標準、追加工時計算、付款里程碑、保固與離場
台灣合約另加注意：統一發票、統一編號、合約印花稅、爭議條款寫台灣法院（不要寫香港 / 新加坡仲裁）
BotsUP 提供正式合約範本 — 透過矽基崛起有限公司簽約，可開立統一發票

先講結論：5 個條款的核心

#	條款	壞例子	好例子
1	功能範圍	「開發一個電商 App」	3 個角色 × 每角色 X 個功能，列 flow
2	驗收標準	「雙方確認即完成」	具體 pass / fail test cases
3	追加工時	無	原範圍外功能 NT$X/h，超過 Y% 需重新合約
4	付款里程碑	「完成後付款」	簽約 30% / 階段驗收 40% / 上線 30%
5	保固與離場	無	交付後 30 天保固 + 原始碼交付 + 帳號權限交接

下面一個一個拆。