建置它的案例
為什麼要建置這個而不是組裝堆疊？
建置 SaaS 的預設方式是組裝：一個驗證提供者、一個計費 SDK、一個資料庫、一個電子郵件服務、一個功能標記工具——在實際產品的第一行之前有五個供應商。它們之間的接縫將成為你的程式碼庫：協調計費與存取的 Webhook 處理程式、在系統之間複製使用者的同步作業，以及計費供應商表示已付款而應用程式表示已鎖定的凌晨 2 點類別的錯誤。 Kliv 將機殼作為一個系統（租賃、計費、權益、電子郵件、資料）進行運輸，因此你需要花費數月時間編寫的接縫不存在。
底盤沒有差異化；你的產品不是。沒有人會因為登入頁面或發票電子郵件而選擇你的應用程式——儘管他們會留下一個損壞的應用程式。將描述放在你的網域上，只有你知道的事情，並讓每個 SaaS 共享到達的部分都已組成。當你的定價發生變化時——新的層級、計量附加元件、企業交易——這只是對話中的一句話，而不是重新架構。
系統剖析
SaaS 實際上是由什麼組成的
除去產品，每個 SaaS 都有相同的骨架：租戶、席位、方案、大門、儀表、發票。 Kliv 運送骨架；你描述了它周圍的產品。以下是系統第一天就知道的內容。
組織機構
每個客戶都是一個組織——他們的使用者、資料和帳單都在一面牆內。公司 A 無法讀取公司 B 的資料庫。
成員及角色
你的客戶是公司，而不是登入名稱——所有者、管理員和成員，每個人都看到自己的角色允許做什麼。
方案和價格
型錄：等級、試用、一次性解鎖、計量附加元件 — 你的定價頁面作為系統強制執行的資料。
權益
金錢和功能之間的聯絡——該組織的訂閱開啟什麼，在任何重要的地方進行檢查。
儀表和使用情況
使用情況根據客戶的登入活動進行計數 — 他們可以看到，由你計費。
訂閱和發票
每個租戶的商業狀態——試用、活躍、逾期——都有發工單明。
誰看到什麼
資料庫強制執行的規則
- 租使用者的行屬於租使用者 — 在資料庫中不可能進行跨組織讀取，也不會在應用程式中進行過濾。
- 權益依照即時計費進行：升級立即開放功能，取消則依計畫縮小功能範圍。
- 計量表和發票是同一個系統──測量的就是計費的，沒有任何需要核對的地方。
- 付款失敗後，在付款客戶關閉任何大門之前，就會開始催款——重試和恢復電子郵件。
這是 SaaS 的一部分，沒有人選擇建置，每個人都必須建置：身份、租賃、資金以及約束它們的規則。當它作為一個系統到達時，你的描述就變成了關於你的產品。
SaaS 的困難部分已經解決
這些不是附加元件——它們是相同的平台元件，是組合而成的。
預設多租戶
當客戶註冊你的應用程式時，每個客戶都會獲得自己的組織。 A 公司永遠無法看到 B 公司的資料 — 隔離是在資料庫層級的每個查詢上強制執行的，而不是在必須記住編寫的應用程式碼中執行的。你自己的管理資料位於單獨的內部專用牆後面。
產品內的團隊和席位
你的客戶不是單一使用者—他們是公司。登入、角色和每個組織共享是同一身份系統的一部分，因此「同一公司的每個人都可以看到他們公司的專案」是一句話，而不是衝刺。
依照 SaaS 實際收費方式收費
具有試用和公平按比例分配的訂閱、一次性解鎖以及基於使用量的計量定價。 「Pro 方案每月 20 美元，每份產生的報告另加 2 美分」是一種描述 — Kliv 為你建置產品、價格和儀表。
追隨金錢的特徵
將功能附加到方案和門控頁面、資料和功能。升級、降級或取消－在帳單變更時，存取權限將自動生效。沒有授權程式碼，沒有夜間同步。
也出售內容存取權
內建檔案儲存有自己的存取規則：私有、每個組織共用或訂閱後。高階 PDF、影片和下載內容可透過與應用程式的其餘部分相同的權益來解鎖。
在你的應用程式中自助計費
客戶在產品內的帳單頁面上更新卡片、切換方案並閱讀發票 — 當付款失敗時，Kliv 會重試並向他們寄送電子郵件，直到付款恢復為止。
充電方式
SaaS 的三種收費方式
定價頁面不斷演變－層級分割、儀表出現、企業交易需要發票。型錄應該保持不變，無需重新架構。
分級訂閱
$29–$99/月
選擇 Starter 或 Pro 的團隊
計畫附加的功能層：Starter 取得核心，Pro 開啟報告，API，團隊功能。
- 解鎖
- 功能遵循方案－升級立即開啟它們，降級按方案縮小範圍，沒有任何手動切換。
- 計費
- 每月或每年進行試驗並公平按比例分配；失敗的卡會在存取範圍縮小之前重試並收到恢復電子郵件。
- 退款
- 審批門控－退款是決定，而不是意外。
基於使用情況
每次執行 0.05 美元
其帳單應追蹤其價值的客戶
基本方案加上儀表：渲染、訊息、API 呼叫 — 無論產品中的價值單位是什麼。
- 解鎖
- 使用情況會計入客戶的登入活動，在發票到達之前可以在其帳單頁面上看到。
- 計費
- 計量費用按照訂閱週期累積和計費 — 計量表和發票一致，因為它們是同一系統。
- 退款
- 有爭議的訂單專案透過相同的審批流程解決。
一次解鎖
一次性 500 美元
想要附加元件而不是其他訂閱的客戶
終身模組、入門套餐、早期採用者優惠 — 與訂閱一起出售一次。
- 解鎖
- 購買授予永久權益，該權益與客戶執行的任何方案共存。
- 計費
- 一次收費，一張收據－相同的型錄，相同的帳單頁面。
- 退款
- 相同的審批流程。
發布前
第一週，啟動前
SaaS 比任何宣傳冊網站都有更多的機制需要證明——這正是第一週很重要的原因。
塑造產品
描述一下：產品的用途、客戶是誰、層級、以及每個層級開放什麼。 Kliv 建置了第一個預覽，其中的組織、方案和大門已經真實存在。
讓它成為你的
你的網域、你的品牌、你產品的語言 — 以及從結帳強制執行的相同型錄產生的定價頁面。
連結真實的東西
連線 Stripe，設定實際價格和試用長度，將功能附加到方案中，並邀請你的團隊進入運營商的視野。
試著打破它
註冊成為測試客戶。嘗試讀取另一個組織的資料 — 觀察資料庫拒絕。一張卡失敗，一個計畫降級，看著大門隨之而來。
然後排練一年
在 Sandbox 中，使用模擬資金和模擬時間，在發布前執行你的 SaaS 的第一年：試用轉換或到期、客戶在 3 月份升級、卡在 6 月份出現故障並恢復、取消在正確的日期關閉正確的功能。你發布了一家已經經營的企業——而不是希望它能夠運作。
建造或購買
為什麼不直接將堆疊黏合在一起呢？
| 膠合堆疊 | 與 Kliv | |
|---|---|---|
| 租賃 | 身份驗證提供者的組織功能加上你編寫並永遠重新審查的行過濾器。 | 在資料庫中強制執行的組織－跨租使用者讀取是不可能的，也不會被過濾。 |
| 計費 ↔ 存取 | Webhook 處理程式將計費供應商與你的應用程式關於誰付款的想法進行協調。 | 權益按照本機計費 — 沒有任何縫隙可以協調。 |
| 使用定價 | 計量服務、計費服務以及它們之間的對帳工作。 | 電錶和發票是同一個系統。 |
| 生命週期電子郵件 | 另一個供應商、另一個範本語言、另一個 Webhook。 | 內建收據、催款和試用提醒 — 在你的範本上。 |
| 產品生產時間 | 幾個月前的底盤首先有差異化的功能。 | 底盤是第一天；你的描述已花在產品上。 |
租賃
膠合堆疊: 身份驗證提供者的組織功能加上你編寫並永遠重新審查的行過濾器。
與 Kliv: 在資料庫中強制執行的組織－跨租使用者讀取是不可能的，也不會被過濾。
計費 ↔ 存取
膠合堆疊: Webhook 處理程式將計費供應商與你的應用程式關於誰付款的想法進行協調。
與 Kliv: 權益按照本機計費 — 沒有任何縫隙可以協調。
使用定價
膠合堆疊: 計量服務、計費服務以及它們之間的對帳工作。
與 Kliv: 電錶和發票是同一個系統。
生命週期電子郵件
膠合堆疊: 另一個供應商、另一個範本語言、另一個 Webhook。
與 Kliv: 內建收據、催款和試用提醒 — 在你的範本上。
產品生產時間
膠合堆疊: 幾個月前的底盤首先有差異化的功能。
與 Kliv: 底盤是第一天；你的描述已花在產品上。
常見問題
租戶隔離實際上是如何執行的？
在資料庫中，具有行級規則。每個客戶都是一個組織，他們的行都帶有該邊界 — 頁面中的錯誤不會洩漏其他租戶的資料，因為查詢本身返回空。
我可以將訂閱與計量使用結合嗎？
是的 — 這是一個方案，而不是兩個系統：Pro 層，頂部每個渲染 0.05 美元。訂閱對基本費用進行計費，計量表對使用量進行計費，客戶可以在一張發票上看到兩者。
當客戶取消或降級時會發生什麼？
權益會按照你的策略設定的時間表縮小範圍（立即或在期末時），並且將保留資料。返回的客戶會在原地恢復他們的組織，這使得贏回他們成為一個計費事件，而不是遷移。
客戶可以管理自己的帳單嗎？
是的 — 產品內的帳單頁面：更新卡片、切換方案、讀取發票。當付款失敗時，催款會重試收費，並在任何人的存取範圍縮小之前向客戶寄送電子郵件。
發布後我可以更改定價嗎？
是的——型錄就是資料。新增層級、分割方案、引入計量；新價格適用於新結帳，現有訂閱將保留其購買的條款，直到你另有決定為止。
這是真正的多租戶，還是帶有功能標誌的帳戶？
真正的租戶：每個客戶組織都是資料庫中的一流邊界，擁有自己的使用者、角色和行 — Kliv 本身執行的多租戶架構相同。