010. 先看問題｜AI 不是讓 SaaS 失去價值，而是讓訂閱重新被審問
Debug Tuboshu 這支影片《只用 10% 的功能，卻付 100% 的錢：AI 讓我開始退訂 SaaS》表面上是在講退訂工具，核心其實是更大的軟體採購變化：當 AI 讓「自己做一個剛好夠用的版本」變得便宜，許多原本不用想的 SaaS 訂閱，開始需要重新接受 Build or Buy 的審核。
這不是一個「SaaS 已死」的故事。更準確地說，這是一個「SaaS 不能只靠使用者不會做來收錢」的故事。
過去很多工具之所以能被買單，不一定是因為它們每個功能都高度必要，而是因為替代選項太貴。你要找工程師、理解 API、架伺服器、處理部署、修 bug，時間成本一攤開，月付幾十美元很合理。但 AI 把這條線往下拉：如果一個下午能做出剛好需要的 10%，那原本合理的月費就會突然變得刺眼。
魚塘值得抓住的不是「退訂」這個動作，而是退訂背後的判斷方式：以前是沒有能力 Build，所以只能 Buy；現在是有機會 Build，所以每一筆 Buy 都要重新說明自己包進了哪些隱形價值。
021. ManyChat 的 10%｜當需求很窄，AI 會讓自製變得突然合理
影片的起點是 ManyChat。講者說自己真正需要的功能很單純：有人在 Instagram 貼文底下留言特定關鍵字，就自動私訊一個連結。以他的情境，這項需求每月要付 69 美元，而且流量往上價格還會增加。
如果放在過去，這種帳通常不會細算。為了一個自動私訊流程，自己開發兩三天，成本可能已經抵掉好幾個月訂閱。更何況還要串 Meta API、做管理介面、部署、除錯。買現成服務就是理性選擇。
但 AI 改變的是邊際開發成本。講者的說法是，若跟 AI 協作，一個下午就能做出真正需要的那 10% 功能，Build or Buy 的結論就會改變。這裡的「10%」不是精準比例，而是一種產品拆解方式：使用者不是在買整套 SaaS，他是在買自己工作流裡真的會用到的那一小塊。
對 SaaS 公司來說，這其實很刺。過去把很多功能打包在一起，是產品商業化的標準做法：自動化、範本、分析、分眾、團隊權限、整合入口，全部收進一個月費裡。但如果某些使用者只需要其中一個穩定動作，AI 會讓「拆出來自己做」變成新的替代方案。
不過這不是說每個人都該立刻退訂 ManyChat 或任何類似服務。這個案例成立，有幾個前提：需求很明確、流程很窄、失敗成本可控、使用者願意處理 Meta API 權限與部署。只要其中任一項不成立，原本的 SaaS 月費就可能重新變合理。
所以這個案例真正提出的問題是：你的 SaaS 月費，買到的是一整套營運能力，還是只是替一個很小的流程付過高的包裝費？
032. 開源不是免費午餐｜GitHub 專案需要 AI，也需要成本模型
影片接著把 Build 拆成兩種：一種是請 AI 幫你做出需要的功能；另一種是把現成開源專案拿回來架、回來改。第二種在 AI 時代特別重要，因為很多人不是沒有免費軟體可用，而是以前沒有能力把它跑起來。
開源專案的 README 常常寫著 Docker、環境變數、Port、Database、Reverse Proxy。每個字都查得到，但真正要接在一起就會卡住：版本不對、套件沒裝、連接埠被占用、資料庫連不上、憑證不知道放哪裡。AI 在這裡扮演的角色，不是神奇地讓維運消失，而是把「讀懂並執行安裝步驟」的門檻降低。
講者用 Bitwarden 作例子：原本很多人會付費使用密碼管理器，但也可以把自架版本跑在自己的伺服器上，再用官方 App 或瀏覽器擴充功能連回自己的服務。這裡有一個關鍵觀念：客戶端和伺服器端不是同一件事。App 有開源，不代表完整服務都能搬回自己家裡；伺服器端也要能自架，才有完整替代的可能。
這也是很多「開源平替」討論容易誤判的地方。看到 GitHub 不等於看到整個產品。你拿到的可能只是客戶端、外掛、SDK、範例程式，也可能是完整後端。甚至即使程式碼完整，背後仍可能需要第三方 API、搜尋資料、地圖資料、Email、簡訊、AI 模型或付款服務。
所以 AI 讓開源更接近一般使用者，但它沒有把開源變成零成本。它只是讓「我看不懂 README」不再是第一道牆。真正的牆往後移了：你要知道自己拿到哪一塊、缺哪一塊、哪些外部服務仍然要付費，以及壞掉時誰負責。
043. 真正該算的帳｜Buy 算月費，Build 要算時間、部署、依賴和維護
這支影片最有價值的地方，是講者沒有停在「自架比較便宜」。他反而提醒，Build and Buy 要算兩筆帳。
Buy 的成本比較容易看見：月費、席次費、流量費、升級費，以及長期平台綁定。這些通常會直接出現在信用卡帳單或採購合約裡。
Build 的成本比較容易被低估：開發時間、算力、部署、第三方 API、資安、備份、維護，還有最常被忘記的使用者自己的時間。很多自架方案在 demo 階段看起來免費，真正上線後才開始長出成本。
講者整理了三個常見輸點。
第一是算力成本。有些系統本來就重，資料庫、搜尋、排程、自動化一起跑，省下訂閱費卻租了一台更貴的 VPS，最後未必比較便宜。Supabase、n8n 這類工具可以自架，但不代表每個使用規模都適合自架。
第二是規模成本。一個人用很便宜，不代表十個人、五十個人、一百個人用也便宜。人數一增加，流量、檔案、資料庫、備份、權限管理、稽核和支援都會一起變重。很多工具在個人自用階段很漂亮，到團隊使用階段就開始露出維運帳單。
第三是生態系成本。有些產品值錢的不只是功能，而是模板、教學、整合、自動化工具、團隊習慣與外部人才市場。Notion 類工具尤其明顯：頁面和 database 可以被仿製，但團隊已經累積的工作流和整合網路不容易搬。
這裡可以把判斷簡化成一張心中的矩陣：需求越窄、維運風險越低，越值得用 AI 做一個剛好夠用的小工具；需求越通用、協作越多人、資安與可靠性越重要，就越該買成熟 SaaS。介於中間的區域，才是 AI 時代最有趣的新地帶。
054. SaaS 的新說服門檻｜未來的競爭者是「使用者 + AI」
影片後半段提醒一件容易算錯的事：Build 的回報不一定是省錢。有時候公司明知道自己架比較貴，還是會做，因為買到的是控制權。
第一種控制權是資料。使用 SaaS 等於把檔案、客戶資料、聊天紀錄，甚至程式碼放在別人的系統裡。這不代表對方一定會濫用資料，但你必須相信對方的隱私政策、安全機制和未來規則。自己架的價值，是資料放在哪裡、誰能看、備份幾份、保存多久，都能自己決定。
第二種控制權是功能。ManyChat 案例裡，講者不是否認完整產品有價值，而是他只需要留言關鍵字自動私訊這一小塊。當使用者能把自己需要的功能切出來做，就不必為 90% 沒用到的功能長期付費。
第三種控制權是系統命運。如果整間公司的流程都建立在某套 SaaS 上，對方漲價、砍免費方案、改 API、移除功能或停止營運，你通常只能接受。但如果程式碼和資料在自己手上，就算原作者不更新，手上的版本仍有機會繼續跑，必要時也能自己改。
這才是 SaaS 真正的新壓力。以前 SaaS 的競爭對手主要是另一套 SaaS；現在多了一種競爭者：使用者自己，加上 AI。這個競爭者不一定能做出完整產品，但它可以做出足夠解決當下痛點的小工具。
因此未來 SaaS 仍然很有價值，但價值敘事會改變。它不能只說「你不會做，所以你要買」。它必須更清楚證明：我替你處理更新、部署、備份、資安、多人協作、權限、可靠性、支援和生態系，而且這些總和比你自己做更便宜、更穩、更省心。
065. 結語｜退訂只是表象，重新理解軟體價值才是主菜
這支影片最好看的地方，是它沒有把 AI 講成 SaaS 殺手。講者最後也明確提醒：Self-hosted 不代表比較安全。SaaS 原本幫你處理的更新、備份、權限、漏洞、安全監控，自己架之後就會變成你的責任。新手如果要試，應該從壞掉也沒關係、沒有重要資料的小工具開始，而不是第一個自架專案就搬公司核心資料庫。
這個提醒很重要，因為 AI 會讓人產生一種錯覺：既然它能幫我寫程式、看 README、跑 Docker，那我就已經擁有整個產品了。但軟體產品從來不只是程式碼。它還包含監控、備份、升級、資安、客服、文件、合規、協作、權限、資料遷移和事故處理。
所以魚塘的結論會比「退訂 SaaS」更保守一點：AI 讓更多人第一次有資格把 Build 放進選項裡，但它沒有讓 Buy 失去意義。真正的變化是，Build 從「多數人根本不用想」變成「很多小需求可以重新試算」。
對個人創作者、小團隊和工程能力較強的公司來說，這會帶來一波軟體訂閱盤點。每一筆月費都可以問幾個問題：我真的用了多少功能？這個流程是否足夠窄？失敗成本高不高？資料是否敏感？自架需要哪些第三方依賴？未來維護誰負責？團隊是否已經深度依賴這個生態系？
問完之後，有些 SaaS 會被退訂，有些會被降級，有些會被小工具取代。但也會有一些 SaaS 變得更穩，因為它們終於被看見：原來我付的不是功能清單，而是可靠性、協作成本、資安責任和長期維運。
AI 時代的軟體市場，不會簡單走向「全部自己做」。它更可能走向重新分層：窄需求、低風險、可替換的小流程，會被越來越多使用者和 AI 拆出來；高風險、高協作、高可靠性、高生態系依賴的需求，仍會留在成熟 SaaS。中間那一段，才是接下來最值得看的戰場。