交付形態選型的核心原則是先判斷「這個服務值得自建嗎」、再進入自建世界的服務選型。提供線上服務的途徑是一個光譜：全託管平台（Wix、Shopify、Google Sites）、辦公生態自動化（Google Apps Script）、BaaS（Firebase、Supabase）、半託管 CMS（WordPress）、到自建程式 — 本模組其餘章節討論的資料庫、快取、queue、部署選型、全部屬於光譜最右端的自建世界。落在光譜其他位置的服務、那些章節的問題暫時與它無關；判斷自己落在哪、以及什麼訊號出現時該往右移、是比「選哪個資料庫」更早的決策。

本章目標

讀完本章後、讀者能夠：

1. 用差異化位置與業務量判斷服務該落在交付形態光譜的哪一段
2. 看懂全託管平台、辦公生態自動化、BaaS、半託管 CMS 與自建各自的能力邊界與遷出代價
3. 在選擇託管形態的同時、保留日後遷往自建的可遷出路徑
4. 把「該升級自建了」的判斷從感覺轉成可觀察的 tripwire

【觀察】自建的合理性來自差異化位置

自建的合理性來自一個前提：這個產品的差異化在軟體本身。差異化在商品、內容、社群或服務品質的生意、軟體只是通路 — 通路用現成的、把工程資源留給差異化所在的位置、是成本上更誠實的選擇。

第一列的判讀方式值得展開：把產品的核心流程用一句話描述、再問「這句話是不是某個託管平台的官方首頁文案」。「賣手作飾品、信用卡結帳、出貨通知」就是 Shopify 的首頁；「活動報名、自動寄確認信、報名滿額關閉」就是表單工具加自動化的範圍。描述不出落在任何平台標準域的流程 — 例如「客戶上傳檔案後跑客製演算法、依結果動態計價」— 才是自建訊號。

「產品本身就是軟體」這一列要先過一個澄清：這個軟體是要賣的產品、還是經營業務的工具。「給健身教練用的課表系統」有兩種身分 — 開發者要賣給眾多教練的產品（市場上的垂直 SaaS 是競爭對手、交付形態走自建）、或教練管理自己學員的工具（同一批垂直 SaaS — 課表、預約、POS — 正是該優先評估的託管形態）。同一句需求描述、兩種身分的結論相反、先拆身分再進訊號表。

【判讀】交付形態光譜

光譜從左到右、控制力遞增、維運責任同步遞增。每一段先看它解什麼、再看邊界訊號與遷出代價。

全託管平台：Wix、Shopify、Squarespace、Google Sites

平台承擔整條技術棧：主機、憑證、防護、金流、版面。使用者操作的對象是「網站內容」、不是「程式碼」。電商走 Shopify、形象站與簡介站走 Wix / Google Sites、訂閱內容走 Substack 類 — 各平台的標準域內、上線時間以天計、且本系列 0.8 資安與資料保護需求 裡多數伺服器側的功課由平台承擔。

邊界訊號：客製需求開始對抗平台 — 結帳流程要插入平台不支援的步驟、資料要跟外部系統雙向同步、頁面效能撞到平台的模板天花板。在平台內 workaround 的程式碼（Shopify 的 liquid hack、Wix 的 Velo 腳本）累積越多、等於在用最差的開發環境自建。

遷出代價：資料匯出通常有官方管道（商品、訂單 CSV）、但 URL 結構、SEO 累積、會員密碼（雜湊不可攜、遷移等於全體重設密碼）、訂閱金流的扣款授權（綁在平台的金流帳戶上）都要重建。

辦公生態自動化：Google Apps Script + Sites / Forms / Sheets

這一段解的是「流程自動化」、不是「產品」。表單收件進試算表、定時整理寄報表、收到 email 觸發動作 — Apps Script 把 Google Workspace 的元件串成工作流、零主機、零部署、權限直接掛在 Google 帳號上。同段位的還有 no-code 資料庫工具（Airtable、Notion 當輕後台）— 串現成元件、零部署的角色相同。內部工具與小規模對外流程（報名、登記、排班）在這一段的成本接近零。

邊界訊號：第一個出現的通常是配額牆 — 某天報名表單停止收件、log 裡躺著超額錯誤、而且已經靜默丟了一個下午的提交。再來是併發：兩個人同時送出、Sheets 用最後寫入蓋掉前一筆。最後是工程紀律的渴望、腳本長到想要版本控制與測試時、它已經是一個沒有工程基礎設施的程式專案。

遷出代價：低 — 資料在 Sheets / Drive 裡天然可匯出、流程邏輯通常短到可以重寫。這一段的風險是「忘記遷」、不是「遷不動」：業務量上來後配額錯誤靜默發生、報名表單少收一批人才發現。

BaaS：Firebase、Supabase

BaaS 把後端拆成現成模組：認證、資料庫、檔案儲存、推播、serverless function。前端（app / SPA）自己寫、後端用平台的 SDK 直連 — 本系列 0.2 狀態與資料儲存選型 討論的多數問題、在這一段被平台的預設答案取代。行動 app MVP 與快速驗證期的產品、BaaS 把「後端工程師」這個角色延後了。

BaaS 的邊界牆通常分三面依序出現。第一面是報表 — 老闆要一張跨集合的月報、Firestore 查不出來、工程師開始把資料複製第二份、複製管線本身變成要維護的系統。第二面是帳單：讀寫計費隨流量線性成長、某個月的發票讓人重新打開計算機比對自建。第三面最安靜：client 直連資料庫的模型把授權邏輯全部塞進 security rules、規則檔長到沒人敢改時、0.8 的整個控制面已經壓在一個難以測試的規則語言（DSL）裡。

遷出的代價集中在資料層：資料本身可匯出、但資料模型沿平台特性設計（為遷就查詢限制、同一份資料複製存放多處的反正規化結構、加上平台專屬的即時同步語意）、遷到關聯式資料庫等於重做資料層。認證體系可攜性視平台而定（Firebase Auth 可匯出密碼雜湊、是少數友善案例）。

半託管 CMS：WordPress 與同類

WordPress 代表「半手動自定義」這一段：核心由開源專案提供、功能靠外掛拼裝、版型可以改到面目全非、主機可以託管也可以自架。內容為主、客製需求中等的站（媒體、部落格、預約、小型電商加 WooCommerce）長期住在這一段。控制力比全託管平台高一級：資料庫是自己的 MySQL、檔案是自己的目錄、想改什麼理論上都改得動。

邊界訊號：每次外掛更新前先全站備份、更新完手動點一輪主要頁面 — 這個儀式固定下來時、外掛堆疊已經超出任何人的全盤理解。效能問題跟著來：頁面變慢、但慢在哪一層查詢沒人說得清。資安面則是時間問題：WordPress 外掛漏洞是攻擊者的固定狩獵場、patch 責任在自己身上、沒人 patch 的站是 0.11 攻擊者視角 裡最便宜的目標。

遷出代價：真正遷不動的是外掛私有表裡的業務邏輯 — 會員等級、預約規則、客製欄位散在各外掛自己的資料表、遷移時要逐個考古；內容本身（文章、媒體）反而是最成熟的匯出路徑。

垂直 SaaS：行業專用的託管形態

垂直 SaaS（預約系統、課表排班、POS、訂位平台）是全託管平台的行業特化分支。平台已經把該行業的標準流程做成產品、使用者設定開通而非寫程式碼。業務流程落在平台標準域內時、效率跟全託管平台相同；差異在於當需求偏離行業標準域（例如預約系統要加客製的動態定價邏輯）、平台的 API 與 webhook 是延伸天花板 — 超出就是自建訊號。遷出代價集中在客戶資料與業務規則的可攜性：客戶名單、歷史交易紀錄的匯出格式、以及在平台 UI 裡長出來的行業特定規則（排班邏輯、會員等級、優惠券組合）能否帶走。

個人自架工具：常駐本機、無對外服務

這一段跟前面所有形態的本質差異在於：沒有對外使用者。遠端操控自己的主機、家庭自動化、個人備份同步這類工具、使用者就是所有者（單人或家人）。它在光譜上是自建的一個特例 — 自建成立、但本模組其餘章節的多數問題（租戶、使用者資料庫、對外服務）不適用。常駐在自有主機（launchd / systemd）或私有網路上、本模組裡真正展開的只剩三條：入口怎麼安全進來（部署平台）、誰能存取（資安）、密鑰怎麼保管（secret）;資料庫、快取、queue、多租戶隔離多半 N/A。

認證也離開 web-auth 光譜。沒有帳號系統、沒有 SSO、主體就是持有裝置的所有者：一層裝置原生生物辨識（Face ID / 指紋）認「人」、一層 app 與主機共享的密鑰認「連線」。入口形態常是 outbound tunnel（cloudflared / Tailscale）而非公網 IP — 本機主動外連、路由器零開 port。詳見 7.2 身分與授權邊界 的單人裝置認證段與 5.10 Outbound Tunnel 入口。

這個模型的邊界在使用者數。使用者從「自己」變成「自己 + 幾個朋友」時、第一個多出來的使用者就打破整個模型 — 共享密鑰無法分辨是誰、生物辨識綁在單一裝置、沒有帳號就無法個別撤銷。這時回到完整自建訪談、把認證升級成帳號系統。

遷出方向也跟其他形態相反 — 方向是「長成服務」、離開平台只是副產物。工具沒有累積對外使用者資料、遷移成本低;真正要重做的是認證與授權層（從單人共享密鑰換成多使用者帳號系統）、以及入口（從個人 tunnel 換成能承載多人的公開入口）。

自建：本模組其餘章節的世界

差異化在軟體本身、或所有託管形態的邊界都已撞到、就進入自建。自建的真正成本由本模組其餘章節展開：0.0 需求分類 開始、0.6 成本、風險與選型取捨 把人力與維運成本攤開。自建換到的是：資料模型自己定、流程任意客製、成本曲線在規模化後由自己控制、以及所有控制面（資安、觀測、備援）可以做到合規要求的深度。

【判讀】混合形態是常態、不是過渡期的妥協

光譜上的位置不必全站一致。常見的健康組合：行銷頁與內容放託管平台（Wix / WordPress）、核心產品自建、兩者用子網域分流；電商主站走 Shopify、客製的批發報價系統自建接 Shopify API；內部流程跑 Apps Script、對外產品自建。判讀單位是「每條業務流程」、不是「整間公司」— 把不是差異化的流程硬塞進自建 codebase、跟把差異化流程硬塞進託管平台、是同一個錯誤的兩個方向。拆分軸除了逐流程、還有逐層：headless 形態（託管平台當後端引擎、自建前端體驗層）是同一條流程內的層級混合、判讀方式相同 — 每一層各自問「差異化在這層嗎」。

光譜上還有兩個停靠點值得知道：靜態網站生成器（Hugo / Next.js export）搭配 hosting（Netlify / Vercel）介於全託管與半託管之間，適合文件站與行銷頁；Edge Functions（Cloudflare Workers / Vercel Edge）介於 BaaS 與自建之間，寫程式但不管基礎設施，適合輕量 API 與邊緣邏輯。兩者的邊界訊號與遷出代價跟相鄰形態類似，需求超出時回到各自相鄰段落的判讀。

【權衡】託管形態的成本與資安帳

託管形態把伺服器帳單換成平台帳單、把維運人力換成平台依賴。權衡時五個方向都要看：

1. 資安限制：平台扛掉 patch、憑證、DDoS 防護 — 這對沒有資安人力的團隊是淨收益。代價是資料主權與稽核深度受限：資料落在平台的儲存裡、audit log 細度由平台決定、有資料落地或合規要求（金融、醫療、政府標案）的業務、託管形態可能直接出局。
2. 流量與穩定性：平台的彈性通常優於小團隊自建（Shopify 扛 Black Friday 是它的本業）、但天花板不可協商 — API rate limit、配額、模板效能、撞到就是撞到。
3. 平台費用：月費 + 抽成（電商平台的交易抽成在量大後是實質稅率）。自建與託管的成本曲線會交叉、交叉點要算：平台月費 + 抽成 vs 自建的工程薪資 + 雲端帳單、在目前與三倍業務量下各是多少。
4. 人力與操作：託管形態讓非工程角色能直接維護（改文案、上商品、調流程）、這個能力在小團隊值很多錢；自建後每個改動都過工程隊列。
5. 機會成本：選託管、省下的工程時間投到差異化；選自建、買到的控制力要有明確用途。「以後可能要客製」是最常見的偽自建理由 — 客製需求出現時再遷、總成本通常低於提前自建養一套用不滿的基礎設施。

【檢查】可遷出保險：選託管的同時保留往右走的路

託管形態的真正風險是 vendor lock-in 的具體形：遷不出去。保險在進場時最便宜。選擇任何託管形態的同時、確認下列事項：

每項保險在遷出日如何兌現 — 保險與理賠流程的對應 — 見 10.3 託管形態遷出 的資產線盤點。

【檢查】升級自建的 tripwire

「日後可能需要自建」要轉成可觀察訊號、寫進選型記錄、而不是留在感覺裡：

tripwire 是重評承諾、不是遷移保證 — 觸發後每拖一季、資料量與整合深度都在墊高遷移成本。任一 tripwire 觸發時、回到本模組從 0.0 需求分類 走完整的自建選型；評估成立後的執行劇本 — 資產線盤點、並行期、回切窗口 — 見 10.3 託管形態遷出。

下一步路由

• 判斷落在自建：從 0.0 後端需求分類地圖 開始走本模組的選型順序。
• 判斷落在自建、但周邊能力仍想逐塊外包（認證、搜尋、金流、表單、後台）：見 0.22 能力級買 vs 建。
• 判斷落在個人自架工具（單人自用、無對外服務）：跳過資料庫 / 快取 / queue 章節、只看 7.2 單人裝置認證 與 5.10 Outbound Tunnel 入口;多人化時再回完整自建選型。
• 判斷落在託管形態：完成上方可遷出保險清單、把 tripwire 寫進選型記錄、定期回看。
• 成本曲線的算法：見 0.6 成本、風險與選型取捨。
• 託管形態下仍需要的資安底線（帳號安全、權限、資料匯出管控）：見 0.8 資安與資料保護需求。
• 從託管遷往自建的執行劇本：見 10.3 託管形態遷出；模組總覽見 模組十：系統演進與遷移。