上週我們在恆遠內部跑開發週會時，工程同事丟了一個 GitHub 連結出來，一家 28 人的歐洲 SaaS 公司，靠把 GrowthBook 自架在自己的 AWS 上，省下原本要付給 LaunchDarkly 的一年三萬美元訂閱費，然後拿其中六千美元發給內部負責 A/B test 治理的兩位工程師當績效獎金。
這件事在我們團隊裡引發了一輪討論，因為過去 12 個月，我們在自家三個產品（秒發報價Pro、開課王、IG Post Manager）上跑了 8 個以上的 feature flag，控制官網 UI 改版的灰度發布、A/B 測試新註冊流程、限定 beta 用戶看到 AI 自動建議功能。我們用的就是 GrowthBook 自架版，DB 跑在自己的 Postgres 上，整套工具的「邊際成本」就是 EC2 一個月的 35 美元。如果一年前選了 LaunchDarkly Pro 方案、5 個 seat、一年 7,200 美元，同樣的事我們會付 200 倍的價格。
這篇要拆解的就是這個決策，A/B Testing 和 Feature Flags 這兩個工具該怎麼選、什麼時候該掏錢買 SaaS、什麼時候自架划算、什麼時候根本不該碰。我們會把市面上四條主要路徑（LaunchDarkly / Statsig / GrowthBook / Unleash）攤開來，用同一把尺評比，並且把恆遠在合約談判和開源自架實作上踩過的坑都寫出來。
給中小企業老闆、產品經理、CTO、採購評估者看的，你會在這篇拿到 6 個治理決策節點、5 條合約紅線、3 個報價區間，以及實際採購前該問的問題清單。我們把過去 12 個月在恆遠內部跑 GrowthBook 自架、評估過 LaunchDarkly 跟 Statsig 報價、甚至幫客戶談下 Statsig Enterprise 條款的所有第一手經驗都濃縮在裡面。
中小企業老闆採購這類工具最常踩的坑有三個，買到「自己用不到的進階功能」、簽到「條款對自己不利的 3 年合約」、或被「自架划算」這句話騙進去花了 80 小時工程時間建一個其實用不到的內部平台。這篇要幫你避開的就是這三個常見錯誤。
ℹ️為什麼這篇值得看完
市面上大多數 Feature Flag 採購文章是平台廠商或代理商寫的，你看到的是「為什麼要用」「為什麼貴的好」。這篇是恆遠數位科技自己在內部產品線上跑了 8+ feature flag、評估過 4 家平台後寫的買方視角文章。我們沒有任何一家 Feature Flag 平台的代理或聯盟關係，所有數字都標註 2026 年 6 月當期定價來源。
A/B Testing 跟 Feature Flags 到底是不是同一件事
進到採購話題之前，先把這兩個詞釐清，因為市面上 60% 的混亂來自把它們當成同一回事。Feature Flag 是「開關」，A/B Testing 是「實驗」，兩者技術底層相通但目的完全不一樣。
Feature Flag 的核心功能是「在 production 環境動態控制某段程式碼要不要執行」，例如新版搜尋演算法只開給 5% 的用戶、新註冊流程限定 VIP 客戶看到、夜間批次任務出問題時用 flag 一秒關掉。它的價值是把「部署」和「發布」分開，程式碼可以上線但功能不開，等準備好了再開。
A/B Testing 則是「同時讓兩個版本上線、收集行為數據、用統計檢定判斷哪個贏」。它要求平台具備事件收集（events ingestion）、實驗組分流、統計引擎（通常是 t-test、Bayesian、CUPED 等）、結果儀表板。
兩者的關係是：A/B Testing 通常需要 Feature Flag 當底層機制（用 flag 把用戶分組），但 Feature Flag 不一定要做 A/B Testing。一家公司可能只用 flag 做灰度發布而從不跑實驗，這在中小企業反而是常見的起點。
ℹ️我們的判斷：先有 Flag 再談 A/B
對營收月 500 萬以下、產品 PV 月 10 萬以下的中小企業，我們的建議很直接，先把 Feature Flag 接起來、控制灰度發布跟緊急回滾就好，A/B Testing 那一層等到你有了至少 3 個假設想驗證、且每天有 1000 個活躍用戶可以分組之後再投入。原因是 A/B Testing 的統計檢定需要樣本量，PV 太少跑出來的結果信賴區間寬到沒辦法做決策，這時你付的訂閱費等於是繳「實驗失敗的學費」。
業界數據也支持這個判斷。Verified Market Reports 在 2026 年 4 月的調查指出，A/B 測試軟體市場規模約 9.8 億美元，
但其中 約 72% 的採購來自大型企業中小企業（員工 50 人以下）只佔約 18%。這個數字告訴我們，A/B Testing 工具的真實價值門檻，本來就壓在中大型流量的產品上。中小企業如果硬要跟，多半會買到自己用不到的功能。
4 條採購路徑的本質差異與決策樹
市面上的 Feature Flag / A/B 平台可以分成四條路徑：訂閱型 SaaS 的代表 LaunchDarkly、事件計費型 SaaS 的代表 Statsig、開源自架的代表 GrowthBook、純開源 + 企業版的代表 Unleash。我們先把它們的本質差異攤開，這比看價格表更能幫你判斷該往哪條路走。
路徑一：LaunchDarkly ， 訂閱型 SaaS 的天花板
LaunchDarkly 是這個品類的市場領導者，2024 年估值約 4 億美元，企業客戶涵蓋 Atlassian、IBM、Microsoft 等。它的定價模型是「Service Connection × Plan Tier」雙軸計費：Foundation 方案 $10/connection/month（年繳），Pro 方案 $12/seat/month，Enterprise 與 Guardian 為客製報價。
Vendr 2026 採購數據 顯示，中小型團隊年度合約金額落在 1.5 萬至 5 萬美元，企業級部署可上看 15 萬美元以上。LaunchDarkly 不公開列表定價，所有交易走銷售團隊報價，這也是它被詬病為「歡迎企業、不歡迎自助購買」的主因。
路徑二：Statsig ， 事件計費的後起之秀
Statsig 走的是完全相反的路線：免費 Developer 方案就提供 200 萬 events/月、不限 seat 數、不限 flag check 數，僅在 A/B 實驗事件累積超過免費額度後才開始計費。Pro 方案 $150/月起跳、含 500 萬 events，超出後每千 events $0.05。
Statsig 的賣點是「flag check 永遠免費」，這對只想用 flag 做灰度發布、不跑大規模 A/B 測試的中小企業極友善。Statsig 還有 Startup 方案，新創團隊可以申請 12 個月的 Enterprise tier 試用、含 10 億 events 額度，這在實務上等於是「免費跑一年再看要不要升級」。
路徑三：GrowthBook ， 開源 MIT 授權的自架方案
GrowthBook 採用 MIT 授權，自架版完全免費、無 seat 限制、無 flag 限制、無 event 限制。Cloud 版的 Starter 免費（3 用戶、100 萬 events/月），Pro 每 user $40/月起。它的特色是內建統計引擎完整，CUPED、Sequential testing、Bayesian、Multi-armed Bandit 都有。
我們公司內部用的就是 GrowthBook 自架版，跑在 ECS Fargate 上，連我們自己的 Postgres data warehouse。GrowthBook 官方 pricing 明確指出他們不收 MAU、不收 API call、只收「真的負責管實驗的人」的 seat 費，這個模式對中小企業特別划算，你的終端用戶看到 flag 不會被計費。
路徑四：Unleash ， Norway 出品的歐洲方案
Unleash 走 Apache 2.0 授權的開源路線，Free OSS 版本可自架但限制 1 project / 2 environment。Pro 雲端方案 $75/seat/month、含 5300 萬 API 請求；Enterprise 版本最低 5 seat、年繳 $4,500 起跳，提供多區域 Edge、SSO、RBAC。
Unleash 比較特別的一點官方公告 OSS Edge 將於 2026 年 12 月 31 日 sunset，之後自架到一定規模就需要付費 Enterprise Edge。如果你打算選 Unleash 走「永久免費自架」，這個時間點要列入合約評估。
把四條路徑用同一把尺攤開，這是我們在內部評估會議上實際畫出來的對照表，可以直接拿去你的採購會議用。
維度 | LaunchDarkly | Statsig | GrowthBook 自架 | Unleash |
|---|---|---|---|---|
起步成本（10 人團隊 / 月） | $600（Pro） | $0（Developer） | $35（EC2） | $0（OSS） |
計費基礎 | Per seat + Service Connection | Events 量 | Self-host seat 無上限 | Per seat（Cloud） |
A/B 統計引擎 | ✓ 進階（Pro+） | ✓ 內建 CUPED | ✓ Bayesian + Sequential | ✗ 需外接 |
自架可行性 | ✗ 純 SaaS | ✗ 純 SaaS | ✓ MIT 授權完整 | △ OSS 有限制 |
適合誰 | 年收 1 億+ 的企業 | 3-50 人成長期新創 | 有 1 位 DevOps 的 SMB | 歐洲合規敏感企業 |
ℹ️我們認為，「未來 3 年的 Feature Flag 市場會被 LLM 切走一塊」
把鏡頭拉遠看，A/B Testing 這個品類的核心假設是「人類做不出最佳 UX，需要靠統計實驗找出來」。但 2026 年下半年我們已經看到 OpenAI、Anthropic 都在實驗「讓 LLM 自己提出 UX 變體、自己跑 A/B、自己判讀結果」的工作流。3 年後，真正能做 A/B 的可能會是把 LLM 嵌進去的下一代平台，LaunchDarkly 跟 Statsig 都得做這層整合才能擋下來。對中小企業的意義很實在：現在別簽 3 年合約，留下換工具的彈性。
6 個治理決策，中小企業老闆採購前該問的問題
採購 Feature Flag 平台不是「挑最便宜的」也不是「挑最大牌的」。在我們陪客戶評估系統採購的經驗裡，真正決定買對的，是先把這 6 個治理問題答清楚，回頭再選工具就會很快。
決策一：你的真實需求是 Flag 還是 Experiment？
這是最常被跳過的問題。回去看你的產品 backlog，過去 6 個月，你做了幾次「想開新功能但又怕炸到 production」的部署？做了幾次「想知道兩個版本哪個轉換率高」的實驗？
前者是 Feature Flag，後者才是 A/B Testing。如果你大部分需求是前者，買 LaunchDarkly Pro 或 Statsig Pro 都是浪費，免費的 Unleash OSS 或 GrowthBook Cloud Starter 就能滿足。如果你是後者，且樣本量足夠（每天 1000+ 活躍用戶），再去看 Statsig 或 LaunchDarkly Experimentation 加購模組。
決策二：你的部署環境支持自架嗎
如果你的 production 環境本來就跑在 AWS / GCP / Azure 上，且有 1 位以上熟 Docker 的工程師，自架 GrowthBook 或 Unleash OSS 是極理性的選項。我們內部 GrowthBook 跑在 Fargate 上，整套服務每月成本約 35 美元，且資料完全留在自家 VPC、沒有任何 cross-cloud 傳輸。
但如果你的開發團隊本來就忙於本業、沒有人能維運第三方服務，這時 Statsig 免費 Developer tier 或 LaunchDarkly Foundation 反而是更穩的選擇。自架的隱藏成本是「半夜服務炸了沒人接」。
決策三：資料主權是不是強制條件
金融、醫療、政府標案類的客戶會被要求「使用者行為資料不能離境」。這時 LaunchDarkly / Statsig 等美國 SaaS 直接出局（除非你能談下 EU region 或台灣 region，但這通常綁 Enterprise 合約）。GrowthBook / Unleash 自架版可以讓所有資料留在你指定的雲區域。
決策四：你打算跑幾組實驗
Statsig 的計費基於 events 量，如果你預期 12 個月內會跑 30+ 組實驗、每組樣本量 5 萬以上，事件量會快速爆衝（一個用戶在實驗中觸發 3-5 個事件是常態）。這時 LaunchDarkly Pro 的 per-seat 模式反而比較好預測成本。如果你只跑 3-5 組實驗，Statsig 的免費額度應該完全夠用。
決策五：你的工程文化能不能 own flag 治理
這是大多數採購會議跳過的「軟性決策」。Feature flag 用久了會變垃圾，上線測試完忘了關、永遠 100% rollout 卻沒刪除、半年後沒人記得這個 flag 控的是什麼。這叫做 flag debt（旗標債）。
根據 LaunchDarkly 2024 State of Feature Management Report沒有治理流程的團隊平均有 35% 的 flag 是「死碼」（dead flags），這些 flag 佔據程式碼複雜度但已經無用。所以選工具之外，你還要決定「誰負責每月盤點 flag 並關掉死碼」，通常是 tech lead 或 staff engineer。沒有這個角色，買哪家平台都會撞牆。
決策六：採購預算 vs 工程時間預算的轉換比
最後一個決策節點是會計問題。LaunchDarkly Pro 5 seat 年繳 $7,200 美元，這個錢如果換算成工程師時間，大約是一位中階工程師 80-100 小時的薪資成本（台北行情，含勞健保）。
問題變成：自架 GrowthBook 或 Unleash 需要多少工程時間？我們的實測數據是，第一次部署約 16 小時（含 docker-compose、Postgres、Redis、reverse proxy 設定），上線後維運每月約 4 小時（更新版本、處理告警）。換算 12 個月維運成本約 64 小時，加上初次部署 16 小時 = 80 小時。
這就是為什麼我們前面說「年營收 500 萬以下的公司，自架划算」，你的工程時間相對昂貴，但比起連年訂閱費仍然 ROI 更高。年營收 5000 萬以上、開發團隊 10+ 人時，工程師時間更貴，這時付 SaaS 訂閱費讓他們專心做本業反而合算。
3 個報價區間，中小企業實際會付多少錢
把上面 6 個決策套到實際採購情境，我們整理出三個典型報價區間。這是 2026 年 6 月當期、針對台灣中小企業的實測報價（恆遠協助客戶評估或自家詢價的真實樣本）。
情境 | 輕量入門：5-10 人團隊、月 PV < 10 萬 | 成長期：10-30 人團隊、月 PV 10-100 萬 | 企業級：30+ 人團隊、月 PV 100 萬+ |
|---|---|---|---|
年成本（USD） | $0 - $1,800 | $5,000 - $18,000 | $30,000 - $150,000+ |
年成本（TWD 約值） | 0 - 5.8 萬 | 16 - 58 萬 | 97 - 487 萬+ |
推薦路徑 | GrowthBook 自架 / Statsig Developer 免費 / Unleash OSS | Statsig Pro $150/月 起 + 自架 GrowthBook 雙軌 | LaunchDarkly Enterprise + Statsig Enterprise |
含什麼 | 基本 flag、灰度發布、少量 A/B | 實驗統計引擎、SSO、Audit log、SLA | 多 region、SOC2、客製合約、專屬 CSM |
不含什麼（要另外付） | 商用 SLA、企業 SSO | Multi-region、HIPAA、SAML 進階 | 通常都全包，但要小心 add-on |
中小企業老闆最常問的問題，「我月營收 300 萬，到底該付多少給 feature flag 平台」？答案是：如果你還沒上 SOC2 客戶、沒有金融或醫療合規要求、產品也不是高頻 A/B 實驗導向，正確答案是「$0」，用 GrowthBook 自架或 Statsig Developer 完全夠用。把那 5 千美元省下來投資前端速度優化或客服 AI，ROI 高 5 倍以上。
如果你正在評估 Feature Flag 平台、但卡在「自架還是買 SaaS」這道題，我們很樂意 聽你聊聊現況，一起看看以你公司目前的技術棧跟團隊規模，哪條路徑最划算。如果是想把 AI 流程跟 feature flag 結合（例如用 flag 控制不同 LLM 模型的灰度發布），可以參考我們的 AI 系統開發服務。
5 條合約紅線，簽 SaaS 訂閱前必須鎖死的條款
⚠️簽訂閱合約前的 5 條紅線，任何一條沒鎖死都會被坑
Feature Flag SaaS 廠商的合約陷阱比想像中多，尤其當你從 Developer / Foundation 升級到 Pro / Enterprise 時，條款細節決定你接下來 3 年的議價權。下面 5 條紅線是我們陪客戶談 SaaS 訂閱、評估自家採購時整理出來的，簽合約前一條一條對照。
紅線一：自動續約條款（auto-renewal terms）
美國 SaaS 廠商的標準合約往往內建「除非提前 60-90 天書面通知，否則自動續約並按 list price 漲幅 10-20%」。你以為簽的是 1 年合約，實際上是「一旦過了取消窗口就再綁 1 年」。談判時必須把通知期改為 30 天、續約價格漲幅綁定 CPI（消費者物價指數），不接受 list price 自動上漲。
紅線二：用量超額計費的單價鎖定
Statsig 的事件超額是 $0.05 / 1K events，聽起來不多，但你在跨年 sale 流量爆衝時，一個月可能多付 5,000 美元意外帳單。談合約時要求「超額單價在合約期內鎖定」，並要求「超額 X% 觸發 email 告警」這條條款。
紅線三：資料匯出與 vendor lock-in
你在這家 SaaS 上累積 12 個月的實驗紀錄、flag 配置、用戶分組，這些是有商業價值的資產。合約要明寫「終止合約後 30 天內可全量匯出 JSON / CSV、廠商提供 API 配合移轉、過渡期不收費」。沒寫這條，廠商在你想換工具時可以用「資料只能在 admin 介面手動下載」拖你 6 個月。
紅線四：SLA 細節與賠償上限
「99.9% uptime SLA」聽起來很安全，但細看通常是「達不到時退月費的 X%」，所以即使 LaunchDarkly 整月宕機，你最多拿回一個月訂閱費，這完全 cover 不了你 production 因此炸掉的損失。Enterprise 合約要爭取「SLA 違約金以年費為基礎、不設賠償上限」，但廠商通常會把上限壓在年費 1.5 倍，這算是合理範圍，但「無上限」是中型企業多半談不下來的。
紅線五：審計權與安全條款
如果你的客戶有金融、醫療、上市櫃合規需求，合約必須明訂「廠商配合年度 SOC2 / ISO 27001 報告分享、客戶有權派第三方稽核」。沒寫這條，你下游客戶的合規團隊會直接打槍你的供應鏈。
紅線 | 廠商標準條款（多半對買方不利） | 我們建議改成 |
|---|---|---|
自動續約 | 提前 90 天通知 + list price 自動漲 | 提前 30 天 + CPI 綁定 |
超額單價 | 合約期內可調整 | 鎖定 + 超額 X% 告警 |
資料匯出 | 僅 admin 介面手動下載 | 30 天內全量 API + JSON 匯出 |
SLA 賠償 | 退當月費 | 以年費為基礎 + 上限可談 |
審計權 | 不提供 | 配合 SOC2 + 第三方稽核權 |
自架 vs SaaS 的 TCO 真相，3 年總成本攤開看
TCO（Total Cost of Ownership）是採購會議上最常被誤算的數字。SaaS 廠商會強調「自架要付工程薪水、AWS 帳單、營運心力」，自架支持者會強調「SaaS 訂閱費連年上漲、vendor lock-in 風險」。我們把這場辯論用真實數字攤開，以一個 15 人技術團隊、月 PV 30 萬、5 個 feature flag、每年 6 組 A/B 實驗的中型 SaaS 為基準，跑 3 年總成本。
成本項（3 年累計） | 自架 GrowthBook | Statsig Pro | LaunchDarkly Pro |
|---|---|---|---|
訂閱費 | $0 | $5,400（$150 × 36 月） | $21,600（$12 × 5 seat × 36 月） |
基礎設施（AWS 費用） | $1,260（Fargate $35/月 × 36） | $0 | $0 |
初次部署工程時間 | $2,400（16 小時 × $150/hr） | $600（4 小時 × $150） | $900（6 小時 × $150） |
3 年維運工程時間 | $21,600（4 小時/月 × 36 × $150） | $5,400（1 小時/月 × 36 × $150） | $5,400 |
超額/事件費用 | $0 | 約 $3,600（PV 高峰超額） | $0 |
3 年總 TCO | $25,260 | $15,000 | $27,900 |
結果出乎很多人意料，這個樣本下 Statsig Pro 反而最划算，因為它的免費額度大、Pro tier 的 $150/月對 30 萬 PV 來說有充足緩衝。LaunchDarkly Pro 雖然是純訂閱、不用維運，但連年費讓它 3 年 TCO 反而拉到 $27,900。
但這個結果有個關鍵假設，「工程師時薪 $150 美元（約 NT$4,500）」。如果你的工程團隊在台灣中南部、時薪約 NT$2,500，自架 GrowthBook 的 TCO 會降到 $17,000 左右，反而比 Statsig 划算。如果你是新加坡或矽谷團隊，工程師時薪 $250+，買 SaaS 永遠比自架划算。
這也是為什麼我們前面說，「Feature Flag 採購的真實決策變數，從來就不在價格表上，而在你團隊工程時間的機會成本」。同樣的工具，給不同公司算 TCO 會得到完全相反的結論。
恆遠內部的 8 個 Feature Flag 實戰
前面講了很多評估框架，這裡實際分享我們公司內部怎麼用 feature flag，這是我們在自家 3 個產品線上跑了 12 個月後的 dog-fooding 真實場景。
我們公司內部就用 GrowthBook 跑了 8+ feature flags，控制官網灰度發布、A/B 測試、企業 AI 流程切換。具體在跑的 flag 場景包含
- 「new-pricing-page-v2」flag，官網新版 pricing 頁先開給 10% 流量，跑 14 天看停留時間有沒有變短，沒問題再 100% rollout
- 「ai-quote-suggest」flag，秒發報價Pro 的 AI 自動建議功能，先開給 20% 付費用戶試用，根據功能採用率調整
- 「emergency-rollback-payment」flag，金流模組緊急回滾開關，半夜 prod 出問題時 30 秒切回舊版
- 「llm-model-selector」flag，AI 系統內部跑的 3 條 LLM pipeline（Claude / GPT / Gemini）可用 flag 切換，方便比較成本與品質
- 「dark-mode-beta」flag，開課王新介面的深色模式，限定 VIP 學生看到、收回饋
- 「instructor-dashboard-v3」flag，講師後台 v3 開發中，內部測試帳號才能看到
- 「ig-batch-publish」flag，IG Post Manager 批次發文新流程，逐步開放到不同付費等級
- 「contact-form-experiment」flag，官網聯絡表單 A/B test，A 組 3 欄、B 組 5 欄，比較轉換率
我們在 GrowthBook 後台還有額外的治理流程，每月第一個週一是「flag 清盤日」，工程組會盤點哪些 flag 已經 100% rollout 超過 30 天、且程式碼裡還沒移除，標記給對應的工程師排入下一個 sprint 清掉。這個流程是 2025 年底實作的，原因是 2025 年中我們發現有一個叫做「new-checkout」的 flag 已經 100% rollout 8 個月、但對應的舊 checkout 程式碼還沒刪，這 8 個月每次部署都在白白編譯死碼。
這套 feature flag 治理也跟我們其他系統工程實踐連在一起，相關文章可以延伸閱讀
• 想看我們如何在 mobile 端做灰度發布、用 EAS Update 控制 OTA rollback，可以看 Expo EAS Build + EAS Update 上架實戰，那邊有完整的 mobile app 灰度策略 SOP。
• 想理解產品分析 SaaS（Mixpanel / Amplitude / PostHog）跟 Feature Flag 怎麼互補，看 產品分析 SaaS 採購完整指南，那篇講的是「A/B 實驗結果產出的數據」要落地到哪一層分析工具。
• 想看 Serverless 採購決策（影響你自架 GrowthBook 的基礎設施成本），看 Cloudflare Workers vs Vercel Edge vs AWS Lambda 採購指南。
• 多租戶 SaaS 的 Feature Flag 治理更複雜（每個 tenant 可能看到不同 flag），延伸看 客製化 SaaS 多租戶架構完整指南。
• 找外包做 AI 系統時的 PoC 卡關、灰度發布失敗都跟 flag 治理有關，看 找外包做 AI 系統的 7 個坑。
• 想看客製化 CRM 系統開發的 6 個關鍵決策，這跟 Feature Flag 治理在工程文化上有共通點，看 客製化 CRM 系統開發完整指南。
最常見的 6 個地雷與我們的避坑建議
地雷一：以為 Feature Flag 是「免費功能」
很多開發團隊在 codebase 裡寫 if-else 當作土法 feature flag，用環境變數、用 config 檔。短期省事，但 12 個月後你會有 30+ 個散落各檔案的「假 flag」，沒有 audit log、沒有 rollback 機制、沒有人記得哪個是死碼。買 SaaS 或用 GrowthBook 自架的真正價值是「把治理機制集中」，不是 if-else 多寫一行。
地雷二：把 A/B test 結果當聖經
新手最常踩，A/B 跑了 7 天、A 組轉換率 3.2%、B 組 3.5%、宣稱 B 贏。但這個樣本量根本沒過統計顯著性檢定，差異可能純粹是運氣。正確做法是用統計引擎內建的 p-value 或 Bayesian posterior 判斷，且樣本量至少跑滿一個完整週期（含週末高低峰）。GrowthBook 跟 Statsig 內建這些檢定，LaunchDarkly Pro 需要加購 Experimentation 模組。
地雷三：flag 命名沒有規範
12 個月後你會發現團隊裡有 `new-flow`、`new-flow-2`、`new-flow-final`、`new-flow-final-v2` 這種命名災難。建議從第一天起立規範，格式 `{module}-{feature}-{intent}`，例如 `checkout-coupon-experiment` 或 `dashboard-darkmode-rollout`，並在 platform 後台分 tag。
地雷四：flag 跟業務邏輯耦合
如果你的 flag 用來「永久區隔 VIP / 一般用戶看到的功能」，這不是 feature flag，這是業務邏輯。應該寫進 user.tier 欄位用程式碼判斷，不是用 flag 撐。Flag 的本質是「短期的開關」，最多 3 個月就該下線。
地雷五：沒有 kill switch 集中視圖
production 半夜炸了，CTO 需要知道「現在開著哪些 flag」「哪個 flag 可能是元兇」。但很多團隊的 flag 散在 LaunchDarkly + 自寫 config + GrowthBook，半夜要打開三個後台查。建議集中到一個平台，就算暫時用不到 A/B 功能。
地雷六：把 Flag 平台當機密資料儲存體
我們看過有團隊把 API key、payment secret 寫進 LaunchDarkly 的 flag value 欄位，用「動態 config」當理由。這嚴重違反安全原則，flag 平台不是 secret manager。要存秘密用 AWS Secrets Manager 或 HashiCorp Vault，不要混進 flag 系統。
ℹ️工具選哪一家，影響其實沒有想像中那麼大
比較 LaunchDarkly、Statsig、GrowthBook、Unleash 的時候，很多人沒注意到一件事，選哪一個，對你產品最終轉換率的影響其實沒有想像中那麼大。真正拉開差距的是「有沒有把 feature flag 接進每天的工程流程」。同樣用 Statsig，有人只是當開關工具，有人讓它跟 CI/CD、product analytics、客服回報系統串成一條治理鏈，差別不在工具，在你工程文化的成熟度。如果你想討論怎麼把 flag 治理嵌進你公司既有的開發流程，這類整合在我們的客製化系統開發範圍內。
ℹ️我們怎麼看 Feature Flag 採購這道題
Feature Flag 跟 A/B Testing 平台現在處在「品類成熟、廠商分化」的中期，LaunchDarkly 在做企業合規深化，Statsig 在拼免費額度搶 SMB，GrowthBook 跟 Unleash 在固守開源根基。3 年後贏家會是把 LLM 嵌進實驗工作流、能自動產出 UX 變體跟判讀結果的下一代平台，而非「最便宜」或「最大牌」。我們的取捨是，這個階段不賣永久訂閱、不簽 3 年合約、保留換工具的彈性。對中小企業老闆來說，現在不需要急著挑「品牌」，而是先問自己一件事：『我們團隊的 flag 治理流程準備好了嗎？』先把治理規範寫出來、把 flag 命名跟清盤節奏定好，工具選哪家之後再說。
Feature Flag 治理 checklist 下載
我們把這篇文章用到的「5 條合約紅線檢核表」「6 個治理決策樹」「flag 清盤 SOP」整理成一份 12 頁 PDF，附範本與恆遠內部實作截圖。等你下載完，可以直接套用到你下一次採購會議。下載連結將於 2026 年 7 月公開，可先 聯絡我們 留下 email 由我們寄送。
ℹ️我們做過這件事
順帶說一下，這篇講的方法我們公司自己每天都在跑，目前內部就有 20+ 個 AI 流程與 8 個以上的 feature flag 在工作中，跑在自家三個產品線上（秒發報價Pro、開課王、IG Post Manager）。我們也做過產業客戶的客製化系統，例如汽車包膜業客戶從 Excel 報價搬到線上系統 + 電子簽約、影視器材租賃的檔期大表系統等。看到這裡，如果你也在想『這套放在我們公司會是什麼樣子』，我們很樂意 聽你聊聊現在的實際情況，一起看看哪些做得起來、能從哪一塊開始。
Q中小企業到底需不需要 Feature Flag 平台？
如果你的產品已經上線、有付費用戶、且每月至少做 2 次以上的功能部署，需要。原因其實是「你需要一個可以快速關掉新功能的開關」，而非「你想做 A/B test」。但這不代表一定要付錢，GrowthBook 自架版或 Statsig Developer 免費 tier 對大多數中小企業夠用，年成本接近 0。真正該付錢的是流量大到一定規模、需要進階統計引擎跟企業合規（SOC2、HIPAA）的團隊。
QLaunchDarkly 跟 Statsig 哪個適合 10-30 人的成長期新創？
Statsig 的免費額度大、Pro tier 只要 $150/月含 500 萬 events，對成長期新創極友善。LaunchDarkly Pro 是 $12/seat/month，10 人團隊就要 $1,440/年起跳、20 人團隊 $2,880。如果你打算跑大量實驗、樣本量充足，Statsig 划算。如果你的需求主要是 flag 治理跟企業合規（例如客戶要看 SOC2），LaunchDarkly 的企業級工具鏈更完整。多數情況我們建議成長期團隊先用 Statsig 免費 tier 跑 6 個月，再評估升級。
Q自架 GrowthBook 需要什麼樣的工程能力？
需要 1 位熟 Docker 跟 Postgres 的後端工程師、能維護 cron job 跟基本 reverse proxy 設定。GrowthBook 官方提供 docker-compose、Helm chart、Terraform 模組，初次部署約 16 小時。日常維運每月約 4 小時（更新版本、處理 alert）。如果你的團隊沒有這個角色，自架反而會變成隱藏成本，這時用 GrowthBook Cloud Starter 免費 tier 或 Statsig Developer 比較理性。
QFeature Flag 跟 A/B Testing 是同一個工具嗎？
技術底層相通但目的不同。Feature Flag 是「開關」，控制某段程式碼要不要執行、誰看得到。A/B Testing 是「實驗」，同時上線兩個版本、收集行為、用統計判讀勝負。A/B 通常需要 flag 當底層分組機制，但 flag 不一定要做 A/B。中小企業常見的順序是先用 flag 做灰度發布、累積經驗，等樣本量足夠（每天 1000+ 活躍用戶）再投入 A/B 實驗。
Q簽 Feature Flag 訂閱合約最容易被坑的條款是什麼？
三個地雷，自動續約（廠商往往內建提前 90 天通知 + list price 上漲）、超額計費單價可在合約期內調整、資料匯出限制（只能 admin 介面手動下載）。簽約前要把續約通知期改到 30 天、超額單價鎖定、資料匯出 30 天內全量 JSON / API 都寫進去。SLA 賠償條款也常被忽略，要爭取「以年費為基礎」而不是「退當月費」。
Q用了 Feature Flag 之後，flag 越來越多怎麼辦？
這叫 flag debt（旗標債），是長期治理的核心問題。建議三個機制，第一，flag 命名規範（格式如 `module-feature-intent`，並標 tag）。第二，每個 flag 創建時要寫「預計下線日期」，平台到期自動 alert。第三，每月固定盤點，把已經 100% rollout 超過 30 天的 flag 標記給工程師清掉。LaunchDarkly 2024 State of Feature Management 顯示，沒有治理流程的團隊平均有 35% 的 flag 是死碼，這也是為什麼我們前面強調「先有治理流程再選工具」。
Feature Flag 跟 A/B Testing 看起來是工程議題，本質是「中小企業老闆怎麼用工程工具守住預算、加快決策速度」的採購議題。希望這篇 6 個治理決策 + 5 條合約紅線 + 3 個報價區間能讓你下一次採購會議直接套用。
如果你還在猶豫該自架 GrowthBook 還是買 Statsig，或想討論怎麼把 feature flag 跟你公司既有的 AI 流程結合，可以 把你公司現在的情況丟過來，我們陪你看一下從哪一塊開始最划算。想看更多採購決策框架，可以延伸閱讀 產品分析 SaaS 採購完整指南。
AUTHOR
恆遠數位編輯團隊
想了解更多？看看我們的相關服務
相關文章
業務 pipeline 5 階段設計實戰：中小企業 CRM 從 lead 到成交的落地 SOP
企業 SLA 監控儀表板 SaaS 採購完整指南：Datadog / Grafana Cloud / New Relic / Better Stack / Uptime Kuma 5 家比較，5 個必看指標、4 個採購雷區、3 種團隊規模預算
企業 API 整合外包採購完整指南：6 種常見場景、5 條合約紅線、4 種計費模式踩雷，中小企業老闆讓 SAP / Shopify / LINE / 金流 / 物流 API 串起來的決策手冊
中小企業老闆「影子 IT」全公司治理完整 SOP：六個盤點訊號、五條停損動作、四條跨部門報銷拒付規則，把員工偷刷的 SaaS 收回 IT 預算可視範圍
ERP CRM 導入前 90 天：公司數位資產準備度體檢，6 個資料盲點、5 個前置功課、4 個老闆要先想清楚的問題
留言(0)
尚無留言，成為第一個留言的人吧！