EPISODE 1782

[INTRODUCTION]

[0:00:00] ANNOUNCER: Discord is a popular communication and streaming platform that was originally launched in 2015. It was first popularized in the gaming space, but its user base has grown to include a broad array of communities, businesses, and social groups. Justin Beckwith is the Director of Engineering at Discord. He leads engineering for the platform ecosystem organization and has played a pivotal role in developing Discord's embedded app SDK. Justin joins the podcast with Sean Falconer to talk about leading engineering at Discord.

This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

[INTERVIEW]

[0:00:51] SF: Justin, welcome to the show.

[0:00:52] JB: Greetings, Sean. Thanks for having me.

[0:00:54] SF: Yeah, absolutely. You're Director of Engineering at Discord, leading platform ecosystem. I wanted to just start off by having you walk us through and walk myself through some of your journey to Discord. What was the state of the product as a developer platform when you joined?

[0:01:10] JB: Yeah. I had a really unique opportunity in joining Discord. It's coming up on three years since I've been here, which is hard to believe. Before this, most of my career was really in enterprise software. I'd worked a lot on cloud developer platforms, had an opportunity to work on Azure, on Google Cloud, a couple of different platforms there. This was the first consumer platform I had a chance to work on. One of the things that really drew me to it was that there's this large, vibrant, excited, just a whole slew of developers that were already there. They were already building things, like chatbots, /commands, rich presence, all kinds of any way that they could extend what was on Discord, people were trying to do it. It was a unique opportunity to walk in where that ecosystem had been defined. It was core to the product. I have a chance to come and work on something that inspired people.

[0:02:00] SF: How do you think working on something where you're building, essentially, still building developer platform? This is designed for developers, but the end user of the developer is going to be consumer. How do you think that might be different from the types of work that you do versus B2B technology, SaaS, or some managed service, or something like that?

[0:02:21] JB: Really interesting question. I think that there are a lot of places where they're similar. At the end of the day, enterprise developers are still developers, consumer developers are developers. We want a lot of the same things. We want great documentation. We want walkthrough guides. We want SDKs, command line tools. I'd say, the places where it was uniquely different really came around velocity and stability. I think on an enterprise platform, you have it beat into you where it's like, you want to know your roadmap. You want to have that three-year roadmap. Some places have worked, we had public 12-month roadmaps, where we talked about what we're going to release.

There are these very, very hard and fast rules about how you break things and never breaking the platform. In a lot of cases, and sometimes an enterprise software, crummy UX is okay. The number one thing that you need is the ability to get the job done for us to make the API exist. Then if we want to make it easy to use, or if we want to go have great UX behind it, then we can go focus in there. I think what I've found is that the expectations on consumer facing platform for developers, they're a little bit different, right? It's expected you're going to move faster. It's expected that just the nature of the product itself. It's not going to be as predictable where we're going to go from one quarter to the next, because we're trying to chase users and we're trying to act more quickly than a large enterprise scale platform.

[0:03:40] SF: Yeah. You and I were chatting before we started recording. We were both at Google at the same time. You worked in cloud. I worked in cloud. I think cloud, you're dealing with a 18 to 24-month public roadmap. Any breaking change of an API is probably going to be a year and a half minimum deprecation cycle or something like that that you're going through. Do you think when you're building a developer platform where the end user is going to be consumer, are people more forgiving of those breaking changes, or are the same expectations there?

[0:04:10] JB: Yeah. I think that this is where it's like, the same expectations are there for the end user. We can't do anything that's going to break end users, right? That would be a complete failure for us. We absolutely don't want to willy-nilly introduce breaking changes. That's one of the things with the activities platform that we've put out there that we've been very careful, right? We've worked with a lot of partners. We've spent a couple of years, actually, building this thing out, getting it stable, making sure that we had a good handle on the primitives of it. Just because it's a consumer platform doesn't mean that you can just go break things. It just means the cycle can be a little bit different. I think that the industry just moves a little bit faster.

[0:04:47] SF: Yeah. I think one of the things that's really interesting about Discord is that it was designed, from my understanding, anyway, to be extensible and adaptable from day one. I think it's really hard to build a product that has a singular focus, has your product market fit and be really good at that, while also being good at being extensible, and being extended in ways that probably the founders never ever thought anybody would extend it in that way. Can you talk a little bit about, as far as you know anyway, the decisions behind that and what was particularly difficult about pulling some of that stuff off?

[0:05:22] JB: Yeah. I mean, I think that you'd mentioned it being maybe extensible in ways that maybe the founders didn't think of, that's actually not true. Jason and Stan, the co-founders of Discord, they constantly talk about the value of it being an extensible platform and how that was one of their goals, actually, from day one. I think that made it a lot easier for me to walk into this job where they had this running head start. I'd mentioned it already, had this vibrant community of passionate developers. It's because it was built like that from the beginning, and they erred on the side of make it open, let people use the platform in the way that they're going to use it.

Early on, we might change some things, we might break some things and that's okay. We know that people are coming in and just trying to build against it. But they definitely started with that philosophy of keeping everything open and then just seeing what people would build. One of my favorite things when I joined here, we have, of course, all of our communication at Discord is through Discord. The app city, the channel where we communicate most with the team has this channel description on it that says, "You honestly wouldn't believe the things that people make." It's really resonated for me and it's turned out to be entirely true as you see the stuff that people just come up with and build.

[0:06:30] SF: Yeah. It's interesting, also in a time where companies like Reddit and X, or Twitter have actually closed down their APIs, it feels like Discord is going the other way where they're actually leaning into this even more and it's becoming - it was already a developer platform, but there really seemed to be investing resources into that. Given that they already had this thriving developer ecosystem, when you joined, what were some of the focal points, areas that you initially jumped into and thought either they were a problem area, or maybe there were things they weren't doing today that needed your expertise to get in there and take care of?

[0:07:12] JB: Right. I mean, in terms of needing my expertise, that's certainly not the thing that I provide for the team most of the time. I'm there to guide, unblock very much in the style of letting the experts that we have do their best work. The first place when I joined the team that we spent a lot of time was helping shepherd this transition with chatbots, where originally the way that chatbots were born on Discord, because everything was just open was you would build a bot, you would listen to every message that came through on a web socket. If that message summoned your bot, sometimes it was with a bang and then the bot name, then you would parse the message and react to it and then respond just like a user would, right? It was effectively using the same API as we used in the client to send and receive messages.

This worked initially out of the box. But as we grew and as more and more users came onboard, we realized, one, that was a pretty difficult way to build a bot, because you had to handle the scale of listening to every message in every single server and responding to that. Two, from a privacy standpoint, we didn't want to put users in a position where as these bots proliferate, they could start collecting all these messages and doing whatever with it. One of the things that was put into motion before I got here, but I had to help see it through was this transition to what we call /commands. That's effectively building a model where a user has to summon the bot in a very specific way. You register your commands. It has different sets of data types. We can provide really nice, fancy UX over this to make a great user experience. Whereas, before it was a little bit more hackery and terminal feel. Now, we have broad, rich UI that makes it easy to use.
Helping the team through that and what that breaking change meant. What was a reasonable amount of time to give developers? How do we communicate it? How do we make sure that we have all of the features that we need in place before we make this migration? I would say, that was the first big project that I got to work on when I came in. Ironically, it was thinking through a breaking change and how we roll that out in a way that's safe for users.

[0:09:08] SF: Yeah. What were some of the decisions that had to be made in order to do that gracefully?

[0:09:12] JB: I think the biggest issue there is always going to be trying to give the same amount of features that users are accustomed to. We wanted to make this change that we thought was going to be good for developers and was going to be good for users. We want to make sure we did it in a way where they weren't losing anything, right? We want the same level of flexibility. Most importantly, we wanted users that are using these bots day in and day out to be able to do most of the same things. A lot of the decision making was, how far do we build, right? How do we take this system that was completely open-ended, put some structure around it, give it some nice primitives, make it feel good, make it feel like it wasn't just, we're asking users to move just because we ask them to. We wanted them to want these bots. We want them to want to move to this new system. We spent a lot of time thinking through the user and user implications of what we were building.

[0:09:58] SF: Yeah. How do you manage to strike a balance between making something that's user-friendly to the consumer, but also extensible to developer, to a place where you're not able to extend it where it becomes just difficult to use? If I think about back in the early days of MySpace, and some of the things that people could do, you'd hit a MySpace page and your browser would basically crawl to a halt, because there's multiple music playing and there's all these slow loading graphics and stuff like that. Because there was no guardrails around what anybody could do. You're just having people create these horrific websites. How do you basically give people the freedom to create, while essentially putting some limitations around what it is possible, so that they are always creating a decent user experience?

[0:10:44] JB: It's a great question. I think, I'm of two different minds here, I'll be honest with you. I think on one hand, if you want to have a truly open platform, you have to be able to accept that people are going to build things that maybe don't look great, or don't look the way you would have built it. If it's not popular and if it looks bad and if it isn't a great experience, they're not going to use those apps. If someone creates an app for your phone that looks terrible and doesn't use the right primitives, then you're probably not going to go download and install that, right? But if it does something great, if it does something novel, if it does it in a way that we never imagined you building it, that's the goal.

You can't get that level of creativity and you can't get that break out of the norm and the expectations, unless you give a little bit more freedom on what they can build. That's one piece of it where I definitely have, that's my general mindset. That having been said, we also want to make it easy for developers. The last thing we want to do is have the out of the box experience be compromised. On Discord, for something you can do for the developer. I think that's where with /commands, it's a great example where we spend just a ton of time, stylizing it, having developers provide us with a decorative way to say, these are my commands. These are the inputs. Giving them structured ways to provide output, not completely giving up formatting.

One of the advantages of that that we get that's obvious is to the user getting that level of consistency. The other hidden advantage that you get out of it, actually, is managing a lot of the things that come from having a desktop web and mobile platform. Developers don't have to think as much about how is this formatted on mobile? How we're looking with this device? How does it look in this situation? We can do a lot of that for them.

[0:12:25] SF: Yeah. I think there's a lot of stuff that has gone into not only making development easier, but also in particular, gaming development where I think Discord has been really successful. Just so much has gotten easier. When I think back nearly 20 years ago, when I got into building games for a while, it was just a lot of work, it was C++, OpenGL, DirectX, there's a lot of math, physics. But game engines have lowered the bar there, made things much easier. Then with Discord, you're getting cross-platform compatibility. Then as a game designer, you have a fast path to users and distribution.

Now you throw in things like gen AI and just even using as a development tool, it was probably easier to build a game now than it ever was. I'm curious, I know you're more on the developer ecosystem side, but what are your thoughts on how some of those things in particular, Discord and the distribution that's available there has impacted how we build games and design games and what kind of games are possible?

[0:13:24] JB: Yeah. I think that's one of, I'm all for democratizing developer platforms. I think anywhere in the industry where we can make it easier for more people to build, especially folks that are creative and don't have traditional backgrounds, maybe in computer science, then we're opening the possibilities of what can get built out there. I think those are all positive. I think that's been one of the funnest projects I've ever worked on here at Discord has been the release of activities and making it so that developers can build HTML5 and JavaScript games, put them right into Discord.

I mean, web games, it's not entirely new, but I think the twist that we're able to put on it that's a lot of fun is bringing the social structure to that game. Instead of starting a game maybe on your own and then going off and playing it solo, it's making you do it with friends. You can do it in a video call, have context, have video, voice, chat. All of that just already taken care of in there. Then bring your game into that environment. It's been just a ton of fun to work on.

[0:14:24] SF: Yeah, you get a lot of the - you're basically providing a lot of the social communication infrastructure that for any modern game, you probably would have to build from scratch if you didn't have it at a box through a platform like Discord.

[0:14:37] JB: Yeah. I mean, if you're already here, you're hanging out, you're with your friends and you want to find something to do, it's nice to just have it out of the box, be able to go into our app launcher, pick a game, and you just get all that stuff for free.

[0:14:49] SF: Talk to me a little bit about activities and how that works from the development standpoint. How do I get out building one of these?

[0:14:56] JB: Yeah. We have a lot of great guides. We were talking earlier about standing up our first developer relations team here at Discord over the last couple of years. Has been fun. We have great documentation on discord.dev that goes step by step. At the end of the day, the games that we support right now on the platform, they're web games. They're HTML5 and JavaScript. You host them. We have an NPM module that has our SDK that gives you all of the hooks into Discord, so you can get things like sessions start, knowing what people are playing, invites, sharing interesting things that happened back in the game, back out.

You, for the better part, can build a standalone HTML5 JavaScript game, add the social layer with a Discord, and then go through some lightweight steps to publish it in a way that we can access and launch it through Discord itself. At the end of the day, if you're comfortable with web development, web game development specifically, it's pretty easy.

[0:15:47] SF: then as a developer, I'm using the embedded SDK to build those experiences. Then, is that loaded up, essentially, as an iFrame embedded directly within Discord?

[0:15:57] JB: Exactly. Well, it's an iFrame. It's locked down in a variety of ways to make sure that it's safe for all of our users that are using it. Yeah, it effectively loads the whole experience inside of an iFrame in the client, and that's both desktop and mobile platforms.

[0:16:12] SF: What are some of the limitations that have to be put on that to make sure that it's secure? I'm sure there's a number of privacy challenges as well that come along with that.

[0:16:22] JB: One of the nice things about working at a company with a world-class security engineering team is that they really helped us make sure we got that right. We've had a couple of years to work on it out of the gate. In terms of how it limits what you can build, most of the things that are really limiting there are like, well, A, it is limited to web. We're not able to go provide things, like native game development just yet. That's not something that we can go out and build. It's restricted to HTML5 JavaScript.

Any feature that has a risk of exposing the user's IP address to other users, or to end developers, those are actually things that we try to avoid as well. I would say, that's probably where the majority of the limitations come from, honestly, is that at the end of the day, Discord is a communications platform that is primarily working with the people who game. One of those big risks in gaming communities is having someone get your IP and then getting DDoSed while you're trying to play a competitive game. That's something we're incredibly sensitive to. When you're dealing with something like an iFrame or a web app like this, we have to be really careful to restrict which APIs you can put into place and how you build it to make sure you do it in a way where there's no direct communication from user to user, or even user directly to the developer. We actually proxy everything.

[0:17:33] SF: Then for me, if I build one of these games, these activities, I put it in Discord, it's like App Store, people are installing it, it gets really popular. Is it on need, essentially, be able to scale the infrastructure to match how much interest there is, essentially?

[0:17:48] JB: That's exactly right. We definitely discussed the idea of having our own hosting platform. That's something that we went back and forth with a number of times. At the end of the day, the variety of ways in which people can build these backends, the richness of them, the differences from one game to the next and what's requirements look like, we really wanted to leave that to developers to be able to own the intricacies of that stack and own how they're going to scale it. We have some developers that have their own whole backend ecosystem that's common across all of their games, regardless of where they run. We didn't want to dictate the backend to developers. Yeah, ultimately, they're responsible for how they scale and the stone of triumph, how they carry that.

[0:18:26] SF: Then, can I monetize my game through downloads, or installs?

[0:18:31] JB: Yeah, absolutely. I mean, not through downloads or -

[0:18:34] SF: I guess not really downloads.

[0:18:35] JB: - installs specifically. Yeah. Download's not really a thing in this case. But that's something that we've been working on for the last year as well, is what's called premium apps. This works across both actually /commands, traditional apps on Discord, as well as activities. We've had a number of features we rolled out, where we'll do all the payment platform stuff for you. You just have to integrate. You can sell in-app purchases, subscriptions. We have some new things that are about to come out in the next couple of weeks that are going to continue to make that better. We've been actively working there for a while and all that stuff's out. You can absolutely monetize. Yeah.

[0:19:10] SF: Then, were there particular, I guess, technical challenges with rolling out the embedded SDK? You said the activities platform was something you were working on for a number of years. What was some of the big challenges there, besides some of the security things that we mentioned?

[0:19:24] JB: Well, I think we talked a little bit about building out a developer platform for a consumer ecosystem and how that can be a little bit different. I think the first thing we really needed to nail down was the user experience. Playing games inside of a chat app comes with a number of interesting UX challenges. Figuring out how to do that in a way that's delightful and gets people coming back and doesn't interfere with the main point of the app is connecting with people chatting, right?

I think that the first challenge is there. I mean, yes, there's a bunch of interesting technical challenges, but the first ones were really the UX and making sure we got that right. When getting to the technical side of the house, I'd say the number one challenge we faced initially out of the box was that security problem. We wanted to be so careful here, because we have what is an iFrame running inside of Discord, making sure that nothing can escape that iFrame, making sure it doesn't get access to anything on the user system that shouldn't have access to. Pen testing that. Trying out all kinds of different ways to make sure that we'd covered all of our bases. That was one of the key technical challenges that we had going in.

When it comes to the titles themselves, because actually, many of the initial activities were actually built by Discord, we have an in-house studio that goes and experts in building web games, performance was really a bit of a challenge, because we have these games we want to build. We want to have great experiences. These are game developers. We have a Discord that have worked on large AAA titles, and they have very specific things they want out of that experience. They want it to be great. Building it in a way that runs on the web that is also rich with features, gameplay mechanics, performance, and would run not only on a desktop, but on a mobile device in an iFrame was actually a pretty big technical challenge, and it's been inspiring to watch them work through that.

[0:21:08] SF: Did you have to do some work to seed the marketplace of the app store, essentially, with building some in-house apps launched with something, at least empty marketplace is not very exciting?

[0:21:20] JB: Yeah. Activities have actually been on Discord for a couple of years, but they've all been those first-party ones that we've built. These have been titles like Chess in the Park, Poker Night, Letter League, some of the classics when we wanted to put out there to feel out. Is this something users want? I think out of the gate, we had over 40 titles that were available before we went to GDC last year and opened this up for anyone to start building. Then even during that time over the last couple of years, we've been working with a bunch of other game studios. We ourselves tried it out. We built some titles. We had some games we felt great about.

We worked with other partners like FRVR, a couple other companies to release their titles that we thought were really exciting and captivating on the platform. Also, to make sure we had the API right. If you're the only one that's tested your API, you can't be sure that you have that thing right, or that others could use it. We wanted to get that validation as well.

[0:22:11] SF: In terms of the UX, what's it look like as a game embedded in Discord, versus me having, essentially, a conversation with the other people who are actually also playing the game?

[0:22:21] JB: Yeah. There's two different modes that you can play these games. One is through, starts with a voice call. That's been the original mode and is right now our most popular, where we get in, let's say that we're in a server and we get in a voice channel. We're talking and we just decide, "Hey, I want to play a game, or I want to listen to music." That's another thing. We have multiple music activities that are available as well. Someone can click in on the app launcher while you're in that call. You pick the activity and then other people can just jump and join in. You're still in the voice channel. You're still in Discord. You have text. You have voice. You can scoot around the rest of the app, but you're just inside of the main screen playing a game.

We also have outside of the voice call, if you want to have something that's a little bit more async, you can start these games from inside of a text channel as well. Let's say, and you want to start a game, have other people see that the session is happening and then join in without having to be in the voice call first. You can do that as well.

[0:23:13] SF: What about multiplayer? If I'm building one of these activities, what do I essentially see as a developer to know how many people are there? How I can help them interact with each other, and so on?

[0:23:25] JB: Sure. We provide APIs for that. That's one of the main benefits you have of building this into Discord is you get that stuff for free. We give you a list of the current participants that are inside the call, people that are inside of the activity. Then you can build your game around that. One of the things that's been interesting to work on is thinking through all of the models of multiplayer, where it's like, some games you can show up. If you're the only person there, you have to show up with other people in the call. It's like small party games. 

Others that have built on top of the platform will do global queuing. You can show up on your own. There's a global queue of everyone playing that game, and you can still have that communication just with your group inside of the channel. I think that this is something that's evolving and developers, since we've opened it up, are doing all kinds of interesting things we didn't expect, which is exactly what we were hoping for.

I think for people that are building these games, having a lot of clarity on what are the communication structures? Do you want global queuing? Do you want it to be private matchmaking? Really thinking through that can be helpful in figuring out how successful your game is going to be.

[0:24:29] SF: There was a period where platforms like Facebook and other social media platforms were really big, I think, in gaming for the Farmville era of Facebook. I mean, I'm not on Facebook a lot of these times, so I need to ask my parents who are on there. It seems like, they blew up and then they've fallen off, at least, is my sense. Why do you think that Discord has been so successful with this? What's different about it, versus some of the things that were happening 10 years ago on platforms like Facebook?

[0:24:59] JB: I think at the end of the day, Discord is built for gamers, by gamers platform. Gaming is through the DNA of the company. It's something that people here care deeply about. I think that we wouldn't put a platform out there that we ourselves didn't want to go use. That's first in our hearts and the first sets of users that we really think about ourselves. I think that's the first thing is it's not like this was a social media platform that we then added gaming features onto. It's always in core to who we are and what we built.

I think the second thing is really starting with the social group first. We don't want to build a generic gaming platform. There are plenty of those out there. That has been done many times. For us, it's about finding something to do with your friends. Having people that are here, we want better ways to hang out, better ways to connect and be together, and that's the social aspect that we add into the whole thing that makes it - that has made it successful.

[0:25:56] SF: Yeah. Since you have these social groups and why this focused on connecting with your friends, or at least online communities that are similar to you, do you think that this allows more niche games, niche experiences to be successful at scale than something? I mean, it's hard to find, essentially, your audience if you are in a niche without something like this.

[0:26:17] JB: I'm so glad that you asked that question. That's the magic of Discord, actually, is that we attract all of these communities of interest and we help people that are passionate about niche things find each other and build their communities up. That doesn't go for just the servers themselves, or the communication that happens there. It happens with apps, too. We see this today with traditional /command apps, where you can build something. Are you super into Magic the Gathering? Yeah, there's an app. There's someone who's built /commands for that. D&D, we actually have room 20 that came onto the platform and released their platform through Discord.

Even more niche than that, though, because it's open, this gets back to what I was saying earlier, we can't predict what people are going to build. You can extend Discord in any way that you want to that makes sense for your community. I think that's the exciting part of all of this is watching not - Yes, the big titles are important and we want people to launch games and get all kinds of eyeballs and become wildly successful. As a business, that's critical. For me, personally, I love the niche stuff. I love something that's only going to make sense for one community and one server, but it solves their problem exactly. That to me is very, very exciting.
[0:27:24] SF: Yeah. It's like, most of the stuff that I built in my career is so niche that only myself and a handful of other people care. In terms of niche groups and niche experiences have been built on the platform, what are a couple that really stand out to you?

[0:27:37] JB: Oh, goodness. I love the apps that get built that are just silly. I'm personally, one of my core values and something I deeply enjoy is whimsy. One of the first apps that we had built, this isn't an activity. This was just a standard bot that got built here was a turn up app. The thing was silly. It was built as an example of how to use user apps, which are apps. Instead of installing it in a server, users have control and they can install and take them with them. It lets you give people turn ups. It lets you have an economy of turn ups and a whole - it became like a gift giving thing, where someone did something nice for you and you're like, here's a turn up. Enjoy that.

It's a silly thing. It was pointless, but it made people so happy and it grew like wildfire internally. In Discord, we ourselves are always using these kinds of bots and is a way to communicate and show gratitude. I think those types of experiences, the things that help me connect with people, show gratitude, have fun, be silly, that's the magic of Discord. It's the magic of extending it to.

[0:28:40] SF: I think that's also probably the magic of democratizing some access to being able to build these types of experiences, too. If you're not so limited by the technical hurdle of actually building something and you can focus a little bit more on your imagination, then it potentially opens up the world of people that can essentially create experiences like this that maybe you haven't been able to do that in the past.

[0:29:05] JB: Yeah. I mean, so hard to build a lot of the underlying primitives for communication into your game. If you're starting with the game and then trying to build all of this, it distracts you from that end experience, right? Distracts you from the creative process of building the game itself. I love that we were the social box that you can just build within. You have the community existing, and it scales. You can start with something that's very little code that you don't have to build a ton with for a simple bot, all the way up to a full-blown game title that runs inside. You get to scale based on your abilities and how deep you want to go.

[0:29:39] SF: Yeah. I mean, I think it's really fascinating that Midjourney started on Discord and blew up from there. It's probably not what you think is the most natural path to using something like Midjourney, but it worked for them. I'm curious, are people using Discord almost like a place to test app ideas since you have access? I think there's 200 million monthly active users, or something like that on Discord. So, you're able to reach a very large audience in theory quickly. Are people experimenting there and then maybe taking it outside of Discord as things develop and actually grow in popularity?

[0:30:17] JB: I think that, yeah, there's definitely a subset of apps that are doing that. Midjourney is an interesting example of one that started in Discord. Use that to get their viral growth and awareness and to spread through communities. I know that they are going out there and building some standalone experiences. The magic of most of the apps to get built in Discord is using it with your friends. If it's just an app that you're building to use for yourself, or for a utility app that's for one person, you can build that in Discord and will successfully help you scale it and you'll grow. You're going to get the most out of the platform that way.

The sweet spot are really, really the apps that help people do things together. I think that with some of those early AI apps, it's not that I could generate the image that made it fun. It's generating the image and then sharing it with my friends and then having them riff on it and then having that spur new ideas. I think the real successful apps on Discord are going to be the ones that embrace that social aspect.

[0:31:13] SF: How's the user engagement been with the embedded activities, compared to the traditional bots and other types of integrations?

[0:31:21] JB: It's still emerging. I think that the thing with traditional bots that you have to keep in mind is that those have been there on the platform since pretty much day one. As Discord grew, all of those existing bots grew with the platform and become vital and integrated and important activities. We have strong numbers. We're growing. More and more people are using it. It's not quite caught up to bots yet, but it's going to take a little bit of time.

[0:31:43] SF: What are some of the challenges as a third-party developer I might face when using some of the developer tooling that's available on Discord?
[0:31:52] JB: Yeah. I think some of the biggest challenges we've seen so far for developers that are coming onto the platform, one is if you're an existing game studio, or you're an existing developer and you want to build something, you know that Discord's popular. It's out there. You want to figure it out, but you don't have a lot of expertise in it is building things in a way, just like I was saying earlier, that take advantage of the social aspect. I think that if you try to build a game where it's like, you just come in, you use it, you play it, and you don't fully embrace the idea of people communicating and playing together, then you're not going to be as successful as someone that really understands the Discord dynamic and how those communities work.

I'd say, that's the first place where folks that are maybe coming from traditional gaming backgrounds have had to go learn and had to learn the best way to integrate that. On a technical level, you also touched on this a little bit. I think the biggest challenge is dealing with your own success. If you're an indie, you're an indie studio, you build a title, you put it out there, you think, this might be popular. Then we can have the effect of pointing 200 million monthly active users at an app and scaling it very quickly if it becomes popular. As a developer, I think helping people recognize the potential for the scale of their success has been another interesting challenge.

[0:33:01] SF: Yeah, I mean, there used to be, the whole was it /god effect, or?

[0:33:06] JB: /god. We're going in the way back machine. I love it.

[0:33:09] SF: Yeah, we're going in the way back machine, where that was for a blog article, or something like that. Is that something that has impacted existing people, like building apps on the platform? It's like, "Oh, I built this for my friends," and then suddenly, it blows up and I'm like, my server is just completely boiling over?

[0:33:27] JB: That can happen. Yes. That's definitely a risk. I think for activities, because it's the second time we've done this, we lived this with bots the first time. For a lot of the partners that we work with, we give them some controls to do slow scale out, right? We can control how many impressions they're going to be getting, where they get positioned inside of our shelf. Some partners, we do geo rollouts, where we'll start only say, in Canada, and do a slow rollout that way so that they can scale up with it. That has been effective. That's helped us out so far with activities specifically, making sure that for the bigger titles that we know we're going to have this issue, we can work with them. We have some tools in the toolbox to help. Yeah, once something gets viral, it getting /god, getting the Reddit hug of death, all the Discord laser beam, these are all things you do have to be thinking of.

[0:34:14] SF: What about on the Discord side, in terms of infrastructure challenges? You've grown a lot, especially with the developer and oriented platform. I would think that even as people are building games and a game gets popular, it could actually bring new users to the platform, to having a really hot show on a streaming platform, or something like that. Suddenly, you're getting a lot of sign up. How does that impact traffic that you have to deal with on the back end?

[0:34:40] JB: Yeah. I'm going to be honest. We've yet to have something so successful that it is actually challenged us in terms of the overall scale of Discord. I mean, the platform is what, eight years old now. It's been out for quite a long time. I guess, had 200 million monthly active users. We've had, I would say, the closest we've come is we've had a few of the AI apps that really took off, like Midjourney is a good example, where we noticed that one when it really took off. For those, there are some interesting backend challenges that our core tech engineering team will have to go solve from time to time. For the better part, it hasn't been anything we couldn't handle. Discord went through a huge boom during the pandemic in terms of growth and it's in a really stable great spot right now to handle that traffic.

[0:35:24] SF: Eight years ago, what's the backend stack look like, as much as you are familiar with anyway?

[0:35:30] JB: Yeah. We actually have a great blog that often talks in detail about how some of the moving pieces here work. I love this question in interviews. It's actually really fun when I'm working on hiring and I was like, "Oh, what kind of languages do you use?" I get to take a deep breath and talk about all the way from the top, with React Native. Sometimes you're in Swift and Kotlin. Sometimes you're mostly in TypeScript, or React. Working all the way down to, we have a Python API layer that is the most basic HTTP API. Python and Flask, just like anyone else would do. For the core communication, the pieces that are really interesting are in Elixir running on the BEAM VM, which is just magical technology for anybody that has built a messaging app. Once you find the BEAM VM, you learn that everything starts to get a little bit easier, and you can scale pretty well on it.

For bits where we have very, very performance needy parts, especially coming from that API layer, we do a fair bit of Rust these days for performance, stuff that is performance requirements around it.

[0:36:28] SF: I'm not familiar with the BEAM VM. What is that project?

[0:36:31] JB: Yeah. The BEAM VM is just the virtual machine that if you build applications, originally Erlang, so a lot of telephony systems were built on top of Erlang running on the BEAM VM. More recently, most people that are targeting it are using Elixir as a programming language, which has that like, a functional Ruby feel to it. It has a je ne sais quoi of Ruby, if you've never worked with Erlang and you start working with it. It really just makes message passing and building high throughput and messaging systems easier.

[0:37:01] SF: Going the outside of the infrastructure question to more this growing trend that's been happening in industry with gen AI. We talked about Midjourney and the impact that it had. How is gen AI impacting the Discord platform? Are you seeing a lot more app developers trying to build stuff related to that, or even your own investments into the space?

[0:37:23] JB: I think that it follows the lines of a lot like, any trend that comes and goes on the Internet. I'm not saying this one will come and go, but it's what's hot right now. It's what's fun and interesting. Of course, when that happens, people are going to bring it to their social spaces. It's been fun to watch Discord be the center of it in a lot of cases, especially with Midjourney, now Vigle will be doing a lot of the same things, but with the video. I think that Discord is a great place for it, because it helps people share, build off of each other's ideas, and be creative in a group setting. I think that at some point, there will be the next wave and hopefully, that one's on Discord as well. I really think it comes down to that social aspect and sharing that makes it popular.

[0:38:03] SF: What are you focused on, you and your team, for the next six to 12 months that you can share?
[0:38:08] JB: Yeah. We want to make everything about building games on Discord, building activities better. That means giving users more ways to interact with them, making it feel like a top-notch experience, making it feel like running it, you can build something as good as a native game that runs inside of Discord. We want to give them more ways to communicate with each other, invite people, build your social network, and do all of that on the app. This year was really a lot of making it possible. Next year is going to be about turning that crank and making it great. That's what we're hoping for.

[0:38:41] SF: In terms of making, being able to build games that feel native, are you thinking you'd actually provide the library support to do like, essentially, the graphics of the game?

[0:38:51] JB: I think this is where we take advantage of a lot of the great work that's already out there in the community. One of the companies that we've been working with is Build's phaser.io. Wonderful HTML5 JavaScript web gaming platform. We have other partners that we've worked with from the beginning that make that stuff possible. We want to deepen and tighten those relationships a little bit and work more closely with all of the companies that are building game tech that let you export to web as a target. I think that the more we do that, the more the developers are going to get best-in-class developer experience for building these type of titles, and we can focus in on the part that we're good at.

[0:39:26] SF: Right. Yeah. It's more about partnership and creating probably an integrated experience of here's our opinionated way of building games on Discord. But you're not building everything soup to nuts from the ground up.

[0:39:38] JB: Exactly. Unity is out there and can export to web. Phaser is there. There are a bunch of these web platforms that are quite good. How can we make them better? How can we work with them? That's what we're going to do.

[0:39:49] SF: Awesome. Well, is there anything else you'd like to share?

[0:39:51] JB: No. Just this has been an incredibly rewarding experience the last couple of years. I think, like I mentioned, the magic of Discord is that it's here for people to have fun. It's here for whimsy. It's here to bring folks together. If people take anything away from this from a like, why you should build on Discord, it's about integrating into that social layer. It's about integrating to go to where people are already connecting with their friends and think about how you can build experiences that take advantage of that connection. Yeah, that's it.

[0:40:19] SF: Awesome. Well, Justin, thanks so much for being here. I really enjoyed this.

[0:40:23] JB: Yeah, this was awesome. Thank you so much for having me.

[0:40:26] SF: Cheers.

[END]