自從看完《Unscripted》以及許多 Starter Story 的商業案例後，我就養成了在生活中觀察 SaaS 題目的習慣。
剛好身邊有不少經營中小型企業的朋友，每次聽他們分享公司經營上遇到的問題，我都會忍不住在腦中拆解他們的 workflow，思考其中有沒有什麼事情，可以透過我會的技術解決。
最近的一次聊天，就讓我找到了一個結合法遵與 RAG 的題目。我很快開始動手做 POC，除了寫程式，也一邊補足自己在 RAG 與法遵上的知識。
靠著 Claude Code 輔助，一開始的進展非常順利，隨著 RAG pipeline 與系統架構逐漸完整，我開始意識到，工程實作可能只是這個題目最容易解決的部分，真正困難的點在後頭：Golden set 的資料要從哪裡來？當一個法遵案例連我自己都看不懂時，該怎麼判斷系統的回答是否正確？Eval 又該由誰來做？
這些問題最後都指向同一件事：這套系統能不能商業化，取決於我對 domain knowhow 的理解，以及能否把這份理解轉成可靠的交付。
對我來說，軟體系統有相對清楚的 verification 方式。但法律就沒這麼容易了，那是超出我專業範疇外的知識體系。
軟體與法律，兩者都需要有人為其負責，但法律答案即使附上法源，仍需要具備資格的人判斷，並且願意替結果背書。我沒有足夠的信心，單靠技術跨過這道門檻。
走到這裡，我開始省思：是我一開始就選錯了題目，還是這有辦法透過 skin in the game 來跨過？
當我還卡在這個問題裡找不到答案時，LinkedIn 上的獵頭竟然剛好丟給我幾個 AI Native SaaS 的機會。我甚至還沒來得及把自己的思緒整理清楚，就進入了另一輪面試準備週期。這個專案就這麼被我擱置在一旁。
在幾輪面試下來，也剛好給了我機會看見資金更充足的新創，如何處理類似的 domain knowhow 困境。
比方說，以法律為題材的 AI 新創，他們有足夠的資金直接把律師與顧問納入團隊，有些人甚至就是公司股東。提供領域知識的人共同承擔風險，也共享產品成功後的利益。
很顯然，這種資本與組織規模已經超出獨立開發的範疇。但它呈現出的工作方式，很接近我嚮往的環境：工程師與領域專家長期待在同一個問題裡，也一起承擔產品最後能否交付的責任。
對我來說，這種合作最有價值的地方，是工程師能一路參與問題如何被定義、答案如何被驗證，以及產品最後如何交到客戶手上。
如果有機會加入這樣的團隊，我能透過自己的工程能力，把領域專家的判斷轉成可靠、可維護的系統，除了把需求做完，也逐漸弄懂為什麼要做、客戶真正重視的是什麼、技術上該怎麼取捨。Domain knowhow 便會在這個過程中累積。
這段面試經驗也讓我回頭檢視，自己對獨立開發的假設。
我原本把這條路想得很線性：找到一個潛在痛點 → 累積足夠的 domain knowhow → 搭配 technical skills 與執行力做出 POC → 確認有人需要之後，接著處理 distribution。
而問題就在這個順序。它假設我能先辨認出值得解的痛點，再把所需的 domain knowhow 補齊。
真的走進陌生領域後，我才發現，domain knowhow 很難像技術套件一樣，等到需要時再安裝。有些知識需要長期累積，有些資訊根本不在公域流通。更麻煩的是，一個題目是否適合獨立開發，可能在我真正理解它以前，根本沒有辦法判斷。
那麼，獨立開發者究竟該如何找到值得長期投入的痛點？又該怎麼累積足以解決它的 domain knowhow，最後把產品帶到願意付費的人面前？
帶著這些問題，我回頭研究了最近接觸到的三位獨立開發者。
三位獨立開發者，三種選題路徑
Jesse Hanley、Takuya Matsuyama 與 Jannis Fedoruk-Betschki 三人的背景跟產品截然不同，卻都從自身的職涯軌跡逐步累積，發展出一門能由一人或極小團隊長期經營的生意。
以下我會先簡單介紹產品，再用四個問題來拆解這三個案例：
- 他解決了什麼問題？
- 他憑什麼能解決？
- 客戶從哪裡來？
- 驗證花了多久？現在走到哪裡？
1. Bento - Jesse Hanley
Bento 是一套主打 Email 成功送達率與行銷自動化的平台，服務對象以 SaaS 和電商公司為主。
當初我會注意到 Jesse，是因為在 X 上看見 Marc Lou 跑去日本找 Jesse 玩。好奇之下，我開始爬文研究他到底是誰，也撈出了一系列 Podcast 訪談。
我很喜歡 Jesse 在 Podcast 上帶給我的感覺：務實、真誠、帶有溫度。而他也常在訪談中帶出自己的價值觀——他很重視家人與生活品質，他總是傾向把生意維持在小而美的規模，把時間跟專注留給真正重要的人事物。
他解決了什麼問題？
Jesse 想解決的問題，來自他過去操作 Email 行銷的經驗。
行銷團隊寫了好的內容、設計了完整的漏斗，最後卻因為寄件信譽、DNS 身分驗證或共享 IP 裡的其他寄件者，讓信件直接進入垃圾郵件。既有工具的自動化流程編輯器也常常很難用，價格還會隨著聯絡人數暴增，即使多數名單根本沒有收到信。
Bento 最初走的其實是網站個人化的服務，當時還不是 Email 行銷產品。為了讓企業客戶看見個人化帶來的成效，Jesse 又加入分析與追蹤功能，記錄網站訪客的行為。上線後，他發現客戶對這些訪客數據的興趣，甚至高於原本的個人化功能。這讓他開始思考：既然已經知道訪客做過什麼，能不能直接根據這些行為採取下一步行動？於是他加入 Email 自動化，再一路往 SMS、交易型郵件與成功送達率深挖。
他憑什麼能解決？
Bento 這題目與 Jesse 的工作經驗幾乎完全重疊。他早期替澳洲的保健品零售與電商公司負責系統、行銷及運營，後來又自己經營行銷公司，替客戶操作 SEO、廣告與 Email 行銷活動。等於他自己就是 Bento 的理想顧客 (ICP)，多年後才開始打造自己的工具。
Jesse 自學 Rails 與 React 進行全端開發，當遇到超過能力範圍的問題，就找更有經驗的工程師合作，再從對方提交的程式碼中學習。
客戶從哪裡來？
Bento 的獲客方式也沿用他過去經營行銷公司的做法：長期在網路上無償的幫助別人。
Jesse 曾經連續三、四年把 Calendly 放在 Twitter 個人檔案，任何人都能直接跟他預約通話。他常常花一個多小時免費幫對方釐清問題，最後什麼也不賣。這些關係可能幾年後才變成客戶，或在某個朋友受不了 Mailchimp、Klaviyo 時，想起可以找 Jesse。
客戶進來後，他又透過創辦人親自提供的支援繼續推動口碑。US$30 與 US$3,000 的客戶都能直接在 Discord 找到他；他也會親自展示產品、協助資料搬遷、錄製教學影片。
小客戶介紹大客戶的情況反覆發生，客戶支援本身逐漸變成 Bento 最重要的獲客渠道之一。近年他也開始透過 Podcast 節目、贊助與訪談，反覆讓目標客群記得 Bento 的存在。
驗證花了多久？現在走到哪裡？
從 Jesse 的回顧看來，Bento 在開始前沒有經過一輪明確的市場驗證。當時他仍在經營自己的行銷公司，出發點之一只是很想寫程式、成為開發者。他找來在東京認識的 Andrew Culver 合作，第一年把數據分析、少量 Email 與自動化功能全塞進產品。Jesse 後來形容，當時的自己想替所有人做所有功能，結果一直沒有進展。
直到 COVID 疫情期間賣掉行銷公司，需要重新建立現金流，他才開始全心投入回 Bento。
這時他發現，使用者真正有迴響、也確實持續使用的是 Email 功能，才開始把產品往這個方向收斂。
如果只看市場驗證所需的時間，Bento 其實是三個產品裡最慢的。Jesse 邊經營行銷公司邊開發，花了約三到四年，才讓功能完整到足以被客戶視為既有 Email 服務商的替代方案。這場驗證沒有在幾週內跑完。他一路從客戶的使用狀況找線索，慢慢收斂產品定位。
但這段時間也換來了很深的產品認知。2026 年 3 月的 Tropical MBA 訪談 將 Bento 描述為一間年度經常性收入已超過 US$1M 的公司，換算後每月營收規模至少是 US$83K。Jesse 沒有公開精確 MRR，但整間公司大多數時候依然只有他自己，加上幾位兼職協作者。
2. Inkdrop: Takuya Matsuyama
Inkdrop 是一套專門為軟體工程師打造的跨平台 Markdown 筆記工具，支援離線使用、雲端同步、端對端加密與外掛系統。
我是在研究 Peak Pals 編輯器選型時，關注到 Takuya。他是我少數知道的日本獨立開發者，他也用 Ghost 自架 部落格，讓同樣身為 Ghost 用戶的我感到格外親切。
他非常認真地透過 YouTube 經營受眾，用著他獨特的日本腔英語，分享自己的生活，以及一路面對的挑戰。他近期有一集講述自己如何在 AI Era 被搞到 burnout，讓我相當有共鳴。
他解決了什麼問題？
這個產品的起點非常直覺：Takuya 找不到自己想用的筆記軟體。（跟我開發 Peak Pals 的初衷很像！）
他當時用 Evernote 記錄開發筆記，但它並不適合存放大量程式碼片段與 Markdown。網頁版工具離線時不能用，透過 Dropbox 同步的編輯器又慢又吃 CPU，其他選項不是功能太少，就是複雜到讓他不想每天打開。試過一輪後還是找不到能長期使用的工具，於是他決定乾脆自己做一個。
他憑什麼能解決？
Inkdrop 的領域認知首先來自 Takuya 自己。他就是目標用戶，每天寫程式，也每天記錄技術筆記。
他從青少年時期就持續開發軟體，工作上待過 Yahoo! Japan，也長期參與開源專案與接案。他曾經做出擁有 13 萬使用者的音樂應用程式 Walknote，卻完全沒有辦法變現。這段失敗讓他深刻認知到，下載量與商業可行性是兩件不同的事。到了 Inkdrop，他從第一天就採用訂閱制，並把客群限縮在願意為開發工具付費的人。
客戶從哪裡來？
Inkdrop 早期的獲客幾乎都來自內容行銷。Takuya 持續寫下自己如何開發、獲得第一批客戶以及經營一人 SaaS，再把文章分享到 Hacker News (HN)。流量最高的時期，約九成新使用者都來自 HN。他沒有在部落格直接推銷產品，只是很誠實地分享自己做對與做錯的事情，反而慢慢累積了讀者與口碑。
2018 年後，獲客重心逐漸移到 devaslife YouTube 頻道。他拍自己的開發生活、工具與業餘專案，在影片裡自然帶到 Inkdrop。到了 2024 年，YouTube 一度帶來 70–80% 的新使用者。後來他也建立付費用戶才能加入的 Discord、舉辦線上聚會；這些管道未必帶來大量新客，卻讓核心用戶更願意留下。
驗證花了多久？現在走到哪裡？
Takuya 沒有在開發前進行用戶訪談或架產品 waitlist。他先清空了手上的接案，接著給自己三個月的時間完成 MVP，並在 2016 年 6 月把封閉測試版丟上 Hacker News。文章登上首頁後，短時間內帶來超過 1,000 人登記測試。這些使用者提供錯誤回報與功能建議，也讓他從使用數據裡觀察到確實有人每天使用。這是 Inkdrop 最早的市場驗證。
產品在 2016 年 10 月正式收費，半年後累積 US$1,000 銷售與 30 位付費使用者；上線約一年時，MRR 已經來到 US$1,361。速度不算爆發，但已經足以證明有人願意長期為這個利基產品付費。
Takuya 最近一次給出的明確數字，是 Inkdrop 已經連續三年以上超過 US$10K MRR。不過他在 2026 年初的 2025 年回顧 中也提到，因為整年專注開發 v6、減少行銷，新客成長放緩，營收比 2024 年低。因此目前只能確認它曾穩定跨過 US$10K MRR，無法知道 2026 年的精確數字。
3. Magic Pages: Jannis Fedoruk-Betschki
Magic Pages 做的是 Ghost 部落格託管服務。使用者不需要處理伺服器、更新、備份、CDN 或寄信設定，幾分鐘內就能建立一個功能完整的 Ghost 網站。
Jannis 是近期讓我印象最深刻的一位獨立開發者，因為我們有過實際互動——我甚至在跟他接觸的兩個月後，成了他的付費用戶！
我當初是在 Ghost forum 上搜尋關於搜尋功能的討論串，當時的我想要自己做一個 Ghost RAG 的 side project，進而看見 Jannis 在論壇上非常活躍，還分享了自己開發的全新搜尋套件。當時我覺得：這個人超屌，一定是個 Geek。繼續往下爬文才發現，他竟然還經營著 Ghost 託管服務，而且是一人公司！
最開始跟他的接觸，是因為 Magic Pages 官網的 localization pricing 頁面出了一些 bug，讓我誤以為年費是 US$4,480，後來才發現其實是 NT$4,480，幾乎是 Ghost(Pro) 的半價！跟他反饋完本地化問題後，他竟然在 30 秒內秒回我，還在 10 分鐘內修正了這個 bug，讓我非常驚艷。
隨著我鑽研如何進行 migration 的過程，我也問了他幾次問題，接著就開始了試用期。這段期間只要我寄信到客服信箱，他都在短時間內親自回應我，不論他自己當地是什麼時間。就這樣，我被他的執行力與熱誠打動了，決定加入他的平台。
後來我也發現了他的 寶藏 Blog。他在上面分享許多創業過程遇上的困難以及個人經驗。我最喜歡的是他講述自己當初 回絕 Apple offer 的故事，那個選擇也一路造就了今天的他。
他解決了什麼問題？
Ghost 這套開源軟體已經把寫作體驗與電子報系統做得很好，剩下的差異通常出現在架站方式的選擇；選擇自行架站，就得面對 Docker、資料庫、備份、DNS 與 Email 設定；選擇託管服務，價格又可能隨著自訂主題、CDN 或進階功能一路往上疊。許多創作者只想專注在寫作，最後卻被迫理解一堆可能兩、三年才碰一次的技術細節。
另一個差異在於電子報的計價方式。Ghost(Pro) 依網站的會員總數決定方案，免費會員也會列入計算，但寄信次數沒有限制。Magic Pages 則提供無上限的會員數，每月包含 10,000 封 Email，超出後每 10,000 封收取 US$5。對寄信頻率不高的小型部落格來說，後者更貼近使用情境，能夠省下寄信成本。
Jannis 最初也沒有打算經營一間完整的託管服務公司。2023 年初，他只是想架一台伺服器，放一批 Ghost 網站，再以這套基礎發展 Ghost 客製化開發服務。他先開出 15 份、每份 US$249 的終身方案預售。產品當時甚至還不能使用，第一批客戶卻已經願意付錢。
他憑什麼能解決？
這份信任與他先前累積的領域認知有關。Jannis 原本從事客服工作，2020 年曾在一間新創公司從零建立客服團隊。當時公司突然有了數百名客戶，規模又不足以繼續請人，他才開始學網頁開發，希望透過程式解決客服與運營問題。
後來他成為專職網頁工程師，也替 Carrd 製作範本、協助客戶處理網站問題。Magic Pages 解決的痛點，剛好落在在客服、網頁開發與 Ghost 三個經驗的交叉點上。
隨著託管的網站從 30 個成長到 100、600，再到現在的 1,400 多個，他又被迫補上基礎設施的知識。Docker、Kubernetes、分散式儲存、CDN、Email 成功送達率，幾乎每一塊知識都來自實際運營遇到的問題。這種認知很難靠做一個 POC 專案就補齊。
客戶從哪裡來？
Magic Pages 的獲客起點是 Twitter。
Jannis 在產品還沒有名字時就公開分享想法，最早的客戶來自他既有的人脈，以及曾經買過 Carrd 範本、接受過他幫助的人。第一輪客戶開始使用後，真正把產品推出去的是口碑行銷。到了 2023 年中，他發現客戶會主動向朋友推薦 Magic Pages，才意識到這可能不只是一個業餘專案。
現在他的主要獲客渠道依然圍繞著創辦人個人品牌、既有客戶與 Ghost 社群。他會在個人部落格公開寫基礎設施出包（post mortem）、成本變化與經營上的困難，也長期出現在 Ghost 論壇和 Reddit。當有人詢問 Ghost 託管服務時，往往是他的客戶主動跳出來推薦。
我自己就是被這種創辦人熱誠轉換成付費用戶的例子。過去我曾因為網站後台卡頓而聯絡 Ghost(Pro) 客服，正常情況要等2~3天才會回，若剛好遇上員工放假，甚至有過七天以上才收到回覆。相較之下，我每次寄信給 Magic Pages，幾乎都由 Jannis 本人在 15 分鐘內回覆。對網站正在出問題的創作者來說，這種回應速度會直接影響對託管服務的信任。
驗證花了多久？現在走到哪裡？
如上面所述，Magic Pages 的市場驗證發生在產品完成以前。最初 15 份預售帶來約 US$3,500，支付了第一台伺服器與部分開發成本；從預售到第一批網站真正上線，大約隔了三個月。2024 年 2 月，他在終身方案之外加入月繳與年繳方案，七個月後達到 US$1,034 MRR。
這也是 Jannis 最後一次公開精確 MRR。2025 年 5 月，他只透露 Magic Pages 的收入已經持續高過自己的正職工作；截至 2026 年 8 月，官網則顯示超過 1,400 位創作者。由於客戶混合了月繳、年繳、終身方案、舊價格與多網站帳號，無法從網站數量推算目前 MRR。但從產品在三年內由一人業餘專案長成三人小團隊來看，它已經走過最初的商業驗證階段。
回到我的選題困境
研究完這三個案例，我也重新梳理了自己開發 Peak Pals 的經驗。
跟 Takuya San 一樣，我當時就是 Peak Pals 最直接的使用者。從流程該怎麼設計，到哪些問題應該優先解，我一直都很清楚；產品上線後，我自己每天使用，搭配 beta users 持續提供回饋，feedback loop 很自然就建立了起來。這些 domain knowhow 原本就存在於我的生活裡，幾乎不需要另外取得。
真正卡住的是商業模式與 distribution。這部分我在 Peak Pals V1 發佈心得 也有寫下省思。
這次的法規 RAG 剛好相反。我透過工程視角看見了解法，卻卡在無法有效進行 LLM Eval、缺乏情境資料，難以替結果背書。
其實在深入研究這三位獨立開發者以前，我曾經跟一位好友 Marcus 討論過，該怎麼補足自己缺少的 domain knowhow。
他提出了一個我沒有仔細想過的方向：如果缺的是領域知識，何不直接聘請領域專家，透過長期顧問或鐘點諮詢來補足？
而且問題的規模可以調整。一個人能做的事情，跟一個團隊能做的事情肯定不同。如果目標是打造一個人能完成的產品，需要諮詢的範圍應該也不至於高到無法負擔。
反過來說，如果一間公司需要聘請大量領域專家，靠著許多不會寫在書上的經驗建立背景資料，那可能本來就不是一個人的範疇。即使我真的加入那間公司，這些知識門檻也不會因此消失。
聽完之後我才發現，自己原本的思緒把兩件事情混在一起了：一件是「我要怎麼取得 domain knowhow」，另一件是「這個問題到底適不適合獨立開發」。
我很認同聘請顧問可以幫我快速理解產業結構、既有 workflow、法規與常見問題，少走很多冤枉路。
但我比較沒把握的，是那些難以量化，卻足以深刻影響 product sense 的經驗。以及那些「未知的未知」。
那天我們沒有聊出一個明確的答案，不過 Marcus 確實幫我把原本混在一起的問題拆開了。從第一性原理去拆解問題本質，一直以來都是他的強項。也因為他提出這個方向，我才繼續往下研究，最後寫成這篇文章。
工程與 Domain Knowhow 的不對稱
研究這三人的過程中，我被提醒了一件事：Jesse 跟 Jannis 都曾將工程開發外包。
Jesse 找了 Andrew Culver 協助開發 Bento，自己是一邊看 code，一邊慢慢學會 Rails 與 React。
Jannis 早期也曾花錢請外部開發團隊協助客製 Email functionality。
但即便他們都外包過工程環節，他們都持續保持 hands-on，事情爆炸了自己都有辦法跳下去解決。他們這段從非工程背景一路走到 SaaS founder 的過程，帶給我很大的啟發。
但我也發現，他們選擇外包的工作都是「功能」問題或是「客服」——範圍明確，能夠定義與驗收。
就像現在為何 LLM 可以取代大量的 coding 實作一樣，工程師們對於定義 spec 最在行了，而 code 本身也是最容易被驗證的介質。
Domain knowhow 與商業邏輯就沒那麼容易定義與外包。
他們一直自己握著「什麼問題值得解、該服務誰、誰會願意付錢」的商業判斷。
AI 加速了軟體基底的建置，卻沒有能力提供 product sense。
這讓獨立開發者做產品的職涯路徑有機會反過來：
Non-tech Domain Expert → 借助 AI 與工程能力 → Domain-specific SaaS
對工程師來說，如果想進入一個完全陌生的領域，顧問也許可以幫忙補課。但要真的理解那個領域，長期環境的選擇 (exposure) 或 incentives 一致的夥伴，還是更務實的切入點。
痛點背後的「在乎」
回頭看這三人，我發現他們還有一個共同點：他們都由衷的高度在乎自己正在解的問題。
Jesse 過去經營行銷代理商，所以他很清楚 Email 工具不好用、信件進垃圾郵件，最後會怎麼傷害客戶的行銷成果與信任。
Takuya 每天都要寫 technical notes。只要工具不好用，就會持續磨損他日常的開發能量。
Jannis 原本做過 customer service。他在意創作者有沒有被技術問題卡住，也在意問題發生時，有沒有人願意接住他們，並且用對方聽得懂的語言協助解決問題。我自己也親身感受過 Jannis 的這一面。有好幾次，我都覺得自己的問題問得有點唐突，Jannis 還是很大方地回答了所有細節毫無保留。那種熱誠很難靠 SOP 模仿，也是我很欣賞、很嚮往的一種做產品的態度。
這幾位開發者都不是某天突然坐下來想著：「噢！我要開始找痛點囉～」再決定產品要往哪裡走。這些痛點原本就存在於他們的生活與工作裡。
因為在某個領域待得夠久，他們知道哪些地方真的麻煩，也看得出哪些摩擦力只是大家已經習慣了，但不代表無法被解決。當其中一個問題讓他們在意到想親手做出解決方案，產品就慢慢的「長」了出來，這過程是有機的。
當然，光是在乎還不夠。
持續交付的能力，以及有效的根據回饋持續修正與 pivot 也很重要。
我想讓什麼開始複利
寫到這，我開始思考另一個問題：接下來幾年，我想讓什麼開始複利？
作為工程師，我很習慣累積 technical skills。LeetCode、system design、framework knowledge，都有相對清楚的學習路徑。投入多少時間、學會哪些東西、能不能通過面試或完成實作，通常也有明確的 feedback。
這些能力依然重要。我希望自己對工具的掌握一直維持在前緣，也持續磨練處理複雜問題的能力。但如果我想做出真正解決問題，也讓自己感到驕傲與滿意的產品，工程能力還需要搭配對使用者與 domain 的理解。
Peak Pals 的開發經驗讓我理解到，工程能力佐以 AI 可以把想法快速帶到 production，但產品該解決什麼、哪些功能應該優先，以及最後能不能真的幫助使用者，還是取決於我對問題的理解。
我想刻意累積的，是這種產品思維的複利（product sense）。
在一個問題空間裡待得夠久，久到知道哪些問題真的值得解、哪些需求只是噪音、客戶願意為什麼付錢，以及產品應該往哪裡長。
這些判斷很難透過讀書或短期衝刺補起來。它們藏在一次次與使用者互動、解決問題與修正假設的過程裡。對我來說，這些 domain knowhow、customer insight，都是做出好產品前很難取代的累積。
如果能在職涯上置身於自己真正在乎，且願意長期投入的 domain，依然是時間上最高效的配置。有著良好工程文化的團隊會讓工程師接觸客戶、參與問題定義，也能看見產品決策最後造成的結果。
Coding 已經能被 AI 加速。省下來的心力，我想拿去理解用戶、思考產品，再把這些理解轉回技術判斷。
工作以外的生活經驗、遇見的人、長期參與的社群，也會把我帶進其他問題裡。我未必需要刻意切出一個 time block 來「Explore domain knowhow」。
對我來說，當前能持續執行的，是留意那些反覆讓我覺得不對勁、甚至在乎到想親手解掉的麻煩。Technical skills 繼續累積，當真的遇到一個足夠在乎的問題時，我就有能力立刻動手驗證。
討論