2012 年 8 月，Mike Perham 算出自己开发 Sidekiq 的时薪：3.5 美元。
这个 Ruby 后台任务处理工具已经有人使用，也收到社区贡献。但过去半年，许可证销售只带来约 700 美元，而他估算投入了 200 小时。他已经有家庭，需要解释这些业余时间为什么值得花在免费软件上。Perham 当时的记账文章
把故事停在这里，局面并不明朗。产品得到关注，意味着它碰到了需求；越来越多人使用，也意味着维护开始成为一份难以随意放下的工作。用户获得了一个新工具，作者却还没有获得持续提供它的条件。
后来人们把 Sidekiq 当作一人公司的代表。早期记录值得读，正因为它保存了成功标签之前的缺口。
先让软件进入别人的日常工作
Sidekiq 处理的是网站后台任务。例如，用户完成眼前操作后，系统仍需发送通知、处理数据。这样的软件最终要承受真实业务中的任务量和故障，开发者自己的测试只能覆盖一部分。
Perham 在 2017 年访谈中回忆，他所在的公司使用 Sidekiq，并测试商业功能。他给公司免费许可，换取早期测试，自己也负责生产运行。这让他能看到软件进入业务以后怎样表现。创始人访谈，约 15:40
这段关系没有出现在产品功能表里，却提供了重要的开发条件：一处真实使用现场，以及问题返回作者的路径。一个独立开发者可以下载相同的工具，写出相近的代码，却未必有一家愿意承担早期试用成本的组织。
对准备做类似项目的人而言，缺少使用现场时，继续加功能未必是最有效的动作。找到一个规模合适、愿意试用并反馈的伙伴，可能更早暴露产品真正需要解决的问题。
使用关系建立起来之后，另一道缺口才逐渐补上。Perham 推出了商业扩展 Sidekiq Pro。2014 年回顾时，他写到，一部分用户愿意为额外功能和持续支持付费，自己已经全职从事开源开发；免费的部分仍然需要足够有用。走向全职开源的记录
收费改变了时间的来源。原先从家庭和业余生活里挤出的劳动，有机会由受益者持续购买。社区能提供反馈、代码和传播，付费关系则使作者能够继续处理这些反馈。两者所补上的条件不同。
公司运作所需的其他劳动，也没有全部落在作者个人身上。他找律师协助设立公司，向会计师学习记账，并将购买后的访问开通等重复事务自动化。同一访谈，约 5:03 与 30:12
于是，“一个人经营”呈现出更具体的样子：有些能力由专业服务提供，有些动作交给程序，另一些判断留在作者手中。员工表记录组织内部的雇用关系，无法完整显示支撑产品运行的劳动。
客户购买 Sidekiq 商业产品时，也在做类似的选择。Perham 在 2015 年业务回顾中，将修复、改进和专家支持列为产品价值。客户由此能够少做一部分自行开发和维护的工作。2015 年业务回顾
这一侧购买律师和会计的专业劳动，另一侧向软件客户提供可重复的服务。小公司的行动范围，就在这些具体交换中逐渐扩大。
同一套办法，没有复制出第二个 Sidekiq
同一份年度回顾还记录了 Inspeqtor 的失败。
Perham 尝试将开源与商业扩展的方式用于这个新产品，但采用和销售都很有限，他决定不再增加新功能。已有技术经验、经营经验和商业模式，并没有让下一项产品自然成立。Inspeqtor 的回顾记录
材料不足以解释失败的完整原因。但它足以提醒我们：不能把 Sidekiq 的结果全部归给“创始人很能干”，再假定这种能力随时可以搬到另一个需求上。愿意使用的人、使用发生的场合、持续付费的理由，都需要重新建立。
本文采用的是创始人的当时记录与后来的自述。它适合重建这些转折，不能据此估计一人公司的成功率，也不能作为经营数字的独立审计。
这段历史留下的实用判断很朴素。评估一个小项目时，除了看作者会做什么，还应沿着工作追一遍：谁让它接触真实需求，谁提供作者尚不具备的专业能力，谁为持续维护付费，问题又怎样回到能够处理它的人手里。
缺少其中一段关系，个人再忙，也可能只是在替尚未形成的经营条件垫付时间。