What Building a Community of 50,000 Taught Me About Software

I've been running Worldwide for five years. It's a Discord community of 50,000 people with a virtual economy, games, and an active daily user base of thousands. I built almost all the infrastructure myself — the bots, the economy, the moderation systems, the data pipeline.

The technical work is documented elsewhere on this site. This is about what I learned that isn't in any CS curriculum.

Users Are Not Rational Actors

My first economy design assumed users would optimize for maximum currency per hour. They don't. They optimize for enjoyment, which is a much harder thing to model.

Some users played the daily gambling game exclusively, even though the expected value was negative. Some accumulated massive balances and never spent them. Some gave away currency to strangers because it felt good. Some quit the economy entirely after losing a large bet, even though their balance was still healthy.

When I added a feature I expected to be unpopular, it became the most-used feature. When I added something I was sure would be loved, it saw 3% adoption and I removed it six months later.

The lesson: you cannot predict user behavior from your mental model of a rational user. You have to watch actual users. Every assumption you haven't validated is a hypothesis.

I started treating every feature launch as an experiment: what behavior am I expecting, and how will I know if I'm wrong? That question alone made me a better engineer because it forced me to define measurable outcomes before shipping, not after.

The Feature That Works at 100 Users Breaks at 10,000

The moderation queue is the clearest example I have. At 500 users, moderators could review every flagged message manually. The queue was manageable because volume was low.

At 5,000 users, the volume was 10x higher but the moderator team hadn't scaled. The queue became a backlog. Moderators burned out. Moderation quality dropped. Bad actors discovered they could exploit the delay.

I didn't see this coming because I was thinking about the feature at the scale I'd built it. I wasn't thinking about what happens when load increases by 10x, then 100x.

This is the systems thinking problem: the behavior of a system changes qualitatively at different scales, not just quantitatively. A moderation system that works through human attention works differently from a moderation system that must work through automated triage. These are architecturally different systems with different failure modes.

The rebuild required automation, priority queuing, and a tiered response system that distinguished between "likely spam" (handle automatically) and "genuinely ambiguous" (human review). The manual queue became a surgical tool for edge cases, not a primary workflow.

The principle I extracted: when designing a system, explicitly consider it at 10x and 100x your current scale. Not because you'll definitely reach those scales, but because the architectural decisions that are right at each scale are often different.

Feedback Loops Can Be Invisible Until They Destroy You

We had a feedback loop in the economy that took me six months to notice.

The mechanism: users who were more active earned more currency. More currency let them buy items that made them more effective in games. Better game performance earned them more currency. The rich got richer, mechanically.

This created a visible outcome — wealth concentration — that I tried to fix directly (currency sinks, decay taxes). Those measures had effects, but they didn't fix the root cause. The feedback loop was still there.

The insight I missed: feedback loops are structural, not behavioral. You can't fix a feedback loop by modifying the behavior it produces. You have to identify and break the loop itself.

The actual fix was changing the game reward structure so that performance above a threshold didn't produce linearly more currency. Winners still got more than losers, but the marginal return on high skill decreased at the top. This broke the rich-get-richer loop at the structural level.

I now look for feedback loops before I look for anything else when debugging emergent system behavior. They're almost always the cause.

Availability Beats Features Every Time

In the early years, I focused on feature development. New economy mechanics, new games, new moderation tools. Features are exciting. Features are visible. Features generate community discussion.

Then I had a 6-hour outage during peak hours. The bot was down, the economy was inaccessible, games were broken. The community mood was catastrophically negative, in a way that a dozen new features couldn't fix.

I'd optimized for feature richness at the expense of reliability. The community's relationship with the platform was built on trust that it would work when they came to use it. I'd broken that trust.

The lesson is counterintuitive to developers who care about their code: users don't care what you built; they care that it works. The most technically interesting feature in your system is invisible when it's running correctly. It's only visible when it fails.

After the outage, I shifted priorities. Monitoring first. Alerting second. Deployment pipeline that made rollbacks fast. Graceful degradation so partial failures didn't cause total failures. Feature development third.

Reliability is not the unsexy counterpart to features — it's the foundation that makes features meaningful.

The Bug Reports That Matter Are the Ones You Don't Get

The moderation queue backlog story above started with a complaint. But by the time someone complained, the problem was already severe.

Most user problems don't generate bug reports. Users experience friction, give up, and quietly disengage. The absence of a complaint doesn't mean the absence of a problem — it often means the problem was serious enough that the user didn't bother.

I learned to read signals that don't look like feedback:

• Drop in DAU without an obvious cause. Something changed and users noticed.
• Unusual patterns in the economy metrics. Volume spikes or drops that don't correlate with server events usually mean something in the UX broke.
• Feature usage that doesn't match design intent. Users finding workarounds usually means the intended path has friction you didn't notice.

The most useful thing I added to my stack was a simple event tracking system — every significant user action logged with metadata. Not for surveillance, for understanding. When something breaks, I can reconstruct what users were doing before it broke. When adoption is low, I can see where users are dropping off.

Observability is not a deployment concern. It's a product concern.

What No CS Curriculum Covers

I finished my B.Sc. knowing how to write correct algorithms, analyze complexity, and reason about data structures. I did not know how to:

• Read metrics to understand user behavior
• Design for failure modes I haven't anticipated
• Make architectural decisions that will hold at 100x scale
• Build community trust and repair it when it breaks
• Make tradeoffs between competing goods (features vs reliability, new users vs veterans)

These aren't soft skills. They're hard skills that require practice on real systems with real users. You can't learn them from a textbook because the thing that makes them hard is that the right answer isn't known in advance.

The only way I know to develop them is to build things, let real people use them, and pay close attention to what breaks and why.

Five years in, I'm still learning.