「用套裝軟體最便宜」這句話，通常在導入第三個月就被推翻。不是套裝軟體不好，而是當你的作業流程開始為了配合軟體而扭曲，那些看不見的成本才是真正的支出：多請的窗口、對不起來的報表、每個月都要人工橋接的資料。
客製化系統不是比較高級的選擇，它只是誠實面對一件事——你的業態、流程、料號規則、對帳習慣，可能真的沒辦法塞進通用產品的資料模型裡。
什麼時候該考慮客製化
有幾個訊號值得警覺。第一，你的核心流程是公司的競爭力來源，例如某種特殊的排程、報價邏輯、或跨通路庫存分配規則。這種東西套裝軟體不會替你設計，因為它不是通則。第二，你已經在用 Excel、Line 群組、或人工核對來「補」現有系統的不足，而且這些補丁每個月都在長大。第三，你需要跟上下游、金流、物流、或內部舊系統做非標準的整合。
舉個例子，假設一家做工業耗材的貿易商，客戶下單時會混用型號、規格、替代品，還要根據不同客戶等級跑不同折扣邏輯——這種業態硬套通用電商後台，通常會演變成業務私下開 Excel 對單，系統只剩下開發票的功能。這時候客製化不是奢侈，是回頭把流程收回系統裡。
反過來說，如果需求就是標準的進銷存、標準的官網、標準的金流串接，套裝或 SaaS 幾乎一定比較划算。這點要先誠實。
需求釐清與規格書的地雷
真正讓客製化專案失敗的，很少是技術問題，多半是需求沒講清楚。我們的經驗法則是：如果一份需求文件裡只有名詞（「訂單管理」「會員系統」「後台」），沒有動詞和條件（「誰、在什麼情況下、做什麼、系統要如何回應、例外怎麼處理」），那份文件其實還沒開始寫。
釐清需求時，比較有效的問法不是「你要什麼功能」，而是：
- 現在這件事是誰在做？用什麼工具做？
- 做錯的時候會發生什麼事？誰負責收拾？
- 一個月會遇到幾次例外？例外的處理方式一致嗎？
- 這個資料，下一站是誰要用？他期待什麼格式？
這些問題會逼出真正的流程，而不是想像中的流程。
規格書則至少要涵蓋：角色與權限、主要流程的正常路徑與例外路徑、資料欄位定義與必填規則、與外部系統的介接點、以及驗收條件。驗收條件特別重要——「好用」不是驗收條件，「業務可以在三個步驟內完成報價並產出 PDF」才是。
常見地雷有三個。一是把「以後可能會用到」的功能都寫進第一版，結果 MVP 變成大怪獸，上線遙遙無期。二是規格只寫成功情境，沒寫錯誤處理，上線後每個 edge case 都變成緊急工單。三是沒有留下決策紀錄，半年後沒人記得為什麼某個欄位要設成那樣，改也不敢改。
我們的觀察
客製化系統真正的價值，不在於「什麼都可以改」，而在於逼你把公司的流程寫清楚。很多客戶在需求訪談結束後才發現，最大的收穫不是系統，是終於有一份文件說明公司到底怎麼運作。系統只是把這份理解固化下來。願意花時間在前期釐清的專案，後面幾乎都走得比較穩；反之，急著先動工的，最後都在補課。