系統開發

恆遠會員中樞系統

把自家 SaaS 重複造輪子的「註冊 / 登入 / 訂閱 / 權限」抽出成共用中樞,新產品 1 行接入。

每一個畫面,都被反覆打磨

從線稿到上線,連一個間距、一種狀態都不放過。點圖可放大看細節。

客戶規模個人 / 工作室
專案年份2025
開發時長持續開發中
技術Next.js・TypeScript・PostgreSQL・Payload

關鍵績效指標

SSO 一次接入、多產品共用
0

JWT 授權查詢 < ms 回應

0

新產品會員模組從零開發 → 天接入

專案資訊

服務項目
系統開發

專案說明

隨著恆遠自有 SaaS 越來越多(秒發報價、ProjectDot 任務點點王、會員手冊等),每個產品過去都要重複實作「註冊/登入/訂閱/權限驗證」這四件事,工程成本一直疊加,更糟的是用戶身分不互通 — 新產品上線時拿不到既有用戶基礎,得從零累積。

恆遠團隊把這層抽出來、做成獨立的會員中樞系統:所有自有產品共用同一套 SSO(Email + Google OAuth)、同一份訂閱方案後台、同一個授權查詢 API。新產品要上線時,只要接這個中樞、就立刻擁有完整的會員與訂閱基礎建設,不用再寫一次。

架構上刻意把「身分/訂閱」與「業務資料」分離:中樞只管 user_id、訂閱狀態、權限有效期;各應用自己存業務資料、用 user_id 關聯。這樣每個應用仍然獨立、單點故障不會擴散,但對使用者來說是無縫的「一個帳號通行多個產品」體驗。

後台則做了完整的訂閱統計與用戶監控儀表板 — 跨產品的訂閱漏斗、LTV、續訂率都看得到,運營決策不用再翻三個系統。

案例故事

CHALLENGE

挑戰

1

每個自有 SaaS 都要重複實作註冊/登入/訂閱/權限驗證,工程成本疊加

2

用戶身分不互通,新產品上線拿不到既有用戶基礎,得從零累積

3

帳號 / 訂閱資料散在多個產品 DB,運營要翻多個後台才能看到完整漏斗

4

每個產品自寫一套金流串接與訂閱狀態同步,bug 頻發、維護成本高

SOLUTION

解法

1

抽出獨立會員中樞:Email + Google OAuth + JWT 授權,所有自有 SaaS 用同一套 SSO 接入

2

集中式訂閱方案後台:產品 / 方案 / 試用期 / 計費週期統一定義,新產品只要設定方案即可上架

3

授權查詢 API + 集中式儀表板:跨產品的訂閱漏斗、續訂率、LTV 一站看完

4

身分/業務資料隔離設計:中樞只管帳號與訂閱、各應用本地保存業務資料,故障不會擴散

RESULT

成果

1

新自有產品上線時,會員與訂閱模組從「2-3 週開發」縮短為「1 天接入」

2

跨產品身分互通,新 SaaS 上線即可承接既有用戶基礎、降低冷啟動門檻

3

統一儀表板讓運營能直接比較各產品的訂閱表現、決策依據完整

核心功能

統一帳號 SSO

Email 與 Google OAuth 登入、JWT Token 驗證,多個自有 SaaS 共用同一份用戶身分。

訂閱方案管理後台

可定義產品、訂閱方案、試用期、計費週期(週/月/季/年/自訂),所有自有產品共用。

授權查詢 API

各應用呼叫即可拿到使用者當前方案、權限與有效期,回應 < 50ms,支援啟動驗證與功能級檢查。

集中式儀表板

跨產品的用戶、訂閱、收入、續訂率、LTV 一站監控,運營決策不再翻多個系統。

業務資料隔離設計

中樞只管身分與訂閱,各應用自存業務資料、僅以 user_id 關聯,單點故障不擴散。

Admin 完整管理

用戶搜尋、強制登出、手動升降級、異常登入紀錄、API Key 管理一應俱全。

想做類似的?告訴我們你的情況

看完這個案例有想法了嗎?直接告訴我們你的情況,第一封回信就給你「怎麼做、要多久、大概多少錢」。

返回作品集