消費品牌與電商
把一個手作品牌做成能持續收款與營運的產品系統
Halo.Project 從品牌、內容與網站，到會員、金流、互動工具和日常營運，已由團隊實際經營約兩年。
問題
手作飾品不是把商品照片放上網就完成。顧客需要理解材料與設計，團隊需要處理內容、會員、付款、訂單、客服與例外狀況。系統如果只追求功能清單，卻沒有接住實際出貨與溝通流程，很快就會成為另一個營運負擔。
限制
- 小型品牌需要控制開發與維護成本，不能把成熟的電商能力全部重做一次。
- 客製化商品含有選擇、溝通與人工製作流程，不完全符合標準購物車的資料模型。
- 金流、會員與營運資料必須穩定處理例外，而非只讓示範流程成功。
我們做了什麼
成熟交易交給電商平台
商品、結帳與既有商務能力沿用 EasyStore，讓團隊把開發時間留給真正有差異的體驗。
沒有選擇另一條路，因為 沒有從零重建完整購物車與訂單系統，因為稅務、付款與例外處理的維護成本不會帶來同等品牌差異。
差異化流程由自己的服務承接
互動工具、會員體驗與客製化需求放進自有 Web 與後端服務，保留產品演進的空間。
沒有選擇另一條路，因為 沒有把所有流程硬塞進電商平台外掛，因為資料與互動很快會受限於第三方欄位和發布節奏。
共用後端基礎，模組清楚分開
以 Go 後端共用驗證、資料存取與部署方式，同時讓會員、互動與商務整合維持各自的責任。
沒有選擇另一條路，因為 沒有一開始就拆成大量微服務，因為品牌現階段更需要可理解、可快速修正的營運系統。
用營運現場決定優先順序
客服問題、付款例外與製作流程會直接回到產品排程，先處理會阻斷交易或增加人工負擔的環節。
沒有選擇另一條路，因為 沒有只依照最吸睛的前台功能排開發順序，因為真正影響持續營運的問題常發生在購買之後。
成果
- 品牌已持續營運約兩年，網站、會員與金流串接實際服務日常交易。
- 既有電商能力與自有互動服務形成可持續調整的產品組合。
- 品牌內容、付款、客服與系統迭代形成同一個營運回饋循環。
技術
- Go
- Astro
- EasyStore
- Payment integrations
回頭看
如果重來，我們會更早把每一個功能對應到營運假設，並更快刪掉無法形成回饋的部分。自己經營品牌最直接的一課是：完成的功能沒有自動產生價值，只有被真實流程持續使用的功能才有。