這個開發者用2個自造工具，把"不知道做什么"變成日活用戶

2023年，Moise Lala 的 GitHub 貢獻圖綠得發亮，技術棧從 React 鋪到 Rust，但一個能用的產品都沒有。他卡在開發者最熟悉的困境里：會寫代碼，不知道寫什么。

他的轉變始于一個反常識決定——把自己當成第一個客戶。不是調研市場缺口，不是追風口，而是盯著自己每天真實遇到的問題動手。這個思路讓他兩年內做出兩個持續使用的工具，其中一個正在準備公開發布。

第一個工具：從"應該有用"到"真的在用"

Lala 的第一個作品是一款追蹤類應用。他沒有透露具體追蹤什么，但強調一個細節：他至今每天都在用。這比任何用戶留存數據都直接——開發者自己成了產品的長期日活。

這個項目的起點是他個人的真實需求。過去他嘗試過無數"看起來不錯"的創意，比如模仿熱門應用做競品，或者追逐當時的技術趨勢。那些項目寫到一半就失去動力，因為解決的是想象中的問題。追蹤應用不同，它誕生于他某天發現自己真的需要記錄某件事，而現有工具要么太復雜，要么功能錯位。

他計劃未來某個時間點公開發布，但明確說了"還沒到"。產品需要打磨，更需要他想清楚一件事：給自己用的東西和給公眾用的東西，中間隔著一整條鴻溝。界面可以湊合，但 onboarding（用戶引導流程）不能湊合；數據格式可以臨時，但遷移方案不能臨時。這些差距他還在繼續填補。

第二個工具：YouTube 理財課變成可交互系統

更可能先發布的，是他的預算管理系統。這個工具直接改變了他的財務狀況——不是通過自動化記賬那種魔法，而是讓他看清自己的規劃到底哪里在漏水。

靈感來自他?？吹膫€人理財 YouTube 頻道。那些視頻講了很多原則，比如"先支付自己""區分需要和想要"，但 Lala 發現缺了一層：從知道到做到的距離。他想要一個能每天打開、輸入數字、立刻看到反饋的系統，而不是看完視頻熱血沸騰，下周繼續亂花錢。

于是他動手造了一個。沒有接入銀行 API，不做自動同步，就是最簡單的收入支出錄入加可視化。這個"簡陋"的設計反而成了優勢——手動輸入強迫他面對每一筆消費，而自動化工具常常讓人對數字麻木。用了幾個月后，他定位到幾個具體的財務漏洞，比如某類訂閱服務的真實年化成本被嚴重低估。

這個工具目前仍是個人使用，但功能完整度和界面成熟度都高于追蹤應用。Lala 的發布策略也很克制：先解決自己的問題，再考慮別人的。

"為自己構建"的隱藏成本

Lala 在文章里埋了一個很少被討論的視角。開發者社區愛說"scratch your own itch"（撓自己的癢），仿佛這是萬能解藥。但他的實踐暴露了這套方法的裂縫：

個人問題的解決方案往往帶著強烈的個人偏見。你的痛點可能是小眾的，你的 workaround（臨時解決方案）可能是反直覺的，你的技術選型可能是為了練手而非最優。把這些直接拋給公眾，用戶不會為你的學習曲線買單。

他的追蹤應用就是個例子。核心功能對他完美契合，但擴展到其他場景時，他發現需要重新設計數據模型。預算管理系統相對通用，但"手動輸入"這個設計選擇——對他來說是刻意為之的提醒機制——對習慣自動同步的用戶可能是致命缺陷。

這種張力讓他放慢了發布節奏。不是完美主義，而是承認"為自己構建"和"為市場構建"是兩種不同技能。前者需要洞察自己的真實需求，后者需要剝離個人偏好、找到最大公約數。很多開發者卡在中間：產品對自己有用，就假設對所有人有用，結果上線后面對沉默的市場不知所措。

Lala 的選擇是繼續迭代，同時保持兩個產品的日常使用。他用實際行動測試價值，而不是用假設。

從技能焦慮到問題焦慮

回看他的轉變，核心變化不是技術能力提升，而是焦慮對象的轉移。早期他焦慮"我該學什么框架""我該跟進什么趨勢"，現在焦慮"這個問題我有沒有真的解決""這個交互我自己愿不愿意每天用第三次"。

這種轉移有個副作用：項目數量銳減，但完成度顯著提高。他的 GitHub 不再是一片綠點的海洋，而是兩個持續演進的倉庫。這種"少即是多"的結果，和硅谷推崇的"快速試錯、大量迭代"形成有趣對照。

Lala 沒有否定外部靈感的作用。他的預算系統就明確歸功于 YouTube 內容，但他加了一層轉化——把被動消費變成主動工具。這也是"為自己構建"的一個變體：不是從零發明需求，而是把學到的原則變成可操作的系統。

他的故事指向一個被低估的事實：開發者的個人問題池，可能比想象中更深。不是每個痛點都值得做成產品，但每個持續存在的痛點都值得被認真解決。解決的過程中，技能自然積累，產品自然成型，市場驗證反而成了后話。

現在 Lala 還在打磨那兩個工具。追蹤應用的發布時間表未定，預算系統可能在近期開放測試。他最新的思考是：如果公開發布后，用戶的使用方式和自己完全不同，這個產品還算成功嗎？