自建還是購買軟體：小型企業的決策指南

當你的需求很常見、出錯代價很高，而且已有一套好產品符合你的工作方式時，請購買軟體。會計、薪資、電子郵件與付款幾乎都屬於「購買」的範疇。當你的流程有很強的企業特性、現成工具逼你繞遠路，或你為了用到大型產品中的一小部分而付費時，請考慮自建。許多小型企業最後會兩者並行：核心系統購買，周邊的小工具自建。

AI 應用程式建構工具讓開發變得比過去便宜許多，這對小型、專注的工具來說改變了計算方式。但它並沒有改變一件事：你做出來的任何東西，都得自己維護。本指南提供一套判斷方法。

簡短版本

「購買」的真正成本

訂閱費只是其中一部分。購買時，你還要付出：

• 座位費。 按使用者計價的費用會隨團隊成長，有時比帶來的價值成長得還快。
• 繞路的工作。 花時間讓流程去配合工具，或把資料匯出到試算表，去做工具做不到的事。
• 供應商綁定。 你的資料與習慣都存放在別人的產品中。之後離開就得遷移。
• 價格與方案變動。 供應商會調整等級、功能與價格，而你沒有發言權。
• 串接的膠水。 串接好幾個已購買的工具，往往還需要再一個工具來連接。

你換來的價值相當可觀：主機、安全、更新、備份、合規與支援，都由別人處理。對大多數核心業務功能來說，這很值得。

「自建」的真正成本

自建一開始就有成本，也就是你使用 AI 建構工具的時間，或開發者的時間；而大家往往低估的，是之後的持續成本：

• 主機與資料庫，通常是隨使用量增加的月費。
• 維護。 函式庫需要更新，瀏覽器會改變，總有東西會壞掉。
• 安全。 登入、權限與資料保護都由你負責。
• 支援。 同事或客戶卡住時，會來找你。
• 負責人。 必須有人了解它如何運作，並負責修改。如果那個人離開，工具就可能變成無人照管的孤兒。
• 備份與復原。 萬一出問題，你需要一種方法把資料找回來。

如果想粗略了解不同方式（代理商、自由工作者與 AI 建構工具）的前期成本差異，請參閱 建構一個應用程式要花多少錢。

評分檢查表

針對你正在考慮的工具，為每個問題評分。勾選最符合的那一欄。

如果「購買」在大多數項目中勝出，就購買，而且不必為此感到內疚。如果「自建」勝出，特別是在適配與所有權那幾列，那麼自建就值得認真考慮。如果結果兩極，通常混合方案最適合。

兩個實例

以下是如何使用檢查表的示範，並非真實的企業。

一家小型會計事務所正在選擇記帳軟體。 記帳是常見功能，已有成熟產品，而且出錯會有法律後果。事務所的流程並非競爭優勢，客戶的帳目需要的是正確，而不是特別。幾乎每一列都指向購買。如果記帳產品沒有涵蓋某些需求，事務所仍可能在購買的產品周圍建構一點小東西，例如一個客戶專用的待辦頁面，顯示每位客戶還需要寄來哪些文件。

一家行動寵物美容業者正在選擇預約軟體。 預約工具很多，但這家業者有一個特殊限制：預約時間取決於路線與客戶住家之間的交通時間，而價格又依狗的體型與毛量而異。一般的預約產品會逼老闆每天晚上手動調整行程。偶爾出錯的代價不高，老闆願意維護工具，而且這個流程正是讓生意有效率的一部分。多數列都指向自建，較可能的答案是混合方案：自建預約與路線規劃應用程式，付款交給 Stripe，提醒訊息則由電子郵件或簡訊服務商發送。

規律是：某項需求越是每個企業都共通，就越可能已有好的產品；越是反映你的企業特有的運作方式，自建工具就越有價值。

混合方案：購買核心，自建周邊

對小型企業來說，最實用的答案往往既不是純自建，也不是純購買：

• 購買記錄系統，自建檢視畫面。 保留會計或 CRM，並自建一個讀取其資料的簡單儀表板或客戶專用頁面。
• 自建工作流程，購買管線。 自建你自己的預約或訂單流程，付款使用 Stripe，電子郵件使用 Resend 或 Postmark 這類服務。你自己永遠不必處理卡號。如何為你的應用程式加入付款 說明了這種模式。
• 取代試算表，而不是取代軟體。 許多「自建」的決定，其實是在處理已經超出能力範圍的試算表。如何把試算表變成應用程式 會逐步說明。
• 先自建，之後再改為購買（或反過來）。 一個小型自建工具，可以先證明你真正需要什麼，然後再承諾昂貴的產品；也可能讓你發現自己需要開發者。

AI 應用程式建構工具如何改變決定

直到最近，就算是建構一個小型內部工具，也需要聘請開發者，因此「購買」幾乎成了所有事情的預設。AI 應用程式建構工具改變了等式的前半部：非開發者現在可以描述一個追蹤工具、入口網站或儀表板，並很快得到可運作的版本。

但它們並沒有改變後半部。一個花一個下午做出來的工具，仍然需要有人負責、保護它的安全，並讓它持續運作。AI 建構工具實際的影響是：

• 小型、專注的工具，例如追蹤工具、收件表單、審核流程與儀表板，明顯傾向「自建」。
• 受監管或攸關安全的東西仍然是「購買」，或「由開發者審查的自建」。
• 實驗變得便宜。 你可以先做一個粗略版本，了解自己需要什麼，再決定要不要承諾。

我們的內部工具建構指南一步一步說明，而團隊內部工具構想則提供具體範例。

購買前要問供應商的問題

• 我能否隨時以可用的格式匯出所有資料？
• 當我們增加使用者或資料時，價格會如何變化？
• 如果我取消服務，我的資料會怎麼樣？
• 它能否與我們已在使用的工具整合，還是需要另一個連接服務？
• 出問題時，我該聯絡誰？他們回應的速度如何？

自建前要想清楚的問題

• 誰擁有這個工具？誰是他的備援人員？
• 資料存放在哪裡？如何備份？
• 誰可以登入？每個人能看到什麼？
• 如果你使用的建構工具或平台消失了，你能否把程式碼帶走？
• 能解決問題的最小版本是什麼？

如果你無法回答第一個問題，就先不要自建。

常見錯誤

• 自建已經有解決方案的東西。 客製化的會計或電子郵件發送，通常不值得。
• 為用不到的功能購買。 企業方案的定價是為大型企業設計的。
• 只比較訂閱價格與自建價格。 應該比較兩年左右的總成本，並把你的時間算進去。
• 沒有負責人。 沒有負責人的自建工具會逐漸腐壞；沒有負責人的購買工具，則會被設定錯誤。
• 非黑即白。 大多數良好的做法都是混合方案。

Mythex 的定位

如果你決定自建，Mythex 是一款 AI 應用程式建構工具，適合本指南所說的那種小型、專注工具：你描述工具，它會建構並在即時預覽中執行，需要儲存資料時加入資料庫，並發佈到團隊可以使用的網址。協作者沒有每位使用者的費用，如果座位定價正是讓你想離開已購買工具的原因，這一點很重要。在 Pro 方案中，你可以匯出程式碼或同步到 GitHub，因此之後開發者可以接手。詳見 GitHub 與匯出。方案與點數請參閱 價格頁面。

常見問題