三個市場，三套系統
TSUKI 原本在台北、東京、新加坡各有一套電商後台，三組人維護。同一個商品改一次價要做三次，而且經常有一個忘了。這種結構不是誰決定的，它是逐年長出來的 —— 每次進一個新市場的時候，複製一份都是當下最快的選擇。
抽象化的誘惑
看到這種問題，第一個念頭一定是「做一個通用的規則引擎」。稅可以是一個運算式、金流可以是一組外掛、物流可以是一張對照表 —— 只要抽象得夠徹底，第四、第五、第十個市場都能塞進去。這個想法很吸引人，而且是錯的。
我們刻意不做通用
最後的引擎只支援這三個市場真的用得到的那幾種規則形狀：稅是內含或外加、金流是三種指定的整合、物流是重量級距或固定費率。就這些。一個能表達任何規則的引擎，最後會變成一個沒有型別、沒有除錯器、沒有人讀得懂的第二程式語言。
把「不支援什麼」寫下來
這是整件事最容易被跳過、也最重要的一步。文件裡有一節叫「這個引擎不能表達的規則」，列出七種情況，每一種都寫明遇到時該怎麼辦（答案通常是：改程式）。沒有這一節的話，兩年後會有人試圖用設定去表達第八種，然後失敗，然後怪這個設計。
第四個市場
2026 年初他們開了馬來西亞。規則形狀落在支援範圍內，沒有動到任何一行程式碼 —— 評估時間從六週變成兩天。這個賭注押對了，但要誠實：如果那個市場需要的是第八種規則，我們就要改程式，而那也還是比維護一個通用引擎便宜。
什麼時候該做通用
當你有二十個市場、而且每季新增一個的時候。通用化的成本是固定的，收益跟數量成正比，所以它在某個數量上會變划算。TSUKI 不在那個數量上，而多數公司也不在 —— 問題是幾乎每個團隊都覺得自己在。