2025年12月15日 · 8 min read

白天管大量預算，晚上卻買不到一串衛生紙：我的「幫買」開發筆記

白天，我是一個 產品經理。我習慣看著幾百萬的廣告曝光算在系統裡流動，精準投放到每一個 User 面前。

但晚上下班，走進全聯，我卻經常當機。老婆早上好像說要買蛋？還是那是昨天說的？打開 Line 群組，訊息早被洗掉了。

好吧，買了不吃虧。回家一看，冰箱裡放蛋的區域已經擺滿了都是蛋。「你幹嘛又買？我下午不是傳訊說我買了嗎？」

這就是典型的「資訊不同步」。在公司，發生類似的問題，會有檢討的流程。在家裡，老婆永遠都是對的 (?)

痛點：家庭裡的「資訊不對稱」

職業病發作，我決定把這個問題當成一個產品來解。我不想用現成的 To-do List，那太通用，沒有針對不同的店家，也不能分享給家人。

我決定自己寫一個 Web App。代號：「幫買（Bonbuy）」。

在規劃初期，我差點走歪。我一度想做「家庭庫存管理」，紀錄家裡剩幾顆蛋、幾包米。但很快就把我打醒：誰有那個美國時間去數冰箱剩幾顆蛋？

家庭不需要「倉儲管理」，家庭只需要「採購單」。

這不是 ERP 裡的 Inventory（庫存） 模組，這是 Request & Fulfillment（需求與交付）。

這改變了整個產品的規格：我不在乎家裡「有什麼」，我只在乎現在「缺什麼」，以及「誰去買」。

單手操作場景通常是：一手提籃子，一手滑手機。或者在捷運上突然想到缺東西。

這是核心。當我在全聯把「鮮奶」勾選掉的瞬間，老婆手機上的清單也必須同步消失。不能有延遲，不能有衝突。這解決了最根本的「重複購買」問題。

買完就消失。不要叫我輸入這瓶醬油多少錢，也不要叫我輸入有效期限。一旦買單，這條資料的任務就結束了。

開發過程很快，因為我砍掉了一堆「好像很酷」的功能。

做產品最難的不是加功能，是忍住不加功能。一旦加上輸入價格的步驟，操作時間就會從 3 秒變 10 秒。為了那個該死的「順便記帳」，我可能會犧牲掉核心體驗。

上線一週，效果很直接。不再有「誰要去買？」的猜測，也不再有「重複購買」的浪費。

這流程順滑得就像一個優化過的廣告競價系統。

老婆現在依然不會稱讚我的 Code 寫得多好。但昨晚她默默在清單加了一項「啤酒」。我看著手機跳出的通知，下班順路帶了一手回家。

那一刻我覺得，這 Side Project 沒白做。解決問題，永遠比炫耀技術重要。