文章摘要
这篇文章探讨了在AI时代构建可持续软件公司的挑战。作者以Jira被内部工具替代为例，指出AI改变了“购买vs自建”的决策逻辑，但认为仍有机会通过聚焦最小可售单元来建立小型可持续业务。
文章总结
好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了核心细节，并删减了与主题无关的内容（如文末关于照片的说明）。
文章标题：可销售软件的最小可行单元
核心观点： 在AI时代，并非所有软件都适合“用LLM自建”来替代“购买SaaS”。作者认为，存在一个“可行区间”，只要软件定价合理且具备足够复杂性，购买依然比自建更划算。作者正基于此逻辑，将他的开源项目River发展成可持续的生意。
主要内容重述：
背景与质疑： 作者宣布将全职投入其开源项目River，将其发展为小型可持续业务。有人质疑，在AI时代，任何他交付的软件都可能被LLM（大型语言模型）生成的内部工具瞬间取代。
“自建”的成本分析： 作者用一个LinkedIn上的例子反驳：有公司为省下每月400美元的Jira费用，用Claude（AI模型）自建了内部任务追踪器。作者通过计算指出，这看似省钱，实则不然。
- 人力成本： 假设一名工程师年薪20万美元，时薪约96美元。为抵消每月400美元的Jira费用，该工程师每月花在自建工具上的时间不能超过4小时。
- 初始投入： 即使有LLM辅助，构建一个像样的任务追踪器至少需要几周时间。这期间的人力成本远高于400美元。
- 长期维护： 后续的Bug修复和功能开发仍需人力，即使有LLM帮助，维护成本也无法降为零。
- 结论： 作者估算，即使每月维护时间压缩到2小时，也需要37个月才能收回最初两周的开发成本。因此，对于Jira这类定价适中的产品，“自建”在经济上并不划算。
“自建”的临界点： 作者承认，当SaaS产品价格极高时，“自建”就变得合理。例如，Salesforce每个席位每月约500美元，50个席位就是2.5万美元。这笔钱足以雇佣1.5名全职工程师来开发替代品。对于这类高价产品，“自建”是更优选择。
“可行区间”与“最小可行单元”： 作者提出，存在一个“可行区间”。在这个区间内的软件满足两个条件：
- 足够复杂： 用LLM重建并非易事，且存在持续的维护负担。
- 定价合理： 价格没有高到强烈鼓励用户去“自建”。
- 在这个区间内，长期支付的许可费总额，低于“自建”的初始投入和持续维护成本之和。
- 在这个区间的底部，存在一个“可销售软件的最小可行单元”。低于这个单元，自建的成本和精力与购买流程相当，甚至更低，长期来看不划算。
River项目的定位： 作者认为他的项目River（一个基于Go和Postgres的任务队列）就处在这个“可行区间”内。
- 复杂性： River的核心功能免费，但高级功能（如工作流、顺序任务等）需要付费。这些高级功能的设计和性能优化需要大量思考，LLM难以轻易复制。
- 定价： River采用基于团队规模而非人头数的定价模式，起价为每月125美元（支持最多20名开发者），对于中小团队来说成本可控。
最终结论： 作者承认，在LLM时代，他的商业计划是否成功仍是未知数，但他正将自己的生计押注于此，未来几个月将见分晓。
评论总结
根据评论内容，主要围绕“购买 vs 自建”软件的核心观点展开，以下是平衡总结：
1. 购买 vs 自建的成本计算已改变 - 评论1指出“购买 vs 自建的计算方式已改变”（"buy vs. build. . . the calculus changed"）。 - 评论2强调理性计算需谨慎，即使软件节省1小时也价值正向，但开发者常拒绝付费（"if the software they're buying saves one single hour of productivity, it's value-positive... and yet they won't buy it"）。
2. 自建成本仍不可忽视 - 评论4指出自建成本远非零，迭代仍需时间（"the cost to build software is still not 0... it still takes time and iteration"）。 - 评论13警告复制复杂平台（如Jira、Salesforce）需数千工程师多年努力，简单提示无法实现（"These software platforms are built by thousands of engineers over more than a decade... to think someone can duplicate them with some clever prompting is to completely fail to understand the scale"）。
3. 社区效应与长期维护 - 评论5强调软件社区效应，自建孤立方案会失去用户需求带来的正向外部性（"If everyone is building their own isolated solutions, how does this positive externality manifest itself?"）。 - 评论8指出个人项目常因维护动力不足而停滞，专业场景仍倾向付费（"the effort and motivation required to extend beyond the crazed early days is still more than the utility I get"）。
4. 专业成长与心态转变 - 评论9描述年轻工程师从“为何付费”到“为何自建”的转变（"Why would I pay for that when I could easily just do it on my own? ... flips to: Why would I build and maintain something on my own when I could pay someone else a few bucks to do it?"）。
5. 商业视角：聚焦盈利而非节省 - 评论17主张应关注如何赚钱而非省钱，优秀工程师应投入能增加收入的项目（"focus more on how much you can make than on how much you can save... they should put their hard work into things which increase business revenue and profit"）。
6. 企业软件的真实需求 - 评论18指出企业真正需要的是SSO、多租户等“企业层”功能，而非复杂特性（"what cost me most of the development time wasn't the features but all the FUD around them e.g. SSO, multitenancy, audit logs"）。
7. 市场与竞争动态 - 评论15认为“自建 vs 购买”假设仅两方，若自建容易，第三方竞争者会压低价格（"If it's easier to build internally, then it's easier for a 3rd party competitor to enter the market and bid the price down"）。
8. 对创业者的建议 - 评论6建议“公开构建”以吸引开发者（"Selling to devs is hard, did you consider building in public?"）。 - 评论12提醒需考虑时间假设的指数级变化（"do your calculus on time shifting assumptions"）。