一句話總結

TinyPilot 如何提升經常性收入？

重點提要

• 我深入思考為 TinyPilot Pro 增加經常性訂閱需要付出什麼。
• 我進一步探索使用 Nix 來管理開發環境。

目標達成度

每個月初，我都會宣告當月想達成的目標。以下是我達成目標的情況：

達成 9.8 萬美元銷售額

• 結果：營收下滑 10% 至 8.4 萬美元
• 評分：C

儘管我們獲得了幾則新的正面評價，營收仍下滑：

• RaidOwl
• Home Network Guy（以及隨附的部落格文章）
• Network Profile
• Botio Studio（中文）

我們損失了一部分銷量，因為 Amazon 透過其如卡夫卡式般繁瑣的帳號健康政策調降了我們的商品排名。現在我們已重新獲得他們的信任，銷量也再次回升。

我也從其他創辦人那裡聽說，每年這個時候通常會出現夏季低潮。TinyPilot 在 2022 年 7 月也確實出現了 11% 的營收下滑。

讓 TinyPilot 轉移至合約製造商的進度維持在時程內

• 結果：時程已延後三週。
• 評分：D

製造時程延後了，因為合約製造商的下游供應商需要更多時間來生產電源轉接器和 USB 傳輸線等零件。在轉換期間庫存歸零之前，我們仍有約三週的緩衝，但情況已開始有點吃緊。

這不是一個設計良好的目標，因為期限並非由我決定，而且我對此的掌控也有限。我真正能做的，最多就是防止事情在 TinyPilot 這端卡關，並要求合約製造商遵守時程。

花在電子郵件上的時間不超過 40%

• 結果：大部分時間都花在處理電子郵件上。
• 評分：F

我最終花在電子郵件上的時間遠超預期。我在七月安排了休假旅行，卻沒有考慮到休假期間會累積多少待回覆的郵件。

最終，我這個月大部分時間都在回覆電子郵件和審核團隊成員的工作成果。

TinyPilot 數據總覽

儘管營收下滑，利潤仍維持在 2 至 3 萬美元的區間。這個數字有些被高估，因為我的支出被人為壓低了。隨著轉移至合約製造商，我正逐步收掉自行生產，因此已停止採購新材料。

看到新評價這麼多，網站訪客卻下滑，讓我感到意外。看起來 TinyPilot 透過 homelab(家庭實驗室) 評測作為行銷管道，大概已經暫時飽和了，因此我應該把重心放在其他類型的銷售與行銷上。

TinyPilot 如何增加經常性收入？

每當 TinyPilot 的銷量低迷時，我就會更認真思考經常性收入。如果能有一份穩定的收入，而不必一直尋找新客戶，那該有多好。

我很害怕有一天，所有想要 TinyPilot 的人都已經買到了。那到時候我該怎麼辦？

我一開始的計畫就是讓 TinyPilot 擁有經常性收入。顧客只需購買一次硬體，之後每年透過續約軟體授權來支持持續的軟體開發與技術支援。

問題在於，我從未建立向顧客收取經常性收入的機制。三年過去了，除了少數企業客戶外，我們幾乎沒有任何經常性收入。

在這篇回顧中，我想思考為 TinyPilot 增加經常性收入的可能路徑。

TinyPilot Pro 的授權目前如何運作

我在 2020 年推出初代 DIY TinyPilot 套件後幾週，就開始著手開發 TinyPilot 軟體的進階版。

我為 TinyPilot Pro 開發的最早功能之一就是 license checking(授權驗證)。如果要銷售付費版的軟體，我需要一套能確認使用者授權是否有效的方法。

當我開始設計授權驗證系統時，我意識到，身為創辦人要兼顧其他所有職責，光是這個元件就得花上好幾個月才能寫完。如果光是實作授權管理就要花三個月，我還得再花兩個月去實作其他進階功能，顧客才會有足夠的理由購買 TinyPilot Pro。

當時公司才成立幾個月，我不想讓使用者等上五個月才有下一次更新，從而大幅拖慢動能。

有一篇 Basecamp 的部落格文章我現在找不到了，內容談到他們如何決定在連帳單系統都還沒寫好之前，就開始銷售他們的 SaaS 產品。（編按：Nathan Coleman（內森・柯爾曼）找到了，是出自 Basecamp 的著作 Getting Real（《搞定現實》）。）他們的理由是，軟體的帳單是在每個服務月結束時才到期，因此他們在第一筆銷售之後，還有一個月的時間來想辦法收款。

我為 TinyPilot 採用了類似的策略。我決定以榮譽制來執行授權，並預期自己有一年的時間來實作真正的授權管理解決方案。

如今三年過去了，我在 TinyPilot Pro 的授權執行上仍毫無進展。

在最糟的時機執行授權驗證

我們向顧客宣傳 TinyPilot 裝置享有 12 個月免費更新。但我們不能說的秘密是，一旦你在裝置上安裝了 TinyPilot Pro，就可以透過裝置的網頁介面永久持續更新軟體。

TinyPilot Pro 的軟體不會追蹤它是否關聯到有效的授權。有些在 2020 年 8 月購買的使用者，現在已進入一年期授權的第三年。

絕大多數顧客完全沒意識到自己的授權已經到期。他們理所當然地認為，既然 TinyPilot 仍持續向裝置推送更新，授權就應該還有效。

顧客有時確實會發現授權已過期，但往往發生在特別不方便的時機。

TinyPilot 使用 microSD cards(microSD 記憶卡) 作為儲存媒體。microSD 特別容易發生檔案系統毀損。當 microSD 上的檔案系統損壞時，唯一的解決辦法就是用 TinyPilot Pro 的磁碟映像檔重新燒錄 microSD。

為了下載 TinyPilot Pro 映像檔，顧客需輸入訂單資訊。在提供映像檔之前，我們會檢查顧客是否仍持有有效授權。

從顧客的角度來看，這是得知授權已過期的糟糕方式。他們的檔案系統已經損壞，導致 TinyPilot 中斷了工作。為了解決問題，他們得親自走到裝置前，取出 microSD 並重新燒錄。而現在我們還要向他們討錢？

如果顧客不想購買新的映像檔，只要聯絡客服，我們仍會提供舊版映像檔。但他們仍需等待最多一個工作天才能收到我們的回覆，如果這正阻礙他們的工作，體驗就很糟。

這個制度對我們來說也不理想，因為索取舊版 TinyPilot Pro 的請求會耗費客服資源。而且一旦顧客取得新的映像檔，他們又會回到「永久免費更新」的模式，因為他們可以繼續透過裝置內的網頁介面更新軟體。

什麼樣的經常性訂閱才值得投入心力？

任何形式的授權執行都所費不貲。至少，我們得在 TinyPilot 的網頁介面中加入讓顧客輸入授權資訊的功能，然後還需要在網際網路上架設一台伺服器，根據授權來判斷使用者是否有資格取得更新。

這樣做成本高昂，因為需要數週的開發工作，而且當使用者不可避免地來信說他們刪掉了含有訂單資訊的 TinyPilot 電子郵件、因而無法取得更新時，客服負擔也會增加。

如果我費盡心力做完這一切，卻發現對續約率毫無影響，那該怎麼辦？

要讓授權續約值得投入，每年至少需要產生 3 萬美元的額外利潤。我估計授權的金流手續費約為 3%，因此每筆授權續約可為 TinyPilot 帶來約 77 美元的淨收入。

要達到每年從授權中額外獲利 3 萬美元的目標，每年至少需要有 390 位顧客續約（390 × 77 美元＝3 萬美元）。

自 2020 年推出以來，TinyPilot 已累計售出約 5,000 台裝置。目前每年約售出 2,700 台新裝置。要達到 390 位付費訂閱者，只需說服現有使用者中的 7.8% 付費以持續取得更新，這似乎是可行的。

我如何測試顧客續約授權的意願？

好吧，我得說服 7.8% 的現有顧客購買續約授權，但要如何在不投入完整授權管理系統的情況下，確認 7.8% 是否可達成呢？

強制恢復原廠設定

今年稍早，我們必須將 TinyPilot 的基底作業系統從 Debian Buster 切換到 Debian Bullseye。Raspberry Pi OS 並未提供支援的大版本升級方式，因此我們不得不強制每位使用者手動重新燒錄 microSD來完成遷移。

我很不願意把這個成本轉嫁給使用者，但我們找不到其他辦法。一個正面的副作用是，它終結了「永久免費」更新的列車。如果使用者的授權已過期，就必須付費購買新的 12 個月授權才能繼續接收更新。

我們在 4 月 27 日推出這項變更，因此我比較了變更前後各三個月的授權續約情況：

一方面，這些變化令人鼓舞，因為強制付費升級帶來了 67% 的續約成長。另一方面，這些變化也令人擔憂，因為三個月內只有 55 位使用者續約。我估計約有 2,500 台裝置的授權已過期，這表示只有 2.2% 的人付費更新。

有幾個因素使得續約率比實際可能的水準來得更低：

• 我們近期的許多工作都集中在讓更新體驗更快、更不容易出錯。這很有用，但沒有人會為了讓未來的更新更順暢而特地去更新。
• 將升級與恢復原廠設定綁在一起，阻力很大。有些使用者可能因為不想花 20 到 30 分鐘重置裝置而放棄更新。

手動到期通知

這個月我想到一個點子，試著在顧客授權過期時寄送電子郵件通知。這當然可以自動化，但在投入太多自動化之前，我先試著手動寄了幾封信，看看是否有人會回覆或因此購買。

為了測試這個想法，我寄出了七封郵件，但沒有任何收件者續約或回覆。樣本太小，無法得出結論。如果我需要 7.8% 的顧客續約，那相當於每 12 到 13 人中只有一人會續約。

我不太想繼續這個實驗，因為有許多不利因素：

• 這些郵件是在他們不一定在乎是否繼續收到 TinyPilot 更新的時候寄達。如果提示是在使用者於 TinyPilot 網頁應用程式中點擊「Update」按鈕時出現，會是更有意義的測試。
• 有些顧客是用看起來像是收垃圾信用的次要帳號購買 TinyPilot，因此他們可能根本沒看到我的來信。
• 這些顧客可能會發現，即使不付費續約，仍能繼續收到新更新，因此他們沒有續約的誘因。

新增自動續約選項

我們目前僅提供單次購買的授權續約。我尚未探索經常性訂閱選項，因為 Shopify 原生僅支援單次購買。

要在 Shopify 上收取經常性款項，我得使用第三方 Shopify 應用程式，而我很不喜歡這麼做。依我的經驗，Shopify 應用程式品質不佳，而且要求我開放顧客資訊的廣泛存取權限，甚至包括那些交易根本未經過第三方整合的顧客。

不過，與其他實驗相比，自動續約選項在測試顧客訂閱意願方面，算是相當划算。如果我只是在授權購買頁面上多加一個選項，例如「或以 9 折購買年繳訂閱」，就能知道是否有顧客願意訂閱。

新增訂閱按鈕相對容易，而且我們很可能不必更動其他任何流程或系統，因為訂閱只會以一般的 Shopify 訂單形式出現。

業餘專案

What Got Done

我最近一直在嘗試 Nix，其中讓我感興趣的功能之一是 nix develop。它能讓你建立一個自給自足的 shell 環境，裡面精確包含了建置與測試專案所需的開發工具。

我在各種軟體專案中遇到的一個困擾是維護相依套件的困難。我的專案相依於特定版本，例如 Go 1.19 或 Node.js 16。每當需要升級到下一個版本時，要弄清楚如何在開發環境中安裝它，然後在持續整合（CI）設定中更新版本號碼，總是很麻煩。

更糟的是，如果同一系統上有多個專案，為其中一個專案更新 Node.js，就意味著其他專案會被換成非預期的 Node.js 與 npm 版本。

nix develop 的承諾是，我可以在一個地方定義相依套件：一個 Nix flake(Nix 組建描述檔)。例如，如果我需要升級到下一版 Go，只要更新一個檔案，重新執行 nix develop，就能在本地 shell 中取得正確版本的 Go。我的 CI 環境也會執行相同版本。該環境僅限於該目錄，因此變更套件版本不會影響同一系統上的其他專案。

我開始在 What Got Done 中嘗試 nix develop，因為它相依於 Go 與 Node.js，而版本管理一直是個痛點。

在 What Got Done 的開發環境中試玩 Nix 很有趣，但目前我遇到了以下幾個障礙：

• 我搞不懂如何讓 Go 的靜態二進位檔建置正常運作，而解法給人的感覺像是：「你本來就該知道這個神奇咒語。」
• 沒有簡單的方法可以指定相依套件的精確版本。
  • 我原本預期能像 Docker 那樣宣告版本，例如 go:1.19.3，但 Nix 不支援這種語意。
  • 對於如此強調可重現性的工具，這讓我感到意外。
  • 我找到最接近的解法是使用第三方工具來找出與套件版本對應的 nixpkgs 雜湊值，然後將套件鎖定到該 nixpkgs 雜湊。這是 What Got Done 其中一個相依套件的實際寫法。
  • Devbox 解決了這個問題，但那樣你只是間接使用 Nix，還得學習 Devbox 在 Nix 之上所建立的抽象層。
• 填入 Nix store 的速度慢到令人卻步。
  • 有一個 nixos/nix Docker 映像檔可以在 CircleCI 中很快地啟動，但為我的 Nix+Go flake 建置 Nix 環境卻要花約兩分鐘。
  • 這表示我執行的任何 CI 步驟都得先花兩分鐘來初始化 Nix。
  • 我試過快取 Nix store，但它約有 3 GB，CircleCI 需要約兩分鐘來下載與解壓縮。我認為 CircleCI 是將快取檔存放在 Amazon S3 上，因此除非快取大小小於 1 GB，否則效能會非常差。

總結

完成了什麼？

• 發表了〈Installing NixOS on Raspberry Pi 4〉
• 學會使用 hurl 來取代以 curl 為基礎、針對 HTTP APIs 的整合測試。
• 造訪了北卡羅來納州夏洛特與加拿大蒙特婁。

經驗與教訓

• TinyPilot 似乎已耗盡我們從部落格與 YouTube 評測中獲得的行銷價值。
  • 相較於一年前新評測帶來的效益，現在新評測的回報已明顯遞減。這絕對不像兩年前單一評測就讓銷量幾乎成長三倍的盛況。
• 提供可自動續約的 TinyPilot 授權選項，是測試經常性收入市場最划算的方式。

下個月的目標

• 盡快將製造轉移至合約製造商。
• 擬定搬離 TinyPilot 本地辦公室的詳細計畫。
• 測試自動續約 TinyPilot 授權的選項。

徵求協助

• 如果你有使用第三方 Shopify 經常性訂閱應用程式的經驗（無論好壞），特別是針對數位產品，歡迎寫信給我。
• 如果你能找到那則我印象中模糊的 Basecamp 故事，請在留言中告訴我。