高中生的付费Discord机器人月利润1.2万日元 — 拆解成本320日元、定价500日元背后的依据

在免费理所当然的市场里,一名高中生做了付费产品

在Discord语音频道中朗读文字的机器人,早在2021年就已经有多款免费产品存在。而在这个市场以月费500日元的订阅模式切入、并在上线第二年做到月利润约1.2万日元的,是当时还是高三学生的sizumita所开发的BardBot(bardbot.net)。本文基于其本人在Zenn上公开的运营记录,拆解这份小小的盈利建立在怎样的计算之上。

金额本身并不大。之所以仍值得报道,是因为国内几乎找不到把成本明确公开、定价依据说明清楚、连加入节奏都有具体频率数字的个人开发记录。这个案例的价值不在赚了多少钱,而在于定价设计的透明度。

已公开的数字

项目	内容
服务	BardBot(Discord朗读机器人)
运营者	sizumita,文章发布时为高三学生,“未踏Jr.”计划入选者
定价	月费500日元 / 20万字
主要成本	Google Cloud Text-to-Speech为1600日元/100万字,20万字约合320日元
利润	上线第二年月约12000日元
新增加入节奏	每4天1-2人
可用性	99%
功能	最多同时在4个语音频道朗读,配有Web管理面板

营收总额本身未披露,公开的只有”月利润约12k”这一结果值和单价。因此本文也不对会员数或月营收进行反推。若一味叠加推测,反而会让本案例中唯一确定的”成本与价格的关系”也变得模糊。

卖的不是功能,而是”不拥挤”

BardBot诞生的动机并非功能不足。本人的说法是:免费的朗读机器人”要么使用人数太多有各种限制,要么朗读会变慢”。也就是说,免费机器人的弱点并非开发者偷懒,而在于将共享资源无偿开放这件事本身。用户越多,人均可用资源就越少,品质随之下降,这是运营努力无法解决的结构性制约。

付费化正是用金钱把这个制约切割开的做法。按缴费额度分配朗读字数配额的模式下,用户增加也不会影响现有用户的体验。之所以能打出99%可用性这样的数字,正是因为收入与基础设施成本直接挂钩。可以说,这里出售的不是朗读功能本身,而是”不被他人使用量侵蚀的品质”。

先有成本,后有价格

定价的说明十分清晰。Google Cloud Text-to-Speech的单价为每百万字1600日元。若用满上限的20万字,成本约为320日元。“再加上服务器费用,这个价位应该比较合适”——月费500日元就是这样定出来的。

这个结构中重要的一点是,320日元是用满上限情况下的成本。20万字是月度额度,并非所有用户每月都会用完。实际平均消耗量越是低于额度,单个用户的实际成本就越低于320日元,毛利率也就越高。在按量计费的成本上覆盖一个固定额度的模式,这部分差额就是利润。反过来说,如果额度设置得过大,或成本单价被上调,利润会立刻消失。500日元这个价格,不是凭感觉定的,而是由这一道计算公式支撑起来的。

转折点是”被别人的文章收录时”

运营记录中有一节标题是”订阅用户迟迟不见增长”。作为对策提到了三点:开设Twitter账号、通过撰写note文章引流,以及被已经拥有大量读者的他人文章收录。而本人写道:“多亏了这个,才做到了每4天1-2人的订阅加入节奏”。

前后两侧的数字并非都有明确记录(“之前”只有”不见增长”这样的定性描述)。即便如此,加入节奏能够用具体频率来表述的转折点就在这里——这一因果关系是本人明确指出的。不是培育自己的账号,而是把自己的产品放到已经拥有读者的地方，借渠道而非造渠道的判断,正是这个案例的转折点。考虑到个人开发中最容易缺失的正是获客环节,月1.2万日元的盈利可以说不是靠技术力,而是靠这一手决定的。

技术选型是对”不能停机”的投资

99%的可用性并非偶然得来的数字。最初的机器人用Python编写,但Discord API的封装库停止了开发,而且还存在内存使用量每天上涨5%的问题。之后尝试用F#,但封装库无法运行,只好放弃,最终改用Rust + Serenity重写。用于在多个机器人之间即时同步设置的内部API采用Go + Echo,Web端用Next.js + Firebase,缓存用Redis,托管方式为ECS on EC2(t3.micro,预留实例)。

成本意识也贯穿始终。数据库因”Cloud SQL费用太高而放弃”,改用Firestore。日志基础设施Kibana + Elasticsearch则自建在可免费使用的Oracle ARM实例上(内存24GB、4vCPU)。计费全部交给Stripe Checkout和Billing Portal处理,接收Webhook的Firebase Functions会自动更新Firestore。通过不自行开发支付相关功能,实现了一个人也能运转的运营方式。

另一方面,Web托管由于”不知道Hobby套餐和付费套餐有什么区别,本想用Hobby,但由于是营利用途只能作罢”,最终使用了Vercel Pro。对于单笔毛利只有几百日元规模的业务而言,这样的固定成本并不轻。月1.2万日元的利润,正是在不断削减成本的努力之上剩下的数字。

弱点在哪里

第一,这项业务只存在于Discord这一个平台之上。一旦API规格或使用条款发生变化,收入会整体受到影响。第二,单价薄。要让一个月费500日元的产品利润翻倍,只能让会员数翻倍,经营杠杆很难发挥作用。第三,运营者的可支配时间直接与学业挂钩。文中也明确写道:“在高考结束之前,大概只能做做维护检查”,增长因此被本人的人生阶段强烈制约。

面向海外的多语言(i18n)适配、高考后的新功能开发、面向企业的Discord机器人这三项构想虽有提及,但截至文章发布时均尚未着手。本文不将这些计入既有成果。

这个案例哪里可以移植

可以移植的是”先算成本,再定价格”这个顺序。对于使用按量计费API的产品,先算出上限情况下的成本,再加上固定成本,最后凑成一个整数，这套流程谁都能照做。即便市场上存在免费的替代品,只要这个”免费”是靠牺牲品质来维持”共享资源拥挤”的问题,那么付费产品就有切入的空间，这个判断同样可以被一般化应用。

难以移植的有两点。一是能在高中阶段独自完成用Rust重写、多语言实现这样的技术能力。二是能被已经拥有大量读者的他人文章收录这样的关系网络,这与”未踏Jr.”入选者这一社群内部的身份地位密不可分。加入节奏发生转变的那个节点,恰恰是最难复制的要素。

同时也要正视规模的局限。月1.2万日元并不足以改变生活。但只要成本与价格的关系设计得当,会员数增长时,利润就会按比例上升。这个案例展示的并非一个终点,而是一种检验业务是否具备可扩展形态的方法。