匿名个人开发者的ERP集成SaaS:零员工、零广告费,MRR约300万日元——近半年没有手写过一行代码

MRR约300万日元。零员工,零广告费。而且近半年没有手写过一行代码——2026年3月发布在Zenn上的一篇个人开发者文章,正是凭这三件套被广泛阅读。主角既不是光鲜的AI应用,也不是消费级服务,而是把老旧ERP”疯狂的XML异步SOAP接口”转换成现代、无状态RESTful JSON的代理服务器——企业系统的管道工程。

先说明:这个案例是匿名的自我申报,运营者和服务名均未公开。数字只来自本人的Zenn文章,没有任何外部验证手段。我们仍然报道它,是因为这篇文章为”AI写代码的个人开发”讨论提供了罕见的样本:附带收入实数和运营细节。请读者带着这个保留来读以下数字。

公开的数字与构成

产品的原型可以追溯到数年前:作者在一个ERP集成项目中被消耗殆尽,于是为有同样痛苦的开发者切出了一个转换层。客户是世界各地的开发者，文章描绘了”美国西海岸的负责人”因老旧ERP环境的紧急故障前来求助的场景。虽是B2B,却没有商谈环节,以月费$30起的自助服务出售。

获客:蹲守”报错信息”

支撑零广告费下MRR300万日元的获客手段,归根结底是SEO,但瞄准的关键词很独特。作者称之为蹲守”绝望的错误堆栈”。与老旧ERP搏斗的开发者,搜索的不是产品名,而是眼前弹出的报错信息本身。于是作者在Dev.to和英文博客上发布以报错信息为标题的技术文章,在文末引导至付费方案。

这一设计的强处在于搜索者的付费确定性极高。对于业务因报错而停摆的企业负责人来说,月费$30甚至算不上一个决策。而且”老旧ERP的特定报错”这一搜索面几乎不存在竞争内容,域名权重高的大媒体也没有动机进入。与在Microsoft生态缝隙中做到年入$1M的案例一样,这是拾取巨型平台周边”没人捡的不便”的结构。

“不写代码”运营的内幕

这篇文章被广泛传播的最大原因,是对AI运营的深入记述。据作者说,近半年他”没有花过一秒钟做打开编辑器、人工输入的传统编码工作”。他从终端调用Claude Code,用文字传达需求和规格,让它循环生成测试代码并自动修复。报错监控也由自动化机器人负责分析和修复。

需要注意的是,这不是”AI从零造出一门生意”的故事。产品本身是作者数年前做的,与市场的接口(哪些报错会被搜索、客户为什么付钱)也是靠人力试错确立的。AI替代的,是规格已定的成熟产品的维护与改修,这正是最适合AI的工序。与十年来由创始人一人手工运营的Healthchecks靠手艺积累形成对照,这个案例应读作”只把成熟后的运营交给AI”的分工实例。

运营哲学也一以贯之:废除咨询表单,退订一键完成。有意抹去人工接触点,把UI做成用户可以自助闭环的形态。正是在不投入人力做客服的前提下,零员工的B2B才得以成立。

需要打折扣的地方

再强调一次,这个案例最大的弱点是不可验证性。既然匿名且不公开服务名,就没有任何仪表盘或第三方报道能佐证MRR300万日元。发布于Zenn这一技术社区、技术栈与运营记述内在一致,可以作为旁证,但不是证明。按编辑标准,它归类为本人公开(primary),但应比实名实服务公开数字的案例低一档置信度来对待。

从作者的记述中也能读出业务结构上的风险。第一,老旧ERP市场虽然萎缩缓慢,但绝非增长市场,而转换代理在原厂把API现代化的那一刻就失去存在意义。第二,获客只靠SEO一条腿,对搜索算法和AI搜索带来的曝光变化十分脆弱。第三,“AI写全部代码”的运营给业务引入了新型依赖:模型与工具的价格和质量波动。零员工的轻盈,与风险显现时连商量对象都没有,是一体两面。

可复制的条件与局限

能从这个案例一般化的有三点:①B2B的”痛点驱动”利基(具体到负责人会用报错信息搜索的程度)与零广告、零销售的自助服务适配度最高;②AI代码生成最有效的场景不是新开发,而是规格已定的成熟产品的维护;③不靠人力承接客服的设计(自助闭环UI、一键退订)是单人B2B的前提条件。这与把开发者工具养成MRR $50K生活方式生意的案例相通,是”开发者卖给开发者”模式的教科书式构成。

局限同样明确:这个模式只向拥有”数年前自己在企业系统上吃过的苦”这一入场资产的人开放,因为痛点的分辨率决定了利基选择和SEO文章的说服力。而且既然是匿名案例,就不应把数字本身当作复制目标。要带走的不是300万日元这个金额,而是痛点具体性、自助服务、AI维护这一组合的设计图。