選開發廠商是一個資訊很少、代價很高的決定。簡報都做得漂亮，報價單又難以互相比較，真正的差異往往要到專案中後期才會浮現。這篇整理實際能預測合作品質的問題。
先確定你要買的是哪一種
同樣叫「找廠商做系統」，需求其實分三種，混在一起談就會比錯價：
| 你需要的 | 適合的對象 | 常見計價 |
|---|---|---|
| 先想清楚要不要做、怎麼做 | 技術顧問、兼任 CTO | 專案制或月費 |
| 把已經確定的東西做出來 | 開發團隊 | 固定價或里程碑 |
| 系統已上線，要有人持續顧 | 維運團隊 | 月費，依服務等級 |
只買中間那段，最容易出事：需求沒釐清就開工，上線後又沒人負責。
五個真正能預測結果的問題
1. 他們會不會反對你？
只照著需求做、從不提出質疑的廠商是風險。好的夥伴會在寫程式之前挑戰你的假設，指出哪些功能可以不做。第一次會議如果對方全程點頭，這通常不是服務好，而是他們不打算為結果負責。
2. 程式碼和資料歸誰？
你應該擁有完整的原始碼、資料庫與雲端帳號，而且能隨時自己接手。直接問：合約結束後我能拿到什麼？如果答案含糊，或程式碼只放在對方的儲存庫，就要小心。
3. 上線後誰負責？
問清楚維運的範圍、回應時間與費用。多數廠商在交付當天責任就結束，但真正的成本從那時才開始。沒有維運方案的報價，其實不算完整報價。
4. 出錯的時候怎麼處理？
每個專案都會出錯。值得合作的廠商會告訴你他們搞砸過什麼、怎麼補救；只說「我們沒失敗過」的，要嘛經驗太少，要嘛不誠實。
5. 誰會實際做這個案子？
提案的人和寫程式的人是不是同一批？有多少工作會再外包出去？這一題的答案，決定了你之後溝通的成本。
怎麼看報價
三種常見結構，各有適用場景：
- 固定價：範圍明確時最安全，但改需求要走變更流程。適合範圍寫得清楚的專案。
- 按時計價：適合探索期或需求會變動的專案，但要求對方提供工時明細與上限。
- 月費團隊：適合長期、持續調整的產品。要確認每月包含的人力與工作內容。
比價時要比同一份範圍。一份報價含測試、文件與三個月保固，另一份只含開發，金額當然不同。可以請對方把不含的項目也列出來，這比總價更能看出誠意。
合約要寫清楚的五件事
- 智慧財產權歸屬：程式碼、設計檔、資料，包含在對方既有元件上的授權方式。
- 驗收標準：怎樣算完成，由誰認定，多久內要回覆。
- 付款節點：跟里程碑綁在一起，不要一次付清。
- 維運與保固：保固期多久、涵蓋什麼、之後的維運費怎麼算。
- 退出機制：終止合作時的交接內容，包含原始碼、文件與帳號移轉。
警訊
- 報價單只有總價，沒有項目拆解。
- 承諾的時程明顯短於同類專案，而且說不出為什麼做得到。
- 無法提供可查證的案例，也不願意提供推薦人。
- 用技術名詞回答商業問題，你問「這樣能省多少人力」，對方回答「我們用了最新的架構」。
- 不談維運，或把維運當成之後再說的事。
- 要求一次付清，或拒絕把程式碼放進你的儲存庫。
一份可以直接用的評估清單
跟每一家候選廠商問完之後，逐項打勾：
- 能說出他們認為這個專案最大的風險是什麼
- 提出過至少一項「這個可以不做」的建議
- 原始碼、資料與帳號都歸你
- 提案的人會參與實際開發
- 報價含測試、文件與保固，項目清楚
- 有維運方案，且費用先講清楚
- 能提供同類案子的做法說明，即使客戶名稱保密
- 願意先做小範圍試行再談全案
勾不滿六項的，價格再低也不建議合作。換廠商重做的成本，通常是原本報價的兩到三倍。
如果你已經踩到雷
原廠不回應、工程師離職、文件不見，都還有救。先做一次系統健檢：確認程式碼能不能接手、架構有沒有致命問題、資料是否完整，再決定維護、改善或重寫。多數系統不需要重寫，只需要有人真的負起責任。