A high schooler's paid Discord bot nets ¥12,000/month profit — reading the logic behind pricing ¥500 on top of a ¥320 cost

Entering a “free is the norm” market — as a high schooler, charging money

Bots that read chat text aloud in Discord voice channels already existed in multiple free forms by 2021. Into that market, at a ¥500/month subscription, came BardBot (bardbot.net), built by sizumita, a high school senior at the time, who reported roughly ¥12,000/month in profit by the service’s second year. This piece breaks down the calculation behind that small black number, based on the operating log sizumita published on Zenn.

The amount itself isn’t large. Still, it’s worth covering because almost no domestic record of solo development discloses cost, pricing rationale, and signup pace this concretely. The value of this case is less the money earned and more the transparency of the unit-economics design.

The published numbers

Total revenue itself isn’t disclosed. What’s public is only the result, “about ¥12k in monthly profit”, plus the unit price, so this piece won’t back-calculate member count or monthly revenue. Stacking estimates on top of estimates would blur even the one relationship this case makes certain: cost versus price.

What’s being sold isn’t the feature — it’s “not being crowded”

BardBot wasn’t built to fill a feature gap. His own explanation: the free read-aloud bots all “have too many users, so there are limits, or the reading gets slow.” The weakness of the free bots is structural rather than developer laziness, inherent to giving away a shared resource for free. As more users pile on, each user’s share shrinks and quality drops. That’s a constraint no amount of operational effort can solve.

Going paid was an act of decoupling that constraint with money. In a model that reserves a character quota proportional to what a user pays for, adding more users doesn’t degrade quality for existing ones. The reason he can claim 99% uptime is that revenue is tied directly to infrastructure spend. What’s actually being sold here can be reframed as: freedom from having your quality eroded by other people’s usage, rather than the text-to-speech feature itself.

Price came after cost, not before

His pricing explanation is straightforward. Google Cloud Text-to-Speech costs ¥1,600 per million characters. At the 200,000-character cap, the maximum cost per user is about ¥320. “Factoring in server costs on top of that, this felt about right”, and that’s how ¥500/month was set.

What matters structurally here is that ¥320 is the worst-case cost. The 200,000-character quota is a monthly cap, not every user maxes it out every month. The more actual average usage falls short of the cap, the smaller the effective cost per subscriber, and the higher the gross margin. In a model that layers a flat-rate quota on top of a usage-based cost, this gap becomes profit. Conversely, an overly generous quota, or a cost hike from the API provider, would wipe out margin instantly. The ¥500 price point isn’t a gut call. It rests on this single equation.

The tide turned “when someone else’s article featured it”

The operating log includes a section titled “Subscriber growth was slow.” Three countermeasures are listed: opening a Twitter account, driving traffic via note articles, and, critically, getting featured in an already widely-read article written by someone else. He writes: “Thanks to that, we started getting subscribers at a pace of about 1–2 people every 4 days.”

The before-and-after isn’t given with equal precision. The “before” state is only described qualitatively as “slow.” Even so, the causal claim. This is the point where signup pace became describable in concrete terms, is his own. The decisive move wasn’t growing his own account, but getting his product placed somewhere that already had readers: borrowing a channel rather than building one. Given that acquisition is typically the biggest gap in solo development, the monthly ¥12k profit is arguably decided by this single move more than by any technical skill.

The tech choices were an investment in “not going down”

99% uptime didn’t happen by accident. The first version of the bot was written in Python, but the Discord API wrapper he depended on stopped being maintained, and memory usage crept up 5% per day. He then tried F# but abandoned it when the wrapper wouldn’t work, and finally rewrote the whole thing in Rust + Serenity. The internal API for propagating config changes instantly across multiple bots runs on Go + Echo. The web frontend is Next.js + Firebase, caching uses Redis, hosting runs on ECS on EC2 (t3.micro, reserved instances).

Cost discipline runs throughout. He passed on Cloud SQL, calling it “too expensive,” in favor of Firestore. His logging stack, Kibana + Elasticsearch, is self-hosted on a free-tier Oracle ARM instance (24GB memory, 4 vCPUs). Billing runs through Stripe Checkout and the Billing Portal, with a Firebase Function receiving webhooks and auto-updating Firestore. Not building payments himself keeps the whole operation runnable solo.

On the other hand, web hosting uses Vercel Pro, since “I’m not sure what’s different about Hobby, but it’s a commercial service, so it can’t be helped.” In a business where gross margin per subscriber is a few hundred yen, fixed costs like this weigh heavily. The ¥12k in monthly profit is what’s left standing on top of a running effort to cut costs.

Where the weaknesses are

The business exists entirely on top of a single platform: Discord. If the API spec or terms of service change, revenue is affected wholesale. The margin per subscriber is thin as well, doubling profit on a ¥500/month product means doubling the member count, with no operating leverage to lean on. And the operator’s available time is directly tied to schoolwork. The article states plainly, “until university entrance exams are over, I can barely do more than basic maintenance”, growth is tightly bound to his life stage.

Three initiatives are mentioned but not yet started as of the writing: i18n support for overseas expansion, new features after his exams, and an enterprise Discord bot offering. This piece does not count any of those as achievements.

What can be transplanted from this case

What’s transplantable is the sequencing: derive price from cost, not the other way around. For any product built on a usage-based API, the procedure (calculate worst-case cost, layer fixed costs on top, round to a clean number) is one anyone can follow. The insight that a free alternative may still leave room for a paid entrant, if the “free” is degraded by shared-resource congestion, also generalizes.

Two things are hard to transplant. One is the technical ability to rewrite into Rust and implement across multiple languages, done solo, while still in high school. The other is the kind of relationship that gets you featured in someone else’s widely-read article, inseparable from his standing within the Mitou Junior community. The turning point where signup pace changed is arguably the single hardest element to reproduce.

And the scale ceiling deserves an honest look too. ¥12,000 a month isn’t life-changing money. But a service with a correctly designed cost-to-price relationship sees profit scale proportionally as membership grows. What this case demonstrates isn’t a destination. It’s a method for checking whether a business is shaped to scale at all.

Related reading

• Sidekiq — running free and paid versions of an OSS project solo
• Plausible — a paid product reaching $1M ARR in a market with a free giant