2024年2月，我在閱讀《複利效應》時讀到了「巔峰表現夥伴」這個概念——每週固定時間，和一位夥伴進行 30分鐘的深度對談，交流彼此在上一週當中所經歷的成功、失敗、困境、頓悟，徵詢必要的回饋，並且要求彼此當責。在看到這個概念的當下，我立刻找了一位同樣渴望自我提升的朋友，來一起執行這個計畫，而他也爽快的答應，從此開啟了我們長達一年的巔峰夥伴計畫。

每週一晚上9點，我們的電話會準時響起，從未間斷。我們都非常重視這個「作戰會議」，把它視為一種儀式。

這一年裡，我們經歷了一些微小的成功、巨量的失敗、數不完的困境，以及難以量化的頓悟時刻。正因為這些跌跌撞撞，我們在職涯、商業思維和人際關係上，也獲得了不少成長。更重要的是，我們活得比以往的每一年都更「有意識」。

痛點浮現

在執行的過程中，一個問題越來越明顯：我需要一個工具來符合「巔峰夥伴」的流程。

長期工作下來，我發展出了一套自己的「第二大腦」系統，每個工具都被我用得淋漓盡致：

  • Heptabase 組織年、月、週的策略規劃
  • Trello 管理日常任務執行
  • Moleskine 手帳的儀式感最能驅動自我覺察
  • Notion 靈活地堆疊零碎想法，組織檔案結構

但每當我要執行巔峰夥伴時，就是手忙腳亂的開始：

每週一晚上9點前，我得先從 Heptabase 回顧我當週的目標是什麼 ⮕ 再到 Trello 回溯完成了哪些任務 ⮕ 再從 Moleskine 手帳裡撈出這週的關鍵醒悟 ⮕ 最後在 Notion 組織零碎想法。

等到我們開始對談時，我早已在四個工具間消耗了心力。這完全違背了我建立第二大腦的初衷——降低心智負擔。

我認為巔峰夥伴真的是一個很好的機制，他著實幫助到我，如果這時有一個工具能夠把它的流程變得更加精簡流暢，那會大幅的幫助到我以及認同這個理念的人。（scratch my own itch）

於是，我決定做出 Peak Pals 來解決這個流程問題。

設計構思

在設計 Peak Pals 時，我開始分析巔峰夥伴為什麼有效。我認為它伴隨幾個關鍵要素：

  1. 首先是每一天要活得有意識：透過日誌記錄自我對話，你被迫去思考「我今天有沒有朝著這週的目標前進？」，即使沒有也沒關係，這會是一個沈澱的機會。
  2. 其次是「胡蘿蔔加棍子」組合拳：當完成一個個的週目標時帶來的正向回饋，改寫多巴胺系統，強化想做好下一個任務的慾望；當有外部友人看著你有沒有好好做每週目標時，那份「被看著」的感覺帶來的社交壓力，會讓你不想丟臉，努力達成。

到這一層思考後，Peak Pals 的雛形就很明確了：保留手帳的儀式感與週目標的明確感，加入非同步的當責系統，來讓這幾個核心要素全力運作。

設計明確、PRD開立完畢後，我立刻著手開發。歷經了四個多月，終於把它推上線，在這幾個月的開發中我踩了不少坑，也做對了幾件事。讓我逐一拆解，希望能幫你少走彎路。

做得好的地方

1 - 儘早建立 Production CI/CD

我很快就決定用 Render 來處理 infrastructure，而不是自己折騰 VPS。這個決策看似伴隨著更高的月費成本，但省下來的時間成本是巨大的——我不用在 SRE 上消耗心力，可以完全專注在前後端的交付。對於 solo developer 來說，每一分鐘都該用在「創造產品價值」上，而不是運維。

2 - 精練的 PRD & User Stories

我花了不少時間把需求拆成清晰的 GitHub issues，每個 issue 都很小，小到可以在半小時內完成。

這帶來了兩個意想不到的效果：首先，每完成一個 issue，都有一種多巴胺爽感，正向迴圈很快就建立了。其次，即使某天工作很累沒力做大任務，我也會強迫自己至少完成一個 bug fix 或小改進，這樣每天都能提交 commit，保持開發節奏（momentum）。

很多時候我們不是沒有足夠的意志力，而是大腦看不到目標與當前所處位置的明確路徑。一旦規劃明確，開立出該做的任務細節與執行方式，就讓自己的身體進入自動導航，逐一完成目標。

Perfect is the enemy of good

3 - 邀請早期 Beta Users

這可能是整個開發過程中所做出最對的決策。看著自己的產品實際的幫助到用戶，那種感受是無可比擬的。當 beta user 反饋出一個 UX 問題或提出改善建議時，我有一種強烈的動力想立刻幫他們解決。不只是出於責任感，而是真實的「我想幫你」的感覺。

因為我有著這個產品的 100% ownership，這當責的連結感與成就感比任何外部誘因都還強烈。

Special shoutout to my beta users: Eishin, Jeff, Samara, Circle, JC & my mom.

4 - 與設計師協作

我找了一位設計師朋友參與這個專案。她的第二視角非常寶貴——我作為工程師習慣從「技術可行性」出發，而她會從「用戶感受」出發。這兩個視角的碰撞，讓我們找到了一個平衡點：既能快速上線，又不犧牲基本的美感和可用性。

這四件事的共通點是：它們讓我在開發過程中保持了節奏感。每一個決策的背後，都是在問「什麼會讓這個產品變得更好、更快交付到用戶手中」。

沒做好的部分

架構與技術細節的遺憾

前端

我沒有從一開始就完整規劃基礎架構。由於正職大多在大型 B2B code base 打轉，回頭做 2C 的產品反而漏思考了很多細節。

i18n（多語言）、notification system、mobile RWD、dark mode、navigation system、landing page SEO、loading skeleton——這些東西後來補都會很痛苦，應該一開始就建立。我只做了其中一部分，現在回過頭想加，都得重構。這是典型的「early decision」問題，越往後補，技術債越高。

後端

我是 FE:BE = 80:20 的 fullstack，這次開發是練手後端的好機會。所以我在 auth flow、high-level abstraction、user base model orchestration、Redis caching 上都還有很多學習空間。坦白說，這不是「做錯」，而是「做得不夠深」。但既然是 side project，我決定把它當成學習投資而非完美交付。

更深層的三個決策失誤

1 - 沒有 Mobile-First 的設計思路

Peak Pals 本質上是一個日常應用，用戶大部分時間在手機上記錄日誌。但我是先做 desktop 版，後來才開始往 mobile 補足。因為個人認為 deep-work 的使用情境應該是 desktop first，但這種想法太主觀了。

事實上，主流用戶仍舊習慣 mobile first。許多 user flow 的問題只有在真實用手機操作時才會浮現。重來的話，我應該從一開始就 mobile first，同步進行 desktop 和 mobile 開發，這樣才能及早發現流程上的問題。 Cross device component reusability 也會拆的更明確。

2 - 完全忽視 SEO

我一開始的心態是「這是個 hobby project」，所以沒把 SEO 當一回事。但現在回想，Peak Pals 本身就高度仰賴搜尋——「巔峰夥伴」、「目標管理工具」、「當責系統」、「線上手帳」這些搜尋關鍵詞。

我當時應該直接選 Next.js 並建立 programmatic SEO 的基礎架構，而不是用純 SPA。這個決策的代價是，我現在很難透過搜尋引擎獲得新用戶。

3 - 沒有任何商業模式

這是最大的失誤。我完全沒想過收費，甚至想讓它永遠免費。理由很簡單——我覺得它能幫助到人，這份價值感就夠了，我不認為它值得收費。

但事後我才明白，不收費其實限制了我能做什麼。首先，我燒不起 LLM token，所以沒有辦法加入 AI 相關功能（我原本想用 AI 來幫助用戶更好地反思）。

其次，我無法為重度用戶開發進階功能——一旦我有營收壓力，就能合理地為核心用戶投注更多技術成本。現在我被「維運成本」（大概是 600 元/月，四隻 services + 網域）給 cap 住了。回頭看，收費不只是為了賺錢，而是為了給自己「更好地投資這個產品」的正當理由。沒有收費看似超然，實則是給自己一個理由把它停留在 Hobby Project 的層級，最終為市場帶來的正和反而不是最高的。

架構決策、商業決策，都該儘早思考。就連我這個每週都勤奮看 Indie Hacker 文章的人，該犯的 noobie mistakes 一個也沒少犯！

結語

我會持續在 Peak Pals 上投入開發，希望能為現在和未來的用戶打造更棒的使用體驗。在寫下這篇文章的時間點，Peak Pals 有著 10+ 的日活躍用戶！！不多，但我仍感到開心。

坦白說，Peak Pals 在產品層面還有很多未解的問題：

  1. 它終究不是社交媒體——我想要的是記錄並且鼓勵「過程驅動」的工具，而不是展示「美好結果」的舞台。（process driven > event driven）
  2. 它應該能 standalone 獨自使用也很有效益，夥伴（Pals）功能只是加分，不是必需。
  3. 我既想保留人的主動反思，又想引入自動化和 AI-in-the-loop 來減輕負擔，但這兩者的平衡點在哪裡，我現在還沒找到。
  4. 焦點設計——Year > Week > Day 的層級很清楚，但 Month 到底該不該有，我還在猶豫。
  5. 最終就是更好的 onboarding 體驗，與 retention。

解決這些問題並且把 Peak Pals 推到我心中該有的完整度，會是接下來的旅程。

我最近看到 750words 這款跟 Peak Pals 很像的軟體登上了 Indie Hackers 的版面，它透過 17年的迭代，達到了 $26k MRR的成績，我深感敬佩。它給了我一個啟示：再小的 idea，只要找到對的人，就能在長尾效應下活得很好（小而美）。

但這也揭露了另一面——產品做得「夠好」只是基礎。真正的挑戰是：你得先被「看到」。我在技術上踩的坑、架構上做的決策，都有辦法補救，但如果沒有人知道 Peak Pals 的存在，一切都是白搭。我的下一步不只是把產品做得更好，而是思考該怎麼讓對的人看見它，這遠比優化代碼更重要。

在 Peak Pals 上加我為好友，一起成長！🤝 🚀

Add Dave on Peak Pals

本週紀錄

正職的工作節奏終於回歸平衡。前陣子的隕石開發與混亂節奏，在我與夥伴的激烈溝通中硬生生開拓出了一條路，這中間的血與淚真的難用三言兩語道盡。現在能高效輸出專業能力，不被瑣碎和辦公室政治消耗，這種節奏讓我很有成就感、不耗能。

週五趕緊把管理的工作忙完，趁著午休的空擋，跑去和表哥逛我們最愛的 MOA，摸了幾把新槍，阿嘶...逛展的過程，除了與表哥更新彼此近況，也一起重溫小時候，他帶著我在各大槍隊，跟著一群大漢玩生存遊戲的美好時光。

週末，挑了一天與小e去看《國寶》這部神作（分數：10/10，強烈建議不看預告片直接前往）。在等候國寶開演前，我們找了間咖啡廳坐下來放空，我除了構思這篇文章的架構外，也接續著看三毛的《快樂鬧學去》。我曾跟創作課認識的朋友說，當我還有閒情逸致去欣賞純文學作品時，代表生活還在可控狀態，唯有在這樣的狀態下，我的美感受器才能正常運作。這一週，算是這樣的狀態。