最近幾次 discovery call,只要對方看過我們「兩個文組人六週蓋出一套 CRM」那篇文章,幾乎都會問同一句:「所以我們也別買 SaaS 了,直接叫 AI 幫我們寫一套就好,對吧?」
我通常不直接回答對或不對,先反問一句:你要自建的這套系統,是你們贏的關鍵流程,還是隨便一家 SaaS 都長得差不多的功能?
這個問題問下去,對話通常就變了調。AI 確實讓「不會寫程式也能做系統」這件事變成真的——我們自己就是活生生的例子:Zynkr 三套已上線系統(CRM/平台、CMS、記帳)全部 powered by Claude,由兩個非工程師背景的創辦人動手蓋出來。但「做得出來」跟「該不該做」,是兩件事,搞混了,吃虧的通常是自己。
自己用 AI 做系統還是買 SaaS,關鍵不在你會不會寫程式,而在這套流程是不是你的差異化核心、要不要深度整合自己的資料——判斷對了,自建才划算。
▋「自己用 AI 做系統 還是 買 SaaS」為什麼問錯了?先問這套流程是不是差異化核心
先給一個可以直接拿去用的答案:別問「能不能自建」,問「這套流程值不值得你自己扛」。
AI 把「不會寫程式也能做系統」這件事變成了真的——vibe coding 自建讓你用對話就能生出一個跑得起來的系統雛形,這在兩三年前幾乎不可能。所以每次我們公開講「兩個文組人六週蓋出一套 CRM」(完整 build log),最常收到的反應都是「那我乾脆也自己做好了,幹嘛還花錢買 SaaS」。
這個反應本身沒有錯,錯的是問題問得太早。「能不能自建」幾乎每次都是能——AI 拉低的是執行門檻,不是判斷門檻。真正決定自建划不划算的,從來不是你會不會寫程式,而是這套流程本身值不值得你自己扛下去維護、扛下去負責。
打個比方:自建系統更像是自己開一間廚房,買現成 SaaS 更像是叫一間已經營運多年的餐廳外送。廚房蓋起來的門檻現在很低,但蓋完之後,火要自己顧、食材要自己進、出了食安問題也是自己擔。你該問的其實是「這道菜是不是我的招牌、值不值得我自己顧」,能不能蓋廚房從來不是重點。
▋「自建四問」:什麼情況該自建,四個問題先問過一遍
先給一個可以直接拿去用的答案:這四題裡,前三題答「是」、第四題你敢點頭,才該自建;有一題答不出來,買現成的更划算。
我們內部把這套判斷收斂成一個框架,叫「自建四問」。不是什麼複雜的方法論,是我們自己蓋三套系統之前,一題一題問過自己的東西。
1️⃣ 這個流程是不是你的差異化核心? 如果這套流程就是客戶選你、不選別人的原因,買來的 SaaS 只會讓你長得跟所有人一樣——功能對齊了,差異化也被磨平了。
2️⃣ 要不要跟自己的資料、其他系統深度整合? 多數 SaaS 開放的接口只到某個深度,再往下就碰壁。如果你要的是跟自己現有資料庫、內部流程緊密咬合,買來的系統能開的窗口通常不夠大。
3️⃣ 市面上的 SaaS,對你的規模跟預算來說是太貴還是太重? 很多國際大廠的 SaaS 是照大型企業的需求堆出來的,一個小團隊買單,常常是為了用不到兩成的功能,付出對應大企業的價格。
4️⃣ 出問題的時候,團隊扛得住維護債、資安跟金鑰管理嗎? 這題最常被忽略,卻最重要。自建系統做完不是結束,是開始——之後的維運、資安漏洞修補、金鑰輪替,都沒有供應商替你兜底,全部自己擔。
前三題決定「自建划不划算」,第四題決定「你有沒有準備好自建」。三題都答「是」,第四題卻心虛,先別急著動手。
▋自建 vs 買 SaaS:同一張表,兩邊的取捨長什麼樣
先給一個可以直接拿去用的答案:自建換來的是客製深度跟長期主控權,代價是維護責任全部自己扛;買 SaaS 換來的是穩定跟省事,代價是永遠長得跟別人一樣。
把「自建四問」攤開來看,兩條路徑的取捨其實很清楚:
自建系統 — 客製深度:高,流程完全照你自己的邏輯走 · 上線速度:取決於流程複雜度,簡單流程搭配 AI 輔助可能比你想的快 · 長期成本:前期時間成本高,但沒有持續訂閱費 · 維護責任:全部在自己團隊身上 · 適合情境:流程是差異化核心、需要深度整合自己系統
買現成 SaaS — 客製深度:低到中,只能在對方開放的設定範圍內調整 · 上線速度:通常最快,簽約當天就能用 · 長期成本:持續訂閱費,規模一大費用跟著漲 · 維護責任:供應商擔,含資安更新與法規遵循 · 適合情境:流程通用、需要長期穩定與合規保證
這兩條路沒有「比較高級」這回事,只有「適不適合你現在的處境」。我們自己在蓋 CRM、CMS 時選了自建,但同一個團隊裡,也有我們主動選擇買現成方案的地方——這才是判斷該有的樣子,不逢自建必用,也不逢 SaaS 必棄。
▋那 Zynkr 自己怎麼做?三套上線系統的真實判斷過程
先給一個可以直接拿去用的答案:CRM 跟 CMS 我們選擇自建,是因為流程本身就是差異化核心;記帳系統的自建,則是我們主動畫了一條界線,沒有把它當成能推薦給所有人的答案。
Zynkr 現在正式上線在用的三套系統——CRM/平台、CMS、記帳——全部 powered by Claude,由我(非工程師背景)跟另一位共同創辦人(同樣非工程師背景)動手蓋出來。三套系統各自「為什麼自建」,答案並不一樣。
CRM/平台是我們把「自建四問」套得最徹底的一套。業務流程、跟客戶對談的脈絡、我們怎麼判斷一個 lead 值不值得跟進,這些本身就是我們的差異化——市面上的 CRM SaaS 再強,也是照通用銷售流程設計的,硬套上去只會磨平我們自己的判斷邏輯。加上要跟內部的技能市集、顧問案子的資料深度串接,買來的系統開放的接口永遠不夠深。兩個文組人花六週蓋出第一版能上線的雛形(完整 build log),驗證了流程複雜不代表非工程師做不動。
CMS 的邏輯類似:我們的內容產製,從選題、草稿到上架,本身就是一條 AI 深度參與的流程,需要跟撰寫用的 agent、發布流程緊密咬合。買一套通用 CMS,頂多幫我們存文章,接不進這條流程的核心。
記帳系統,反而是我們拿來提醒自己「自建不是萬靈丹」的例子。我們確實自建了記帳系統,但那是單一使用者(我自己)的第一版,為的是跟我們自己的資料流程對得上;它處理不了多實體、跨法規報稅這種通用合規需求。如果你的記帳需求要符合複雜的稅務法規、多人多單位共用,買一套經過多年合規驗證的現成方案,通常比自己蓋一套更穩——法規遵循的責任,讓供應商一起分擔,好過全部壓在自己團隊身上。這也呼應「自建四問」的第四題:維護債、資安與金鑰管理,團隊扛不扛得住,答不出來就先別自建。
▋常見問題(FAQ)
Q1:不會寫程式真的能用 AI 蓋出能上線的系統嗎?
真的可以,但有前提。Zynkr 自己的三套系統——CRM/平台、CMS、記帳——都是兩位非工程師背景的創辦人用 AI(powered by Claude)動手蓋出來、目前正式上線在用的,不是停在提案階段的雛形。前提是你得先想清楚要蓋什麼、蓋給誰用——AI 補的是「寫程式」這段執行門檻,判斷該不該蓋這件事,還是得靠你自己。「兩個文組人六週蓋出一套 CRM」的完整過程,寫在這篇 build log裡。
Q2:自建系統要花多久?
取決於流程複雜度,沒有統一答案。我們蓋 CRM 第一版能上線的雛形花了六週,那是在流程已經想清楚、AI 輔助寫程式的情況下;流程越複雜、要整合的系統越多,時間自然拉長。比起糾結「幾週能蓋完」,更值得先問「自建四問」裡的前三題——流程複雜但確實是差異化核心,時間成本通常划算;流程簡單、市面已有成熟 SaaS,硬要自己蓋反而是浪費時間。
Q3:自建的系統之後維護怎麼辦?
維護責任全部在自己團隊身上,這是自建跟買 SaaS 最大的差別。系統上線只是開始,後續的資安更新、金鑰輪替、bug 修補、隨需求變化的調整,都沒有供應商替你兜底。這也是「自建四問」第四題特別把維護債跟資安獨立拉出來問的原因——回答不出團隊扛不扛得住,代表還沒準備好自建。
Q4:哪些系統不建議自建?
通用型、法規導向的需求,買現成方案通常比自建更穩。像是要符合複雜稅務法規、多實體多單位共用的記帳系統,或涉及嚴格合規要求的領域,現成方案經過多年市場驗證、供應商替你擔一部分合規責任,自己蓋一套等於把這份責任全部扛在自己團隊身上。判斷原則很簡單:這流程如果不是你的差異化核心,買現成的通常比自建划算。
Q5:自建前要先準備什麼?
先把「自建四問」問過一遍,再動手。具體來說:先想清楚這套流程是不是你真正的差異化核心、要不要深度整合自己的資料、市面 SaaS 對你的規模是不是太貴太重、團隊扛不扛得住之後的維護跟資安責任。這四題想清楚了,再考慮用 AI 動手蓋——如果判斷結果是流程太複雜、內部又還沒能力先梳理清楚,找一個顧問夥伴可能比自己硬蓋更快,這也是我們在「自建、買 SaaS、還是找顧問」的三叉決策樹裡講過的判斷脈絡。
▋結語
自己用 AI 做系統還是買 SaaS,答案從來不在「你能不能」,而在「這套流程值不值得你自己扛」。
Zynkr 自己的 CRM/平台、CMS、記帳三套系統,都是 powered by Claude、由兩個非工程師背景的創辦人動手蓋出來、正式上線在用的——每一套動手之前,都經過我們自己「自建四問」的檢驗。
如果你正在盤算要不要自己動手蓋一套系統,拿不準該自建、買現成,還是找外援,歡迎預約一次 AI 導入決策診斷(discovery call),把你的情況攤開來,一起過一遍判斷。