當顧問公司決定
把 Swingvy 換成
自己寫的系統

背景

Swingvy 是一套 HR SaaS（Software as a Service，軟體即服務），覆蓋員工資料、出勤、合約、薪資的基本流程。我們從 2024 年開始用，對一個 5 人的顧問團隊，標準 HR 流程它都接得上。

但隨著我們的工作模式越來越特殊，Swingvy 開始顯得不合身。我們的員工有客戶專案的 cost loading 要算、有跨客戶的差旅與請款流程要追、有顧問日報的時數紀錄要結到專案——這些都不是任何標準 HR SaaS 想解的問題。我們開始用 Slack、Google Sheets、Notion 補 Swingvy 補不到的地方，到後期 HR 流程已經分散在 4 個工具裡。

這時候我們做了一個顧問公司常常告訴客戶的選擇：與其 workaround，不如重建。

為什麼換掉 Swingvy

Swingvy 本身沒問題，是它跟我們的工作模式不再相配。具體的觸發點有三個：

1. 專案 / 員工 cost mapping 沒得做。顧問公司的核心報表是「每個客戶專案實際花了多少人月」，需要從 HR（員工成本）+ 工時系統（每人時數）+ 客戶系統（專案）三方匯流。Swingvy 只能匯出 CSV 給你自己接。
2. 差旅請款想加 AI 但加不上。顧問業跑客戶端常產生大量收據，希望員工拍下收據後系統自動辨識金額、商家、稅額、類別並進入請款流程。Swingvy 是黑箱，AI 整合不在它們的 roadmap 上。
3. 我們本來就用 Vibe Coding 賣給客戶——對自己用一遍是最好的試煉。客戶問我們「Vibe Coding 真的能取代既有 SaaS 嗎？」，我們需要一個自己親身做過的答案。

技術選擇

我們選自己最熟、5 年後仍會穩定的堆疊：

• Next.js 16 (App Router)：Web 前端與 API routes 一體
• iOS + Android Mobile App：給差旅現場拍收據、查請款狀態用
• Supabase (Postgres)：資料庫 + auth + storage
• Vercel：部署、edge function
• Clerk：員工身分管理，整合 Google Workspace SSO（Single Sign-On，單一登入）
• Anthropic Claude API：收據 / 發票自動辨識——金額、商家、類別、稅額一次抽取
• Tailwind + shadcn/ui：UI 組件系統

沒有 hype-driven 選擇，每個工具都解釋得出為什麼選它。

4 週實作節奏

2 個 sprint，每個 sprint 兩週。Web、iOS、Android 三端在 sprint 2 末尾同步上線。

Sprint 1（Week 1-2）：核心員工管理 + Swingvy 資料遷移

• 員工資料 schema 設計
• Auth 整合（Google Workspace SSO via Clerk）
• Swingvy 資料匯出與遷移（Swingvy 提供 CSV export，寫腳本對照進新 schema）
• 合約管理（含版本歷史、PDF 上傳到 Supabase storage）
• Web App 基礎頁面與 admin console 骨架

Sprint 2（Week 3-4）：流程 + 收據 AI + Mobile + 切換

• 台灣勞基法給假規則引擎（年資對應特休天數）
• Slack /pto 指令請假流程，主管審核
• 薪資結構（含勞健保、6% 自提）
• Claude API：收據 / 發票拍照後自動辨識金額、商家、稅額、類別，直接帶進費用報銷
• 客戶專案 / 員工 cost loading 報表（連動每月人事費用）
• iOS + Android Mobile App：給差旅現場拍收據與查請款狀態用
• 切換週：Swingvy 與新系統並存 5 個工作天，同事兩邊用過後我們關掉 Swingvy

上線

2026 年 5 月，新系統正式上線——同步交付 Web Application、iOS Mobile App 與 Android Mobile App 三端，Swingvy 訂閱同步退場。

這套系統的範圍從 day 1 就超出了「HR」——它整合了我們內部需要的營運中樞：

• Receipt Scan（收據掃描）：員工手機拍下收據，Claude API 自動抽取金額、商家、類別、稅額，直接帶進費用報銷流程。週末出差不用回辦公室再打字——這是我們最早決定要做的 AI 功能。
• 客戶專案 cost mapping：HR 員工成本、工時、客戶專案三方匯流，每個專案的實際人月成本能即時查到。
• 給假規則引擎：勞基法年資對應特休天數自動計算。
• Slack /pto 請假流程：員工在 Slack 申請、主管審核、結果回寫。
• 合約管理：員工合約版本歷史 + PDF 集中存放與檢索。

意外收穫：EKel 客戶看到 demo 後說「我們也要這樣的」，於是這套系統變成了 Vibe Coding 業務的銷售素材。客戶看到的不是 PowerPoint 上的 mockup，是一個我們自己每天真的在用的系統。

學到的事

這個案子讓我們確認了 Vibe Coding 的真正定位。

Vibe Coding 不是「比 SaaS 便宜」，是「比 SaaS 合身」。Swingvy 的訂閱費對 5 人顧問團隊不算痛——真正的痛是它管不到我們最在乎的事（專案 cost mapping、收據掃描、客製審核流程）。Vibe Coding 給我們的是「能管到一切想管的事」。

Build vs. Buy 的判斷是「客製需求 / 標準需求 比例」。當這個比例超過 30%，不論團隊大小，自建幾乎總是贏。SaaS 收的是「標準功能」的錢，你買 70% 的東西最後再花 200% 的時間 workaround 那 30%。

AI 加值是 Vibe Coding 的明顯優勢。收據拍照丟給 Claude 自動辨識成請款項目，這是 SaaS 沒辦法給的——它們的產品週期跟不上 LLM 演進的速度。自建系統可以隨時加，能因應 LLM 的快速演進升級。

EKel 把這個系統的架構決策、schema 設計、AI 整合做法，整理成 Vibe Coding 的標準教材。每個新客戶都會看到這個案例，作為「自建到底長什麼樣子」的具體參考。