Solo Builder Checklist：你的產品及格了嗎

一個人做產品第 14 / 18 篇

本篇是「一個人做產品」系列的第 14 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

最後一件事：把整本書變成一份 Solo Builder Checklist

恭喜你走到這裡。

14 章，從 Solo Builder 宣言到真實案例拆解，我們走完了一個產品從零到一的完整旅程。

但資訊量很大，容易看完就忘。所以這最後一章，我要把整本書壓縮成一份你可以反覆使用的 checklist。

這份清單不是「讀完打勾就好」的裝飾品，它是你的產品健康檢查表，每隔一段時間拿出來對照一下，看看哪些環節做到了、哪些還沒有、哪些需要補強。

不需要全部打勾才能上線。但如果太多項目是空白的，你可能要回頭看看對應的章節。

階段一：驗證（對應第 2-4 章）

這個階段的目標是：確認你不是在浪費時間。

問題驗證

你能用一句話說清楚你的產品解決什麼問題
這個問題有證據支持（社群討論、搜尋量、身邊的人也遇到）
你做過 AI 輔助的市場掃描，確認問題的普遍性
你模擬過至少 3 種不同類型的目標用戶訪談
你設定了明確的 kill criteria（什麼情況下放棄）

競品分析

你知道至少 3 個直接競品和 2 個間接競品
你做了競品矩陣（功能、定價、優缺點比較表）
你找到了至少一個明確的差異化角度
你確認差異化角度有市場需求（不是你自以為的優勢）

MVP 範圍定義

你的 MVP 功能清單不超過 5 個核心功能
你有一份「砍掉的功能清單」，而且比保留的功能更長
每個保留的功能都直接服務於核心價值主張
你預估了 MVP 的開發時間，而且不超過 4 週

Landing Page

Landing Page 已上線（即使產品還沒做好）
頁面上有清楚的價值主張、核心功能說明、定價方案
有等候名單或預先註冊表單
已經分享到至少 3 個相關社群
你有在追蹤轉換率（訪客 → 填表的比例）

階段一的及格線

至少完成 12 項以上，你才應該開始寫程式碼。 如果不到 12 項，回去看第 2-4 章。你花在驗證上的每一小時，都在為你省下未來數十小時的開發時間。

先說清楚：「12 項」是經驗法則，不是鐵律，也不是普世真理。如果你做的是免費工具、開源專案、純內容部落格或作品集型 side project，那「定價方案」「等候名單」這種項目本來就不適用——硬湊到 12 才動手，反而是在扭曲你的判斷。真正要問的是「對我這種產品該驗證的，有沒有驗證到」，不是「項數夠不夠」。

還有一個反方我得補：驗證和建造不是二選一。當 AI 讓一個能用的原型幾個小時就生得出來時，「先丟一個粗糙版本給真實用戶用」本身就是最強的驗證——直接動手做也是一種合法的驗證手段。我看過太多人卡在「再驗證一下、再問一輪」結果三個月沒寫半行 code，這是另一個極端。先驗證 vs. 先建造，取決於你的產品做出來有多貴：做出來要兩週就先驗證，做出來只要一個下午就直接做。

階段二：建造（對應第 5-8 章）

這個階段的目標是：用最少時間把產品做出來並開始收錢。

AI 開發工作流

你的專案有 CLAUDE.md（或等效的 AI context 文件）
AI 知道你的專案架構、coding style、測試慣例
你有建立至少 2 個 custom skill 來加速重複性工作
你知道什麼時候該用 AI、什麼時候該自己寫（第 5 章的判斷框架）
你的 prompt 有版本控制（好的 prompt 跟好的程式碼一樣值得保存）

部署上線

產品已部署到 production 環境
CI/CD pipeline 設定完成（推到 main 自動部署）
部署流程從 commit 到上線不超過 10 分鐘
你知道怎麼 rollback 到上一個版本
域名設定完成（自訂域名，不是平台預設的子域名）

Landing Page 與 SEO

頁面有正確的 meta title 和 meta description
有 Open Graph 圖片（社群分享時有預覽圖）
Google Search Console 已設定
Lighthouse Performance 分數 > 90
行動裝置體驗正常

付費機制

金流串接完成（Stripe、Gumroad、或其他）
測試過完整的付款流程（從點擊購買到收到確認信）
有免費方案或試用期讓用戶先體驗
退款政策已寫好並公開在網站上
你收到過至少一筆真實的付款

錯誤追蹤

有設定錯誤追蹤服務（Sentry、LogRocket 等）
核心功能有錯誤時你會收到通知
你知道過去一週產品有沒有發生錯誤

階段二的及格線

至少完成 15 項以上，你的產品才算「上線」。 特別注意：金流串接和錯誤追蹤不能跳過。一個收不了錢的產品不是產品，一個出錯你不知道的產品是定時炸彈。

同樣提醒一次：這條線是寫給「要收錢」的產品看的。如果你做的是免費工具或開源專案，金流、退款政策那幾項根本不存在，扣掉之後你的「15」自然就變小了——別因此覺得自己沒及格。把標準換成「對你這個產品該有的，有沒有都做到」就好，錯誤追蹤這種跟收不收錢無關的，才是真的不分產品類型都得有。

階段三：成長（對應第 9-12 章）

這個階段的目標是：讓產品能夠在你不盯著的時候也正常運作。

用戶回饋

產品內有回饋收集機制（表單、email、對話框）
你有定期（至少每月一次）整理和分析用戶回饋
你有一份「用戶要求但你還沒做的功能」清單，並且有優先排序
你做過至少一次根據用戶回饋調整產品方向的決策

客服與文件

有 FAQ 或幫助中心頁面
常見問題有標準化回覆範本（可以用 AI 輔助生成）
客服回應時間有明確承諾（例如 48 小時內回覆）
你每週花在客服上的時間不超過 2 小時

監控與維運

有 uptime 監控（產品掛了你會知道）
有設定告警（關鍵指標異常時通知你）
你知道產品目前的核心指標（DAU、MRR、錯誤率）
有自動化備份策略
備份做過至少一次還原測試

定價與商業模式

定價經過至少一次調整（根據市場反饋）
你知道你的 unit economics（每個用戶的獲取成本和終身價值）
營收趨勢是穩定或成長的
你有考慮過不同的定價模式（月費、年費、一次買斷、分級定價）

階段三的及格線

至少完成 10 項以上，你的產品才能稱為「有在成長」。 這個階段最容易被忽略，因為你會覺得「產品已經上線了，沒壞就不用管」。但沒有回饋循環和監控的產品，只是一個靜靜等死的網頁。

一樣，「10 項」是抓個感覺用的數字。這階段的「定價與商業模式」「unit economics」那一整區，對不收錢的產品來說整塊都跳過——免費工具的「成長」是看活躍用戶和留存，不是看 MRR 趨勢。回饋循環、監控、備份還原這幾項才是不管你收不收錢都該做的；數字湊不齊不代表你沒在成長，要看湊不齊的是哪幾項。

階段四：自主運行（進階）

這個階段不是每個 Solo Builder 都需要達到的。但如果你的產品已經開始有穩定收入，這些是下一步需要考慮的。

財務健康

營收已經覆蓋營運成本（伺服器、域名、第三方服務）
你知道你的月度淨利潤是多少
有三個月的營運預備金（即使收入中斷也能維持）
已經處理好稅務和法律結構（個人所得 / 行號 / 公司）

自動化程度

產品可以在你完全不碰的情況下正常運作至少兩週
客服有自動化回覆處理最常見的問題
帳單和收款完全自動化
部署和更新可以用一個命令完成

成長引擎

你有明確的主要成長渠道（SEO、社群、口碑、付費廣告）
成長渠道有持續帶來新用戶
用戶留存率穩定（不是只有新用戶、舊用戶一直流失）
你有一套可重複的內容產出節奏

階段四的及格線

如果你達到了這個階段的大部分項目，你已經不只是 Solo Builder——你在經營一個 micro business。 是時候考慮：這個產品值不值得投入更多時間？需不需要開始外包部分工作？要不要考慮全職投入？

AI 輔助自我評估

如果你想要更深入的診斷，可以把你的產品現況丟給 AI 做一次全面評估。以下是一個結構化的 prompt：

我是一個有正職的 Solo Builder，以下是我目前的產品現況：

產品名稱：[名稱]
產品類型：[SaaS / 內容平台 / 工具 / 其他]
上線時間：[何時上線]
目前用戶數：[大約多少]
月營收：[金額]
每週投入時間：[小時數]

以下是我已完成和未完成的項目：

已完成：
- [列出你已經做到的事]

未完成：
- [列出你知道該做但還沒做的事]

請以 Solo Builder 的角度幫我分析：
1. 我目前在哪個階段？（驗證 / 建造 / 成長 / 自主運行）
2. 最急迫需要處理的 3 件事是什麼？
3. 哪些未完成項目可以先跳過？
4. 以我的時間限制，建議的優先順序？
5. 有沒有我遺漏的關鍵項目？

AI 的回答不是聖旨——但它能幫你從「我覺得好像還可以」變成「我清楚知道下一步要做什麼」。

Solo Builder 宣言——再看一次

第 1 章開頭，我分享了 Solo Builder 宣言。走完 14 章之後，我們再看一次這六條信念：

先 ship，再完美。 → 你在第 13 章看到了——我的每個產品都是不完美就上線的。
時間是最稀缺的資源。 → 每一章的「傳統做法 vs. AI 加持做法」都在告訴你同一件事：用 AI 買回時間。
AI 是隊友，不是魔法。 → 第 5 章深入探討了這一點。AI 處理苦工，你負責判斷。
正職不是阻礙。 → 第 1 章的「隱藏優勢」，到第 13 章的真實案例，都證明了邊上班邊做產品不但可行，而且有獨特的優勢。
一個人不代表什麼都自己來。 → AI、開源工具、現成服務——你的「團隊」比你想的大得多。
做自己會用的東西。 → course-forge 就是最好的例子：從自己的痛點出發，做自己每天都在用的工具。

這六條不是「讀完感動一下」的雞湯。它們是決策框架。每次你猶豫要不要加一個功能、要不要換技術棧、要不要等到完美再上線的時候，回來看這六條。

這 14 章你學到了什麼

讓我用一張表格幫你回顧整本書：

章	標題	你學到的核心概念
1	Solo Builder 宣言	AI 改變的是時間成本，不是能力門檻
2	點子驗證	一天內用 AI 完成市場調查和競品分析
3	技術選型	一種語言打天下、選生態系不選框架
4	MVP 設計	砍到不能再砍，只保留核心假設
5	AI 驅動開發	從 Vibe Coding 到 Agentic Workflow
6	部署上線	零設定 CI/CD，選對平台省 80% 維運
7	Landing Page 與 SEO	讓目標用戶找到你
8	付費機制	一個人怎麼串接金流開始收錢
9	用戶回饋	系統化收集和分析回饋
10	客服與社群	用 AI 把客服時間壓到最低
11	監控與維運	讓產品在你睡覺時也穩定運行
12	Side Project → Micro SaaS	什麼時候該認真、怎麼定價
13	實戰案例	四個真實產品的完整拆解
14	Checklist	你的產品在每個階段是否達標

每一章都不是獨立的。它們串成一條路徑：驗證 → 建造 → 成長 → 自主運行。

你不需要一次走完。根據你現在的階段，跳到對應的章節就好。

延伸資源

如果你想更深入特定主題，以下是我推薦的資源：

產品與創業思維

The Mom Test（Rob Fitzpatrick）— 怎麼做用戶訪談才不會被禮貌性的「好棒喔」騙到
Lean Startup（Eric Ries）— MVP 和快速迭代的經典
Zero to Sold（Arvid Kahl）— 從零到出售 SaaS 的完整經驗，Solo Builder 必讀

AI 輔助開發

Claude Code 官方文件 — 最新的 skill、MCP、multi-agent 功能
Anthropic Cookbook — AI 應用的實戰 recipe

技術棧

Astro 官方文件 — 你的靜態網站框架
Cloudflare Developer Docs — Workers（含 Static Assets）、D1、R2 全家桶。Cloudflare 已在 2025 年把 Pages 的功能整併進 Workers，新功能只進 Workers，新專案建議直接用 Workers with Static Assets
Hono 官方文件 — 輕量 TypeScript 後端框架

Solo Builder 社群

Indie Hackers — 最大的獨立開發者社群
r/SaaS、r/SideProject — Reddit 上的 Solo Builder 討論區
台灣獨立開發者社群 — 在 Facebook、Discord 都有，搜「indie hacker 台灣」

最後想對你說的話

你讀完了整本書。但讀完不等於做完。

我認識太多人，讀了一百本創業書、看了一千支 YouTube 影片、收藏了一萬篇文章——然後一個產品都沒做出來。

不是因為他們不夠聰明或不夠努力。是因為準備永遠不會「夠」。你永遠可以再多學一點、多準備一點、多想一點。

但產品不是想出來的。產品是做出來的。

你不需要完美的點子。你不需要完美的技術棧。你不需要完美的 Landing Page。你不需要完美的定價策略。

你需要的只是一個「還可以」的點子，然後開始動手。

那些你崇拜的獨立開發者——他們的第一個產品也是粗糙的、不完美的、甚至有點丟臉的。但他們做了一件你還沒做的事：他們 ship 了。

所以，合上這本書。打開你的編輯器。

你的備忘錄裡那個一直躺著的點子，今天就開始驗證它。

用第 2 章的方法，花一個下午確認它值不值得做。如果值得，用第 3 章的框架選技術棧。用第 5 章的方法讓 AI 幫你寫程式碼。用第 6 章的流程一週內部署上線。