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

市面上也有幾個提供類似功能的開源工具,但 PicoShare 獨特之處在於它不需要資料庫伺服器。這代表你可以用單一的 Docker 容器來執行它,而其他方案則需要更複雜的編排設定。
PicoShare 成了我發布過的開源專案中成長最快的一個。它在發布後兩週內就獲得了 600 個 GitHub stars。截至本文撰寫時,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 roles 相依於 Git 儲存庫,Git 儲存庫又相依於其他 Ansible roles,而這些又相依於一堆 YAML 檔案中的參數。小小的改動就要耗費數週的開發時間。
這一切都只是因為我一直沒花心思去學正規的 Linux 打包工具。
今年,TinyPilot 團隊學會了使用 Debian 套件。過程遠比我想像中輕鬆。我以為我們得部署各種套件伺服器和金鑰伺服器,結果根本不需要。一旦找到正確的指南,流程其實相對簡單。
Debian 套件加速了我們的開發。相關工具能更早揪出代價高昂的錯誤,而且我們可以輕鬆地將預發布版本部署到測試裝置上,而先前的安裝系統卻讓這個流程複雜到幾乎不可行。
檢視去年目標的達成度
去年,我設定了三個高層次目標,希望能在這一年內達成。以下是我的達成情況:
將 TinyPilot 的年營收成長至 100 萬美元
- 成果:TinyPilot 營收成長 76%,達到 81.2 萬美元
- 評分: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 社群對本文初稿提供的寶貴回饋。
隨機一篇部落格



留言
登入後參與討論