在 LLM 让软件开发成本断崖式下降的时代，做一家小型软件公司还有没有意义？前 Stripe 工程师、开源项目 River 的作者 Brandur Leach 在自己的博客上发表了长文《The Minimum Viable Unit of Saleable Software》（可销售软件的最小可行单元），试图用一个清晰的经济学框架来回答这个问题。他的核心结论是：LLM 让软件变便宜了，但没有让它变免费——在成本和复杂度之间，仍然存在一个"可销售软件"的生存区间，关键在于找到那个"最小可行单元"。

Leach 用一个 LinkedIn 上的真实案例开篇。一位用户发帖称，他的公司每月向 Atlassian 支付 400 美元的 Jira 订阅费，这让他"个人感到被冒犯"，于是他让团队用 Claude 从零构建了一个内部任务跟踪系统。Jira 消失了，400 美元的月费消失了，取而代之的是一个可以通过 LLM 持续优化、任意定制的内部工具。这个案例听起来像是"买不如建"的完美胜利，但 Leach 随后用一组简单的数字拆解了这个逻辑。

假设一名工程师年薪 20 万美元，每周工作 40 小时，那么月薪约 16667 美元，时薪约 96 美元。为了抵消向 Atlassian 支付的每月 400 美元，这名工程师在自己的 Jira 克隆版上投入的维护时间——包括向 LLM 发指令修复 bug、添加功能、维护数据库等——每月不能超过约 4 小时（400÷96）。即使将时间压缩到每月 2 小时，在初始构建耗费两周（约 7692 美元工程成本）的情况下，也需要 37 个月才能回本。Leach 坦率地写道："我也像所有用过 Jira 的人一样讨厌 Jira，并且有一种几乎无法控制的冲动想自己重建它，但这笔账算不过来。"

salary = 200_000.0

{
  month: salary / 12,
  week:  salary / 52,
  hour:  salary / 52 / 40,
}.each { |k, v| puts "%-6s $%0.2f" % ["#{k}:", v] }

month: $16666.67
week:  $3846.15
hour:  $96.15

但这并不意味着"买"在所有情况下都优于"建"。Leach 紧接着切换到天平的另一端，以 Salesforce 为例：一个满载功能的 Salesforce 席位月费约 500 美元，50 个席位就是每月 25000 美元。用这笔钱，你可以雇佣 1.5 个全职工程师（25000÷16667）来专门构建内部 CRM。即使 CRM 的复杂度远高于任务跟踪器，在这个价格水平上，"建"的选项已经进入了合理区间。Leach 特意指出 Salesforce 年初至今股价下跌了 30%，暗示市场似乎也认同这种判断。

从这两个例子出发，Leach 提出了全文的核心概念——"可生存区间"（zone of viability）。在这个区间内的软件满足两个条件：第一，有足够的技术新颖性，使得通过 LLM 重建并非微不足道，并且存在持续的维护负担；第二，定价不至于高到强烈鼓励用户用 LLM 重建。只要持续定价保持合理，用户支付的总许可费就低于从头构建并持续维护一个内部版本的累计工程成本。而在这个生存区间内的某个位置，就是"可销售软件的最小可行单元"——低于这个阈值，自己重建的代价就小于完成第三方采购流程的代价，而且长期来看也不划算。

Leach 本人正在将这个框架付诸实践。他和合伙人 Blake 运营着一个基于开源项目 River 的小型企业——River 是一个面向 Go 和 Postgres 的任务队列。River 将大部分任务相关功能（周期性任务、调度任务、唯一任务、Web UI 等）作为开源免费提供，但将高级功能（工作流、顺序任务、并发限制任务等）和企业计费能力保留在每月 125 美元起的 Pro 版本中。Leach 刚刚离开上一份工作，正式全职投入 River，并坦承他正在用自己的生计对这个理论下注。

这篇文章之所以值得关注，不是因为它给出了一个确定的答案，而是因为它为 LLM 时代的软件创业者提供了一个可操作的思考框架。过去一年中，"AI 会取代所有 SaaS"的叙事相当流行——如果任何人都能用 Claude 或 Gemini 在几小时内生成一个内部工具，为什么还要为第三方软件付费？但 Leach 的分析揭示了这个叙事中被忽略的变量：维护成本。LLM 降低了构建的门槛，但软件的生命周期远不止于首次构建——持续的迭代、调试、安全更新和运维管理仍然需要人类判断力，而这些东西从来不便宜。

更值得注意的是 Leach 的定价策略中隐含的竞争逻辑。River Pro 采用了基于团队规模而非用户数量的次线性定价，每月 125 美元覆盖最多 20 名开发者。这个价格点被精心设定在"比你自己重建更便宜、但又不至于低到无法维持业务"的狭窄区间内。对于那些有能力用 LLM 复刻 River 高级功能的团队来说，125 美元的月费与投入数周工程时间之间的对比，使得"买"成为了理性选择。这可能是 LLM 时代小型软件公司的核心生存法则：不是去和 AI 比谁做得更多，而是找到那个"你雇人重建花的时间比付我钱还贵"的甜蜜点。

当然，这个框架并非适用于所有软件品类。当一个品类的技术新颖性趋近于零——比如一个基本的 CRUD 管理系统——即使定价再低，LLM 生成一个替代品的成本也可能低到足以颠覆整个市场。反过来，当一个品类的复杂度和专业深度足够高时，即使定价非常激进，"建"的门槛也可能高到让大多数团队望而却步。Leach 的框架提醒我们，这两个极端之间的广袤地带，仍然存在着大量可持续的商业机会——前提是开发者能够诚实地评估自己产品的技术壁垒和维护成本特征，并据此制定定价策略，而不是盲目地追逐资本驱动的高增长叙事。

Leach 的分析提供了一个实用的框架，但有一些值得补充的细微之处。首先，"最小可行单元"因团队规模和工程师薪资水平而异。对于一个时薪 96 美元的硅谷工程师来说，用两周时间重建一个每月 400 美元的工具需要 37 个月回本；但对于一个时薪 20 美元的印度或东欧开发者团队来说，同样的计算会得出完全不同的结果。LLM 在这道方程式中充当了一个杠杆——它对所有人的效率提升比例相似，但绝对成本基数不同。这意味着，同一款 SaaS 产品在不同地区的市场中对 LLM 替代的抵抗力是不同的，这为全球化定价策略带来了新的复杂度。

其次，Leach 的框架隐含着一个关于 LLM 能力的假设：模型可以高效辅助开发，但最终的架构决策、性能优化和长期维护规划仍然需要人类判断力。这个假设在 2026 年仍然成立，但它的有效期是个未知数。如果下一代模型在复杂系统的长期维护上取得了实质性突破，"最小可行单元"的阈值就会向上移动——更多品类的软件会被挤出可销售区间。从这个意义上说，Leach 的框架不仅是定价策略，也是一个"与 LLM 赛跑"的时间游戏：在这个生存区间完全闭合之前，软件创业者需要用高品质和合理的品牌溢价建立起足以抵抗替代的用户黏性。

最后，这篇文章也回应了一个更广泛的行业焦虑。过去两年，"AI 将吃掉所有软件"的说法从 VC 的 pitch deck 蔓延到了工程师的水群聊天中。但如果冷静下来算笔账，这个恐惧的大部分是基于"构建成本为零"的错误假设。Leach 用一种工程师熟悉的方式——列举数字、计算回本周期、画出供需曲线——证明了一件重要的事：在构建成本和零之间，还存在一个足够宽的地带，可以让小公司活下去。只要那个地带还存在，那些理解自己产品的技术护城河有多深、并据此定价的创业者，就仍然有故事可讲。

参考来源：Brandur Leach: The Minimum Viable Unit of Saleable Software