Day 11：Web SaaS 要不要轉 iOS/Android App？先算基數、再看規模、最後才看上架風險
一個以「省 LINE 推播費」開頭的問題，最後發現真正該評估的是帳號模型，不是要不要包殼
「要不要把 Web SaaS 做成原生 App」這個問題，正確的評估順序不是「App 好不好做」，而是三層依序往下算：這次真的要花多少錢／省多少錢 → 規模放大後問題的性質會不會變 → 如果值得做，風險藏在哪裡。三層算完，常常會發現一開始的動機（省一筆固定成本）根本不是决定要不要做的關鍵因素——真正的關鍵是另一件事。
結論先講
「要不要把 Web SaaS 做成原生 App」這個問題，正確的評估順序不是「App 好不好做」，而是三層依序往下算：這次真的要花多少錢／省多少錢 → 規模放大後問題的性質會不會變 → 如果值得做，風險藏在哪裡。三層算完，常常會發現一開始的動機（省一筆固定成本）根本不是决定要不要做的關鍵因素——真正的關鍵是另一件事。
這篇記錄的是一次真實案例的推導過程：某企業管家 SaaS 產品，客戶問「要不要做成 App，主要是想省 LINE 官方帳號的推播費」。 第一層：先把基數算出來，不要用直覺判斷
案例背景：某製造業客戶，廠內約 2,000 名員工使用，功能涵蓋預約、訂餐、活動報名，走 LINE 官方帳號做推播與登入。客戶的假設是「App 推播免費，LINE 推播要花錢，做成 App 應該划算」。
實際算量：一般上班日約 2,000 則推播，每月平均 2 個活動日各 4,000 則，一個月抓 22 個工作天，算出來約 48,000 則/月。查了 LINE 官方帳號現行費率（2026），高用量方案月費 NT$1,200、含 6,000 則免費額度，超量加購每則從 NT$0.2 起（依量遞減）。就算不打折硬算，一個月成本落在 NT$9,600 左右，年成本約 NT$11.5 萬。
這個數字放到「自建 App」要付出的成本裡（App Store／Play 帳號、原生推播基礎設施、雙平台維護、上架審核流程）——完全不成比例。光是這一層算完，「為了省推播費做 App」這個理由就已經站不住腳，不需要再往下討論技術可行性。
判準：任何「為了省 X 成本而做 Y」的架構決策，先把 X 的實際金額算出來，再去估 Y 的開發成本量級。順序反過來（先討論怎麼做、後面才回頭算划不划算）是常見的浪費。 第二層：規模放大，問題的性質會變
同一個客戶接著問：如果平台未來有 20 家企業客戶、每家都在 App 裡用不同模組，這樣該不該做？
這裡問題的性質整個換了——不再是省錢，是「要不要把產品的主要互動介面，從『每個客戶各自的 LINE 官方帳號』換成『一個統一的 App』」。 用單一客戶算出的推播成本，多數情況下是分散在各企業自己的帳單上（各自的 LINE OA 各自付費），不會直接放大成平台方自己的成本負擔。 但隨客戶數增加，會線性放大的是另一件事：每上一家新客戶，都要重新跑一次「申請 LINE OA → 設定 LIFF → 綁定登入」的導入流程。這才是規模化後真正該被拿來跟「做 App」的成本比較的東西——不是推播費，是重複性導入摩擦。
客觀評論：這是這次推導裡最容易被忽略的一步。單一客戶的量體只能回答「這次值不值得」，不能直接外推到平台規模的決策——放大規模後，原本的變因（推播費）可能變得不重要，而一開始沒被當成問題的變因（重複導入成本）反而變成主要考量。做規模化決策時，必須重新定義「這次到底在省什麼」，而不是把小規模算出來的結論直接乘以客戶數。 第三層：如果真要做，錢真正花在哪、風險藏在哪
假設規模化理由成立，決定要做 App，真正的成本結構跟直覺也不一樣：
做 App 本身不貴，貴的是帳號模型解耦 用 Capacitor 包裝現有 Web App（UI 零重寫，資料/API 照樣即時打後端），這一步成本相對低。真正貴的是：現有身分模型如果是「透過某個企業自己的 LINE 官方帳號 context 判斷你是哪家公司的人」，一個要橫跨 N 家企業的 App，必須先把「這個人屬於哪家公司」從「你是從哪個入口點進來的」解耦成一套獨立、App 自己能問能認的登入機制。這塊工程量占了做 App 總工程量的大多數，跟「包不包殼」無關。
上架審核是新的風險類別，跟 Web 部署的失敗模式完全不同 Apple 對「單純包一個網站」的 App 有明確政策風險（功能不足被拒），殼包得太薄反而更容易被拒——這點違反直覺：以為「殼越薄、風險越低」，實際上「殼太薄」本身就是被拒的理由之一，除非有真正的原生能力撐著（推播、生物辨識鎖、相機掃碼等）。 B2B 多租戶要走公開上架還是私有分發，是兩條完全不同的路，私有分發（企業自己的裝置管理系統）往往又要求每個客戶自己做一次設定——跟第二層想省掉的重複導入成本，其實是同一類問題换了個地方出現。 憑證（推播憑證、簽章憑證、Provisioning Profile）都有到期日，過期是靜默失敗——不會像 Web 部署失敗那樣立刻看到錯誤，往往是使用者反映「App 收不到通知」才發現。
同步開發 App 不等於零風險地不影響 Web 如果 App 跟 Web 共用同一份程式碼庫（Capacitor 常見做法），大部分改動確實互相獨立（部署管線本身是分開的）。但帳號解耦這塊不是新增代碼，是改動 Web App 現在正在依賴的既有認證路徑——這類「表面上是為了新功能做的改動，實際上動到雙邊共用的核心資產」的改動，風險等級跟一般功能開發不一樣，該被當成獨立的、需要對舊路徑做回歸驗證的 migration 來處理，而不是附屬在 App 開發任務底下順手做掉。 可複用的判準 先算基數，再談方案——用「省成本」當理由的架構決策，先把成本金額量化，很多時候第一層就能把答案定案，不用往下討論技術細節。 規模改變問題的性質——單一案例的結論不能直接乘以規模外推，放大規模後常常會冒出新的主要變因（重複導入成本），原本的變因反而不重要了。 殼薄不等於風險低——尤其在有審核機制的平台上（App Store），「功能太少」本身就是一種風險，不是只有「功能太多、太複雜」才有風險。 會被兩個以上用戶端共用的改動，要當獨立 migration 對待——不管它是不是包裝在某個新功能底下，只要動到的是雙邊都依賴的核心路徑（尤其是認證），就該先驗證舊路徑不受影響，再讓新功能依賴它。 本篇由 claude-code（claude-sonnet-5） 於開發過程中產生。 repo：RedBallFlow @ 3cd6b7f9 標籤：multi-tenant saas mobile-app capacitor line app-store architecture-decision