如何以自己的工具取代昂貴的 SaaS（以及何時不應這樣做）

以自己的工具取代昂貴的 SaaS 訂閱，在以下情況下可能是合理的：你只使用大型產品的一小部分功能、為了很少登入的人而按座位付費，或者產品無法配合你的工作流程。但如果供應商正在代你持續進行艱巨的工作（例如安全、合規、郵件送達能力或系統整合），取代通常就不划算。訂閱費用是看得見的，但當你離開時需要承擔的維護、安全及支援工作卻是看不見的，而這些才決定轉換是否值得。

AI 應用程式建置工具已經大大降低了「建置」的成本。本指南講的是其餘的部分。

坦白的取捨

付費使用 SaaS，買到的不只是功能：

對於只有少數內部用戶的小型工具，部分項目會比較容易處理；不論規模大小，某些項目始終都很困難。問題不是「我們建置得到嗎？」——借助 AI，你通常做得到。真正的問題是「我們能否承擔起它的管理責任？」

何時取代 SaaS 是值得的

理想的取代對象通常具備以下特點：

• 你只使用大型產品的一小部分。 例如只把一套完整的專案管理軟件當作共享待辦清單使用，或只把 CRM 當作附有備註的聯絡人名冊。
• 按座位收費令你吃虧。 很多人只是偶爾需要存取，但每一位都要付月費。
• 你的工作流程與工具互相抵觸。 人們為了彌補產品不合用，保留了匯出的檔案及額外的試算表。
• 資料結構簡單。 記錄、狀態、備註及少量檔案，沒有複雜的會計或信用卡資料。
• 用戶是內部人員或人數不多。 你的團隊，或一小群已知的客戶。
• 有負責的人。 有一位指定的人會照顧它。

典型的例子包括：簡單的追蹤器、收件及申請表格、審批流程、內部通訊錄、客戶進度頁面、輕量級 CRM、匯總數字的儀表板，以及單一業務的預約頁面。

何時不值得取代

在以下情況下，應繼續付費，或尋找較便宜的產品，而不是自行建置：

• 錯誤會招致法律或財務後果。 例如會計、薪金、稅務，或必須符合當地規定的發票系統。
• 供應商提供的是專門的基礎設施。 例如電郵發送（維持發信聲譽非常困難）、信用卡付款（安全標準嚴格）、影片串流或電話服務。
• 安全本身就是產品。 例如密碼管理器、身分識別及單一登入，或任何儲存健康或財務紀錄的工具。
• 系統整合才是它的價值所在。 如果工具的價值在於能與數十個其他系統連接，要重新建置這些連接將會是一項龐大而持續的工作。
• 許多外部用戶依賴它。 面向公眾的工具需要支援、正常運行時間及無障礙設計，而這些責任將由你承擔。
• 沒有人能夠承擔管理責任。 如果只有建置它的人明白運作方式，而他又很忙或即將離開，你就是在為未來製造問題。

一個實用的折衷方案是：取代昂貴產品的介面，同時保留專門的服務作為底層。例如自行建置預約流程，但付款使用 Stripe，確認電郵則使用電郵服務供應商。

計算真正的成本

在轉換之前，把雙方的成本都寫下來。

現有 SaaS 的成本：

• 訂閱費，包括你未來一兩年可能加入的座位。
• 你需要的附加功能及較高級的方案。
• 處理變通方法及額外試算表所花費的時間。

自建工具的成本：

• 建置時間：你自己的時間，或開發人員的時間。
• 運行成本：託管、資料庫、檔案儲存、電郵或付款手續費。
• 每月的維護時間：更新、修正，以及人們要求的小改動。
• 支援時間：回答問題，以及為新成員安排入門。
• 風險：一天停止服務或數據出錯，會招致多少損失。

如果兩者數字接近，就保留 SaaS。只有當節省的金額清晰，而且你自己的工具也確實比現有產品更適合你時，建置才值得投入精力。有關各種方法的前期成本比較，請參閱建立應用程式需要多少錢。

削減 SaaS 費用的其他方法

建置並非削減 SaaS 費用的唯一方法。在作決定之前，先考慮以下幾點：

• 降低方案或減少座位。 很多團隊為已離職或很少登入的人付費。檢查實際使用工具的人，就可以在不改變其他任何東西的情況下削減費用。
• 詢問價錢。 年費計劃、非牟利機構或初創公司專用的計劃，以及直接向供應商的銷售團隊查詢，都可能令價格下降。
• 改用較簡單的產品。 如果你只使用大型工具的一小部分，專注於該部分功能的較小產品，可能費用更低，也更貼合需要。
• 善用你已經付費的工具。 辦公室套件及現有工具，往往已經能夠應付簡單的需要，例如表格、共享清單及基本儀表板；人們原本為這些功能另外購買了不同產品。
• 整合。 兩至三個功能重疊的工具，有時可以合併為一個。

如果其中一種方法已經能解決問題，它通常是較好的選擇：不需要建置時間，不需要維護，而且供應商仍然負責困難的部分。只有當以上方法都不適用，而且擁有該工具的理由很清楚時，才考慮建置。

轉換檢查清單

建置之前

• 從現有工具匯出資料，並檢查內容。留意缺少的項目：附件、留言、歷史紀錄、記錄之間的連結。
• 列出人們真正使用的功能。直接問他們，不要自行猜測。
• 列出供應商為你做、而你將會失去的工作（見上表）。
• 指定負責人及後備人員。
• 檢查合約：通知期、續約日期，以及取消後的資料刪除安排。

建置期間

• 只建置人們實際使用的功能，其餘的不必理會。
• 從一開始就設定登入與權限，並決定誰可以查看什麼。
• 將機密資料（API 金鑰、密碼）保存在環境變數中，而不是程式碼裡。
• 加入簡單的匯出功能，確保你的資料不會被困在自己的工具之中。
• 完成 AI 建置應用程式的安全檢查清單。

取消之前

• 匯入已匯出的資料，並檢查數量及抽樣記錄。
• 讓兩個工具並行運作一段短時間。
• 確保備份可以運作，並實際還原一次備份。
• 為備份負責人寫一份簡短的「這個如何運作」說明。
• 完成以上所有步驟後才取消，並在取消前先下載最後一次匯出的檔案。

實際的維護、安全與支援工作

維護

小型工具需要的維護不多，但仍然需要。設定定期提醒，以更新依賴項目、檢查登入及主要流程是否仍然正常，並清理無人使用的東西。保存一份用戶要求的清單，並分批決定，而不是逐一即時處理。

安全

大部分的安全工作，都在於做好基本功夫：每個顯示資料的頁面都要檢查登入者的身分；用戶只能查看他應該查看的記錄；機密資料只留在伺服器端；輸入內容要經過驗證；並且備份必須存在。如果工具保存了客戶的個人資料，就要考慮誰可以匯出，以及資料保存多久。如有疑問，在真正的資料放入之前，請開發人員檢視一次。

支援

事先決定用戶如何回報問題：共享的通訊頻道、電郵，或工具內的表格。並撰寫一份一頁紙的使用指南。使用的人越多，這件事就越重要，而它也是最常被忽略的成本。

如果你改變主意

擁有程式碼會給你更多選擇。如果工具發展到你不想再自行管理的程度，你可以把它交給開發人員或工作室接手，前提是你能夠把程式碼帶走。在任何平台上開始建置之前，先確認這一點是值得的。如何匯出並自行託管 AI 建置的應用程式 會講解其中涉及的內容。而且，在你清楚知道自己的確切需要之後，重新回到付費產品也完全沒有問題。

在 Mythex 上建置取代工具

如果數字顯示應該建置，Mythex 很適合用來製作這類專注的取代工具：你在對話中描述需要的功能，它會建置並運行，需要儲存資料時會加入 Postgres 資料庫，然後發佈。託管、資料庫及檔案儲存與建置共用同一個點數餘額，協作者也不需要按座位額外付費。Pro 計劃可以匯出專案或同步到 GitHub，所以你永遠不會被綁死在平台上；詳情請參閱 GitHub 與匯出。想比較計劃，請瀏覽價格頁面；如果你仍在考慮，可閱讀小型企業自建與購買軟件的比較。

常見問題