一句话总结

TinyPilot 如何增加经常性收入？

本月亮点

• 深入思考了为 TinyPilot Pro 增加订阅制需要做些什么。
• 进一步探索了用 Nix 来管理开发环境。

目标完成情况

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

实现 9.8 万美元销售收入

• 结果：营收下降 10% 至 8.4 万美元
• 评分：C

尽管我们获得了几篇新的好评，营收还是下滑了：

• RaidOwl
• Home Network Guy（及配套博文）
• Network Profile
• Botio Studio（中文）

由于亚马逊通过其堪称卡夫卡式的账户健康政策降低了我们商品的排名，我们损失了一部分销量。目前我们已恢复正常，销量也已回升。

我也从其他创始人那里听说，每年这个时候都会出现常规的夏季低迷。而 TinyPilot 在 2022 年 7 月也确实经历了 11% 的营收下滑。

按计划推进 TinyPilot 向代工厂转移

• 结果：进度已推迟三周
• 评分：D

生产进度推迟是因为代工厂的下游供应商需要更多时间来生产电源适配器、USB 线等零部件。在过渡期间库存耗尽之前，我们还有大约三周的缓冲期，但情况已经有点吃紧。

这并不是一个设计得很好的目标，因为截止日期不是我定的，我对此的掌控也有限。我真正能做的，就是确保 TinyPilot 这边不掉链子，并督促代工厂按计划执行。

花在邮件上的时间不超过 40%

• 结果：大部分时间都花在了邮件上
• 评分：F

实际上我花在邮件上的时间远超预期。七月我休假外出了一段时间，却没有考虑到假期期间会积压多少邮件。

最终，这个月的大部分时间都用在了回复邮件和审核同事的工作上。

TinyPilot 数据一览

尽管营收下滑，利润仍保持在 2 万至 3 万美元区间。这个数字有些虚高，因为我的支出被人为压低了。随着向代工厂过渡，我正在逐步缩减自有生产，因此已停止采购新材料。

让我意外的是，尽管发布了这么多新评测，网站访客量却下降了。看起来 TinyPilot 在 homelab 评测这个营销渠道上暂时已经饱和，我应该把重心放在其他类型的销售和营销上。

TinyPilot 如何增加经常性收入？

每当 TinyPilot 销量下滑，我就会更加思考经常性收入的问题。如果能有一份稳定的收入，而不必一直去寻找新客户，那该多好。

我很担心总有一天，所有想要 TinyPilot 的人都已经买到了。那时我该怎么办？

我一开始的计划就是让 TinyPilot 拥有经常性收入。客户一次性购买硬件，然后通过每年续订软件许可证来为持续的软件开发和技术支持提供资金。

问题在于，我从未为 TinyPilot 建立起向客户收取经常性收入的机制。三年过去了，除了少数企业客户，我们几乎没有任何经常性收入。

在这篇回顾中，我想探讨一下增加 TinyPilot 经常性收入的可能路径。

TinyPilot Pro 现有的授权机制

我在 2020 年发布最初的 DIY 版 TinyPilot 套件几周后，就开始着手开发 TinyPilot 软件的高级版本。

我为 TinyPilot Pro 构建的首批功能之一就是许可证校验。如果要销售付费版软件，我需要一种方法来验证用户的许可证是否有效。

当我开始设计许可证校验系统时，我意识到在兼顾创始人其他职责的情况下，仅这一组件就要花上几个月才能完成。如果许可证管理就要花三个月，我还得再花两个月去实现其他高级功能，才能让客户有足够的理由购买 TinyPilot Pro。

公司当时才成立几个月，我不想让用户等上五个月才迎来下一个版本，从而拖慢整体节奏。

有一篇 Basecamp 的博文我现在找不到了，里面讲到他们在还没写好计费软件时就决定开始销售 SaaS 产品。（编注：Nathan Coleman 找到了，就是出自 Basecamp 的那本书《Getting Real》中的一节。）他们的理由是，软件的账单是在每个服务月结束时才到期，所以在完成第一笔销售后，他们还有一个月的时间去想办法收款。

我在 TinyPilot 上采用了类似的策略。我决定采用自觉遵守的方式来执行许可证，心想自己还有一年的时间去实现真正的许可证管理系统。

如今三年过去了，我在 TinyPilot Pro 的许可证执行方面依然毫无进展。

在最糟糕的时机执行许可证校验

我们向客户宣传 TinyPilot 设备附带 12 个月的免费更新。而我们心照不宣的秘密是，一旦设备上安装了 TinyPilot Pro，你就可以通过设备的网页界面永久免费更新软件。

TinyPilot Pro 的软件并不会追踪其是否关联了有效许可证。有些用户在 2020 年 8 月购买，现在已经用到了为期一年的许可证的第三年。

绝大多数客户根本没有意识到自己的许可证已经过期。他们理所当然地认为，既然 TinyPilot 还在向设备推送更新，那许可证就一定还有效。

客户有时确实会发现许可证过期了，但往往发生在极不方便的时候。

TinyPilot 使用 microSD 卡作为存储介质。microSD 卡特别容易出现文件系统损坏。一旦文件系统损坏，唯一的解决办法就是用 TinyPilot Pro 的镜像重新刷写 microSD 卡。

要下载 TinyPilot Pro 镜像，客户需要输入订单信息。在提供镜像之前，我们会检查客户是否仍持有有效许可证。

从客户的角度来看，这是一种极其糟糕的得知许可证过期的方式。他们的文件系统已经损坏，TinyPilot 的工作已被中断。要解决问题，他们必须亲自走到设备前，取出 microSD 卡并重新刷写。而现在我们还要向他们额外收费？

如果客户不想购买新镜像，只要联系客服，我们仍会提供旧版镜像。但他们仍需等待最多一个工作日才能得到回复，如果这耽误了他们的工作，影响就很糟糕。

这个系统对我们来说也不理想，因为索要旧版 TinyPilot Pro 的请求会消耗大量客服资源。而且一旦客户拿到新镜像，他们又会回到“永久免费更新”的模式，因为他们可以继续通过设备的网页界面更新软件。

怎样的经常性订阅才值得投入？

任何形式的许可证执行都会成本不菲。最起码，我们得在 TinyPilot 的网页界面中增加让客户输入许可证信息的功能，然后还需要在公网上部署一台服务器，根据许可证来判断用户是否有资格获取更新。

实现起来之所以昂贵，是因为这需要数周的开发工作，而且当用户不可避免地发邮件说他们因为误删了包含订单信息的 TinyPilot 邮件而无法获取更新时，还会增加客服负担。

如果我费了这么大劲，却发现对续订率毫无影响怎么办？

要让许可证续订变得值得，它每年至少需要带来 3 万美元的额外利润。我估计许可证的支付手续费约为 3%，因此每次续订能为 TinyPilot 净赚约 77 美元。

要实现每年通过许可证额外获利 3 万美元的目标，每年至少需要有 390 名客户续订（390 x $77 = $30k）。

自 2020 年推出以来，TinyPilot 总共售出了约 5000 台设备。目前每年售出约 2700 台新设备。要达到 390 名付费订阅者，意味着只需说服 7.8% 的现有用户为持续更新付费，这似乎是可行的。

如何测试客户的续订意愿？

好吧，我需要说服 7.8% 的现有客户购买续订，但如何在不投入完整许可证管理系统的情况下，判断 7.8% 这个目标是否可行呢？

强制恢复出厂设置

今年早些时候，我们不得不将 TinyPilot 的基础操作系统从 Debian Buster 切换到 Debian Bullseye。Raspberry Pi OS 没有官方支持的大版本升级方式，因此我们不得不让所有用户手动重刷 microSD 卡来完成迁移。

我很不愿意把这个成本转嫁给用户，但我们找不到其他办法。一个积极的副作用是，这结束了“永久免费”更新的模式。如果用户的许可证已过期，就必须付费购买新的 12 个月许可证才能继续接收更新。

我们在 4 月 27 日推出了这一变更，因此我对比了变更前后各三个月的许可证续订情况：

一方面，这些变化令人鼓舞，因为强制付费升级带来了 67% 的续订增长。另一方面，这也令人担忧，因为三个月内只有 55 名用户续订。我估计约有 2500 台设备的许可证已过期，这意味着只有 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。例如，如果我需要升级到下一版本的 Go，只需更新一个文件，重新运行 nix develop，就能得到一个拥有正确 Go 版本的本地 shell。CI 环境也会运行相同的版本。环境仅作用于当前目录，因此更改包版本不会影响同一系统上的其他项目。

我开始在 What Got Done 中尝试 nix develop，因为它依赖 Go 和 Node.js，版本管理一直是个痛点。

在 What Got Done 的开发环境中使用 Nix 很有意思，但目前遇到了以下几个障碍：

• 我一直没搞明白如何让 Go 的静态二进制构建生效，而找到的解决方案感觉就像是“你就应该知道这段神奇咒语”。
• 没有简单的方法来指定依赖的精确版本。
  • 我原本以为可以像 Docker 那样声明版本，比如 go:1.19.3，但 Nix 并不支持这种语义。
  • 对于一个如此强调可复现性的工具来说，这让我很意外。
  • 我找到的最接近的解决方案是使用第三方工具来查找与某个包版本关联的 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，否则性能会非常糟糕。

总结

完成了什么？

• 发布了《在 Raspberry Pi 4 上安装 NixOS》
• 学会使用 hurl 来替代基于 curl 的 HTTP API 集成测试。
• 造访了北卡罗来纳州夏洛特和加拿大蒙特利尔。

经验教训

• TinyPilot 似乎已经耗尽了通过博客和 YouTube 评测所能获得的营销价值。
  • 相比一年前，新评测带来的回报正在递减。这绝对不像两年前那样，一篇评测就让销量几乎翻了三倍。
• 提供自动续订的 TinyPilot 许可证选项是测试经常性收入市场性价比最高的方式。

下月目标

• 尽快将生产转移至代工厂。
• 制定搬离 TinyPilot 本地办公室的详细计划。
• 测试自动续订 TinyPilot 许可证的选项。

求助

• 如果你有使用 Shopify 第三方订阅应用的经验（无论好坏），特别是针对数字产品的，欢迎通过邮件联系我。
• 如果你能找到我记忆中那篇 Basecamp 的故事，请在评论区告诉我。