I built the next Discord!

You’ve seen the post. Maybe you wrote it.

Every act of creation carries four questions. What did you try to build? What do you think you built? What did you actually build? Do you know what you built?

That LinkedIn post answers the first question. This article answers the other three.

What Discord Actually Is

Discord is not a group chat application. Discord is an enormous, distributed systems problem that just happens to look like a group chat application.

When you send a message on Discord, that message travels over a persistent WebSocket connection. It is sent near real-time to millions of concurrent users. Meanwhile, there are millions of other concurrent users doing the exact same thing.

Messages are saved to a database. Discord started with MongoDB. Then Apache Cassandra. They migrated next to ScyllaDB when Cassandra couldn’t adequately solve the hot partition problem. Hot partitions happen when too many requests hit the same node, trying to get the same recent messages.

In Discord, the query SELECT * FROM messages WHERE channel = ? AND timestamp > ? does not exist.

Then there’s presence. The little green dot telling you who is online, in which server, in which channel, sent to every relevant client, in near real-time, again to millions of concurrent users. People can be online with multiple simultaneous sessions. If I close my laptop lid, but my phone is still open, I remain online. No, this does not mean that presence is an integer instead of a boolean.

Discord handles both voice and video distribution. That’s a new infrastructure problem. WebRTC. Selective forwarding units. Jitter buffering. Codec negotiation. At scale.

Screen sharing. Private messaging. Moderation tooling. Bot integration. Nitro premium features. Server boosts.

You have solved approximately 0% of Discord’s problems. Relax. Take down that post from LinkedIn.

The Depth You Don’t Know You’re Missing

Latency is bound by physics. Getting a message from Toledo to Tokyo in under 100 milliseconds requires edge infrastructure. Doing it securely requires private networks. Doing it reliably requires redundancy. It requires technical know-how and sophisticated teams of experts.

Where do you run your infrastructure? Do you rent it from AWS? Do you build your own? Netflix is an AWS flagship success story. Dropbox started on AWS, then decided to build their own infrastructure. At six users, the correct answer is “whatever’s free.”

Were you planning on capital allocation decisions? No. You just wanted to send messages to your friends.

You Are Not Going to Ship This

You are not going to ship this app. Not to strangers. Not to the public. Not to anyone outside your friend group. If you try, the world will correct you before you hit a hundred users.

You haven’t thought about what it costs to run infrastructure. You haven’t thought about CDNs for your static assets. You don’t know about frontend or backend redundancy. You don’t have a data recovery plan. You aren’t prepared for DDoS attacks. You aren’t ready for supply chain attacks in your NPM packages. You certainly haven’t thought about toxic content or about how you’ll handle a subpoena for messages.

None of that is hypothetical. All of it is unavoidable once you have real users paying real money to use your chat app.

This isn’t a knock. It’s a scope check. The thing you built for six people doesn’t need any of it. The moment you try to be a chat app for everyone, it needs all of it. That gap is not closeable with a weekend and a capable coding agent.

Here’s What You Did

You built something. You sent a message from your computer and it showed up on your friend’s phone. That is goddamn amazing! Pop the corks, friends! An act of creation happened. You should be proud of your accomplishment.

Seriously. You looked at a problem and you solved it. That’s how software actually gets built. You participated in that. The complexity you didn’t add made what you built possible. Those aren’t in opposition. They’re the same story.

When you finally delete Discord off your phone or computer because the thing you built works, you did, in fact, kill Discord for you. That’s not a consolation prize. That’s a precise definition of success.

The Real Question

How many Discord servers are just a half dozen friends sending memes to each other?

What’s described above is a fraction of Discord’s actual use case.

Your use case is six users and a meme folder.

Those are not the same product. Discord happens to also run the second one because it’s incidental load on infrastructure built for the first. You were renting a commercial kitchen to make yourself a sandwich. Your counter at home works fine.

A persistent group chat for six people is a solved problem with a surface area approximately the size of a weekend. The hard problems discussed above don’t exist at six users. The requirement set for “my friends and I want to share memes” is small, achievable, and completely legitimate.

You didn’t fail to build Discord. You built a different, more appropriate product. You just didn’t know that’s what you were doing because you never stopped to define the problem.

A Different Kind of Disruption

Historically, people have framed this as disruption. That framing is pointed in the wrong direction.

In The Innovator’s Dilemma, Clayton Christensen describes how incumbents get knocked off by cheaper, simpler competitors that fill gaps for overlooked customers. Company A disrupts Company B by building a product that’s good enough for the bottom of the market, then slowly building over time.

Christensen’s lens is pointed at boardrooms and B2B disruption.

The disruption that’s actually happening right now isn’t little chat app versus Discord. The ecosystem of problem solving has changed. Problems that previously required a team, a budget, a product roadmap, and a six-month timeline now require a weekend and a capable coding agent.

You had a problem. You solved it.

You are not disrupting Discord. The incumbent isn’t Discord. The incumbent is the idea that your problem isn’t worth solving unless someone else can profit from the solution.

I have fixed wiring in my own house, but I wouldn’t call myself an electrician. I have built a shelf from raw wood, glue, stain, and screws, but I wouldn’t call myself a carpenter. People have always solved their own problems with the tools they had available. That’s not necessarily a business strategy, but it is human.

The hustle economy broke our brains. We started believing that every act of creation must be monetized. If you build something and don’t profit, you’re a failure. That’s why you posted it on LinkedIn. That’s where business successes live.

You’re allowed to build something because you think it’s interesting. You’re allowed to learn something just because you didn’t know it before. You’re allowed to make the thing because making the thing was the point.

Most of the time, we are all just solving our own problems, and that’s enough.

What happens next time when, instead of heading to the app store, you reach for your coding tool of choice first?

---

---