小到一個人養得起：我挑選要做哪些工具的四個標準

從四月到現在，我陸續上線了十個左右的小工具。常有人問我怎麼有時間，答案是：我沒有比較多時間，只是在動手之前，先用幾個問題篩掉大部分的點子。這篇整理我自己的四個標準。

一、它能不能只解決一件具體的事

我做過的工具，每一個都能用一句話說完：查台灣百岳、把 log 貼給 AI 之前先遮蔽、整理旅行照片、替租屋列表標出行情。如果一個點子需要用「而且還可以……」來接第三句，我就會把它拆開，或乾脆放棄。功能越少，要維護的面就越小，使用者也越容易理解它在做什麼。

二、它需不需要一台一直開著的伺服器

這是我最實際的篩選條件。靜態頁面加上少量 API 的工具，放在 Cloudflare Workers 上，流量小的時候幾乎不花錢，也沒有伺服器要修補。如果一個點子必須養一台 24 小時運轉的機器，我會先想想它是不是真的值得。

更進一步，有些工具我讓它完全不需要後端。例如照片整理和機敏文件遮蔽，所有處理都在使用者的瀏覽器裡完成。沒有後端，就沒有後端會壞掉，也沒有使用者資料要保管。

三、資料壞掉時，後果有多大

我會先問自己：如果這個工具給出錯誤的資訊，使用者會付出什麼代價？

• 租屋行情估價錯了，頂多多看一間房。
• 登山地圖的天氣錯了，可能讓人少帶一件保暖衣物。

後者我就選擇不做，改成連到官方的資料來源。代價越高的領域，我越傾向把判斷交回給權威單位，而不是自己包裝一個看起來很方便的答案。

四、半年後的我還看得懂嗎

每個專案我都會寫 README，記下部署方式、踩過的坑，以及「為什麼這樣做」。尤其是那些違反直覺的決定，例如為什麼這個資料庫在預覽與正式環境是共用的、為什麼某個 migration 不會自動執行。寫下來的成本是十分鐘，不寫的成本是半年後的一個下午。

這些標準也會讓我說「不」

用這四個標準篩過，大部分點子都會被淘汰，包括幾個我自己很喜歡的。但留下來的工具，都是能長期維護的。我寧願擁有十個還在運作的小工具，也不要一個做到一半、沒人維護的大專案。

你可以在首頁看到目前上線的作品。