我作為自籌創業者的第五年
五年前,我辭去了在 Google 擔任開發者的工作,創立了自己的 bootstrapped(自籌資金)軟體公司。
最初幾年,我創立的所有事業都以失敗收場。沒有一家的月營收超過幾百美元,而且全部都處於虧損狀態。
在創業第三年的中途,我打造了一款名為 TinyPilot 的裝置。它讓使用者無需安裝任何軟體,就能遠端控制自己的電腦。這項產品很快就受到歡迎,自此成為我的主要重心。
2022 年,TinyPilot 創造了 $812k 的營收,較 2021 年成長了 76%。
在這篇文章中,我將分享擔任自籌創業者第五年所學到的一切。
過往回顧
年度亮點
TinyPilot 年營收成長至 $812k
| 收支項目 | 2021 | 2022 | 變動 |
|---|---|---|---|
| 銷售額 | $459,529 | $807,459 | 啟用 JS 以查看差異 |
| 信用卡回饋 | $2,241 | $4,327 | 啟用 JS 以查看差異 |
| 原物料 | -$224,046 | -$333,656 | 啟用 JS 以查看差異 |
| 人事費用 | -$142,744 | -$206,187 | 啟用 JS 以查看差異 |
| 電機工程顧問 | -$28,662 | -$124,643 | 啟用 JS 以查看差異 |
| 廣告 | -$3,873 | -$51,764 | 啟用 JS 以查看差異 |
| 網頁設計/品牌 | -$15,931 | -$30,215 | 啟用 JS 以查看差異 |
| 郵資 | -$24,227 | -$30,779 | 啟用 JS 以查看差異 |
| 雲端服務 | -$5,553 | -$7,865 | 啟用 JS 以查看差異 |
| 辦公空間 | -$4,400 | -$6,600 | 啟用 JS 以查看差異 |
| 設備 | -$2,083 | -$5,915 | 啟用 JS 以查看差異 |
| 其他 | -$4,902 | -$8,183 | 啟用 JS 以查看差異 |
| 淨利 | $5,349 | $5,979 | 啟用 JS 以查看差異 |
雖然營收成長 $350k 聽起來很亮眼,但實際上我只賺到 $6k 的利潤,就沒那麼令人興奮了。我沒有給自己發薪水,所以這 $6k 就是我在 2022 年從這門生意中獲得的全部所得。儘管如此,我仍對這些數字以及它們對 2023 年的意義感到興奮。
成本大幅增加的主因之一是電機工程。在整個 2021 年期間,TinyPilot 的電機工程外包廠商一直難以跟上 TinyPilot 的成長速度。在 2021 年底,我換了一家更符合我們需求的新廠商,但費用卻是原來的三倍。
持續的晶片短缺迫使我們頻繁地重新設計,這讓工程時數與原物料的成本大幅膨脹。我們常常為了趕在現有版本庫存用罄前重新設計電路板而與時間賽跑,因此一再支付額外費用以加速流程。
我們終於在九月擺脫了不斷重新設計的循環。我對第四季的成績抱持希望,也期待它能反映來年的走勢。當季的利潤為 $28.6k,因此如果 2023 年每月平均能有 $9.5k 的利潤,我就很滿意了。
TinyPilot 推出全新網站
當我在 2020 年推出 TinyPilot 時,我告訴自己網站和標誌只是暫時的。結果,產品迅速竄紅,讓我根本沒時間去更換它們。
TinyPilot 網站重新設計的前後對比:TinyPilot 網站重新設計
我先前曾寫過與設計公司合作是多麼令人沮喪且所費不貲,但我對成果感到滿意。舊版網站看起來像個業餘專案,而新設計則像是一家真正的公司。我猜測銷售額的提升至少有一部分要歸功於新設計。
TinyPilot 團隊從六人擴編至七人
截至 2021 年底,TinyPilot 團隊的組成為:
- 我,唯一的創辦人
- 三位兼職軟體開發者
- 兩位兼職本地人員,負責組裝裝置與處理訂單
- 其中一人同時負責客服
到 2022 年底,我們新增了兩位支援工程師並調整了職責,團隊現在的組成為:
- 我,唯一的創辦人
- 兩位兼職軟體開發者
- 兩位兼職本地人員,負責組裝裝置與處理訂單
- 兩人現在皆負責客服
- 兩位兼職支援工程師
加入支援工程師的感覺就像找到了拼圖中遺失的那一塊。在他們加入之前,技術支援全由我一人負責,佔據了我約 20% 的時間。現在,我花在處理支援請求的時間不到 5%,而客戶也能更快獲得協助。
支援工程師還會處理我過去沒時間做的事,例如調查複雜的錯誤、撰寫文件,以及改善我們的診斷工具。
擴編團隊考驗了我作為管理者的能力。2021 年時,TinyPilot 的工作流程還相當單純。幾乎每個人都是以單人作業的模式工作,成果不是直接交給我,就是交給客戶。當員工需要彼此協作時,也總是同一職務的夥伴之間。
整合支援工程師意味著必須釐清不同團隊如何協同作業。當支援請求需要出貨人員與支援工程師合作時,流程該如何運作?支援工程師與開發團隊之間的回饋機制又是什麼?
PicoShare 成為我成長最快的專案
近幾年來最讓我困擾的一件事,就是用 Google Drive 或 Dropbox 這類雲端儲存服務分享單一檔案有多麼麻煩。它們不會給你檔案的直接連結——只會給你一個連到其網頁介面的連結,並在那裡不斷要求你的收件者註冊帳號。如果你上傳影片到 Google Drive,即使影片已經是能在瀏覽器中播放的最佳化格式,它們仍會讓你等上 15 分鐘以上重新編碼。
為了提供現有雲端儲存方案的替代選擇,我打造了一款極簡的檔案分享應用程式,名為 PicoShare。你只需上傳檔案,它就會給你一個可分享的直接連結。就是這麼簡單!不會重新編碼,也不會跳出任何要求註冊的提示。

市面上已有一些提供類似功能的開源工具,但 PicoShare 的獨特之處在於不需要資料庫伺服器。這代表你可以在單一 Docker 容器中執行它,而其他解決方案則需要更複雜的調度設定。
PicoShare 成為我至今發布過成長最快的開源專案。它在發布後兩週內就獲得了 600 個 GitHub 星標。截至撰寫本文時,PicoShare 已有超過 10 萬次安裝。
學到的教訓
別成為任何人的最小客戶
在整個 TinyPilot 網站重新設計的混亂過程中,我犯了許多錯誤,但核心問題在於該設計公司與 TinyPilot 根本不匹配。
該公司的其他客戶預算是 TinyPilot 的 5 到 20 倍。起初,我以為這是個難得的機會——這家擁有高預算客戶的名牌公司竟然願意押注在我這樣的小公司上。
現實是,TinyPilot 是該公司最不受重視的客戶。他們的專案管理一塌糊塗,導致成本飆升、範疇膨脹,時程也不斷延長。
現在,當我與新廠商合作時,我會詢問我的公司與他們其他客戶相比規模如何。如果我在任何重要面向——例如規模、營收或產業——是個特例,我就會另尋他處。
維持 50% 的運作負載
如果公司的產能剛好完全符合客戶需求,那該有多好?員工們正好每週工作 40 小時,處理完所有訂單並回覆所有支援請求。他們既不會感到過度操勞,也不會無事可做,更不會有閒置時間。
實際上,那會是個糟糕的制度。以 100% 的利用率運作,意味著你完全沒有犯錯的餘地。像是銷售額突然增加或員工請假這類日常狀況,就會立刻讓你應接不暇。
我的目標是讓 TinyPilot 的每個人都維持在約 50% 的負載。也就是說,50% 的被動回應工作與 50% 的主動規劃工作取得平衡。對某些職務而言,比例不一定剛好是 50/50,但這是個不錯的經驗法則。
技術支援團隊是最能體現 50/50 分配的例子:他們一半時間回覆支援請求,另一半時間則想辦法讓使用者根本不需要尋求支援。主動性的工作包括修復產品錯誤、撰寫文件,以及改善我們的診斷工具。
TinyPilot 的每個小組都由兩人組成。當其中一人無法工作時,另一人可以暫停主動性工作,處理有時效性的任務而不會感到吃不消。如果因為某個熱門 YouTube 頻道提到我們而湧入大量訂單,我們也有餘裕可以吸收。
| 團隊 | 被動性工作 | 主動性工作 |
|---|---|---|
| 創辦人 | 團隊管理 廠商管理 審核工作成果 補足職責空缺 | 行銷 銷售 重新評估策略 招募與培訓 |
| 支援工程師 | 回覆技術支援問題 | 撰寫文件 撰寫教學 調查棘手錯誤 |
| 軟體開發者 | 修復緊急錯誤 發布新功能 | 改善開發體驗 建立自動化測試 修復非緊急錯誤 |
| 出貨人員 | 組裝裝置 處理訂單 客服 | 建立支援手冊 協助行銷 |
Ansible 與 git 並非軟體散布工具
當我開始打造 TinyPilot 時,我還不知道該如何散布 Linux 軟體。
為了發布 TinyPilot 的原型,我使用了自己熟悉的工具:bash 腳本、Ansible 和 git。該 bash 腳本會建立 Ansible 環境並執行 Ansible playbook。Ansible 會安裝相依套件、對作業系統進行必要的修改,並複製 TinyPilot 的 git 儲存庫。
安裝過程還算可以,稱不上好。速度很慢但很可靠,而且不需要使用者手動進行任何設定。
兩年後,TinyPilot 的更新流程變得一團糟。它仍然依賴原型時期那些不穩固的基礎,只是現在交織成複雜的相依網路。Ansible 角色相依於 Git 儲存庫,而 Git 儲存庫又相依於其他 Ansible 角色,這些又相依於一堆 YAML 檔案中的參數。即使是微小的改動也會耗費數週的開發時間。
這一切都是因為我始終沒有花心思去學習標準的 Linux 打包工具。
今年,TinyPilot 團隊學會了使用 Debian 套件。這遠比我想像中來得輕鬆。我原本以為我們得部署各種套件伺服器和金鑰伺服器,但結果發現根本不需要那些。一旦找到正確的指南,整個過程就相對簡單了。
Debian 套件加速了我們的開發。相關工具能更早發現代價高昂的錯誤,而且我們可以輕鬆地將預發布版本部署到測試裝置上,而先前的安裝系統則讓這個過程變得極其複雜。
回顧去年目標的達成狀況
去年,我設定了三個宏觀目標,希望在這一年內達成。以下是我的達成情況:
將 TinyPilot 年營收提升至 100 萬美元
- 結果:將 TinyPilot 營收成長 76% 至 $812k
- 成績:B
我一直都知道 100 萬美元是個非常有企圖心的目標。雖然我們沒有達標,但我仍對我們如此接近目標感到驚艷。
每週只花 20 小時管理 TinyPilot
- 結果:我在 2022 年花在管理 TinyPilot 的時間比 2021 年更多。
- 成績:D
我原本希望能透過自動化與授權,將管理工作縮減至每週 20 小時,但並未實現。在銷售成長、組建支援工程團隊,以及因晶片短缺而四處救火之間,我的管理時間反而增加了。
推出 TinyPilot Voyager 3
- 結果:我們甚至連設計階段都沒完成
- 成績:F
TinyPilot 一直以來都以 Raspberry Pi 4B 作為核心硬體。Pi 4B 周邊有很棒的生態系,但硬體成本相對較高,且難以與客製化晶片整合。
我在 2022 年的計畫是為更輕薄、更便宜的 Raspberry Pi Compute Module 4 打造客製化電路板。這可將我們的製造成本降低多達 60%,並簡化硬體設計。
然而,我們所有的硬體工程時間都花在追蹤製造問題和供應短缺上,因此在新產品上毫無進展。
第六年的目標
每週只花 20 小時管理 TinyPilot
去年我在縮減工時上徹底失敗,但這現在是我的首要任務。我對今年的機會感到樂觀。2022 年的許多工作已為我在 2023 年脫離關鍵路徑奠定了基礎。
創造 10 萬美元的利潤
在 TinyPilot 成立的前兩年半,我專注於成長。無論我每月賣出 20 台還是 2,000 台裝置,硬體與軟體工程的成本都差不多,因此我需要達到一定的規模,才能讓事業得以維持。
在 2023 年的大部分時間裡,TinyPilot 的產量將受限於供應。得知自己完全沒有機會提升銷售額,雖然令人失望,但好處是我可以放慢腳步,專注於獲利而非成長。
TinyPilot 過去大致都處於損益兩平,但我認為如果能避免進一步的硬體重新設計,今年有機會達到 10 萬美元的利潤。如果沒有 2022 年的硬體重新設計,我本可省下約 10 萬美元的工程費用和 2 萬美元的原物料成本。如果銷售額保持穩定,且在硬體方面採取更精簡的作法,2023 年應該會是獲利的一年。
關閉 TinyPilot 辦公室
我自 2021 年初以來一直為 TinyPilot 租用辦公室。我們用它來組裝裝置、處理訂單和存放庫存。
擁有自己的本地辦公室幫助我們快速適應硬體與流程的變化,但也帶來許多額外開銷。今年,我希望將組裝轉移至中國,因為我們所有的零件都來自那裡。我也正在將出貨作業轉移到第三方物流倉庫。
撤掉 TinyPilot 辦公室將省去我們維護實體空間、管理庫存和安排現場排班的工作。將製造與出貨外包,也將讓團隊在時間與地點上擁有更大的彈性。
我還熱愛這份工作嗎?
每一年撰寫這些部落格文章時,我都會問自己是否依然熱愛自己正在做的事。
2022 年是艱難的一年——絕對是我單飛以來最艱難的一年。我並非過得痛苦,但也不能說我熱愛它。
全球晶片短缺意味著我們從未以完全相同的方式生產過同一批產品。總是有某個零件缺貨或出現製造問題,因此我們不斷地趕著修復問題、調整流程,以免庫存用罄。我們撐過來了,只有少數幾天必須將產品標示為售罄,但過程充滿壓力。
儘管如此,這一年仍有許多值得肯定的地方。我用於寫作和軟體開發的時間相對較少,但我對自己的產出感到自豪。擴編 TinyPilot 組織並摸索團隊如何協作,提升了我作為管理者的能力。看到團隊在各自的角色中成長,並隨著公司演進而拓展技能,讓人感到欣慰。
我依然比起受僱於人,更喜歡為自己工作。我依然感激擁有自己的公司所帶來的自由。而且我依然想永遠這樣做下去。
封面圖片由 Loraine Yow(蘿蘭·尤)提供。感謝我親愛的未婚妻以及 Blogging for Devs 社群對本文初稿提供的回饋。
隨機一篇部落格


