前陣子在 Threads 看到一個討論。
有人分享自己在面試時 Demo 了一些 Side Project，結果面試官問了一句很現實的話：
但你的專案沒有實際使用者，我怎麼知道它到底改善了哪些痛點？
這句話有點刺，但我覺得很值得想。
因為很多 Side Project 看起來功能很滿、架構很漂亮、技術棧也很新，可是只要回到「有沒有人真的使用」這件事，就會變得很安靜。
我以前也很容易掉進這個陷阱。
想做一個工具，就會忍不住開始想：
- 要不要做登入？
- 要不要做後台？
- 要不要做訂閱？
- 要不要做多語系？
- 要不要做成一個完整平台？
結果題目越做越大，真的會用的人反而越來越模糊。
所以這篇文章想分享的是我最近比較深的感受：
做小的 Side Project，不要一開始就急著做大，而是要往小的地方做深。
而且更重要的是，小不代表沒創意。你甚至可以從現在已經存在的服務或工具類型開始，但你要放進自己的想法，讓它變成一個有明確使用情境、有取捨、有個性的東西。
我這次想分享的不是「爆紅」
先講結論。
我做的 MD2DOC-Evolution ，截至 2026-06-04 我在 GitHub 頁面看到的是 49 顆 Star、12 個 Fork。
Google Analytics 的資料則顯示，從 2026-01-01 到 2026-06-04，這個專案相關頁面大約有：
| 指標 | 數字 |
|---|---|
| 約略累積使用者 | 約 460 人 |
| first_visit 事件 | 457 |
| page_view | 1,029 |
| session_start | 814 |
| user_engagement | 613 |
| 週活躍使用者中位數 | 12 |
| 去掉年初高峰後的每週平均活躍使用者 | 約 11.4 |
這些數字不大。
真的不大。
如果你拿去跟那些每天幾萬使用者的 SaaS 比，這個數字小到像在角落裡默默發光。
但對一個個人 Side Project 來說，它代表另一件事：
這不是只有我自己覺得好玩。它真的有人用。
而且不是只有一次性的曝光。從週活躍資料來看，年初有幾波高峰，後面回到比較穩定的小流量，大多數週大約落在 10 人上下。
這個數字很普通，但也很真實。
普通到可以讓我冷靜下來想：
這個工具沒有成為大平台，但它解決了一小群人的一個具體麻煩。
我覺得 Side Project 最重要的起點，就是先做到這裡。
不是「沒人做過」才值得做
很多人做 Side Project 會卡在一個問題：
這個東西已經有人做過了，我還要做嗎？
我以前也會這樣想。
像 Markdown 轉 Word 這件事，世界上當然已經有工具。Pandoc、各種線上轉檔服務、甚至 Word 本身也可以處理一部分格式。
那我為什麼還要做 MD2DOC-Evolution？
因為我遇到的痛點不是「完全沒有工具」。
我遇到的痛點是：
一般轉檔工具不懂技術書稿的細節。
技術書或技術文件常常會有程式碼區塊、提示框、表格、對話內容、章節層級、頁首頁尾、目錄、QR Code、甚至是要給 AI 協助重構的格式規範。
一般工具也許可以轉成 Word。
但轉完之後，你還是要花很多時間修版面。
所以我的題目不是「我要做全世界第一個 Markdown 轉 Word 工具」。
我的題目其實更小：
我想做一個比較懂技術內容創作者的 Markdown 轉 Word 工具。
這個題目小很多，但也清楚很多。
它讓我知道哪些功能該做，哪些功能先不要碰。
它也讓使用者比較容易理解：
如果你只是偶爾把一段文字轉成 Word，你可能不需要它。
但如果你常寫技術稿、教學稿、AI 對話稿、開發文件，而且最後還是得交出 Word，那它就可能剛好打到你的痛點。
小產品的價值，在於它敢有偏見
我現在越來越覺得，Side Project 最迷人的地方，不是它有多完整，而是它有沒有清楚的偏見。
這裡的偏見不是壞事。
偏見是指：
- 你認為哪一種使用情境最重要？
- 你願意服務哪一群人？
- 你不打算服務哪些需求？
- 你願意為了某個體驗，犧牲哪些通用性？
大平台常常要盡可能滿足所有人，所以它會變得很中性。
但 Side Project 不需要。
個人專案最有機會做出差異的地方，就是把你的使用經驗、你的審美、你的工作流放進去。
MD2DOC-Evolution 對我來說，就是這樣的東西。
它不是單純把 Markdown 丟進去，然後吐出一個 Word 檔。
它背後其實有一個很明確的想法：
技術內容的排版，不應該每次都靠手動整理。
所以我會在意程式碼的呈現、提示框的樣式、文件結構的穩定性，也會在意 AI 能不能協助把舊稿件重構成符合工具規範的格式。
這些想法可能不是每個人都需要。
但正因為它不是每個人都需要，才有機會讓真正需要的人留下來。
流量數字教我的事：Direct 比想像中重要
這份 GA 資料裡，我覺得最有意思的不是 page_view，而是來源。
從新使用者來源來看：
| 來源 | 新使用者 |
|---|---|
| Direct | 361 |
| Referral | 79 |
| Organic Social | 11 |
| Organic Search | 6 |
工作階段來源也有類似的趨勢：
| 來源 | 工作階段 |
|---|---|
| Direct | 640 |
| Referral | 147 |
| Organic Social | 13 |
| Unassigned | 12 |
| Organic Search | 11 |
這代表什麼？
它不太像是「大家剛好從 Google 搜到」。
它更像是有人從 GitHub、文章、朋友分享、或自己收藏的入口進來。也就是說，這種小工具的擴散方式，不一定是靠 SEO 打爆搜尋流量，而是靠：
- 清楚的使用情境
- 可以直接打開的 Live Demo
- 開源專案頁面
- 使用者覺得「這個我下次還會需要」
- 技術社群裡自然傳來傳去的連結
這也讓我重新理解 Side Project 的行銷。
不是每個小工具都需要一開始就寫商業計畫書。
有時候你需要的是讓它能被看懂、能被試用、能被收藏、能被再次打開。
如果一個小工具每週都還有 10 個人左右回來看，這件事本身就已經在說話了。
面試時真正能講的，不是「我用了什麼技術」
回到一開始 Threads 上那個問題。
如果面試官問：
你的 Side Project 有沒有實際使用者？你怎麼知道它改善了痛點？
我覺得比較有力量的回答，不是馬上開始背技術棧。
不是說：
- 我用了 React
- 我用了 TypeScript
- 我用了 Vite
- 我用了某某套件
這些當然可以講，但它們不是核心。
更有力量的講法應該是：
我觀察到技術內容作者在 Markdown 到 Word 的流程裡，常常卡在排版、程式碼、提示框與文件格式。
所以我做了一個專門針對技術書稿的轉檔工具。
它目前在 GitHub 有 49 顆 Star，今年約有 460 位使用者，週活躍中位數大約是 12。
數字不大，但代表它不是只有我自己使用，而是真的有一群人遇到相似痛點。
這樣的回答，會比「我做了一個很完整的平台」更扎實。
因為它有使用情境，有產品取捨，也有真實資料。
Side Project 的價值不只在於程式碼能不能跑，而在於你能不能說清楚：
- 你看到什麼痛點？
- 你為什麼這樣解？
- 你怎麼知道有人需要？
- 使用者資料讓你修正了什麼想法？
- 接下來你會怎麼讓它更好？
這些問題，才比較接近真實產品開發。
不要急著做大，先做小到有人會用
我現在對 Side Project 的看法是：
不要一開始就問「我要怎麼做成一個大產品」。
可以先問：
我能不能做出一個小到很明確，但真的有人會用的東西？
小到什麼程度？
小到一句話就能說清楚：
- 給誰用？
- 解決什麼麻煩？
- 為什麼不用現有工具就好？
- 我的版本多了什麼自己的想法？
如果這四題答不出來，功能再多都會散。
相反地，如果這四題答得出來，你甚至不用一開始就做很大。
你可以先做一個很窄的入口，讓人打開就知道它要幹嘛。
你可以先做一個 Live Demo，不急著做登入。
你可以先開源，不急著收費。
你可以先服務一種文件格式，不急著支援所有格式。
你可以先把一個痛點解到舒服，再慢慢長出下一個功能。
這不是保守。
這是讓 Side Project 不要被自己的野心壓垮。
已經存在的東西，也可以長出你的版本
我很喜歡「不要重造輪子」這句話，但有時候它也會讓人不敢開始。
因為你會覺得：
既然已經有人做了，那我是不是就不能做？
可是現實是，很多好用的小工具，本來就不是因為它是第一個，而是因為它解得比較貼近某一群人的生活。
同樣是筆記工具，有人要極簡，有人要雙向連結，有人要白板，有人要資料庫。
同樣是轉檔工具，有人要批次處理，有人要格式穩定，有人要支援技術書稿，有人要公司內部可以放心使用。
需求不是只有一條路。
Side Project 的機會，常常藏在這些分岔裡。
你不一定要做「全新的類別」。
你可以做「更適合某個場景的版本」。
但前提是，你要真的放進自己的判斷。
如果只是把現有工具複製一次，那很快就會失去理由。
如果你能說清楚：
我知道這類工具已經存在，但我在這個場景裡看到一個沒有被好好處理的細節，所以我做了這個版本。
那它就有存在的價值。
這 460 人給我的回饋
我不會把約 460 位使用者講得像什麼巨大成就。
但我也不想把它看得太小。
因為對個人開源專案來說，這些資料至少告訴我幾件事：
- 這個痛點不是只有我自己有。
- 專案頁面與 Live Demo 有被打開。
- 使用者來源裡 Direct 與 Referral 很高，代表連結本身有擴散。
- 每週仍然有人使用，代表它不是只有發布當天熱鬧一下。
- GitHub Star 雖然不是等於使用者，但它代表有人願意留下注意力。
這些回饋不會讓我覺得「我已經成功了」。
比較像是它推了我一下：
你做的這個小東西，有人正在用。接下來請更認真地對待它。
這種感覺很不一樣。
當 Side Project 只有自己用時，你可以很隨性。
但當你知道外面真的有人打開它、收藏它、甚至 Fork 它，你會開始更在意文件、錯誤訊息、範例、穩定性，以及下一個版本到底該不該做某個功能。
這就是使用者資料帶來的壓力。
也是 Side Project 真正開始變有趣的地方。
給正在做 Side Project 的你
如果你也正在做 Side Project，我會建議不要急著把題目拉到很大。
先把它縮小。
縮到你可以用一句話說出它的價值。
縮到你知道第一批使用者可能是誰。
縮到你可以判斷哪些功能現在不該做。
縮到你可以真的把某個流程做得比現有工具更貼近你的使用情境。
然後，讓它被使用。
不要只停在 Demo。
放一個 Live Demo。
寫清楚 README。
開源也好，寫文章也好，丟給朋友試用也好，總之要讓它離開你的電腦。
因為 Side Project 最珍貴的不是「我做出來了」。
而是當你做出來之後，有人真的帶著自己的問題走進來，然後留下了一點使用痕跡。
對我來說，MD2DOC-Evolution 現在還是一個小專案。
但它已經不是一個只存在於我腦中的小專案。
它有 49 顆 Star，有大約 460 位使用者，有每週約 10 人上下的使用痕跡。
這些數字不誇張。
但它們很踏實。
而對 Side Project 來說，踏實有時候比巨大更重要。