一句话总结

如何提高 TinyPilot 的利润率？

亮点

• 尽管月营收高达 3 万美元，TinyPilot 依然勉强维持收支平衡。
• 我正在探索让大公司为 TinyPilot 支付更多费用的方案。
• 我必须接受一个事实：管理团队本身就是一份真正的工作。

目标评分

每个月初，我都会定下当月想要完成的目标。以下是本月的完成情况：

将 TinyPilot 营收提升至 3.3 万美元

• 结果：TinyPilot 营收提升至 3.9 万美元
• 评分：A

在顶级 IT 硬件博客 / YouTube 频道 ServeTheHome 发布重磅评测后，TinyPilot 的销量迎来大幅飙升。

将 TinyPilot 的运营全面迁至新办公室

• 结果：TinyPilot 已完全在新办公室运营
• 评分：A

我们终于把 TinyPilot 的运营从我家搬到了真正的办公室。过程中也有一些令人焦虑的时刻，比如一度不确定在 Linux 上能否调通打印功能，但总体而言搬迁非常顺利。现在，进货直接发往办公室，员工在办公室完成组装和测试，发出的订单也都从办公室寄出。

就《Refactoring English》目录收集反馈并迭代

• 结果：已收集反馈，但尚未确定如何整合
• 评分：B

我从 Write Useful Books 社区和自己的邮件订阅列表中收集了反馈。在 202 位订阅者中，有 6 人作出了回应，虽然比预期的少，但提供了很有帮助的反馈。

大家似乎对“如何写出更好的博客文章”这类宏观任务更感兴趣，而对讲解如何改进动词用法等章节兴趣不大。我想重新排序，把更吸引人的部分前置，但又不确定该怎么做，因为后面的章节依赖于前面的基础内容。

令人兴奋的成果自然比基础知识更吸引人。如果我写一本关于开发游戏的书，大家会对“如何打造拥有智能 AI 的敌人”这类章节感兴趣，而可能对“线性代数基础”没什么兴趣。这并不意味着我可以直接跳过基础，但或许意味着我需要在讲授基础的同时，找到让课程更实用、更易上手的方法。

TinyPilot 数据一览

TinyPilot 迎来了有史以来第二好的一个月。令人欣喜的是，在这样的销量下，所有环节都运转顺畅。今年 1 月出现类似的销售高峰时，我们曾不堪重负。好在我们改进了订单履约流程，这次所有系统都保持了正常运转。

我只是个管理者

2012 年到 2014 年，我在一家名叫 iSEC Partners 的公司担任软件安全顾问。我的上司 Peter 负责整个纽约团队。他经常自嘲说：“我只是个管理者——是额外的开销。”他这么说，是因为手下的员工都在做实打实的工作，而他只是公司官僚体系的一部分。

但 Peter 是一位极其出色的管理者，大家都心知肚明。我想他之所以拿自己角色的重要性开玩笑，是因为做管理让他没什么时间参与公司里更有趣的事，比如安全研究和工具开发。

我现在很能体会 Peter 当时的感受。经常到了一天结束时，我会觉得自己一整天什么也没做，只回了邮件。但退一步看，我也能理解为什么会这样。如今，与我一起做 TinyPilot 的人有很多：

• 三名远程软件开发人员
• 三名负责库存、组装和订单履约的本地员工
• 两家在 3D 打印和电气工程方面与我紧密合作的供应商

这样算下来，总共有 8 个人我至少每周都要沟通一次。除此之外，还有需要对接的其他人和服务方，比如办公室房东、人力资源/薪酬服务商、知识库以及库存管理工具等。而客服和销售则完全由我一个人负责。

考虑到这些，花大部分时间回邮件也就显得合理了。我需要调整策略，更加主动地拥抱管理工作。

不做团队成员能做的事

我现在做的最蠢的事情之一，就是去揽那些团队里其他人完全能胜任的任务。上个月我提到自己每天只有一小时能写代码。再仔细想想，其实这一小时也不该由我来写，因为我的队友们也能写代码，而我在那些只有我能做的事上已经落后了。

把只有 Michael 能做的事交出去

还有一些任务，理论上别人可以做，但实际上做不了，因为目前只有我拥有所需的权限或知识。

这些任务大多横跨不同领域或角色，比如管理只有本地员工才会用到的工具。以下是我应该交出去的事情（按与我解绑的难易程度从易到难排列）：

• 管理连接 Shopify 与库存表格的胶水代码。
• 管理用于构建 TinyPilot 生产镜像的脚本。
• 管理库存表格中的公式。
• 回复客服问题。
• 对 TinyPilot 的发布版本进行最终的质量测试。

月入 3 万美元为何还不盈利？

我最近向女朋友抱怨说，TinyPilot 在扩张过程中遇到的许多问题，很可能都有现成的简单解法，只是我不认识做类似生意的人，所以无从得知。她问我想向谁请教，并指出我完全可以自己想几个人选，然后直接给他们发邮件。

我第一个想到的是 Sidekiq 的创始人 Mike Perham。Mike 在 Indie Hackers 上的访谈是我最喜欢的一期。我还在 Google 工作时就听过，他的生意一直被我视为理想的独立软件业务——靠写开源软件月入约 8 万美元。最棒的是，客户都在自己的机器上运行 Sidekiq，所以几乎不可能出现需要他立刻处理的紧急情况。

我和 Mike 素不相识，于是给他写了封邮件，做了自我介绍，并请教他对 TinyPilot 有什么建议。他第二天就回复了，给出了好几条慷慨的建议。其中最让我印象深刻的是他对我财务状况的反应：

把利润提上去。5% 的利润率不是一门健康的生意。要么把成本降下来，要么适当提提价，要么找一个接近纯利润的纯软件附加产品。

这句话点醒了我。我知道利润很低，但还是觉得月入 3 万美元就已经处境不错了。但换成 5% 利润率的角度来看，情况就完全不同了。

根据 Mike 的建议，我仔细审视了自己的开支。我还没完成 5 月的账目，所以这里以 4 月为例。

原材料的成本并不意外。硬件产品的利润率一般在 50% 到 60% 左右，所以在约 3 万美元的销售额中，1.5 万美元的原材料成本符合预期。这方面几乎没有压缩空间，因为我购买的材料没有更便宜的替代品。有些东西比如线材，我为了保证质量会多花一点钱，但那在一台售价 300 美元的产品上也就差 1 到 2 美元。真正贵的部分是那些根本没有便宜替代的零件，比如树莓派或 HDMI 采集芯片。

第二大开支是软件开发，这看起来可能有些奇怪，毕竟我自己就会写软件。问题在于，要写好软件需要不被打扰的专注时间，而 TinyPilot 有太多非软件方面的事务要处理，根本无法保证这种专注。2020 年底，TinyPilot 的软件开发一度陷入停滞，就是因为我是唯一的开发者，而当时正忙于新产品的各种后勤事务。

我可以雇更便宜的开发者，但那很快就会酿成灾难。我合作的开发者都非常优秀。他们保持了代码库的高质量，让软件能够持续可维护、少出 bug。

我曾与收费较低的开发者合作过（约 30 美元/小时），他们要么根本做不来，要么会给出简单粗暴的实现，之后导致各种 bug 和维护上的麻烦。如果让低成本开发者来负责这个项目，代码库会在几个月内变得难以维护。

除此之外，我没有其他能大幅削减的开支。第三大开支是本地履约员工，但即使砍掉 50%，总开支也只会下降 2.4%，所以不值得去动一个已经运转良好的体系。

另一种遵循 Mike Perham 建议的方式是增加收入。

从大客户身上获取价值

今年早些时候，我和一家大公司的 IT 经理聊过。他非常喜欢 TinyPilot，想在公司内部推广，用它来替换原来单价 2000 美元的企业级设备。结果他成功了——公司在一个部门内部署了 40 台 TinyPilot，还计划部署更多。

猜猜 TinyPilot 从这次部署中赚了多少？一分钱也没有。

他们没有从我这里购买硬件，而是直接自己组装了设备。而由于软件采用了宽松的开源许可，他们可以在公司内免费使用，无需向我支付任何费用。

这在开源领域是极其常见的问题。宽松的许可有助于让更多人发现并使用你的产品，但也让大公司可以白白利用你的成果，却不给你任何回报。

我也就此事请教了 Mike Perham。以下是他的回复：

听起来你的许可证让大客户占尽了便宜。这是你的代码，对吧？改一下许可证，比如只允许个人用户免费使用单个实例。MIT 或 BSD 许可证很适合用来分享代码，但不适合用来做生意。

算是我的代码吧。参与 TinyPilot 开发的外包人员都签了合同，约定他们贡献的代码知识产权归我所有，但我也接受过一些志愿开发者的贡献。我的理解是，那些无偿贡献代码的开发者在技术上与我共同拥有 TinyPilot 代码的版权。

我以 MIT 许可证发布 TinyPilot，是因为它也给了我灵活性。我想我可以自己把代码“分叉”出来换一个许可证，然后说明它也使用了 MIT 许可的代码，但我不太确定具体该怎么操作。

我已经思考了一些从大型企业客户身上获取更多价值的方法，总结如下：

为 TinyPilot 提供企业版功能

大客户会提出、而其他人从不会提的一个需求，是对 TinyPilot 的编程化访问。比如，“我想监控远程屏幕，来检测目标设备是否崩溃，然后发出告警。”

我打算与大客户沟通，推出具备这类功能的 TinyPilot 企业版，并收取较高的溢价。我觉得像每台设备每月 50 美元这样的定价，对家庭用户来说高得离谱，但对财富 500 强企业而言，如果能让他们免于花费数周时间自研方案，这点钱根本不算什么。

提供 SaaS 增值服务

如果与设备在同一局域网内，TinyPilot 使用起来非常简单，但如果客户想通过互联网远程访问 TinyPilot，目前就得依赖第三方方案。我已向几位客户提过“ TinyPilot 云门户”的想法：一个安全的网页界面，让他们可以在互联网上的任何地方远程访问自己的 TinyPilot 设备。

这将是一个很好的软件即服务订阅机会，可以作为 TinyPilot 硬件产品之外的补充，带来更高的利润率。

不过，我还是想避免运营一个需要我随时待命的服务。我正在探索与一家能够负责服务运维的供应商合作的可能性。

咨询专注于开源许可的律师

关于开源许可，我还有很多不了解的地方，所以应该去咨询一位律师，弄清楚我有哪些选择。理想的许可是让个人用户能以低价在家中试用，然后在企业商用场景下为更贵的许可付费，类似于 Sidekiq 的模式。

历史项目

以下是我仍在维护、但并非当前开发重点的一些项目的简要更新：

Is It Keto

Is It Keto 仍在后台运行，但本月我难得做了一些维护。许多亚马逊联盟链接已经过期，指向了不存在的商品，所以我花了几个小时把它们修复了。

时隔数月再打开代码，实在很想一头扎进去捣鼓一番。但我必须克制自己，因为把精力集中在 TinyPilot 上对我更有益。

Hit the Front Page of Hacker News

这门课程每月仍有几笔销售，但我没花太多时间去推广。

一个亮点是 Dan Willoughby 学以致用，写了一篇登上 Hacker News 第 2 名的文章。而且他并不是靠什么“增长黑客”手段去钻系统空子，只是花时间写了一篇高质量的文章，就获得了相应的回报。看到这个结果我感到非常欣慰。

Zestful

尽管 Zestful 仍处于维护模式，上周末我还是为它发布了一个官方 Python 包。这是我一直觉得该做却迟迟未做的事，之前是因为不知道如何发布 PyPI 包。今年 3 月在摆弄 Restic 时学会了，于是就顺手用这些知识为 Zestful 做了一个包。

现在，用户可以在几分钟内上手 Zestful。像这样安装：

pip install zestful-parse-ingredient

然后导入 parse_ingredient 模块，并传入一种食材：

import json
import parse_ingredient

ingredient = parse_ingredient.parse('2 1/2 tablespoons finely chopped parsley')
print(json.dumps(ingredient.as_dict()))

你会看到类似这样的 JSON 输出：

{
  "quantity": 2.5,
  "unit": "tablespoon",
  "product": "parsley",
  "productSizeModifier": null,
  "preparationNotes": "finely chopped",
  "usdaInfo": {
      "category": "Vegetables and Vegetable Products",
      "description": "Parsley, fresh",
      "fdcId": "170416",
      "matchMethod": "exact"
  },
  "confidence": 0.9858154,
}

总结

完成了什么？

• 将 TinyPilot 的运营从我家搬到了真正的办公室
• 与库存经理合作，在 Notion 中将所有流程文档化。
  • Notion 确实有一些小毛病和坑，但相比我们之前用来记录内部流程的 Google Docs，已经是很大的进步。
• 顺利将职责从 TinyPilot 最初的库存经理（我的女朋友）交接给新入职的本地员工。
  • 我女朋友的研究生课程下周就要复课，所以她将没有时间再负责 TinyPilot 的工作。

经验教训

• 新员工培训要“写出来，而不是讲出来”。
  • 我们对第一位本地员工的培训几乎完全通过书面说明完成，而非现场讲解。
  • 大家都对上手过程的顺利程度感到满意，职责也由此平稳交接给了新员工。
  • 第二位本地员工在 5 月中旬入职，由于所有内容都已文档化，我们预计他的上手会更加顺利。
• 管理工作同样需要时间。
  • 如果想做好管理，我需要放手那些队友也能完成的工作。
• TinyPilot 需要更高的利润率。
  • 增加收入会比削减开支更容易。

下月目标

• 发布 TinyPilot 的新版本。
• 实现 3.5 万美元的 TinyPilot 营收。
• 做出内置以太网供电功能的 TinyPilot Voyager 2 原型。