公開打造 SignalSurf：我們的創業旅程全記錄
72% 的開發者更信任公開透明的新創公司。這是我們完整的 build-in-public 歷程——轉向、數據，以及真實學到的教訓。
每個產品都始於一個你揮之不去的問題。對我們來說，就是眼睜睜看著潛在客戶在 Reddit、Threads、PTT 和 Dcard 上討論競品——結果等我們發現那些對話時，已經晚了三天。等我們找到一則推薦討論串，底下已經有 50 則回覆，最佳回應時機早就過了。
我們不是第一個 build in public 的新創團隊，但我們可能是最執著的之一。根據 2025 年 Stripe 針對 1,000 多位新創創辦人的調查，72% 的開發者表示，他們更傾向信任公開分享歷程的公司（Stripe, 2025）。這個數據說服了我們。我們決定全部攤開來講：指標、轉向、讓人尷尬的早期原型，還有那些我們寧願忘掉的教訓。
這篇文章就是我們完整的 build-in-public 故事。我們會聊為什麼選擇這條路、在回饋循環中學到了什麼，以及那些多數創辦人刻意省略的缺點。
TL;DR: Build in public 不只是行銷手法——它是一種產品開發策略。公開分享歷程的新創團隊，社群參與度比不公開的高出 2.3 倍（Orbit, 2025）。我們從第一天起就用極致透明來塑造產品路線圖、吸引早期使用者，並在競爭激烈的市場中建立信任。
為什麼我們選擇公開打造產品？
透明不只是讓人感覺良好的理念——它能帶來可衡量的成果。2025 年 Edelman 信任度調查報告指出，63% 的消費者願意跟他們認為透明的品牌購買，即使那不是最便宜的選項（Edelman, 2025）。對一個自力更生、要跟資金充裕的對手競爭的新創團隊來說，這種信任優勢很關鍵。
我們的創始團隊在開發者工具領域待了好幾年。我們親眼看過像 Buffer、Plausible 和 Basecamp 這樣的公司，如何透過對數據和決策的極致坦誠來贏得用戶忠誠。我們想跟自己的使用者建立同樣的關係。
但還有一個很現實的原因。我們沒有行銷預算。我們有的是一個有說服力的故事：三個工程師受夠了手動在 Reddit 上搜尋高意圖對話，決定把整件事自動化。分享這個故事除了時間，不花我們一毛錢。
在公開打造的第一個月，我們每週在 X 和 Discord 社群（也同步到 LINE 社群和 Facebook 社團）發布更新。那些貼文每週帶來 340 次個人檔案瀏覽——大約是當時付費廣告效果的 8 倍。
理念上的理由
大部分人對 build in public 有個誤解。它不是過度分享，而是創造責任感。當你告訴社群「我們週五前會上線功能 X」，你就真的會在週五前上線。公開承諾會改變你的行為。
我們發現最好的產品決策來自這個循環：分享我們正在做的東西、傾聽反應、在投入太多時間之前調整方向。這比使用者研究座談會便宜得多。而且回饋是殘酷地誠實。
「Build in Public」到底是什麼意思？
Build in public 是指將你的新創公司的真實進展——營收、用戶數、產品決策和失敗——近乎即時地分享給你的受眾。Buffer 的 Open Blog 開創了這種做法，到 2025 年，已有超過 4,000 家新創公司在 OpenStartup.dev 等平台上公開資訊（OpenStartup, 2025）。這已經變成一場運動，而不只是一個趨勢。
但定義的範圍很廣。對有些創辦人來說，build in public 就是每個月在推特上貼營收截圖。對另一些人來說，是在 Twitch 上直播寫 code。我們介於兩者之間。
我們分享什麼
我們在 Linear 上公開產品路線圖。每週在 Discord 發布開發更新。每次重大轉向之後，我們都寫詳細的回顧文章。沒錯，我們也分享那些讓人不舒服的數字——像是因為 onboarding 流程壞掉，導致流失率飆升到 12% 的那一週。
我們不分享什麼
我們不會分享個別客戶的資料。絕對不會。我們不會透露與合作夥伴正在進行中的協商細節。我們也不會分享任何可能危害使用者隱私的東西。透明和魯莽之間有一條線，知道那條線在哪裡，本身就是一半的挑戰。
分享你的困難真的有用嗎？以我們的經驗來看，絕對有。我們社群裡互動最熱烈的貼文，不是成功故事，而是那些誠實說出哪裡搞砸了、又怎麼修好的紀錄。
我們早期的里程碑和轉向有哪些？
每間新創公司的時間線事後看都很整齊。我們的不是。2025 年 CB Insights 的分析發現，42% 的新創公司失敗是因為做了市場不需要的東西（CB Insights, 2025）。我們差點成為那個統計數字——而且差了兩次。以下是真正發生的事。
| 日期 | 里程碑 | 我們學到了什麼 |
|---|---|---|
| 2025 年 6 月 | 第一版原型：Reddit 關鍵字排程任務推到 Slack | 即使是粗糙的工具，也讓我們的對話捕獲率提高了 8 倍 |
| 2025 年 7 月 | 從關鍵字轉向 AI 意圖分類 | 關鍵字比對產生 70% 的雜訊——意圖分類改變了一切 |
| 2025 年 8 月 | 從 Slack 通知轉移到專屬儀表板 | 大量 Slack 通知很快就造成警報疲勞 |
| 2025 年 10 月 | 從只監控 Reddit 擴展到多平台 | 推薦討論串在每個平台上看起來都差不多 |
| 2025 年 11 月 | 第一批付費客戶（封閉測試） | 人們付費是為了訊號品質，而不是功能數量 |
| 2026 年 1 月 | 正式公開上線，搭配公開路線圖 | 透明加速了口碑推薦 |
最困難的轉向是從關鍵字改成意圖分類。我們花了三週做了一個精細的關鍵字管理介面。把它砍掉感覺像浪費。但我們的信噪比從大約 30% 的相關比對跳到了超過 90%。那一個決定定義了整個產品。
從 Slack 到儀表板的過渡
第一版把每個比對結果都丟進一個 Slack 頻道。簡單。有效——大概持續了兩週。一旦我們在多個 subreddit 上監控超過 20 組關鍵字，那個頻道就變成了消防水管。重要的訊號被淹沒了。我們因為高意圖討論串出現在幾十則低優先通知之間，而直接漏掉了它們。
儀表板不只是 UI 升級。它迫使我們思考優先排序、分類和工作流程。這些後來成為使用者每天都在依賴的核心功能。
使用者回饋如何塑造了我們的產品？
根據 ProductBoard 2025 年產品卓越報告，直接的使用者回饋驅動了高成長新創公司 68% 的功能優先排序（ProductBoard, 2025）。我們做得更徹底——大約 80% 上線的功能都來自使用者對話，而不是內部腦力激盪。
Build in public 創造了一種獨特的回饋動態。當使用者能看到你的路線圖和決策過程，他們不只是提出功能需求。他們會挑戰你的優先順序。他們會建議你沒想過的替代方案。他們會告訴你，你根本在解決錯誤的問題。
真正有用的回饋循環
經過幾個月的實驗，我們找到了目前的流程。首先，我們分享正在考慮做的東西——通常在 Discord 或 X 上簡短發文。然後等待。不是等按讚或轉推，而是等那些真正在用產品的人給出具體、詳細的回覆。
我們注意到一件反直覺的事：使用者明確要求的功能，不一定是他們用最多的。他們用最多的功能，往往是從我們讀出他們抱怨背後的言外之意而來的。「我希望儀表板載入更快」的意思不是我們需要效能優化。它的意思是使用者一天查看儀表板 15 次，需要的是即時推播通知。
為什麼我們重視社群回饋勝過問卷調查？因為問卷調查捕捉的是人們「以為」自己想要的東西。社群對話揭示的是他們「真正」在掙扎的事。這兩者之間的落差，就是 product-market fit 存在的地方。
Build in Public 如何幫助我們獲得早期成長？
我們的前 500 個使用者幾乎完全來自自然管道——沒有付費廣告、沒有 KOL 合作。2025 年 SparkToro 的研究發現，74% 的 SaaS 買家信任同儕推薦勝過任何形式的廣告（SparkToro, 2025）。Build in public 把我們的早期使用者變成了推廣者，他們在我們的產品正是設計來監控的那種對話中推薦我們。
這就是我們產品的美妙反諷。我們做了一個社群聆聽工具，而我們最好的成長管道就是我們幫客戶找到的那種自然社群對話。
複利效應
透明會產生複利。每次週報吸引幾個新追蹤者。那些追蹤者把我們的更新分享給他們的人脈。三個月內，我們的社群成長到多數同類新創需要一年才能達到的規模。
讓它成功的關鍵是：我們不只分享勝利。我們分享混亂的中間過程。排程任務當掉、我們漏掉 6 小時 Reddit 討論串的那一週。不小心連續三天發送重複 Slack 通知的那一次。比起「我們突破 1,000 個用戶了！」，那些故事引起的共鳴大得多。
哪些管道帶來最多成長？
我們在多個平台上做實驗。不是每個管道都一樣有效。有些出乎意料，有些則是完全浪費時間。
| 管道 | 投入程度 | 成果 | 值得嗎？ |
|---|---|---|---|
| X (Twitter) build-in-public 討論串 | 中（每週 2-3 小時） | 追蹤者成長最快，註冊數中等 | 值得 |
| Discord 社群 / LINE 社群 | 高（每週 5 小時以上） | 回饋品質最好，留存率最強 | 絕對值得 |
| Reddit r/SaaS、r/startups（及 PTT 創業相關看板） | 低（每週 1 小時） | 高意圖註冊，但量少 | 值得 |
| LinkedIn 創辦人發文 | 中（每週 2 小時） | 有些曝光，幾乎零註冊 | 對我們沒用 |
| 部落格回顧文章 | 高（每篇 4 小時以上） | SEO 價值，長期建立可信度 | 值得（長期投資） |
| Indie Hackers 更新 | 低（每週 30 分鐘） | 活躍的利基社群，不錯的註冊數 | 值得 |
Reddit 的訪客到註冊轉換率達 8.2%，是所有管道中最高的，儘管帶來的流量最少。X 帶來最多流量，但轉換率只有 1.4%。Discord 的留存率最好：在註冊前就加入我們 Discord 的使用者，30 天留存率是其他人的 3 倍。
那些沒人提到的缺點是什麼？
說實話吧。Build in public 不是只有好處。2025 年 Startup Genome 的報告發現，34% 公開打造的創辦人回報，持續的曝光和表現壓力讓他們更加焦慮（Startup Genome, 2025）。我們親身感受過。
必須持續表現的壓力
當你每週分享更新，每一週看起來都得像是有進步。但真正的產品開發不是線性的。有些週，你在重構沒人會看到的程式碼。有些週，你卡在一個困擾你好幾天的 bug 上。當你知道有人在看的時候，那些週感覺特別糟。
我們必須刻意抵抗只分享好消息的誘惑。當你開始為了最大化正面印象而策展你的 build-in-public 動態，你就已經失去了一開始讓它有價值的東西。
競爭對手也在看
我們公開分享的一切，競爭對手都看得到。我們注意到我們公開討論的功能，幾週內就出現在競爭對手的路線圖上。他們是抄襲我們嗎？也許。也許他們本來就在規劃那些功能。不管怎樣，極度公開確實有策略上的代價。
情緒上的代價
公開分享新創公司的數據有一種獨特的脆弱感。當成長停滯，所有人都看到了。當你犯錯，它永遠被記錄下來。我們有過那種——更新底下的留言刻薄到讓我們質疑透明是否值得的那幾週。
它永遠值得。但有些天，感覺不像。
在我們最慘的那一週——資料庫遷移出問題、我們有 4 小時的停機——我們差點沒發週報。但我們還是發了。那篇更新收到的支持性回覆和有建設性的建議，比我們寫過的任何一篇「一切都很好」的貼文都多。
我們用了哪些工具和管道？
2025 年 Indie Hackers 社群調查顯示，build-in-public 的創辦人平均使用 3 到 5 個平台來分享更新（Indie Hackers, 2025）。我們用六個——但投入程度不同。以下是我們的完整工具組合。
| 工具 | 用途 | 頻率 |
|---|---|---|
| X (Twitter) | 快速更新、里程碑公告、互動 | 每週 3-5 次 |
| Discord / LINE 社群 | 深度對話、功能討論、Bug 回報 | 每天 |
| Linear（公開路線圖） | 功能追蹤、優先順序透明化、使用者投票 | 持續進行 |
| 這個部落格 | 長文回顧、策略文章、SEO | 每月 2 篇 |
| Indie Hackers | 每月營收/成長更新、社群問答 | 每月 |
| GitHub（公開 repo） | 開源元件、邀請貢獻 | 視需要 |
如果重來，我們會改變什麼
如果能重頭來過，我們會更早投入長文內容。我們的部落格文章保鮮期最長，而且會透過搜尋流量隨時間複利成長。X 的討論串能產生立即互動，但 48 小時內就消失了。我們應該從第一個月就開始寫詳細的回顧文章。
我們也會在社群管理上設更嚴格的界限。早期我們試著在一小時內回覆每一則 Discord 訊息。那是不可持續的。現在我們把社群時間集中到每天兩個固定時段，回覆品質反而提升了。
常見問題
Build in public 對還沒有營收的新創公司值得嗎？
值得。2025 年 Orbit 社群驅動成長報告發現，擁有活躍公開社群的 pre-revenue 新創公司，募資速度比沒有的快 2.3 倍（Orbit, 2025）。即使還沒有營收可以分享，記錄你的旅程也能累積一批受眾，當你準備上線時他們就會轉變成早期使用者。在你覺得自己準備好之前就開始吧。
創辦人應該花多少時間在 build-in-public 上？
我們每週花大約 5-7 小時在所有 build-in-public 活動上。包括撰寫更新、回覆社群訊息和起草回顧文章。關鍵是批次處理：我們在週一早上寫更新，整週再陸續回覆互動。別讓它變成全職分心，影響到真正在做的產品。
Build in public 時有哪些東西不該分享？
永遠不要分享個別客戶資料、具體合約條款，或任何可能危害使用者隱私的資訊。我們也會避免在修補前分享即時的安全漏洞。除了這些硬性規則之外，靠判斷力。如果分享某件事會傷害團隊成員、客戶或合作夥伴——就別分享。透明有其界限，尊重這些界限才是讓它可持續的關鍵。
競爭對手真的會抄襲你的想法嗎？
有時候會。我們看過自己公開討論的功能出現在競爭對手的路線圖上。但重點是——點子不值錢，執行才值錢。透過透明建立的信任和社群，遠遠超過某人抄襲功能想法的風險。你的競爭優勢大部分在於團隊的執行速度，而不是保密。
如何處理公開的負面回饋？
我們誠實且快速地回應。當有人公開批評我們的產品，我們感謝他們、承認問題，並分享我們正在做什麼來解決。我們發現，對批評做出有深度的公開回應，實際上比批評本身造成的傷害建立了更多信任。最糟糕的做法就是忽略它或變得防禦性很強。
接下來呢？
我們的路線圖持續公開。目前最多人要求的功能包括 Discord 監控、自動回覆排程，以及更深度的 CRM 整合。我們也在大力投入多語言意圖分類——因為推薦討論串不只出現在英文世界，每種語言都有，中文當然也不例外。
打造產品是一場馬拉松。我們感謝每一位信任我們的早期使用者，也承諾會持續讓這段旅程保持透明。如果你想跟著我們的進度，Discord 社群和 LINE 社群是最多深度討論的地方。
Build-in-public 運動沒有在放慢。如果說有什麼變化，它正在加速。我們認為這是好事——對創辦人好、對客戶好、對整個產業好。更多透明意味著更好的產品。更好的產品意味著更快樂的使用者。這是一個值得持續的循環。