買現成 SaaS 還是客製開發：判斷準則、隱藏成本與混合做法
同一個需求，有人推薦你去訂一套現成的雲端服務，也有人建議乾脆客製一套。兩邊講的都有道理，聽起來卻互相矛盾——這是因為這個問題本身沒有通用答案，它取決於你要解決的事情有多特殊，以及你打算跟它相處多久。
更麻煩的是，兩邊的成本都不會完整寫在檯面上。訂閱制看起來單純，真正的支出常常出現在人數成長、資料搬遷與功能受限之後；客製開發的投入看得見，卻容易忽略上線之後的長期照顧。
以下提供一套可以自己跑一遍的判斷順序，並把兩邊的隱藏成本攤開講。
先分清楚：你要解決的是哪一類問題
在比較方案之前，先把需求分成兩類，這一步做對，後面的選擇會清楚很多。
通用型需求：記帳、發薪、寄信、開會、檔案共用、客服對話。這些事情每家公司做法大同小異，早就有成熟產品，而且產品商投入的資源遠超過任何單一公司自己做的規模。
差異型需求：你的接單方式、你的報價邏輯、你的排程規則、你跟上下游交換資料的方式。這些是你跟同業不一樣的地方，也常常是你賺錢的原因。
原則很簡單：通用的用買的，差異的才考慮做。把資源花在讓自己更像別人的地方，是最常見的浪費；反過來，為了記帳系統多一個欄位就自己開發一套會計軟體，同樣不划算。
判斷卡住的時候，可以問一個問題：如果我改成跟大家一樣的做法，客人或營收會受影響嗎？答案是不會，那就買現成的。
先講清楚本篇的範圍：這裡談的是通則。內容管理、預約排程、會員資料、零售 POS、電商這些領域，「買還是做」卡住的地方各不相同，領域專屬的取捨請看文末對應的那幾篇；本篇只負責把共同的判斷順序講完。
買現成的真正優勢，不只是省開發
現成產品的價值常被簡化成「比較便宜、比較快」，實際上更關鍵的是這幾點。
它已經被很多人用壞過。成熟產品的邊角情況、例外流程與錯誤處理，是靠大量使用者長期回饋磨出來的。自己新做的系統即使功能清單一樣，這些細節都要重新踩一遍。成熟度不必用感覺判斷，有兩個當場就能查的訊號：更新紀錄與服務狀態頁是否公開（願意公開故障與修正的產品，通常也願意面對問題），以及說明文件有沒有寫到例外流程——只寫「怎麼順利完成」的文件，代表例外多半還沒被處理過。
持續有人在改進它。安全性修補、法規調整、與其他工具的整合，這些工作在訂閱制裡由產品商負責，你不必編列人力。
決定可以撤回。用不順可以換，雖然有搬遷成本，但至少不是一次性的沉沒投入。
代價也很清楚：你必須遷就它的流程。多數產品為了服務最大公約數，會把做法標準化，你想要的例外它不一定支援，而且你無法決定它的發展方向。
另外，「買」不只有一種買法。訂閱一套已經做好的產品是一種；租一個平台、自己把應用拼出來（低程式碼與無程式碼）是另一種。後者彈性大得多，但鎖定風險與治理負擔也完全不同，細節可以看低程式碼與無程式碼平台適合你嗎。本篇的判斷順序兩種都適用。
客製開發真正買到的是什麼
客製的價值同樣不在「功能比較多」，而在下面三件事。
流程完全照你的方式走。不需要為了配合工具改變作業習慣，也不需要用一堆手動步驟去補產品做不到的地方。對於流程本身就是競爭力的公司，這一點決定成敗。
資料與系統的掌控權。資料存在哪、誰能取用、要怎麼跟其他系統交換，全部由你決定。要做深度整合或特殊報表時，不會被平台的限制擋住。
可以持續長出來。客製系統的架構是為了你的業務設計的，之後要加功能是延伸，不是繞路。相對地，在現成工具上硬加需求，常常會累積成難以維護的變通做法，也就是技術債是什麼講的那種狀況。
代價是責任全部回到你身上：功能要自己想清楚、品質要自己驗、上線後要自己照顧。
那些不會寫在方案頁上的成本
兩邊都有隱藏成本，而且性質不同。先看訂閱制這一側。
- 隨規模成長的支出：多數產品依使用人數、資料量或交易筆數計價，公司成長時支出跟著上升，而且通常不是線性的。
- 功能分級的門檻：真正需要的那個功能常在較高的方案裡，為了一個功能被迫整體升級的情況很常見。
- 整合與客製設定的人力：把它接進既有流程、設定權限、匯入資料、教會同事使用，這些都是實際投入的時間。
- 變通做法的長期代價：產品做不到的部分往往靠人工補，這些手動步驟會變成永久的例行工作。
- 離開的成本：資料能不能完整匯出、格式好不好用、歷史紀錄留不留得住，這在導入時幾乎沒人問，要走的時候才發現麻煩。
客製這一側的隱藏成本則集中在上線之後。
- 維護與更新：相依的套件與環境會持續變動，不處理就會累積成風險。
- 需求釐清的投入：這是業主端要花的時間，而且無法外包，需求沒寫清楚的後果可以參考軟體需求怎麼寫。
- 知識集中的風險：只有少數人懂這套系統怎麼運作，人員異動時會出問題，文件與交付物要在合約裡講清楚。
把這兩份清單放在一起看，會發現重點不是誰比較省，而是你想把持續投入放在哪裡：付給產品商，或是投入在自己的系統上。
一個可以自己跑的判斷順序
依序回答這五個問題，通常就會得到清楚的方向。
- 這個需求是通用的還是差異的？ 差異型才進入下一題，通用型直接找現成產品。
- 市面上真的沒有嗎？ 先實際試用兩到三套，不要只看介紹頁。很多「找不到合用的」其實是還沒找。
- 不合用的地方佔多少比重？ 如果只有一小部分不合，通常靠流程微調或串接就能解決；大半都不合，才值得考慮自己做。
- 這個流程在可預見的未來會穩定嗎？ 還在頻繁調整就先別寫死，用現成工具跑到穩定再說。
- 有沒有能力照顧它？ 客製系統需要長期維護，如果組織內部沒有窗口也沒有維護安排，做出來的東西會慢慢壞掉。
五題都指向客製，那就客製；任何一題卡住，先用現成的。先買再做，通常比先做再換省力，因為用過現成工具之後，你對自己真正需要什麼會清楚得多。
混合做法：多數公司最後的樣子
實務上很少有公司是純粹的一邊。比較常見的成熟架構是這樣：
周邊全部用現成的。人事、會計、通訊、檔案、客服，這些沒有必要自己做。
核心流程客製。真正決定服務品質與效率的那一段自己掌握，例如接單到出貨的流程、獨特的排程邏輯、跨部門的簽核規則。
中間靠介面串起來。讓資料在兩邊流動，避免同一筆資料要在不同系統重複輸入。這一層的設計與風險可以參考系統整合與 API 串接開發指南。
設想一家做客製化禮品的公司：他們的會計、出貨與客服都用市面上的服務，唯獨把「客戶提供圖檔到生產排程」這一段做成自己的系統，因為那是他們比同業快的原因。其餘環節照抄市場標準，反而讓他們有餘力把資源集中在真正有差別的地方。
混合架構的關鍵是先定義誰是資料的主人。同一筆客戶資料如果兩個系統都能改，遲早會對不起來。哪一邊是權威來源、另一邊多久同步一次、衝突時以誰為準，這些要在串接之前就講定。
什麼訊號代表該從現成方案轉出去
不必急著轉，但下列訊號出現兩項以上時，就值得認真評估。
- 例行的人工補丁愈來愈多。每天有人固定花時間把資料從一個系統搬到另一個、或用試算表補系統做不到的計算。
- 為了配合工具而改變作業方式，而且改得不合理。不是流程被優化，是被迫將就。
- 想做的事被平台擋住，而且不是暫時的。你需要的整合或規則，產品商明確表示不在規劃內。
- 支出成長的速度超過業務成長。人數或用量帶動的費用愈來愈不成比例。
- 重要資料取不出來。要做分析或搬遷時才發現匯出功能殘缺。
- 不同工具之間的縫隙開始出事。訂單漏掉、庫存對不上、客服看不到完整紀錄。
這些訊號的共同點是：問題從「功能不足」變成「結構不合」。功能不足可以等產品更新或找外掛補，結構不合則會持續產生成本，而且不會自己好。
轉換的時候要注意什麼
決定要轉之後，做法比決定本身更影響成敗。
分階段，不要一次全換。先把最痛的那一段抽出來做，讓新舊系統並行一段時間。全面切換的風險在於一旦出問題，業務會直接停擺。
先確認資料能不能帶走。在動工之前實際做一次匯出，檢查欄位是否完整、歷史紀錄是否保留、格式是否可用。這件事要親自驗，不能只看文件說支援。
保留回頭的路。切換初期舊系統先不要停用，並且明確訂出「在什麼情況下退回舊流程」。
把導入當成專案的一部分。教育訓練、雙軌期間的分工、異常的回報管道，這些跟開發一樣重要。舊系統要修、要換還是要重寫，舊系統現代化指南有更完整的判斷方式。
驗收綁在真實流程上。不要只驗功能有沒有做出來，要用真實資料跑完一輪完整的業務流程，這也是軟體驗收怎麼做強調的重點。
買或做從來不是立場問題，而是配置問題：把通用的交給市場，把有差別的留在自己手上，中間用可維護的方式接起來。真正該避免的，是在還不清楚自己需要什麼的時候就急著做一套，或是明明已經被工具卡住好幾年卻一直忍著。
這個判斷很難純粹在紙上完成，通常要把現有流程與工具實際盤過一遍，才看得出哪一段是真的不合、哪一段只是還沒設定好。需要有人陪著盤，和 NETVANA 聊聊你的專案。我們的軟體服務沒有固定套餐，一律先了解需求與現況再報價；軟體服務介紹寫明每一項服務的內容與交付物。
延伸閱讀：本篇談的是通則，領域專屬的取捨請看對應的那一篇——要挑網站的內容管理工具，看CMS 內容管理系統怎麼選；要處理預約與排程，看預約系統開發指南；要處理會員與客戶資料，看會員系統與 CRM 開發指南。另外，第一版該做到哪裡才不會做過頭，看MVP 最小可行產品開發指南；正在挑選開發夥伴，看如何挑選軟體開發公司。
