最近看開發者社群的熱門專案，我注意到一個很有意思的訊號：大家對 free tier、低成本工具、SaaS 替代方案和可自架服務的興趣一直沒有退。表面上看，這像是大家在省錢；但從技術主管的角度看，我覺得真正的重點不是「便宜」，而是「選擇權」。
如果一個團隊只把低成本基礎設施理解成省預算，很容易走偏。省錢當然重要，尤其是小團隊、接案團隊或產品還在驗證階段時，每個月固定支出都會影響喘息空間。但基礎設施不是越便宜越好。真正值得在意的是：當價格改變、服務中斷、授權調整、功能被砍，或資料規模長大時，團隊有沒有能力換路線，而不是被某個服務綁死。
這幾年 SaaS 幫工程團隊省掉非常多麻煩。登入、資料庫、部署、監控、通知、文件、客服、金流、分析，幾乎每一塊都有成熟服務可以接。這是好事，因為多數團隊不該把生命浪費在重造輪子上。可是 SaaS 的方便，也常常讓我們在早期忽略一件事：每接上一個服務，其實也接上一個外部決策者。
這個外部決策者可能會改價格、改 API、改方案限制、改資料保留政策，甚至某天決定你的用法不符合它新的產品方向。大公司也許能簽企業合約、談 SLA、談遷移期；小團隊更多時候只能接受通知。這不是說不要用 SaaS，而是說不要把所有關鍵流程都設計成「只有這條路能走」。
我比較喜歡把基礎設施分成三層來看。
第一層是商品化服務。這些東西用 SaaS 很合理，例如寄信、簡訊、DNS、基本監控、文件協作、表單、低風險的自動化串接。它們的價值在於穩定、省維運、快速上線。只要資料可以匯出、API 邊界清楚、替代供應商夠多，就不必為了自架而自架。
第二層是核心工作流。這一層就要小心了。像是 CI/CD、程式碼託管、任務追蹤、知識庫、資料管線、客戶資料入口、AI agent 的工具層。這些不一定都要自架，但一定要有「退出設計」。資料能不能完整匯出？歷史紀錄會不會只存在平台黑盒裡？權限模型能不能轉移？自動化腳本是不是到處寫死某一家 API？如果明天要換服務，痛苦是一天、一週，還是半年？
第三層是組織差異化能力。這些通常不適合完全交給外部服務定義。不是因為外部服務不好，而是因為這裡藏著團隊真正的做事方式：需求怎麼流動、決策怎麼留下脈絡、例外怎麼處理、AI 怎麼介入工作、資料怎麼被驗證。這一層可以使用外部工具，但架構上要保留主控權。工具可以換，流程語意不能完全被工具綁架。
低成本工具和可自架方案的價值，常常不是讓你馬上替換掉 SaaS，而是讓你知道自己有退路。這就像工程上的 fallback。平常主路徑跑得好好的，不代表備援沒有價值；真正出事時，你會很慶幸自己曾經想過資料格式、同步方式、權限映射和切換流程。
很多人聽到「自架」會直接想到維運地獄，這個反應很合理。我也不認為每個團隊都該維護一堆服務。自架如果沒有能力、沒有監控、沒有備份、沒有升級紀律，只是把 SaaS 費用換成更貴的人力成本。省下來的月費，可能一下就被半夜救火吃掉。
所以我真正主張的不是「能自架就自架」，而是「不要失去可替換性」。有些服務可以完全託管，但資料要可攜；有些服務可以採用雲端版，但流程不要寫死；有些服務可以先用免費額度，但要知道超量後成本曲線長什麼樣；有些服務可以用開源替代方案當備案，不一定每天跑，至少要在架構評估裡存在。
對技術主管來說，這其實是一種成本治理。成本治理不是每月砍帳單，而是在設計階段就知道哪些支出是換速度、哪些支出是換穩定、哪些支出是在累積綁定風險。便宜的東西如果讓團隊走進死胡同，它其實很貴；昂貴的服務如果讓團隊避開大量維運、提高可靠度、保留遷移能力，它也可能很划算。
我會建議團隊定期做一張很樸素的表：目前使用哪些外部服務？各自負責哪個流程？資料能不能匯出？替代方案是什麼？切換需要多久？如果服務停一天、停一週、永久停用，影響範圍分別是什麼？這張表不用漂亮，但會逼大家看見平常被方便性掩蓋的依賴關係。
AI agent 讓這件事更重要。因為 agent 會把很多工具串成一條自動化路徑：讀文件、查系統、產生任務、更新狀態、通知人、甚至觸發後續流程。當工具越接越多，單一服務的變動就不只是某個頁面不能用，而可能讓整條自動化鏈斷掉。這時候，工具的可替換性、資料的可攜性、執行紀錄的可稽核性，就會從工程潔癖變成營運韌性。
低成本基礎設施真正迷人的地方，不是讓團隊永遠用免費方案活著，而是提醒我們：技術架構應該保留轉身的空間。今天用 SaaS 是為了速度，明天保留替代方案是為了安全；今天買服務是合理的，明天能不能不被服務牽著走，也是合理的。
省錢只是帳面上的好處，選擇權才是架構上的價值。當一個團隊能清楚知道自己在哪些地方被綁定、哪些地方可以替換、哪些地方必須保留主控權，它就不只是比較會花錢，而是比較不容易被環境推著走。