引言：把 SaaS 當作一個可以公開拆解的實驗
我是一個喜歡把「做法」公開的一人創業者。這篇是以建造日誌（build-in-public）的方式，記錄一個小型 SaaS 從概念到營收的完整流程：技術選型、付費模型設計、成長實驗、以及我願意公開的真實收入與成本。語氣坦率、帶點工程師幽默（如果伺服器今天沒當機，請恭喜我），希望你能直接借鏡、複製戰術，少走我走過的那些彎路。
專案背景與目標用戶描述
專案名稱（化名）：NoteFlow — 一個簡單的團隊共筆與任務整合小工具。目標是介於個人筆記與大型專案管理工具之間，強調「快速建立共享模板、簡易任務追蹤、以及輕量 API 整合」。
- 目標用戶：小型團隊（2–15 人）、自由工作者、內容創作者想要共享流程模組的人。
- 痛點：現有工具太重、模板管理不友善、API 整合需要工程時間。
- 目標：在 12 個月內達到 MRR（每月經常性收入）US$3,000，並能自給自足（cover cloud + 工時外包成本）。
架構與技術選型的實務理由
選技術時我秉持三個原則：開發速度快、維運成本低、可擴展。以下是實際選型與背後理由。
前端
- React + Vite：開發速度快，社群資源多，元件開箱即用。
- Tailwind CSS：不用花太多時間在樣式上，快速做出可複用的 UI。
後端與資料庫
- Node.js + Express：熟悉度高、部署簡單（heroku / fly / docker）。
- PostgreSQL（hosted like Supabase）：關聯資料適合管理模板與權限，且 Supabase 提供簡單的 auth 與 storage。
基礎設施與第三方服務
- Auth：Supabase Auth（省下自行做 OAuth 的開發成本）。
- 付費處理：Stripe（成熟、API 完整）。
- 部署：Fly.io + Docker（快速、延遲低，個人專案成本合理）。
- 信件通知：SendGrid（少量郵件免費額度）。
實務理由總結：用成熟的 BaaS（Backend-as-a-Service）與付費平台，把自己該花時間做的事（產品與實驗）最大化。
收費方案設計與 A/B 測試記錄
收費策略採三層定價 + 免費試用。初次上線時直接跑 A/B 測試，看哪種文案與價格能提升付費率。
- Free：最多 3 個模板、單人使用、基本 API 速率。
- Pro：US$12/月（或 US$120/年，等於兩個月免費），包括無限模板、多人協作、加速 API。
- Team：US$35/月（5 人起），含團隊管理、SAML、優先支援。
A/B 測試重點與結果
- 測試 A（功能導向）：強調「無限模板、API 加速」→ 轉換率 1.8%。
- 測試 B（價值導向）：強調「節省每週 3 小時流程時間」→ 轉換率 2.6%。
結論：對 B2B 型小團隊，價值導向（時間回收、效率提升）的文案勝過單純列功能。價格上，Pro 套餐在 US$10–15 範圍內最佳化轉換與 LTV。
真實收入表與成本概覽（公開數字）
以下為公開的實際數字（貨幣單位：USD），數字取自上線 12 個月內的簡化總表，供參考與複製戰術。
- 第 1–3 月（產品雛形、測試期）：MRR 從 US$0 增至 US$220。主要來源：早期使用者轉訂閱。
- 第 4–6 月（小規模成長）：MRR 從 US$220 增至 US$1,050。透過社群推廣與內容行銷（寫技術與使用案例）。
- 第 7–12 月（穩定化）：MRR 最終到 US$2,850（第 12 月）。
成本（平均每月）：
- 雲端 / DB（Supabase + Fly.io 小型方案）：US$120
- Stripe 手續費（以收入 2,850 計算，約 2.9%+30c）：US$95
- 工具與外包（SendGrid、Sentry、部分設計外包）：US$200
- 付費廣告 / 推廣（非每月穩定，平均攤提）：US$250
- 合計平均月成本：約 US$665
淨利（第 12 月）：MRR US$2,850 – 成本 US$665 = 毛利 US$2,185（未計個人薪資）。
成長實驗的步驟、結果與學習
我做過的主要實驗如下，附上步驟與可複製的成果：
實驗 1：免費模板市場（Content-Led Growth）
- 步驟：每週公開一個實用模板（例如：發案流程、簡報大綱），並提供匯入按鈕。
- 結果：每個模板帶來約 50–120 名新訪客，其中 2–4% 轉為註冊。
- 學習：免費且實用的模板是引流與建立信任的低成本方式。
實驗 2：價值導向 Landing Page A/B
- 步驟：跑兩版本 landing page（功能 vs. 成效），追蹤 signup → trial → paid 流程。
- 結果：價值導向勝出，付費轉換提高約 45%。
- 學習：B2B 小團隊更在意「省時間、產出可量化」而非功能清單。
實驗 3：按使用量計費 vs. 固定費用
- 步驟：在一小群用戶中測試「按 API 呼叫計費」與「固定 Pro 訂閱」。
- 結果：固定訂閱的預測性收入與續訂率較高（特別是月平均 API 呼叫中等的客戶）。
- 學習：對於需要預算控制的小團隊，固定費用更能降低心理門檻。
可複製的實作清單與注意事項
把我做過且驗證過的方法，精簡成一個可以直接執行的清單：
- 1. 最小可行產品（MVP）先把核心價值做完（例如模板 + 分享功能），把額外功能放進 backlog。
- 2. 使用成熟 BaaS（Supabase、Stripe、SendGrid）把基礎設施時間降到最少。
- 3. 上線第一個月只做三件事：收集使用者反饋、觀察行為數據、跑 A/B 文案測試。
- 4. 建立免費但有價值的資源（模板、教學），作為吸引與教育的入口頁。
- 5. 付費方案採「簡單、可預測」原則；複雜的按量計費只在需要時加入。
- 6. 每月固定檢視 CAC（獲客成本）、LTV（使用者終生價值）與 Churn（流失率），小幅調整後再放大投放。
注意事項（避免踩雷）：
- 不要在一開始就做過多第三方整合，維運成本會爆炸。
- 別把價格訂得太低以為能快佔領市場 — 會吸引大量不會付錢的用戶（心酸）。
- 自動化測量指標（特別是核心轉化漏斗）比漂亮的 Dashboard 更重要。
結論：公開數字不是為了炫耀，是為了讓你少踩地雷
這個小型 SaaS 的路程證明：用對工具、找對用戶痛點、並用簡單的實驗思維，你可以在一年內把產品做到自給自足。公開的收入與成本不是保證你也能複製完全相同的結果，但能讓你看到「真實規模」下的決策與 trade-off。最後的忠告：持續做小實驗、快速失敗、把學到的東西寫下來（最好公開）。如果你也在做類似事情，留言告訴我你最想知道哪一部分，我會在後續分享更深的數據與程式碼片段。
工程師幽默收尾：當你以為一切都穩定時，總會有一個 2AM 的錯誤提醒把你喚醒——那是創業的夜曲。
