一句话总结

摆脱“紧急模式”

亮点

• 我们已完成将 TinyPilot 的订单履约全面转交给第三方服务商。
• 本地团队正在摆脱长达数月的“紧急模式”。
• 既然生产速度不再是瓶颈，我就可以选择一个能最大化利润的定价。

目标完成情况

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

将所有产品转至第三方物流（3PL）服务商

• 结果：我们的 3PL 服务商现已负责所有产品的发货。
• 评分：A

过渡非常顺利，这是公司的一大进步。由 3PL 负责日常订单履约后，我们灵活了许多，不必再每周六天都守在办公室。员工仍会定期去办公室，但不再有必须赶在当天邮车取件前完成所有工作的压力。

选定一家代工厂来接管 TinyPilot 的设备组装，并启动过渡流程

• 结果：仍在洽谈中，尚未正式确定。
• 评分：B-

我找到了一家心仪的代工厂，但还没有正式签约。正在等待对方的正式报价和时间表。按他们乐观的非正式预估，首批生产将在 2023 年 10 月进行。

发布新版 TinyPilot Pro

• 结果：已发布 TinyPilot Pro 2.5.4
• 评分：A

这次发布在功能上没什么亮点，但它为用户从 Debian Buster（现已是旧版系统）迁移提供了路径。放弃对 Buster 的支持意味着可以去掉代码库中大量针对该系统版本的条件判断，从而降低复杂度。

TinyPilot 数据一览

这些数字看起来有点吓人，因为各项都在下滑，但实际落差并不大。总收入只下降了 4%。利润下滑只是因为支出的波动本来就很大。我对月均利润保持在 2 万至 3 万美元的区间依然持乐观态度。

跨过 3PL 这道坎

过去几个月里，TinyPilot 本地团队几乎一直在满负荷运转，所以我的首要任务就是想办法为他们减负。

在减轻工作量方面，性价比最高的举措之一就是完成向第三方物流（3PL）服务商的过渡。自 TinyPilot 创立以来，我们一直从办公室直接发货。改用 3PL 后，我们只需将产品批量运至仓库，之后由 3PL 负责日常的客户订单履约。

把履约外包给 3PL 肯定能省下不少工作量，但矛盾在于切换本身就需要额外的投入。

一旦把产品发往 3PL，大约需要一周时间对方才能准备好处理订单。这意味着我们必须额外备出一周的库存——而在当时连现有订单都勉强应付的情况下，这绝非易事。

我本可以关店一周来完成过渡，但那相当于损失 1 万至 2 万美元的销售额。相反，我采取了几项措施来为本地团队减负，让他们能集中精力备货。

首先，我减少了广告投放。这很好理解——在需求已经超出产能的情况下，再花钱去吸引新客户毫无意义。

其次，我提高了售价。我分几轮上调了 TinyPilot 的价格，以在尽量减少收入损失的前提下放缓销售速度。

最后，我亲自分担了客服工作。本地员工要负责组装、发货和客服，我每帮他们省下一小时的客服时间，就能让他们多一小时去组装设备。

幸运的是，这些措施奏效了。5 月初，本地团队已经攒够了足够多的库存，可以向 3PL 发出一周的量。3PL 上线后，本地团队的工作量下降了约 15%。

整体过渡还算顺利，但如果重来一次，有不少地方我会规划得更好。我整理了一份向 3PL 服务商提问的清单，供首次接触 3PL 的人参考（或者将来我自己换服务商时也能用上）。

摆脱“紧急模式”

即使把履约外包给了 3PL，我们也没能像预期的那样松口气。仓库里只有几天的库存，团队仍在手忙脚乱地组装新设备，以补充 3PL 的库存。

我不禁怀念起一年前本地团队还有大量富余产能的时候。那时我最大的烦恼还是错失了让他们承担更多责任的机会。

今年情况完全反了过来。我开始接手一些原本该由本地团队做的工作。我们始终有种疲于应付、而非从容应对的感觉。像文档整理、库存规划这类长期性工作都被搁置了。

最糟糕的是，销量好的日子也让人高兴不起来。当我在 Shopify 上看到一天卖出 10 多台时，第一反应不是庆祝胜利，而是：“糟了，这会让我们更难在仓库里攒够库存。”

我觉得只有当仓库里有足足一个月的库存时，大家才能真正放松。我在表格里粗略算了一下，按目前的销售和生产速度，要到 7 月才能达到这个水平，但我不想让大家再这样紧绷两个月。

过去几个月里，我一直在考虑再招一名本地员工。之所以犹豫，是因为我预计把履约交给 3PL 后工作量会下降，再把生产交给代工厂后会进一步大幅下降。到那时，本地团队的工作就只剩下客服，我觉得撑不起三个人的工作量。

当看到 3PL 过渡后工作量依然不小，我又重新考虑起招第三个人的想法。随后灵光一现：既然六个月后可能就没那么多活了，我完全可以把它招成短期岗位。

我在 Craigslist 和本地的 Facebook 群组上发布了招聘信息。两周内收到了 18 份简历，面试了 5 个人，并向其中一人发了 offer，对方也接受了。新员工本周入职。

自从决定增聘一人后，团队氛围明显变了。大家不再有那种赶时间的紧迫感，整个人都放松了下来，也重新开始投入到文档和长期规划中。

怎样定价才能利润最大化？

过去两个月里，我一直在通过提价来降低销量。我故意把 TinyPilot 定得偏高，以减少总销量，为备货争取时间。

如今我们已经缓过劲来，也有了更多组装设备的产能，就可以不再为缓解生产瓶颈而定价，而是以利润最大化为目标来定价了。

上个月我已经做过一些定价尝试，现在有了更多数据，来看看具体情况。

Voyager 2a USB-C 版

上个月，TinyPilot 需求缺乏弹性让我感到意外。我原本预计提价后销量会明显下滑。现在有了更多数据，需求曲线比我预期的更接近一些。提价 120 美元（32%）导致订单量下降了 34%。

有意思的是，379 美元和 499 美元两个价位的日均利润几乎完全相等（1220 美元/天 vs 1219 美元/天）。考虑到销量减少 34% 后长期的客服成本会更低，499 美元价位的总体利润其实会更高。

Voyager 2a PoE 版

购买更高端 PoE 版本的客户，在 478 美元到 528 美元之间的价格似乎不太敏感，无论定价多少购买频率都差不多，不过样本量较小。

最赚钱的价格是 498 美元，不过由于统计周期很短，这个数据很可能只是个异常值。

决定：定价 399 美元 + 99 美元

最佳定价点似乎是基础款 399 美元，PoE 升级加 99 美元（即 498 美元）。TinyPilot 在这个价位上实现了最高的销售利润。虽然该时间段的样本量较小，但它也恰好处于其他价格所呈现的曲线顶部附近。

我喜欢 399 美元基础定价的另一个原因是，它对像我这样的人来说仍在可接受范围内。如果三年前我看到像 TinyPilot 这样的产品，我会觉得：“399 美元，对我的 homelab 来说很值。”

业余项目

ScreenJournal

我继续在开发 ScreenJournal，这是一款可以与朋友分享电影推荐的开源网页应用。

4 月份我主要新增的功能是让用户可以评论他人的影评。我没有使用任何评论组件，完全是自己从零实现的。效果如下：

我对 ScreenJournal 做的另一项重大改动是重构了端到端测试，让它们并行运行而非顺序执行。

在做网页应用的端到端测试时，共享数据库一直让我头疼。我始终没搞明白其他开发者是如何绕过这个问题的。

以前，我通过在每次端到端测试前重置数据库来解决共享状态问题。这种方式很慢，而且由于所有测试共享同一个数据库，一次只能跑一个测试。

我现在的方案是为每个客户端分配一个 cookie，并将该 cookie 关联到一个独立的内存 SQLite 数据库。这样测试之间就不再通过数据库共享状态，可以并行运行了。我觉得这个方案比以前的都好，但仍感觉像是在重复造轮子，很想知道读者是否了解更成熟的解决方案。

总结

完成了什么？

• 完成了向 3PL 仓储服务商的过渡。
• 发布了 TinyPilot Pro 2.5.4。
• 参加了 MicroConf US 2023。
• 为 TinyPilot 办公室新聘了一名员工。
• 处理了 2022 年报税中 Section 174 带来的麻烦。

经验教训

• 有很多求职者能够接受短期岗位。
  • 我之前一直不敢招第三个人，是担心岗位需求减弱后不知如何安排。后来我意识到，从一开始就说明这是短期岗位，其实有很多候选人乐于接受，甚至更偏好短期工作。

下月目标

• 帮助最新的 TinyPilot 员工入职。
• 实现 9 万美元营收。
• 找到三位愿意测评 TinyPilot Voyager 2a 的 homelab 博主或 YouTuber。