客製化開發合約先看這五條：報價單上看不出交付品質
同一份需求文件發出去，回來的報價能差四成。多數人的第一反應是砍價，或者懷疑對方虛高。真正的差別常常藏在合約條款裡：原始碼給到什麼程度、逾期怎麼算、維護從哪天起算、變更誰定價、資料落在誰的伺服器上。這五條每一條都能讓報價上下浮動，也每一條都能在專案後半段變成扯皮。
報價低的那家未必故意埋雷。它只是把不確定的部分留白，等交付時再談。甲方拿到的是一個「先上線再說」的價格，後面每一步都要重新議價。
一、原始碼：不是給你程式碼，是給你一份能接著跑的程式碼
「原始碼交付」這句話出現頻率很高，含義差別極大。三件事不清，後續接手成本翻倍。
交付形態。合格的做法是交付完整 Git 倉庫，含提交歷史、分支記錄、建置腳本、相依鎖檔、環境變數範例、資料庫移轉腳本、部署說明。不合格的做法是給一個壓縮包，能執行的目錄，但沒有版本歷史、沒有 CI 設定，相依靠全域安裝，鎖檔缺失。
這兩種形態在「能不能改」上差距很大。有鎖檔的倉庫，任何人 clone 下來相依版本一致；沒有鎖檔，半年後重裝環境，小版本漂移就可能編譯失敗。這不是理論風險，是接手專案最常見的第一道坎。
可重現的部署。要的東西很具體：Dockerfile 或部署腳本、閘道與 Nginx 設定、排程任務清單、環境變數的名稱與用途、第三方服務的回呼位址設定。判定標準只有一條——讓乙方在一台乾淨的空伺服器上，只用交付物把系統跑起來，能不能在半天內完成。跑不起來，就是交付物不全。
第三方資產的註冊主體。網域、雲端主機、物件儲存、簡訊通道、支付商戶號、郵件服務、CDN、SSL 憑證，如果註冊在乙方帳號下，原始碼再完整也等於鑰匙被人扣著。合約裡應當附一張資產清單，逐項寫明服務名、註冊主體、管理員帳號、續費日期、過戶時間點。
智慧財產權條款還要補一句邊界：著作權歸甲方，乙方保留其在簽約前已有的通用框架與元件，需列明清單。不寫這句，甲方以為買斷了全部權利；寫得太死，乙方不願意把基礎庫交出來。列清單是最省事的處理方式。
二、逾期賠付：看四處，不看「有沒有寫」
合約裡出現「逾期按日賠付」並不罕見，真正決定這條有沒有牙齒的是四個細節。
起算點。工期從哪天開始數？從合約簽訂日算最常見，也最不公平——付款、訪談、等甲方素材、等第三方介面審批，這些時間都吃工期。合理寫法是自需求確認書雙方簽字之日起算，同時把甲方側配合義務的時限寫進去：素材 5 個工作日內提供、回饋 3 個工作日內給出，逾期則工期順延。
按日費率。寫百分比還是固定金額都行，關鍵是掛住合約額。費率太低，拖一個月賠的錢不夠一個月的房租，等於沒有約束。
上限。賠付上限最容易被忽略。寫成「不超過合約總額的 10%」，看著合理，但對一個延誤導致錯過銷售旺季的專案，10% 覆蓋不了損失。
解除權。這一項比日賠付更有威懾力：延誤超過約定天數（比如 30 天），甲方有權解除合約並要求退還已付款項。有解除權，乙方才會認真評估自己排不排得過來。
《民法典》第 585 條的規則是，約定違約金過分高於實際損失，法院可以根據當事人請求予以減少。所以把違約金寫成天文數字沒有意義，要的是雙方都認、且真能扣得下來的區間。
【待核實：違約金上限在各地司法實踐中的具體認定尺度，影響條款上限怎麼設】
三、維護期：起算點和範圍，比長度重要
「免費維護 3 個月」單獨看是沒有意義的，它沒說從哪天起算，也沒說維護什麼。
起算點有三種常見寫法：合約簽訂日、系統上線日、驗收簽字日。從簽訂日算是最常見的手法，開發週期兩個月的專案，實際免費維護只剩一個月。從上線日算聽起來好一點，但上線時間可以被乙方操控，把沒做完的系統推上線，維護期就開始跑了。驗收簽字日最清楚：驗收單簽完當天起算，雙方都有明確錨點。
維護範圍要分四類寫：缺陷修復（交付物自身的 bug）、環境維護（伺服器、憑證、相依升級、被攻擊後的復原）、適配變更（第三方介面改版、平台規則調整）、新需求。前兩類通常含在免費維護裡，第三類看約定，第四類一律走變更流程。這四類不分開寫，「維護」就變成各說各話的詞。
回應時限要分級。業務完全阻斷、主要流程不可用、個別功能異常，處理優先級完全不同。7×24 小時回應指受理工單的時間，不是修復完成的時間，這兩個概念混在一起最容易起爭議。可執行的寫法是分級定義加兩組時限：受理時限、復原時限，並寫明計時起點是工單在系統裡提交的時間，不是雙方口頭溝通的時間。
四、變更：沒有凍結點，工期就是活的
變更條款寫不好，前面三條全部失效。專案拖期十有八九不是開發慢，是需求一直在動。
凍結點要設兩個。原型或互動稿確認時簽字，介面結構凍結；UAT 開始時功能範圍凍結，之後只修 bug 不加功能。這兩個點不設，開發永遠在追一個移動的目標，工期估算失效，賠付條款也就無從判定。
計價方式提前定。按人天最簡單，前提是人天單價寫進合約、變更單上寫清人天數和工作內容。按功能點更精細但容易吵，適合需求顆粒度已經清楚的二期專案。
變更單要有固定模板：變更內容、影響模組、增加工時、工期影響、是否額外費用、雙方簽字。口頭答應、聊天裡說「順手加一下」，最後都會變成爭議。
再加一條閾值：變更累計金額超過合約額一定比例（常見 15%~20%）時，觸發一次完整的範圍複核，重新評估剩餘工期與總價。這條能擋住「小改動累積成大專案」的局面，也能讓甲方在預算上早點看出趨勢。
五、資料安全：歸屬、權限、退出
這一條在中小企業合約裡經常整段缺席，出問題時才發現沒有依據。
歸屬要一句話寫死：業務資料、日誌與衍生資料、帳號資產歸甲方所有，乙方僅在被授權範圍內處理。注意「衍生資料」——埋點、報表、日誌容易被預設成乙方的東西。
權限分層。生產資料庫存取應當是審批制：誰能看、看多久、看完留痕。涉及個人資訊的部分做脫敏，測試環境不允許直接使用生產資料。這條不寫，測試庫裡躺著真實手機號是常態。
退出機制比防護措施更容易漏。合約結束時四項：帳號權限回收清單、金鑰與憑證交接、資料匯出格式與時限、乙方側副本銷毀的書面確認。這四項不寫，專案結束半年後在對方伺服器上還能找到你的資料，是很常見的情況。
六、把兩份報價放一起比
拿到兩份報價，先別比總價，把上面五條攤開對照。
| 條款 | 含糊寫法 | 可執行寫法 | 風險落在誰身上 |
|---|---|---|---|
| 原始碼 | 交付原始碼 | 全量倉庫含提交歷史、建置腳本、資產清單過戶 | 甲方，接手成本不可預估 |
| 逾期 | 逾期賠付 | 需求確認日起算，按日費率，上限加解除權 | 甲方，拖期無法停損 |
| 維護 | 免費維護 3 個月 | 驗收簽字日起算，四類範圍分開，受理與復原時限分開 | 雙方，扯皮成本高 |
| 變更 | 需求變更另行協商 | 人天單價入合約、變更單模板、兩個凍結點、累計閾值複核 | 甲方，預算失控 |
| 資料 | 保障資料安全 | 歸屬、權限分層、脫敏、退出銷毀 | 甲方，合規風險 |
條款寫細的那家報價通常高一些。差的那部分錢，本質是把風險買斷。條款乾淨的報價往往包含更長的需求梳理期和更完整的測試與文件工作，這兩塊最容易被省，也最容易在交付階段暴露。
還有一個常被忽略的對照項：簽約主體。報價方與實際開發方是不是同一個主體，有沒有轉包。轉包在客製專案裡不算少見，條款寫得再細，實際執行的是另一批人的話，追責鏈會變長。合約裡加一句「未經甲方書面同意不得轉包分包」，成本很低。
七、一句話的判斷方法
看一家客製團隊靠不靠譜，不用聽它講流程，直接要它把這五條寫成條款發過來。願意逐條落到紙面上的，交付管理一般不會太差；每條都回「到時候再說」的，專案後半程大概率要花雙倍精力去救。
萬楓科技把這五條作為合約附件，原始碼全部交付、逾期賠付、3 個月免費維護寫在條款裡而不是宣傳頁上。這類承諾寫進合約才有約束力，留在頁面上只是話術。
條款之外有個沒解決的問題：賠付再嚴，也補不回錯過旺季的損失。所以選團隊還得看它手上同時有幾個專案，上一個專案的驗收單願不願意給你看。