From open source hits to OpenAI (Changelog Interviews #682)

Speaker A: What's up? Welcome back. This is the Changelog. I'm Adam Stacowiak and today I'm joined by Max Loiber, talking about the long road from open source to open AI. Max has shipped a ton of open source. He helped build Spectrum with the Spec FM crew, sold a GraphQL CDN after realizing he captured almost the entire market. He helped shopify ship Horizon in six months, and now he works on the chat GPT plugin directory and the app platform. A massive thank you to our friends and our partners@flyio that is the home of Change Law.com learn more at flyio okay, let's do this. Well, friends, this episode is brought to you by our friends@coder.com Secure environments where developers and agents work in parallel. And I'm joined by Nikki pike, field CTO4 coder. Nikki, what is a field CTO?

Speaker B: So I get that question a lot. And it's, you know, half the people understand it, half the people don't. So a field cto. I describe it very simply as we're devrel for the C suite. So we provide a bridge between the customer voice, between the, uh, C suite and the managers and the leadership teams of our customers back into our product. And then we go through and we help enable our teams to have the same message, to make sure that the message is correct and that we're building on something that people actually want, not just something that we think they want.

Speaker A: Okay, so we're taking the laptop away from the developer. Not really, though. We're putting them in a cloud development environment, a secure environment where they can work with their agents in parallel. These are blessed environments. What's wrong with the laptop?

Speaker B: The laptop is the trap here. And not only because the fact that it could be stolen, you could lose it, it breaks and you're out of work while you're waiting for a new one. But there's also just the consistency you got there. We all know developers, developers are going to be looking for some of the latest and greatest. And if you're not really controlling how they get out there, that's where you get this. It works on my machine. It doesn't work on production, in production, it doesn't work anywhere else because you don't have that consistency, you don't have that ability to really standardize what that environment looks like. And this is a problem not only for new people coming in. You know, the onboarding statement is average, I think is like four to five weeks for a new employee to really get their, their Local laptop set up and ready to start doing their first time of code. And you know, the time to first commit is a metric that almost everybody knows. And the reason they can't do that is because there's a lot of tribal knowledge out there. They got to go talk to other developers. What are we using? Where do we get our dependencies? Are we getting them from public, are we getting them from private repositories? But there's also the security and the supply chain aspect of this. When you have local machines out there, look at like the Shai Hulad, you know that virus that went out not long ago. This was a compromise of the NPM public repositories. They went and downloaded things, NPM did what it did, next thing you know you're compromised. But when you use something like what we're doing with cloud, uh, development environments, then you can mandate and you can put restrictions on there to say, hey, you can only go get your packages from our private repo. Those packages are expected to have been thoroughly vetted. We know that they're clean now. Does this stop everything like Shai Hulad? No. If that compromised package gets into your private repo, you can still have that, but it really reduces the surface area of the attack and it also reduces the blast area of the compromise should it happen. Because if your laptop gets compromised and you have to kill the laptop for whatever reason, that's weeks out of work while you're either fixing that or you're getting a new laptop in the cloud development environments allows you to kill that, start back up fresh and you're back and running in five minutes. You don't have to wait all that time.

Speaker A: Well friends, the first step is to go to coder.com, install coder self hosted environments for your teams to enjoy to standardize around. And it's open source so you can try it out today. Once again, coder.com. Friends, we're here with Max. Been a fan for many, many years, Max, back in the spectrum days, back in the way back days when you sort of reinvented what has now become GitHub discussions. How does it feel to have such an impact on I guess daily developer lives like you have?

Speaker C: You know this is a big reason why I ended up in this line of work. I started making websites in high school and then I thought the natural path for me would be to go to university and study computer science. And when I got there, uh, I realized that what I really love doing is making things for other people and studying computer science at university. At least for the first little bit, is not very much about making things for other people. And so I got very frustrated very quickly and I actually left within three months because I was like, this is not at all what I want to do. What I want to do is make things for people. And so that's always been what's driven me through my open source work, through my startups. I like making things for people, I like getting things into people's hands and having them use it and then get something out of it. Uh, and so I guess the answer to your question is I think it's really gratifying. It's also humbling in many ways. Some of the things I've made in the open source world are used by millions of people, you know, and so it's quite humbling that this guy from Austria was able to influence the world in that way.

Speaker A: It is wild how one person can change so much. Uh, I think that's the case of a founder and the case of a maker, I would say a builder, a maker, a founder. It's kind of wild to be in that kind of position. You come from a different, like before Spectrum was a thing that you were already doing things like style components, react boilerplate, what were some of like the earlier inputs and I would say like small but big wins that you've had that built you into the person that could be part of the team that built Spectrum, that got acquired by GitHub, et cetera, et cetera.

Speaker C: I think people look at my career and they see all the successes, right? They see style components, they see Spectrum, they see stellate, they see, that's what I see OpenAI. Now, um, what people don't see is all the things that didn't work, right? And so I think really my story is one of making lots of things like in the open source world, right? I made React boilerplate early on that got really popular for a while and then I made style components that got really popular for a while. And both of these open source projects are wildly popular. Top 200 projects on GitHub by stars. All this, lots of, lots of usage really changed the way people think about React and developing applications. What people don't see is the 298 other open source repositories that I've made on GitHub that no one has ever heard of or used because they didn't solve a problem that other people had. And uh, I think my story is one of making lots of things and then some of them ended up working more by chance than on purpose. Um, but really it was a matter of making lots of things and I was making lots of things that were solving my own problem. Even early on, before React Bottle played in any of my open source projects became popular. The reason I even started making things open source is because I got really annoyed when I had to solve the same problem multiple times. I would be building something and I'd be like, ah, ah. Back in the days, it used to be, now I have to configure webpack again. And I don't know if you were around in the 2015 Webpack Days, 2016 Webpack Days.

Speaker A: Oh my gosh, yes.

Speaker C: Uh, thousands of lines of code of JSON that if one little line was a little bit wrong, the whole thing would fall apart with an error message that told you nothing about what was actually wrong. It was really hard to debug. It was a whole mess. And so the reason I started making open source projects is because I ended up solving these problems over and over again. As I was building things, I was like, that's really annoying. Let me just go put this on GitHub so that I can reuse it. And some of those things, like React boilerplate ended up, turns out that other people also have those problems and also wanted a solution for it that they could just reuse without having to solve the problem themselves. Um, but that was really more by chance. What I really started out with was just making lots of things that solved my own problems because I needed them, because I was annoyed by all the friction that I was encountering. Mhm.

Speaker A: What made you feel like sharing was the best way? Was it just the natural gravity of open source? I mean, because not everybody is in the software world and feels like, oh, I made this thing, I should just share it. How did you, how did that come to be your core thesis?

Speaker C: You know, my parents asked me the same thing. My dad for many years would say, why didn't you just charge everybody that uses stock components $1? You'd be a billionaire by now. Give him how many installs you have. And of course that's not how the world of open source works. Uh, but the sentiment is very much the same. Why would you share all these ideas that you have for free? Why wouldn't you charge for them? Um, and I think the answer is twofold. One, I've gotten so much from the community and I build upon the shoulders of giants that I think it's worthwhile to give back and make sure that my ideas also contribute back to the ecosystem. That's the sort of beautiful altruistic motivation, but it's also a very selfish motivation. I really benefited from the things that I made becoming popular. And of course if I had charged for styled components or React boilerplate, if I had charged for my open source projects, nobody would have used them. Right? There's no commercial, uh, there's no ability to directly commercialize these projects, but by virtue of me making these projects and then becoming really popular, my entire career is basically based on these open source projects and who I became, uh, because people know me as the person who made them, but also because of all the people I met and all the input I got and all the learnings I had from making them. And so I think I've benefited indirectly very, very greatly through sharing these ideas and sharing these projects. And I wouldn't be where I am or who I am if I hadn't done that. And so there's an altruistic motivation. But I think it's also worth saying that there's very much a benefit that I've gotten, a very selfish benefit for my own career, my own life and who I've become through sharing these ideas and projects. And so I think it's that combination of I get to help the world and also in return I get rewarded by the world.

Speaker A: Kind of jump into present a little bit on that same note. Uh, do you feel that that's still the same case given the state of AI being so impactful to my, and I'm sure yours, considering where you're working at every single daily life? Like I'm a daily active Codex user. Just to be super clear, I love Codex. Um, do you feel like that same thesis carries to today's world where sharing is the best way to do everything? Or do you feel like open source might even be changing because you know the term has been thrown around? Code is so cheap now to generate. I think products are really hard to create, but the code is fairly easy to generate. Is it good, is it bad that will over time play out? I'm pretty much a, uh, maximalist at this point. But, uh, do you feel like that core thesis you had back in those days of style components, et cetera, carries to today's present world?

Speaker C: I think yes and no. I think the ability for you to help the world still exists. I don't know that the shape of that help necessarily is in code anymore. Um, it is in some ways. Right. Like OpenCloud recently became the most popular open source M project of all time. Uh, and that very much is based around code. And so there's still a lot of code to be written that's valuable, that can be shared, that will impact the world. But I totally agree with you. I think code has become much cheaper to create. And in fact, in many ways, what matters more now is the abstractions that we create. And who knows if those are going to matter a year, five years, ten years from now. You know, in the style Components days, part of what made style components so popular was that we found an abstraction that composed together really beautifully and worked exactly the way that you would think it would work. Every time users thought, oh, I need this thing, Let me just go try it the way I think it should work, it would always work. That was part of what made Style components so successful. People tried it and they went, oh, this works exactly the way I would think it would. That's great. I don't even need to read the documentation. I just know how to use this because it just makes sense. Um, but then making that abstraction work was really, really difficult. That was a lot of work on our part to make that happen. That magic, that simplicity, wasn't simple to create and took a lot of code for us to figure out. Now, I don't know that AI is at a point yet where it could create styled components from scratch if we just gave it the abstraction, but it seems inevitable that it'll get there if it's not there yet. And at that point, abstractions are the only thing that matters because they make a big difference in how people use it. But then beyond that, if AI gets even better, do abstractions even matter? Or are we just going to be programming in English? I don't know. But I know for myself. Since I joined OpenAI, uh, in December, I've shipped many, many PRs here, uh, and made lots of changes to ChatGPT. I haven't written a single line of code. I'm just managing Codex agents now, you know, and I know many people in the industry since December have had much of the same experience, and that's crazy.

Speaker A: Yeah, it's so wild to that. For a while there, it was taboo to say we're using an agent. You know, it was actually expected because, like, we want it to complete the line, we want it to complete the thought. We didn't want it to have the thought, so to speak. And, you know, for me, a lot of things changed back in September, I want to say, last year, and a big swing when Opus 4. 5 came out. And then obviously, the advancements you all made with Codex and GPT, I think it was 5.4or maybe 5.3, I think is what it was in December. And now 5. 4 is just so revolutionary in terms of how it helps me think. And yeah, I mean, I can probably go on deeply about that, but a lot of things really change for everyone. And I think we're in such a uniquely different world here today at the end of March 2026 than we definitely were at the tail end of March 2025. Like, it's dramatically almost like a 180 in terms of difference in how he code or not code.

Speaker C: 100% agreed. I still think even if code is not the mechanism anymore, it is valuable to provide things to the world, whether they're ideas or solutions to problems. I think that is always a valuable thing to do, both for the world and for yourself. Uh, I just don't know that the shape of that will be code anymore. Sometime soon.

Speaker A: Yeah, I don't really know for sure how true that is though, because I'm building something, a new podcast platform for ourselves here at changelog because we have a need for a cdn, we have a need for distributing our podcast, and I've got a couple other podcast ideas to bring back into production. That the current state of our platform is. Is not bad. It's great. It's a really great platform. M. There's just some challenges that I'm trying to solve and that's actually still really hard to build. To generate a little bit of code to do a function or to do a feature is fairly easy to do with the good spec, like you said, uh, coding in English. But to turn that into a cohesive product that's usable by one person is somewhat hard. And then turn that into something that's usable by many people I think is still. It's still hard. We're not writing the code as developers anymore. We're sort of directing it, but still yet building the things that are made from code still hard. Like, I still have to tell love it or leave it Codex, but I still have to tell Codex how to. How to navigate TypeScript and Node. Like, there was so much wrong with the type, the type, um, interface in my application. And I don't think it's me because I told it. We're using types of, uh, TypeScript and we're using Node JS24 and you know, we're using Node next and we're using all these different things to make TypeScript play well with Node. There's still that problem there. It will get more and More solved. But there's still this required incumbent knowledge to direct these things, like a rando who doesn't know about developer landscapes or different trustworthy platforms like Node has been for so many years. Sure, I know BUN is amazing and it is up and coming, but it's not quite there yet to Node's level. And the people behind Node are very smart and very articulate with how they direct Node to be a runtime, not a compiler, which I respect. And so there's still this dance from typescript to Node to platform to running. It's not just prompt and magic.

Speaker C: 100% agreed. I think at the same time, the, the trajectory of where things go is quite impressive.

Speaker A: 100%.

Speaker C: And the question is just if and when it asymptotes, right, will it slow down or will this trajectory continue for a long time? Uh, I certainly feel the difference from even September, December, as we're talking about now, to today. Uh, it was a wild jump. Uh, and it just keeps getting better and better. Uh, and so I do think that abstractions, in fact, I feel like most of the time that I spend now is spent on reviewing the abstractions that the coding agents create. Just like you're saying with the type interface, I'm really making sure that it's less. Ryan Florence is a saying of like, uh, he's always said this. He said he wants to draw the right boxes and then whatever's in the boxes is fine, but he wants to draw the right boxes and he wants to make sure the boxes are drawn in the right way and connect together in the right way. And I feel like that's what I spent most of my time on now, the implementation of it. I review much less than thinking about the overarching architecture and the boxes that exist and how do they interface with each other, how do they talk to each other? Is that actually the right level of abstraction? Or should we be solving this problem at a different layer, at a different level, in a different way? Um, that's most of the time that I spent thinking is actually more about the architectural overall system versus the individual lines of code. Like, is this if statement correct? Mostly those are correct. But the abstractions I agree with you are currently where I spent most of my time.

Speaker A: I did want to chase a couple of those, uh, rabbit holes, so to speak. But I do want to go back into really where you came from. I know we have the present day and we're quite excited about it. We could probably gush deeply about it and you, uh, get two AI maximalists uh, in a room and they'll talk for hours about what they're working on and how cool it is and whatnot. But back in the day of Spectrum, when you all invented this, this new way to give coding communities, discussions and community, um, it was wild to watch your progress because help me understand if this is correct or not. Is Spectrum that you all built the same as the Spectrum Podcast network? Was that a spin off from that or the same team? Help me clarify that before we go deeper.

Speaker C: You know, that story is actually a great example of what I was talking about earlier, because the way Spectrum came to be was that Brian and Bryn, my two co founders, they were running this podcast network called Spec fm and they had, I think four or five podcasts at the time that they were running as part of Spec fm and they were using Slack at the time as their community platform. They were trying to connect their listeners together. And so they created the Slack instance. And eventually the Slack instance grew to tens of thousands of people. And Slack came to them and said, uh, we can't do this. Either you pay us or you have to go find someplace else. And the payment required would have been like hundreds of thousands of dollars a year, not money that a podcast network that wasn't run for profit really, uh, had anywhere laying around. And so they were like, oh no, now we have to go move somewhere else. But if we're really thinking from first principles about the kind of platform that we want our podcast listeners to be connected through, we want something that other people can find on the open web. We don't want it to be a closed platform because, uh, we want those conversations to exist and for people to be able to find them and contribute to them. And so that didn't exist. You know, there were sort of community forums, you know, the classic sort of stayed old forum style conversations. But there wasn't really an equivalent to a Slack that was public. And so that's what the idea of Spectrum was born was. Can we take a public community forum and make it feel more like a real time conversation like Slack and yet still have it be search indexed, have it have the benefit of the open web, have it have the searchability and the findability of the open web? And the reason I got connected to them and this circles back around to what we're talking about is because they were using style components for building their first version of Spectrum and they hid some kind of a bug that I don't even remember. And Bryn just DM'd me on X on Twitter and I was like, hey Max, we hit this bug that I think is a style components bug. Uh, have you seen this before? And I had known of Brent and Brian for a long time and I'd been an avid listener of that podcast. And so I replied back and I was like, hey, just give me access to the code base and let me take a look. I will go see if it's a bug in style components or something with how you're using it. I'll go figure it out. And when they gave me access and I realized that they were building this community platform, I realized that that is exactly what I need for my open source communities, because I was having the exact same problem. I had made REACT boilerplate at the time, which was used by many people and then style components, which was used by many people. And part of the challenge of managing large open source projects like that is that the maintainers end up being the sole supporting pillar that answers every single, every single support request gets answered by them, every single bug report gets triaged by them, every single incoming contribution gets charged by them and it ends up being a huge volume of work. And sometimes other maintainers step up. And in the case of style components and Rick Boltplate, both, I was very fortunate to have some, some people, some really great people step up. But overall it quite quickly becomes a very overwhelming amount of inbound interest. And I was like, oh, if I can just take this community platform and I can get everybody that uses style components to use this community platform, then they can ask questions and other people who use style components can answer the questions instead of me having to answer or us maintainers having to answer every single question. And so I realized I want this, I want this community platform to exist for my open source project set. I have the same problems, I want the same solution. And so I ended up joining them and we end up co founding Spectrum. And that's really where it all started was from their podcast network and them using style components and then reaching out to me. And I think that's a great example of a case in my life where if I had never made style components, I would have never been connected to Bryn and Brian and so the world hopefully greatly from me inventing style components. But in return I got this great journey of founding a startup with two of my now, uh, best friends and had lots of learnings and growth through, through that, that really defined my career.

Speaker A: Well friends, I'm here with a good friend of mine, Michael Greenwich, founder and CEO of Work OS Michael Auth for agents. I feel like this is burgeoning. It's, it's kind of happening all of a sudden. What's the state of the world for offer agents?

Speaker D: Yeah, it feels like author agents is one of those things that nobody, um, knows what it means, but it's very provocative. Everybody wants to talk about it. Practically speaking, I think there's two things here. The first is when you say author agents, you're talking about how do I get the data into an agent that it needs to be able to do its job. And for that we built something called Work Less Pipes. It's actually more of an integrations product. It helps you take your agent and connect it to your customer's Google Drive and connect it to Salesforce and HubSpot and connect it to Slack and all this other stuff that they're going to use and do it in a way that's safe and secure and managed. That's one type of auth for agents kind of data access off. The other type is actually authorization. It's like permissions for what the agent is going to go do because you connect it to all these systems. But then you say, what capabilities does it actually have? How can I restrict the agent behavior so it doesn't go off the rails and go do a bunch of crazy stuff? That's a lot of stuff we're building today. We don't have a product announced yet for that, but we've been working on it. The third, I would say is probably the identity layer for agents. How do I identify an agent by itself? Name? You know, that's really coming from the enterprise identity systems that are out there. If you look at Microsoft and Microsoft's Entra Agent id, they're doing a lot of interesting work there. There's also expansions to OpenID, Connect and skim for agents. We're building all of this into the work OS platform. So if you're looking for an identity stack that'll support agents again, future proofing, Work OS is a great place to go, but it's changing really quickly. You know, none of us were talking about open and claw, uh, you know, like weeks or months ago. Um, and that's a new paradigm I think we're going to see not just within consumer software, but in the, in the enterprise too. So it's an area of very, very rapid development.

Speaker A: Well, it makes me think about agents versus people, not negatively, but this world where we'll have more agents than people.

Speaker D: You know, today, if we have 7 or 8 billion people on the planet in the future, we're still going to have trillions of agents going off and doing things. And so the challenge around identity, uh, authentication for agents is actually significantly bigger than just how people interact in the same way. Like, you know, GitHub, uh, isn't going to work super well for agentic coding because you'll have so much more code getting written. The same is true for identity and permission and logging systems when agents start doing stuff with it. So we're building for that future today.

Speaker A: All right, friends, the next best step is to do what I've done, which is use Auth Kit, okay? That's how I authenticate my CLIs, my APIs, my applications, all that good stuff. WorkOS.com is where you go try it out today. A million users with Auth Kit for free. You can't beat that deal. It's. It's literally free again. Workos.com, try it out today. What was your, uh, so you came in through stock components and a, uh, bug check, so to speak. You became a co founder. What was that initial, I suppose, conversation like, hey, we're starting a company, do you want to join it? Or was it like, hey, you are joining, you're all making a company. Can I join it? You know? And what was your role in the company to. To sort of begin building the product?

Speaker C: I think it was all very fortunate circumstances. Bruno, Brian were building this platform, but they initially, I think we're really building it just for Spec fm, which is why the name ended up being Spectrum. It was meant to be a play on words.

Speaker A: Yeah, that's why I even messed it up initially when I asked that question. I thought it was called Spectrum fm, but then I was like, maybe not. And so you corrected me. So even in my own brain, I'd had totally the podcast network Spectrum in my brain.

Speaker C: So that is exactly where the name came from. Um, and then I think partially because I came in and I was very excited about using this for other purposes, and partially because they realized maybe other companies could also benefit from this. Other people could benefit from this. Um, I think they sort of decided, hey, maybe we should actually try to make this a company. And then they were both designers, uh, Bryn a little bit more than Brian. And they had sort of coded together. They were designers, but they knew how to write code. They were designers who coded. Which I know back in those days was a big discussion, should code or not. Uh, which I think now with coding agencies very much, that really should no longer be a discussion. I hope we no longer have to talk about should designers code? Because all designers cannot code, um, at least prototypes, production code, we'll get there. Um, but anyway, and so they were both coding, but they weren't necessarily engineers. And so when I came in and I started fixing these bugs, um, they I think saw a need for having somebody technical in a company in order to build things. And so I joined as the co founder and cto. And then for the next year and a half we built out this community platform that lots of open source projects mostly ended up using to connect their users together. Before we got acquired by GitHub and it was just us three in our bedrooms uh, hacking together, um, this community platform that we loved.

Speaker A: Did you take on any funding or seed investment? Ah, how did you sustain Initially we

Speaker C: had raised a small uh, pre seed round that sustained us for that year and a half and in fact um, part of the story here is that we got the seed funding that really allowed us to explore this problem space. And then a year in we had built something that lots of people were using but we hadn't really found a good way to build a business out of it. We realized there's really a need for this. Lots of open source projects next JS style components. Lots of open source projects especially started using Spectrum to connect their users together and foster conversations. And so our initial thesis I think of people want a community platform that's publicly available, search indexed. People can find answers after they're given, um, but still want real time conversations that happen somewhat synchronously. That gives more of a sense of community. I think that thesis was proven out. Um, we just didn't find a way to build a business out of it and we tried a few things and none of them really worked. Um, and so then when we started talking with GitHub, it seemed like a very obvious fit to go do this thing at GitHub afterwards because we just, I guess if we had really tried we maybe could have raised another round. But really we realized there wasn't a big business that we built here unless we were going to do ads, which we didn't want to do. Uh, uh, and so we were like, we couldn't find a business model that would work. And so then we said maybe we just gotta do this as part of GitHub.

Speaker A: Yeah, that's interesting. Definitely don't wanna do ads in a thing like that. I mean there's a temptation to. But that becomes a version of a lifestyle business in a way. Uh, but then, you know, I'm curious how GitHub came to be. Was it just that you had natural gravity and they came to you. Was it that you knew somebody who knew somebody and they're like, hey, we need issues isn't enough. We need what has now become discussions. How did that conversation uh, initially play out?

Speaker C: Yeah, there's this other guy named Max, Max Schuening, whom uh, Brian and Bryn were well acquainted with, who was at GitHub at the time working with Nat. And I think just a natural conversation spawned from the fact that they saw lots of their open source projects that were hosted on GitHub using Spectrum, uh, to foster this sense of community. And um, they wanted to see if we can bring part of that to GitHub. And we ended up through uh, uh, uh, lots of iteration and figuring out what would work at GitHub because doing something at a big company is very different than doing it as a three person startup. Um, that turned into GitHub discussions, uh, about a year later that now is used by every single repository pretty much on GitHub.

Speaker A: So the initial conversation wasn't, hey, let's just turn this into. They didn't have a preconceived idea. They just were like, y' all doing cool stuff. We eventually need what you're building. Let's figure it out. That, how do. That seems a little ambiguous.

Speaker C: Yeah, no, that was very much what happened. They, they, they saw that there was a need for this in the M. In, in the, in the community and, but there wasn't like a preconceived idea of like oh, exactly. Should be a tab on repositories that says discussions and that each discussion should look exactly like this. Like that preconceived notion didn't exist. And in fact um, for a while we explored um, whether we could bring, if you think about the Spectrum was a sort of combination between Slack and a traditional forum. It was real time but also had threads. People were meant to chat um, live. If you think about GitHub discussions, it's not exactly chatting live. Right. It doesn't feel like Slack. And so in between those two steps there was a lot of exploration on GitHub that we did around can we bring real time chat to GitHub at GitHub Scale? Um, or do we need to do something a little bit more static? And so we explored those directions for a while before we eventually settled on the static direction. And quite frankly uh, a lot of the difficulty at GitHub scale at the time I think had hundreds of millions of users probably doing real time at that scale is infrastructurally really, really difficult. Now maybe there's a little bit more tooling for it and there's a little bit more vendors that you could use and sort of expertise, but at the time there really wasn't. Slack was a relatively new thing itself. Nobody really figured out how to scale real time that well at that scale. And so for GitHub to take a bet to build all this real time infrastructure for what was a minor part of the platform ended up just not being worth it, uh, for them, I think. And so they ended up deciding to go down the static path and sort of the more. Which now turns into good discussions and it's independently very valuable, but it's not the same as a Slack or real time chat would have been.

Speaker A: Is there any part of you that's a little bummed out about the. I mean, not exactly the outcome as it is today, but the outcome of the product because you all had a particular need, you came to it because you had a particular need. It was uniquely different to combine Slack and a forum to have both static and real time information sort of moving faster. That's not what GitHub discussions is, and that's okay because that's not what GitHub needed necessarily. I think there could still be some cool real time there, but my gosh, the maintainer burden on that would be uh, through the roof and so many people would probably just quit GitHub completely if that were the case. But is there any part of you that, uh, or even maybe the three of you, if you could speak for them, um, that were chasing this particular product direction and then the acquisition slash, Aqua Hire, change the trajectory while it m. Gave you more Runway, gave you more opportunity, and you are where you are because of all this. Did the product story change so much that you were like a little bummed about how it turned out?

Speaker C: For sure, for sure. Uh, I think I had lots of complex emotions at the time that I don't think I actually processed, uh, as well as I could have. It was very obvious that Spectrum as it was couldn't have been a really big business. Maybe couldn't even have been a business by itself. So I think by default the sort of angle that we are taking on the market, um, couldn't have worked. And then for what GitHub needed, GitHub discussions made total sense too. Um, and yet, like you say, there's definitely a wistfulness that the original thing that we spent our blood, sweat and tears on didn't work. And in fact there's players now in the market like Circle, who've built very successful businesses around communities, they took a completely different angle and they focused more on professional communities. They focused more on um, what should I call this, like online course creation. They focused more on sort of those sort of more commercially viable communities. Um, and they've built what from the outside looks like a great business around that. Um, but it wasn't necessarily what we were interested in doing. Right. We really wanted to connect these communities together that were, that naturally emerge that exist around these non commercial projects. And it's difficult to build a business around ah, non commercial projects, uh, as many people know. And so there's a wistfulness, um, but also I'm very happy with how it all turned out and how my life turned out. So uh, we've jokingly, Bryn Bryan and I have jokingly talked about buying Spectrum back uh, uh, from GitHub, um, but it was never more than jokes, uh, because we do find ourselves, and I think this is also worth saying we do find ourselves still having that need. I think actually in some ways WhatsApp groups ironically have become maybe the closest replacement that the Internet has to a sense of community. Um, but other than that nothing really exists, especially nothing Search index that really creates and fosters a deep sense of community and belonging. Um, and so it's an unsolved problem. I don't know if those, maybe those things are at odds, maybe they aren't. Uh, maybe somebody will eventually solve it. But um, it certainly still is a

Speaker A: need that people have that would be interesting to buy it back. The one person that I know who bought something back from GitHub was John Nunemaker. Do you know John Nunemaker by any chance? I know you Both worked at GitHub probably at the same time. I don't actually John Nunemaker, um, but he had worked at GitHub similar to you. And the way in was early GitHub like when it was just Chris and Tom and a few people, it was super early GitHub and they came through an acquisition of their company and then on his way out in his exit, he left with the company. He came in getting acquired and that was kind of interesting was that he was able to take back what he had come in with. I think that speaks to uh, a lens of GitHub that many people don't really think about is the generosity or the flexibility to do something like that. I'm not sure how serious like you said, you just said it is joking but I bet they would because it's just IP sitting in their books that we have to keep maintaining this. At some point they probably own the Spectrum IP the brand and things like that because they actually bought it. They're like, you know what, we don't really need this. You know, sure, take it back. Here is it for basically nothing, you know, comparative to what they acquired you all for. That's something interesting about GitHub and what I know at least through John's story and I think maybe your story to some degree because I bet you they'd be generous and be like, here you go, go ahead, have fun.

Speaker C: You know, it's a fun circle back around to what we're talking about at the beginning. Uh, it, it is, it is always beneficial to give things to the world. Uh, it will come back around to you at some point.

Speaker A: Yeah, I agree with that. Gosh, don't be selfish. It's so hard to, to not protect yourself. But also that's like the easy button to do is to be selfish, but to be just sort of generous and open handed with the world. Uh, there's a lot that comes to givers versus takers. Like if you're a giver, a lot more magically just comes back to you than if you're just a taker only, you know, that's just. This is how I see about that. Okay, so take me into, you know what, what more important is to share about that Spectrum journey From Spectrum to GitHub. Was it a harsh reality check when you first got into GitHub? Was it uniquely different? Did it help you grow in certain ways? What, what really manifested for you when it came to three dudes building the thing in their bedrooms, as you said to getting acquired to now we're exploring more and building out what has become GitHub discussions.

Speaker C: Honestly, I had great fun working at GitHub. I actually really enjoyed it. I think contrary to some other acquisition stories, uh, working on the product that I used most every single day was really gratifying. That is used by many of the people that I know and love. And so I really, there were ups and downs as there always are and as they're also word spectrum. But for the most part I really loved working there. Uh, and years later with my second company when we were going down the acquisition path, I think that was definitely an important data point for me to know that these things can work out okay. Because often in the industry you hear these acquisitions and then the founders get grumpy and they leave and there's all this public feud that Sometimes happens. Um, but many of these acquisitions, they work really well, and people are very happy at the company that they go to. It, um, really just depends on where you end up with. And so we were very fortunate to be able to join GitHub at that time, and I had a really great time.

Speaker A: How did you go from your work at GitHub to eventually exiting and forming your next company? How did that happen? What made that transition necessary? What made it feel like good timing? What changed?

Speaker C: Yeah, after GitHub, um, I joined another startup called Gatsby that, uh, was building a static site generator. And we're sort of trying to build a cloud business around that. And, you know, they were a Series B startup and ironically, they had all the classic chaos that you've heard about of Silicon Valley startups. It was extremely chaotic internally, and a bunch of drama happened, uh, that, some of which eventually spilled out publicly. And so the company kind of quite frankly imploded itself. Uh, you know, when I was there, we had 60 people, and then when I left, we had 25, 30 people. Maybe. Uh, a new CEO was brought in. And then some years later, it got taken over by netlify and became a part of netlify. But that chaos and that drama was really kind of frustrating to me because I felt like Gatsby had all the right ingredients to succeed and was sort of stumbling in spite of itself. And so seeing that as an employee and not really being able to do much about it was, uh, felt very disempowering, I guess. And when I left Gatsby after that drama, I realized I had this idea in my brain that I feel like I could pull this off. I feel like I could build a company and the team without all that drama, that really enjoys working together, that really has a good time and gets along and just ships cool things that the world needs. Um, and I had this other chip on my shoulder from the Spectrum days where I really wanted to build a big business. I really thought I could build a big business. I have the ingredients in me. I just need to go put the horsepower on the road. Um, and the third reason why I ended up going back to finding my own service is I wanted to grow again. The Spectrum days were the days at that time where I'd grown the fastest out of all the times that I'd had. The, the pressures of building a company and all the different things that. That requires forces. It's like a pressure cooker for growth. And if, if I'm the kind of person I like to grow I like to get better, I like to improve myself, I like to be better at what I do and how I interact with, with the world and be better at understanding myself and all these things. And I do that every day. And being in that pressure cooker situation was like a magnifying glass upon how fast I could grow when I'm put into a situation where I have to grow. And so I wanted to go back to that. I like to say that as a company, companies are limited by the growth of the founder. And I think that's something that people who aren't close to founders maybe don't necessarily understand. But the really, really great founders, all of the really successful ones, when you talk to them you realize they're incredibly self aware humans. They know exactly who they are, they know exactly how they are received by the world and then they can play with that and they can integrate that. Having spoken with many of those folks, it really becomes very clear that they're all that really unifies them, that really ties them together. And I think that's not by accident. In fact I think it's a requirement of the job in order to build. And uh, when I say really big business I mean like a VC backed companies who are trying to become trillion dollar companies or billion dollar companies. Building a really fast growing hyper growth startup that is trying to swing big and go for home runs, it requires an immense amount of personal growth on the founder's part. And if that growth doesn't happen it's a limiter to the whole company. And so in a way founding a startup is a forcing function for you to grow faster or it was for me at least for me to grow faster than I'd ever grown before. And so I wanted to get back to that level of growth. I wanted to grow that fast. I know I feel my potential and I feel that I could really achieve something and that I could really figure myself out and figure out how I interact with the world. And so those are the three reasons why I went back to founding a startup. It was personal growth. It was feeling like I, I could build a company and a team that really I could build a team quite frankly. And then the third one was that I could build a big successful outcome.

Speaker A: Yeah, building a team is, is really much harder than meets the eye. I mean you, it's nice to have a network for sure, right. Or to be a giver like you have been an open source and to be seen as somebody that's will, you know, worth trusting or has a track record of uh, success. But building a team that's cohesive, that has similar attributes and similar moral direction even. Because there's a lot of things that break down a team that begin with morals. I think we're all pretty good people, but some people have uniquely different perspectives on life. The way they raise their children, the way they want to live in the world, how they think about money. All these things really get, uh, to the heart of a unique relationship or the relationship itself. To build a good team, what were some of the things that you did to either grow in that way or to learn how to build a team? M. What was the challenge there for you? Was it just easy?

Speaker C: No, not at all. Uh, not easy. It was definitely not easy. Um, I had a lot to learn to do that. Well, I think I will give you a very concrete example and then I will talk about the, the story. Um, maybe two years into my next company's journey, Stelli we had maybe 15 people at the time. It was, you know, a team spread across the world. And we were doing an off site as a, as a small leadership team, me, my co founder and our, our CEO Su, and we were looking around and assessing what, what isn't working at this company, why, how, how could we be better at being stellate? And the thing that came up as the number one challenge that we're facing is that people internally don't give each other enough critical feedback. We don't hold each other to a high bar. And when we looked at why that was, it was because of me. I grew up and I'm an introvert by nature. I'm a hermit, if the world would let me be. I actually get a lot of energy from being by myself. And I can present as an extrovert. And I've given HM lots of talks on stages, and I can interact with people. I'm a little bit of an awkward nerd, but not as strongly as people might suspect from an actual introvert. But part of being an introvert is that I actually really value human connections. I value talking with humans. I actually really enjoy that element of human nature. And so I find it very risky personally to give. I found it very risky to give critical feedback to people because it was always a chance that that critical feedback could lead to disconnection. Right? And so then all this effort that I'd put in as an introvert to establish this connection could now be reduced because of the risk of me giving critical feedback. And so I realized I am limiting the company. The culture of this company is defined by Who I am and I haven't worked through. I haven't figured out who I am and how I can interact with it, uh, with the world in a productive way where I can give critical feedback in a way that still works for me. And so I think building a team is really hard because it requires that level of introspection and understanding yourself. Otherwise, I don't think you can succeed in building a really great team because you have to understand yourself and how you interact with the world and then be willing to, to change yourself if you can, or at least gain freedom with yourself. And in my case, I'm still an introvert. I still think giving critical feedback is really risky. But I've come to understand that about myself. And I, through that, I've gained freedom with myself. And I now know, hey, this, this work isn't good enough. And I catch myself and I go, hey, you have to express this. And I now have learned tools for how I can express this in a way that makes it feel less risky to me. Um, and that. That makes sure that I feel comfortable doing it. And the reason I'm saying this is because I think that's why what you're saying is very true. Building a really good team is really hard, because building a team is really hard. But also the team you build is a reflection of yourself in many ways. And so you have to work on yourself and you have to understand yourself in order to build the kind of team that you want to build. And so that was really the journey over the four years of Stellative was really me figuring out who I want to be and Tim figuring out who my co founder, Tim figuring out who he wants to be. And through that, what kind of company we want to build and what kind of team we want to build. Um, and then the second thing I'll say is we knew that we had no idea what we were doing. Uh, we went into Stella and we thought we can do a better job, but also we knew we had no idea how to do a better job. We just thought we could go figure it out. And the way we went and figured it out is we got help. We talked to lots of people, and eventually we found sue, our eventual coo, who, um, had built many, many companies over the last 20 years and had tons of experience building really great teams. And I learned pretty much everything about both team building, but also about growing myself from her. And so a big part of it was feeling like we could do a better job, but also knowing that we had no idea what we were doing, and we would have to figure it out really quickly. And so how do you do that? You go find other people who've done it and you learn from them and you apply from their learnings what works for you. Yeah.

Speaker A: Ah, that's pretty wild. What, uh, what about this critical feedback? Can you give me some concrete examples of positive or what you learned about critical feedback that was so paramount to this change for you?

Speaker C: Yeah, I think the first piece was really understanding that, that I felt it was risky, and that's why I wasn't. That's why I was subconsciously not doing it as much as I needed to as the leader of a company. Um, and the second piece then was once I understood this about myself working with sue and working with my coach, um, on what tools can I have to feel more comfortable giving critical feedback? And one of those tools that I use to this day, um, is called the COINS framework, which is just an acronym for context, Observation, Impact, Next Steps, coins. Um, and it's a structure that you can use to give feedback that alongside making it about the thing and not about the person, means that feedback has a much better chance of being received well because it's coming from a place of genuine intent. And so to give you an example, context, observation, impact, next steps. It's like, hey, John, in the meeting we were in on Monday, uh, I noticed that you cut off Jack when he was trying to explain, uh, why he, uh, merged this PR that caused this outage. And what I saw on Jack's face was that when you cut him off was almost a look of disappointment or frustration. And I think it might have ruptured some of, uh, your, uh, connection and some of your relationship. And so I would really love it if you could reach out to him and check out with him and then, um, take, uh, a look at, uh, what. And then I would love to take a look at with you, what caused you to interrupt him, what feelings were you having? And why did you feel the need to cut him off before you finished saying what he was saying? And so you go, context is, what was the situation? Impact was observation is what happened. Impact is what impact do I think it had? And the next steps is, let's talk about what we do now. And so I didn't just say, john, you really messed up on Monday's meeting. I think you're an idiot because you cut off Jack, which immediately would have led to a very defensive posture. Lots of things wrong with that way of giving feedback. Um, and so by focusing it on the thing and not the person, and making it and framing it in this COINS framework. It ends up feeling, to me, a lot more comfortable to give feedback, redirecting feedback, critical feedback. Because I feel like, okay, I can express my thoughts in a way where it's really coming from a genuine place of I want us to be better, and I know that we need to be better in order for us to be successful. And so it's my job to give you this critical feedback, and I'm doing it in the best way I can. And so then if it doesn't land and it leads to this connection, then that actually isn't as harsh to me anymore because that's my role as a leader. I have to do this, and we have to get better together. And I'm doing the best I can at giving this feedback. And then if it doesn't end with you at some point, there's only so much responsibility I can take for our relationship. Um, and so this is a very concrete example of something that I learned that I worked on that now means I'm much more comfortable giving, redirecting feedback.

Speaker A: Yeah. I mean, it's so ingrained in you, it seems that you were able to just spell it out literally for us. I like that it's a cool framework, and, uh, it seems like it's become, uh, embedded in the fabric of who you are today, for sure.

Speaker C: Uh, at Shopify, where I was last, I noticed that our team had some of the same tendencies to not give as much feedback as we needed to. And so I introduced this framing that I learned from Kaz, one of the leaders at Shopify called say the Thing. Uh, because I really wanted to encourage people to say the thing. It's really, really important to the success of a company and of a team that people say the thing to each other. And so people feeling comfortable doing that is a key unlock in making a better team. Uh, and so I've run training sessions, and I've taught this framework to many, many people now.

Speaker A: Yeah, it's kind of wild how that's become that close to you. How pivotal was you learning that principle when I believe you said it was you and your COO kind of discovering that it was you being the bottleneck, you being the challenge. How did that change things? Because you said that's when you discovered it and then you implemented. I'm sure you did. How did that change the fundamental shift in not just the. The company itself and how you collaborated and worked together, but ultimately the product you created? Because now you can work better together.

Speaker C: We got much better at everything we did much faster because I was giving feedback to everybody at a higher. More often, uh, more of the things that Steliq did across all of our departments ended up going, ended up happening in a better way and faster. And so I think the company probably felt the same to everybody, uh, before and after. I don't know that anybody could have pointed to, oh, that's what changed at that moment. I don't think it's one of those things where it's like, oh, people in hindsight are going to go, oh, that. I don't know what happened in April of whatever, but something changed and it felt different. I don't think it was anything like that. It was a much more gradual change that I think in hindsight made a huge difference to our performance, which is like a very businessy term, but to the way we did. Um, but it wasn't like a. Everybody's going to point to that moment as that big, pivotal moment where everything changed. It was a much more gradual change than that. And also it was one of the many, you know, this is one learning of many that I have, um, about myself, about how I interact with the world, about how I want to build teams that I've had over the course of building this team. And so it's all these little tweaks as a founder that you have to make over and over and over again, and it's kind of relentless, honestly. Uh, you have to make these tweaks or otherwise your company won't succeed. But like I said, I love that I'm. I, I m. Want to be better at being myself. I want to be better at interacting with the world. I, I love what I do. And so it, it, it's relentless. But I, I love it, uh, you know, and, and so I, I really enjoyed it.

Speaker A: Well, you must have done something right because you were beloved. Ch near zero. Lots of customers trusted you. You got to a lot of money in the bank. Ultimately, you were acquired by Shopify, which we could talk about that story. But whatever you did worked, whatever you did from a product standpoint and a company standpoint, worked to build something that the community, uh, used. Can you talk a bit about what Stellate is and what it did? So there's some context that we've been talking around it and mentioning it by name, but not really contextually, like since we're using the Coins framework, but just using the C from that. What, uh, exactly was Stellate? What took you into this? GraphQL success, this caching success. And uh, ultimately what led to this acquisition? Why did it make sense?

Speaker C: You know what, it all started actually with Spectrum, when, when Bryn Bryan and I were building Spectrum, we were using Firebase at the beginning and it at the time really didn't scale for what we were doing. It was, it was breaking all the time. The security rules were a nightmare to manage. It didn't scale to the number of connections that we had. It really didn't work at the time for, for what we were trying to do. And so we knew we needed to build our own backend for Spectrum. And so we knew we needed to build an API. And we had heard of this thing called GraphQL that Facebook had released sometime before that made um, APIs that made it much nicer to use APIs on the client. And so we decided to go, we tried it and then we really liked it and we decided to go all in on GraphQL and Spectrum. And so our entire API Spectrum was a GraphQL API. And you know, when companies acquire other companies, they want to make sure that they don't buy any liability. And so when GitHub acquired Spectrum, they did a big pen test with one of the world's leading pen test agencies where they put eight pen testers for a week to try and hack Spectrum because they wanted to make sure that when they acquire Spectrum, they're not acquiring a data leak. Right. Uh, and so honestly, Bryn Bryan and I were, excuse my language, shitting our pants, uh, when they said that they were going to do this because we were just three dudes sitting in our bedrooms building this product as fast as we could to try and make something that people wanted and then when people wanted it, to try and not have it break. And so it's not like we had security people on staff, it's not like we had security experts who really knew what they were doing. And so anyway, GitHub went, these pen testers went and they, they tried to hack Spectrum for, for a week or eight days, I don't remember. And they came back and they didn't find any major security vulnerabilities.

Speaker A: Wow.

Speaker C: And I actually largely credit GraphQL for that. And it's GraphQL in combination with uh, uh, actually Vercel, funnily enough, because we weren't doing our own hosting, so we weren't managing aws, im, you know, access anywhere. We were just using Vercel and auto deploying from our repository. And so all of that was managed by them. And the second piece was our API. We were using GraphQL and so we had just made sure that in every single graphQL query annotation there had to be an access check. And the access check had to be something like if user is not an admin of this community, they cannot take this action, return or throw an error unauthorized. Right? That's it. That's literally all we did. We just made sure that every single query and mutation had an access check. And not all of our access checks were perfect. They found some issues with moderators of one channel, of one community's channel could moderate another community channel or something. They found some minor sort of access, uh, checks that weren't quite right but weren't dangerously wrong. But other than that they didn't find anything because everything had at least an access check that made sure that when you were accessing data, uh, you were actually allowed to access it. And so I actually largely credit ironically, GraphQL with uh, our security posture. Because our security posture basically consisted of use hosted providers and then have access checks in every single create mutation, which I know sounds ridiculous to any real security people, but actually worked well enough for the scale that we were at. And so I was a big fan of GraphQL from that experience. I enjoyed using it, uh, I enjoyed building the API, I enjoyed using the API and then the fact that the security aspect was really nicely solved, uh, meant I really enjoyed it. And so one of the big challenges we'd had though at Spectrum was as all these open source communities started using it, our traffic skyrocketed and I'd chosen this database called RethinkDB that was a startup that was building this big database. And the big selling point of RethinkDB at the time was that it uh, was a database meant for real time. So any database query, you could put changes at the end and you would get a real time feed of updates for that database query. Unfortunately, while that was advertised as one of the core features, it was uh, not built in a very scalable manner. And so as we were exploding in traffic, our database started falling over all the time. Literally twice a night I would be paged because our database server had gone down and I had to restart our database, uh, to fix it. It was like a nightmare. And so while this database was crashing every night and I got paged and woke up, I realized we were going to have to switch database. We could not keep this database, we had to switch to something else. But that was going to be a major project. And so I was like, well, how do I. Is there a band Aid fix that I can put on top of this so that while we're switching out the database, we're not crashing every day. And the thing we ended up doing was we put a cache in front of our crash because of course I hit the database.

Speaker A: Let's cache things.

Speaker C: Exactly. It's the obvious solution. And also our use case was very public and read heavy, right? It's a public forum. All the data is. Most of the data is public anyway. 99% of our traffic is reads, there's very few writes. It's perfect for caching. Now, unfortunately, nothing for graphical caching existed at the time. Even though, ironically, everything that graphical clients do is really fancy caching. If you look at how graphical clients do and why they work so nicely on the client, it's because they do a bunch of really fancy denormalized caching that works really well. And so in my head I was like, why can't I just take Apollo client or Urkel and put it on the server and have a cache for everybody? But that didn't exist. And so I built a really shitty version of this at Spectrum. Like a really rough, like just match the query and then return the same JSON like really rough Redis based version of this caching. But in my head I always had this idea like, this has got to exist. You can cache GraphQL really smartly and it has a great impact on the client. Surely you should be able to do this on the server. And so then years later and I talked to people about this and blah, blah, blah. And then years later a common friend of ours, um, pinged me and he was like, hey, my friend Tim has built this prototype of a GraphQL CDN. Isn't that what you were talking about all these years ago that you needed. I think you should go talk to him. And then I had known of Tim, but I never met him. And so I met him. And through that we decided to found this company that eventually became Stellate. And what we were building was a GraphQL CDN, a GraphQL ishcache that took many of the same ideas that GraphQL clients have around caching, but brought it to the server, um, which has its own set of challenges and edge cases and difficulties that we realized over the next four years. Um, but we built what I honestly think still to this day is the best API cache on the planet. Now it only works with GraphQL, but there's no way any cache can work as well. Any API cache can work as well as ours. Did with GraphQL, there's no way you can build a REST level cache that works as well as that. That works generically. You can build custom caches, of course, as lots of people do, but you can't build a generic solution that works as well as our Solution did with GraphQL. For various reasons.

Speaker A: This episode is brought to you by our friends at Notion. You've got a coding agent that writes solid code, but when you point that coding agent at your actual project, the specs, the roadmap, who owns what and is guessing, the smartest agent gets stuck without the right context and the right tools. That's the gap that Notions new Developer Platform closes. With the recent launch of custom agents, Notion became the collaborative AI workspace where teams and agents work side by side. And now their new developer platform is turning that workspace into infrastructure developers can build on. So here's what matters. There's a CLI called NTN Notion and that authenticates in one one line. Then you have workers, which are Notions hosted sandbox of your code, no provisioning infrastructure. You write it, deploy, you're done. And then you build on any tool your agents need with the predictability, parallelism and the custom logic MCP cannot deliver. And because the workspace and the platform you build on are the same thing, it's built for teams from day one. Permissions and governance. Governance baked in. That's agents that actually work alongside your team, not in some single player sandbox. Uh, okay, good. Next step is to learn more about Notions Developer platform today@notion.com changelog that's all lowercase letters. Notion.com changelog to try notions Developer Platform today, when you use our link, of course you are supporting this show. Once again, notion.com/changelog what was the secret sauce? Can you spill those beans or is that part of a.

Speaker C: No, no. Um, okay. Ah, so part of the magic is that GraphQL requires the client to do something called field selection. So instead of just hitting an endpoint like Product one, to get the product one's data, you have to send a query. And that query encodes exactly which fields the client needs. So it'll say of the product with ID1, I need the ID, I need the title, I need the price, I need the description, I, uh, need, um, whatever is in stock, I need whatever images. For each image, I need a URL. You really have to do this field selection. What that means is that at the caching layer we can understand exactly what data the client needs and what data we have in the cache and match them together really intelligently. And so we ended up building this thing called partial query caching, whereby let's say you fetch a product, let's just say it was a product, and then of the product, you fetch the list of reviews, and then of each review, you fetch the author data. Our caching layer could understand this. And if we had the author data of the review in the cache already, let's say it's the user with did1, we could match that data. Partial query caching, we could match that data to the author data and then send a request to the origin that only fetched the product and the reviews that we didn't have in the cache, but wouldn't fetch the author data again. And so we would, at the edge, dynamically split apart the queries into all of their individual pieces, products, reviews, users, the authors. And then we would cache each part individually. And then when a new query came in, we would look at everything we had cached and we would go, okay, of this data that this client needs, what do we actually already have in the cache and what do we need? And then we would only send a request to the origin for whatever piece we didn't have in the cache yet. And then on top of that, we could stream back all the data that we had in the cache already to the client, because GraphQL clients support this. And so we were a completely transparent layer that sat in between the graphical client and the graphical server. And all you had to tell us was of the product. You can cache the title, the description, and the photos, but you can't cache the price because that's dynamic. And you can't cache the availability because that's dynamic. And you would only basically ever get requests for the product availability and the product, um, and the product price and then everything else we would try to keep in the cache as much as we can. And so we enable people to get to really, really high cache hit rates with very, very little effort, because our cache was natively built on GraphQL. And in fact, if you're listening to this and you're thinking, I need this right now, stellate still exists. It got bought by an agency called the Guild, and you should totally go use it. Uh, it works amazingly and they've done a great job maintaining it.

Speaker A: Yeah, that does sound pretty cool. But only if you're using GraphQL. Is GraphQL still popular? I feel like it's kind of like, not popular. It's been fraught with challenge. What's your take on the state of GraphQL as a tech you should pick up today.

Speaker C: Yes. What I just told you was the story of the product. I will tell you the story of stellate the business, um, which is that we built this graphical caching solution. And when we launched it, Tim and I, it immediately exploded. Immediately we went to six figures in revenue in a month. We started closing enterprise contracts left, right and center. In the age of AI where companies are getting to $100 million of ARR in whatever 18 months, this doesn't sound as impressive anymore. But for a B2B enterprise startup, we were a hockey stick man. We launched and we were a uh, hockey stick straight up. We were doing really well. And it was because lots of Companies were using GraphQL and some of them had this problem and nobody had built a solution. And so we had buyer finally built a solution. So we hit this market need just dead on with a really great solution and exploded onto the market. And so we raised a bunch of money. We ended up raising $30 million. Um, and then we plateaued. We just hard plateaued and stopped growing. And then we had a bunch of hypotheses as to why. And so we tried a bunch of things. We tried making the product better, we tried getting better at uh, go to market, enterprise sales, getting our message out there and then closing deals with large enterprise prizes, six figure deals which you know is its own kind of magic and challenge, that's difficult. And we closed some of those. But truthfully our, our, our, our growth went asymptotic hockey stick and then just flattened out and wow. And in hindsight the challenge was we had built a really great product for a market that was just too small to build a venture backed company in. The product that we built was amazing. We had effectively near zero churn, uh, uh, outside of companies that were using us going out of business, nobody ever turned out of our product because there was nobody else solving the problem that we had solved. Never mind solving it as well as we had solved it. And so everybody that needed graphical caching ended up using us. And then they never left because they still needed graphical caching. Which is great, except there weren't enough of those people on the planet to make it for a venture backed company. And so then when we realized this we tried to expand beyond our initial solutions. We ended up building graphical read limiting, we ended up building graphical metrics and sort of trying to build a more complete suite around GraphQL which found some traction but again not enough to be a uh, billion dollar company, not enough to lead to a really, really big outcome. And so after, after three years of, of lots of ups and downs and challenges and successes, I sat down over Christmas and just over the Christmas break, I just sat with myself and I came back and I, and I told Sue, Tim had left at this point, um, the company and because he got burnt out, um, and I told sue and I was like, I don't think this is going to be successful. We're going to have to either pivot completely, do something else entirely, like just throw everything away that we have and do something else entirely, or we're going to have to shut this company down somehow. And you know, this is saying that companies fail when founders give up. And in fact companies only fail when founders give up. Uh, which is obviously an exaggerated statement, but it's actually very true. And at that moment, I gave up. After three years of trying really hard, I was tired. I did not want to go from scratch again. I did not want to start from zero. We had lots of money left in the bank. I could have done something with it, but I personally didn't have it in me. I gave up. And so then the question was, okay, if this is not a venture backed business, what do we do? And what I really cared about was I had built this great team. Again, going back to what we were talking about earlier, I'd spent many years building a really, really great team. And I'd spent a lot of time working on myself and working with the team. We'd hired some amazing people and so I really wanted to take care of the team. And then I also had worked many years with these customers that we had that relied on us as critical infrastructure. We were a big part of the reason why their products didn't go down. We were used by Puma, uh, the sports brand. We were used by some of the biggest, um, car, uh, magazines on the planet. And they relied on us in order to keep their businesses alive. And so I knew I couldn't just turn the switch and be like, okay, still it's dead. Now we're going to turn off the CDN and now all of you are down. That's ridiculous. And so I realized I want to go down this acquisition path. I want to go down the path of an acquisition again. And when I try to find, find a home for the team and the people. And so I ran an incredibly structured acquisition process. I went and made a list of every single company I could think of that was in any way related to what we were doing. GraphQL companies CDN companies, companies that were using GraphQL API companies. It ended up being a list of maybe 70 companies and ended up talking to probably 90% of them. I just treated it like enterprise sales. And I went and talked, I got intros to every single company, ideally to the founders or to the leadership. And I would go to them and I would explain the situation and I'll be like, hey, look, is there a fit here where maybe the team at the product can live on as part of your company? Uh, is that a thing that we could do? And after nine months of lots of negotiations and talking and back and forth and this is a whole journey, I ended up with a dual acquisition where Shopify Acqui hired the team. And so the engineering team and the technical team ended up at Shopify and is still there. And uh, uh, they uh, really, um, enjoy the culture there. And then the product, like I said, was acquired by the Guild and a graphical agency based out of Israel who had built a bunch of open source projects in the graphical space. And we're very excited to buy Stellate and take it over and keep it running and maintain for our customers. And so Stellate still exists, our customers still use it. Uh, it is still a great product and they keep making it better. And then the team ended up getting a great outcome and joining Shopify.

Speaker A: How do you brokerage dual acquisition like that? Is it literally two separate deals where it's like, hey, team leaves, the company goes here. Thank you so much. It's like job placement. Is it glorified? And I don't want to say it as a pejorative. Is it glorified job placement?

Speaker C: Yep.

Speaker A: And product, uh, obviously company, the company itself and the product, not the people, went to the Guild.

Speaker C: Yes. The way this works is that Shopify did what's called an acquihire, where they effectively acquihired the team. So everybody got a great deal out of it and they joined Shopify as a group. Um, and so it was, as you, uh, call it, uh, glorified. Job placement is a funny way of phrasing it. It's uh, a little bit more than that, but that's certainly what happened. They all got great jobs at Shopify. Fine. And working on the interesting things there and are well taken care of. And then the way that works mechanically is that Shopify purchases an exclusive and irrevocable license to the IP of the company. Because the risk of Shopify Aqui hiring the team is that Steli could later go, oh, you hired all of the team, now you're using the knowledge that they gained and the IP that we own, uh, at Shopify. And so we're going to sue you. And so really during an Acquihire, what they're paying for is a license to be able to use the IP that sell it has that is irrevocable and global and blah, blah, blah, all these things. And then because of that, they can hire the people without any legal risk on their side. And that's what they pay money for, basically. Um, and so that's how Acquihires work. And so we did that Acquihire. And then I told Shopify, I was like, hey, as part of this deal, I'm going to come on board too, which is what they wanted. But I'm going to stay behind at Selly for a little bit because I'm going to do another acquisition to try and take care of the product and the customers. And I'll be there in a couple months. And Shopify, much to their credit, were okay with that and said, you do what you need to do for the next three months and then please join us in three months. And so I then spent three months negotiating with the Guild who acquired the actual IP of steli. So they acquired the ip, the product, the customers, the business. They took over that whole thing, which, uh, is what acquisitions normally are when they're not acqui hires. And so as part of this, the really interesting piece was that I had to negotiate between these two parties because the key critical load bearing literal single line of legalese that really mattered to this deal was that the Guild would agree to honor Shopify's irrevocable license to the IP that Slate had. That was a critical piece because all Shopify cared about was we want to be able to hire the people without having the legal risk of you suing us later. If we use their knowledge, right, we're buying the knowledge and we're buying the people. And so we're paying you money for that. And the Guild wanted the product and customers. And so the, uh, whole negotiation was effectively, there was a lot of nuance to it and other small pieces. But the key piece really was the Guild agreed to honor Shopify's license to the ip. And so Shopify was happy with it. And then the Guild was happy with it because they were like, well, Shopify can use it, but for everybody else, we'll, we'll still keep selling Shopify, right?

Speaker A: So Shopify's deal happened first. The Shopify deal happened with you stellate as you were still founder, you hadn't left yet. And so it was a deal that was built into the company that the guild was purchasing the ip, et cetera. So they were purchasing not just the ip, but one critical liability, which was the in perpetuity usage of the license of irrevocable to Shopify.

Speaker C: That's exactly right. And they, they knew this just, just to be clear, like, this wasn't like, you know, this was very much.

Speaker A: It was by design. It was a sneaky thing. I'm sure exactly what the reason why I bring that point up so clearly or try to make it so clear. And uh, it's funny because whenever I just to bring it home a little bit, whenever I like chat, GPT or even Claude like me or the podcast, it frames me as somebody who likes to reframe what people say for clarity. And so just in that moment, it came to me, uh, this thing, I'm kind of aware of that I do. But the reason why I bring that clarity here is, is the orchestration, the sequencing of this acquisition. Like one, you were thoughtful in the fact that you were done. You knew you were done and you knew, you knew as a founder that you either needed to have more gas in you to continue to climb, or you had to pivot because the market just didn't have enough tam. Which is really interesting because you acquired the entire addressable, uh, market. You know, like, that's not frequent in a business. Like, you look at your TAM and you look at your SOM and then your sam. It's like, well, what can we actually do here in those circles? And they're all concentric. But, uh, in your case, they were just. You had taken all the TAM like you'd got it at all. And so you couldn't grow anymore because there's not much more GraphQL API users out there. You'd done the job, you'd succeeded, and so in every way it was successful. Uh, so you were smart in the fact that you're like, we can't grow anymore with the pivot. And that's how I have to go. And I'm also done with this. I'm done with this product in this company and I want to do right by it. But this, the way you've sequenced that acquisition and the, the process is, uh, is a masterclass, honestly. Like coordinating Shopify first, taking in that irrevocable license to it that was with you, the originating company, and then having that purchased by another company that took over the IP and product was just, I want to call it genius. Because that really is such great genius. It's funny when you look back at things that are genius, that are quite logical, that's the logical way. A thoughtful person who's caring about what they built, respectful of the team they built, the product they built. And then being business critical software to so many, you took that responsibility and the accountability in a, uh, very, a very good way. Based on what I'm hearing from the story.

Speaker C: Thank you. That makes me feel warm and fuzzy. Well, good.

Speaker A: I mean, that's. How could you. And then you landed at Shopify. I mean like, hello, let's talk about that. Because I mean you talked about products, you know, you talked about, you know, slash, product SL1, which is like a, an API endpoint. Um, and where else do you have, you know, the world's largest shopping network, so to speak? Shopify, you know, that's cool. You know, so it was a good deal and you ended up somewhere cool. How did that, how did that curtail, um, into. You stay there for three months, wrap up the IP, the acquisition, etc. And then move over to Shopify. What was some of your role and what did you do there?

Speaker C: You know, Shopify is a very special company and I'm extremely fortunate that I got a, that I got a chance to play a small part in it. Uh, when Tobi and Shopify acquired Stellite, Tobi has this philosophy. Um, and I mean Shopify is a company built around entrepreneurship, right? Shopify's customers are entrepreneurs. They make things and then they sell them and Shopify helps them do that. And so Tobi has this philosophy that it is greatly beneficial for Shopify to have more entrepreneurs at the company. And so there's lots of ex founders at Shopify because they understand the journey that the customers of Shopify go through. And so funnily enough, they had an idea of the rough area that I would work in, but kind of like a GitHub, nobody really knew what I would do. I joined Shopify and my first week I didn't have a job effectively and my job was really one, obviously onboard Shopify set up your laptop and all that stuff, but then two, and most importantly was go figure out what the right role is for you. And I worked with my manager Matthew and then Toby and Vanessa, the product leader and a bunch of other people and we looked at a bunch of different options and I talked to a lot of people and what ended up happening is that we found this perfect role for me, which was to be the director of engineering for Liquid Storefronts Um, and now I know how much you know about Shopify. But Shopify, again, entrepreneurs come to it to build businesses online. And the core piece of that that they usually come for is building an online store. These are, you know, I met flower shop owners that wanted to take their flower shop online. And what they cared about was having an online store. And the way they do that is with Shopify, Shopify does the whole thing for them. They don't have to worry about it. And, um, so I joined and I ran this 70 people team, uh, that builds the online store editor, the way that these merchants, these entrepreneurs actually build their online stores on Shopify. Um, and there's a templating language called Liquid that all this is based on that Toby invented 20 years ago. There's a bunch of dev tools around Liquid, a VS code extension, a cli, all kinds of things that we maintained that my team's maintained. There's, um, the Onso editor, which is this website builder, kind of like wixocial airspace or whatever, webflow framework, um, where you can drag and drop, edit your webshop and make it look the way you want to. Um, there's all kinds of workflows around this. And anyway, I ended up running all the engineering teams that build all of that, which was a great fit because it turns out it's highly related to what I thought about with style components, uh, to bring it back full circle, uh, because it turns out in order to build a website editor, you need to have pieces that people can use and these pieces need to compose together nicely and you need to allow people to build more pieces. And so you need nice abstractions. And ironically, a lot of that is what I had thought about my entire career in a different way and so ended up being a great fit.

Speaker A: So masterclass acquisition, and then you have the Shopify world as your oyster to choose from. That's kind of cool. So what attracted you to the Liquid storefronts? Like, what was, what was it about that that was like, okay, I could do anything here, I could find or make my own job and I can explore teams. I'm assuming this is all true paraphrasing, uh, from what I think, uh, you know, how you shared it, what was it about that that really sparked your interest? And what was the dent that you made at Shopify?

Speaker C: I think, uh, actually the answer is a step earlier, which is why Shopify in the first place. And the answer to that is because I strongly believe that entrepreneurship is something that's really beneficial to the world. I Think the world is much better off with founders, um, and with more founders and with more people, excuse me, trying to create things that change the world. And so in small and big ways. And so. And then Tobi has built Shopify, this really unique culture that really values great product thinking, great engineering, uh, really thinking through, from first principles, what is the right thing to exist in the world, and how can we make that happen above all else. And so I was really attracted to that culture for me and for my team. And then when I got there, working on the online store piece of it really was the perfect fit for who I am. My background had all these experiences that I brought from a different arena, a different world that really matched very well the kind of challenges that Liquid Storefronts and the online store faced. And then also, over the course of Stellate, I had again, I'd been in this pressure cooker situation of really growing myself, and I turned into quite a formidable leader, I think. Uh, um, and part of that actually is that I exude a lot of energy into my team. We did lots of anonymous M360 reviews@stellate to try and get better at who we are. And if I collected all of my 360 reviews and made a word cloud out of it, I can guarantee you that the biggest word would be energy. People kept. Every single person, I think, kept remarking about how much energy I brought to the team, how much energy I brought to every day, how much energy I brought to the company, how much energy I brought to them. That was the core piece of that, I think, is really unique to me. I can bring a lot of energy. And so I took over this engineering team that for reasons actually beyond themselves, were thought to be very slow. The Liquid Storefronts team was perceived to be extremely slow. They didn't ship enough. In fact, they hadn't really shipped anything for a whole year, even though there were 50 people at the time. And the area was really important to Shopify and innovating there was really important to Shopify and they had put a great product leader in place, but the engineering team just wasn't keeping up. And so I was like, that is the perfect set of problems for me to solve. I know I am the right person to solve this problem. I'm the right person to work with this team. And so I came in and I brought my energy and I talked to everybody and I connected with everybody. And anyway, lots of work happened. And nine, uh, months later we shipped Horizon, which was the biggest release at Shopify at the time. It was a new default theme with a completely overhauled theme platform that the team had been working on for many years. And we got it done in, like six months. What usually would have taken probably two years. This was a two year project. And Ben, my product guy and I, we said, no, we're going to do this in six months and we're going to figure out how to do it in six months. And so we worked with the team and we really figured it out. And so it really was, in hindsight, the perfect fit. It was a great place for me to be. The team was amazing. We worked together really well. We did a great job scoping the product and just shipping like crazy. Uh, it was very fun.

Speaker A: Did you go right from Shopify to OpenAI, which are where you're at now? What? Uh, you're nodding for the audible audience. He's nodding. Um, what made you make that change? Was it just good timing? Was there an offer? I mean, obviously we know what the world is now, so it's a smart move. But I'm just kind of curious what made the move happen.

Speaker C: It was probably the hardest decision I've made in my entire life. It was a really. Yeah, it was a painful, painful. Three weeks of working through that.

Speaker B: Um,

Speaker C: I loved being at Shopify. I was doing really well. I, uh, knew all the right people. I could get things done. I was in an area that felt like home. I loved my team. I still love my team. These people were great. Um, I didn't want to leave. Uh, and yet my friends who were at OpenAI kept telling me to come talk to them about it and kept telling me that I should think about working here. And they kept pinging me and they kept pinging me. And eventually I was like, whatever, let me just entertain this. Um, let's just talk about what it's like to work here. And as I started talking with them, I realized that the opportunity to work on ChatGPT contained something that I had never had before, which is working on something that my kids and my parents use. I've only ever worked on DevTools and then on Shopify and even Shopify. I was working on Shopify's DevTools for the most part. And even Shopify, which is, you know, is a publicly traded company, that's quite well known. My parents kept thinking, I work at Spotify. Uh, and they kept saying, Spotify, uh, uh, and I had to keep explaining to them that, no, that's something different. We don't quite focus on music. Um, and I realized as I was thinking through this opportunity to work on ChatGPT that working on something that my kids and my parents use is something that I've just never done before. And there was some very. This is very, like a caveman, like, alluring element of, like, oh, I work on something that the people that I love the most, that I hold very dear use pretty much every day and I can improve this thing for them. And so that felt. I'd never been in a position to experience that before, and ultimately that and the amazing people here and the ability to be back working in an office, which I really enjoy, just, uh, meant that I couldn't say no. As painful as it was to say goodbye to Shopify, it really was painful. I cannot express to you. Everybody was extremely sad that I was leaving and tried to keep me and I had to keep telling people that I really respected and loved. But, uh, I just, I can't say no to this. I have to go take this opportunity. And so, despite how painful it was, and I swear to God, it really was, if you ask my partner, she's going to tell you. That was a painful three weeks of thinking through that. But I just realized I have to be here. I can't say no to this opportunity.

Speaker A: Well, now I have to ask you what you're doing then. How much can you share? I know that there's limited ability to share too much, but what. I mean, I know what changes GPT is. I mean, it's changed my wife's life. My wife runs, uh, a small business on her own. It's a tiny home business that's very much a construction business and she's not a construction background person. Um, I'll share some personal life drama from the story, but in the last two years, she's gone from zero to home builder, largely because of CHAT GPT. Like, if it wasn't for the fact that Chat GPT exists and even therapeutic as a. As someone who is that questions their ability to lead, it's reassuring in the things because it has this context history of all the various chats and all the various trials and tribulations from how to frame a home to how to hire a team to how to speak to people that disappoint you or maybe need the COINS framework, so to speak, you know, because ChatGPT has this full framework of who she is. It's able to see her and what she's truly doing in a different light and be her worst and best critic and her best encourager when she feels inadequate and she's totally adequate. Uh, but it's this, it's this layer that was never there before, this magic box just to sort of say hello to, to. So I clearly know how important Chat GPT is. I personally use Chat GPT. I will model ideas that I then take to Codex. Uh, because you know, that's just there, there's still change there where you can actually connect the chat to Codex. And I'm sure you all solve that like Claude has done. Um, but I will model ideas, I'll think about ideas, I'll speak into it. It'll make kids stories for me. So I clearly, like everyone else, does know how important this platform is. But what made it, besides your parents and your kids using it? What are some of the things you're working on that are just clear to us and what you're working on?

Speaker C: Yeah, I work on, um, the ChatGPT app store, which is now called the Plugin Directory. And so the goal is, in order for ChatGPT to be even more useful in our, in our users lives, it needs to connect to more and more things that our users use every day. And as part of that, we're building on a platform that allows other companies to build apps that integrate into ChatGPT. And these are MCP servers. So there's two calls and there's uh, um, resources. But also we worked with the MCP UI creators and then turned the MCP UI into the MCP AppSpec that allows MCP servers to serve actual UI to clients. And so, for example, Zillow and Expedia have built apps where if you search for a house with a Zillow app in ChatGPT, you actually get a Zillow map inside of ChatGPT and you can talk to ChatGPT about the houses you're seeing. If, uh, you're searching for a hotel with Expedia, you can talk to ChatGPT about the hotel you're seeing. And so we're exploring new ways that we can combine the world outside of ChatGPT with ChatGPT and our intelligence and our moral models.

Speaker A: So how deep are you into that exploration? Is it, uh, is it pretty well done in terms of being, uh, is it still the hockey stick or is it plateauing?

Speaker C: No, no, uh, this is very, an extremely active area that we're working on very hard. Um, and so you'll, I think we now have, we went from dozens to hundreds of apps in the App Store over the last few months that you can now install and look through the directory and connect to Things they use every day. And so this is an incredibly active investigation and in fact it's a really active area of collaboration because a big part of this is our partners saying what they want to accomplish. What would they love their apps to be able to do in ChatGPT? And then us thinking, could we do that? What would it take for us to do that? And so it's lots of platform building, inventing abstractions again, going back to the very beginning, inventing abstractions that allow developers to integrate with ChatGPT in different ways. And so, uh, it's very fun.

Speaker A: Can you speak to the MCP server serving UI that seems. I didn't hear that before.

Speaker C: Yeah. So there's now an official spec extension to MCP that's called MCP Apps. And we worked with um, LYUD and IDO and some people on that. Um, that allows MCP servers to serve resources that are HTML based and very specific way. And when you do that, clients that support it, which include ChatGPT, when those tools get called, they will render the UI that are attached to those tools. And so there's now a spec for how you have to build these UIs. It's all web based, so it's all HTML and JavaScript and CSS. You can build these widgets that then get rendered next to your tool with the data that you return. And so you can build these really interesting experiences where uh, you can get ChatGPT to do a tool call and then ChatGPT can show you custom UI that you built on top of that. And um, it's all based on the MCP spec. There's now, like I said, an extension to the MCP spec called MCP Apps and you can uh, like I said, build ui.

Speaker B: Interesting.

Speaker A: What is the relationship with partners? Is that a platform? I'm unfamiliar with it and you can tell me what you can or what you can't. But if I wanted to build let's uh, say a podcast player for the change all network inside a chatgpt, would I have to pay OpenAI for that kind of access? What is the relationship between the partner and having their plugin app inside of ChatGPT?

Speaker C: It's a totally open directory. We review every kind of like the app, Apple App Store, we review every app that comes in to make sure it's safe and that it works for our users.

Speaker A: Interesting.

Speaker C: Um, but it's a totally free directory. Yes. You can build a changelog, podcast, listener MCP app and it will render inside of ChatGPT when people use it.

Speaker A: They would have to have the plugin app. What do you call them? Plugins or apps?

Speaker C: They were called.

Speaker A: Are they interchangeable?

Speaker C: Yeah. We're now introducing this concept of plugins that also contain skills. That's a whole thing that we're trying to figure out. Uh, but yeah, naming's tough. Name is really hard. But these plugins, you can build a changelog plugin and if people have it installed, they can go, ah, changelog. Find me an episode about GraphQL and it will, uh, hit your tool that searches through all your episodes and then we'll render a little, uh, Changelog player widget.

Speaker A: And they can play right in there?

Speaker C: Yeah, they can play right. It's just HTML and CSS and JavaScript. So anything that the web can do, we just iframe your widget into ChatGPT. And so anything that the web can do, you can do. So you can just have a player in there.

Speaker A: Yeah. What are the challenges, I suppose, around style? Because obviously you all have a pretty good brand style inside of the application itself and you probably take yourselves very seriously, which you are. How do you deal with rando like me putting my thing in your thing and you accept it. And I got, I got poor taste, let's just say. How do you deal with that? We don't have poor taste, but just, let's just imagine for this hypothetical situation, I do have poor taste.

Speaker C: That isn't called Adam. Uh, that's right. Um, we certainly review all the submissions and make sure that they are high quality. Um, because ultimately the last reported number externally was that we have 900 million weekly active users. And for something to hit the 900 million weekly active users, phones, uh, there's just a certain bar that you have to hit. Um, but within the bounds of it being a good quality experience, you really have a lot of freedom to render, to export, to express your own brand. Because ultimately these things are, you know, if I go talk to the changelog and then it renders the changelog player widget, that widget people know that it's the changelog and so it looking like changelog is totally a reasonable thing. Right. We're not going to make it, make it look like chatgpt, uh, um, entirely. And so people can certainly express their own brand in these widgets.

Speaker A: You know, this makes me think because of the intelligence that is inherently behind ChatGPT and everything behind it, obviously the different models that come out. Do you see this as a potentially new way to just skip building a website? Potentially? Not so much skip it altogether I'm just thinking, like, if someone's trying to browse something, do I want to build that browse intelligence in my app? Ah, maybe that'd be nice, because I want to have the hub and spoke model as any individual. I don't want to only trust you all because I want to give you a lot of trust. But there may be a point where the relationship fractures. And if I've only built my house on your foundation, then I have no foundation. But I guess what I'm getting to is like, how. How much of the future or how much of the direction can you share in terms of how people are thinking about how this works? Because right now you can't go on to. I mean, you can go onto the changelog website right now and pick any episode, but there's no intelligence there. Even our search is not that intelligent. It's just kind of like Dumb old search. Let's just say that should be an acronym dos, a different dos. Dumb Old Search. But if I can take this, you know, the Smart New search sns, Smart New Search inside of Chat gbt. Because I have a plug in there for changelog that seems kind of cool. And I don't have to go and build that. I don't have to rebuild what Chat GPT iterates on every single day. I could just feed my UI and my data basically what I am or who I am, and then you all can provide the intelligence because Changelog give me all GraphQL or all episodes with Max on it, etc. And maybe you get back one for now, in a year it's maybe two or three, who knows? But now you all deal with the intelligence and I could just skip it.

Speaker C: I don't have a good answer to this question except to say that, uh, I'm trying all the apps that are coming in and I'm trying to see what kind of fun experiences people are building. Um, I don't think there's a world where people don't build their website anymore because they can build a ChatGPT app, but maybe there's something people can build in ChatGPT. Like you're saying that they couldn't build otherwise, and that's the kind of thing that I'm really interested in seeing.

Speaker A: Maybe a better example to zoom into, just because I'm curious, is like a Zillow one. I know folks, I have good friends who just, just search for future properties. They're not even in the market, but they're always watching the market for properties they want. I have A particular friend who wants about five acres near a, near, um, a stream. And we live, like I'd mentioned in the pre call, in the Hill country here in Austin, Texas. It's actually called Dripping Springs. If you ever come out this direction, there's lots of wineries, distilleries, breweries, amazing food because it's Texas and lots of beautiful space because it's the Hill Country. And the Hill country is just like Texas is notoriously flat. But here in the Hill country, it's kind of rolling hills and beautiful. Uh, some like them cedars, they're kind of ugly, they give me allergies because I have them today. Uh, but a lot of great live oaks and various styles of oak trees, mesquite, M, you name it, post oak, et cetera. Point I'm getting at is that Zillow is probably a better example. Could if you went to layer into this. Is this kind of plugin framework able for me to not just extract but push back to my Zillow? So if I can query my Zillow or query Zillow in general, and maybe Zillow knows my account and now I'm not asking ChatGPT to build artifacts that I extract and pull down to my disk and then have to be the API to move them elsewhere, I could sort of do this, give and take back and forth, this smart layer on top of, you know, my Zillow search and help me build out my future. Five acres next to a stream.

Speaker C: That's actually exactly what I'm using it for right now. This Little app in ChatGPT personally, we're looking for potentially, um, buying a house. I guess at this point we're also the kind of people that just watch the market incessantly, waiting for the right thing to come along. And I just go talk to Zillow and ChatGPT and I'm like, hey, I'm looking for this kind of a house, uh, what's on the market right now that could match my needs. And it will get the data from Zillow, it will render me the map and then it'll look through the data and it'll go, oh, this property seems like based on the description of the photos, that could be a really good fit for what you're looking for. Go look at this one first. Um, and so it's been really helpful for that for sure. That's a great.

Speaker A: Are you able to then push that back to a list that Zillow manages for you, like future properties for the max home and you all are excited about it. And now there's this, uh, give and take from Zillow and then push back to Zillow. Is that a possibility?

Speaker C: I actually don't know off the top of my head if Zillow has built a tool like that, but they certainly could build it.

Speaker A: HTTP is that part of the framework, though, the plugin framework?

Speaker C: It's just MCP tools. So you can build an MCP tool that's like, hey, I want to save this home to my favorites. And then ChatGPT, call that tool with the home that you selected and save this tool to your favorites. Save this house of your favorites.

Speaker A: Yeah, there's a lot of directions you could take that, man. Wow. Okay, cool. It makes sense then why you left Shopify to say yes to this, because that seems pretty cool to build on.

Speaker C: Yeah, I would agree.

Speaker A: Well, Max, um, I really enjoy going through your journey, man. Uh, you've had a really wild journey from open source to founding a company to working at GitHub, to moving to Gatsby, to building your own company stellate and how that got acquired and now being at OpenAI on this plugin app directory, like it's a wild ride you've been on. And I'm very fortunate to have a chance to spend the time with you and hear this story and ultimately share this story. So thank you so much for sharing your time. Anything to say in closing here in the last moments.

Speaker C: I just want to say thank you for having me. I've been listening to the Changelog for. I don't even remember. It's many, many, many years. I've listened to many, many episodes. I think I've listened to every single Founder Talk episode. Specifically, I've listened to lots of Changelog episodes. I've been a longtime listener and fan. So thank you for putting out something in the world that's been really, really fun for me to follow along with on my own journey. And, uh, I'm really, I'm really touched that I got to be on here with you together, man.

Speaker A: It's so awesome to have you here. Uh, I'm actually, you know, we consolidated some things here on the network, uh, about a year ago. Um, but I'm considering bringing back Founders Talk as a proper first class podcast again and maintaining both Founders Talk as a standalone podcast and the Changelog as its own standalone pot. Standalone podcast. Just because I miss those very specific founders stories. Like this is going to err on the change law, but just because we've done this kind of compression internally, ultimately it's still the same listenership as, you know, because you're part of that listenership. But, you know, from a brand perspective, it's challenging to shove a deep founders conversation, although it's been sprinkled with a lot of web pack woes and cashing at the at the edges and stuff like that. So we still have all that in this mix. But I'm considering it. I'm considering what it might be like to bring back Founders Talk as a proper, original first class citizen podcast in this network. And, and that's a lot of things that are changing here. Is, is these new fruits and new labors that I'm working on now that I'm solo again in this endeavor. But yeah.

Speaker C: Ah, good luck.

Speaker A: Thanks for saying that, though. I'm glad you've been a listener for all these years and I'm so thankful that you're thankful to come on the show because that means that what I do matters to you and I appreciate that.

Speaker C: Oh, 100%.

Speaker A: All right, Max. Well, thank you for your time. Thank you for your journey and sharing it. Appreciate you.

Speaker C: Thanks for having me.

Speaker A: Fun times. Going through fun times, of course, from back in the day, Spec fm. Love Spec and of course Spectrum. Fun times hearing Max's story, man. Get to work on some cool stuff at Shopify, one of the coolest companies ever. And now OpenAI, uh, also one of the the coolest companies ever. What a treat. Well, a big thank you to our friends at Coder, our good friends at Work OS and our good friends at Notion for supporting this show. And of course to our friends and our partners at Fly. Check them out. Fly IO and to the beat freak in residence. Those beats are banging. Well, that's it. This show's done. Thank you for tuning in. We will see you next week. Sauce.