The Changelog: Software Development, Open Source - From open source hits to OpenAI (Interview)

Episode Date: June 5, 2026

This week I'm talking with Max Stoiber, currently working on ChatGPT's plugin directory and app platform at OpenAI. We discuss the hundreds of open source projects nobody remembers alongside the big ones like react-boilerplate and styled-components, how Spectrum became part of GitHub and eventually helped shape GitHub Discussions, the founder growth that came from building Stellate, the GraphQL cache that turned into a dual acquisition by Shopify and The Guild, and why ChatGPT apps feel like a new surface for software.

What's up, we go back. This is the changelog. I'm Adam Stikoviac, and today I'm joined by Max Stoiber, 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 GraphQLCDN 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 at fly.io. That is the home of changelaw.com. Learn more at fly.io.

Okay, let's do this. Well, friends, this episode is brought to you by our friends at coder.com secure environments where developers and agents work in parallel. And I'm joined by Nikki Pike, Field CTO for Coder, Nikki, what is the field CTO? 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 dev rel for the C suite.

So we provide a bridge between the customer voice, between the 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. 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?

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 that 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 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 local laptops 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 shy Hulud, you know, that virus that went out not long ago. This was a compromise

of the MPM public repositories. They went and downloaded things. MPM did what it did. Next thing you know, you're compromised. But when you use something like what we're doing with cloud 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 shy Hullud? 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 weak.

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. 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 Stoibber. 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? 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, 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 lived 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. 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. And so it's quite humbling that this guy from Austria was able to influence the world in that way. It is wild how one person can change so much. 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're already doing things like stock components, React Boiler Plate. 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. I think people look at my career and they see all this. successes, right? They see style components, they see spectrum, they see stealth, they see

that's what I say. Open AI now. 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 Polaplate early on that got really popular for a while and then I made style components that got really popular for a while. And both these open source projects are wildly popular, the top, you know, 200 projects on GitHub by Stars, all this, lots of lots of usage, really change 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 were used because they didn't solve a problem that other people had. And 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. 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 ReactBelplate and any of my open source projects became popular. The reason I even started making things open source is because I go really annoyed when I had to solve the same problem multiple times.

I would be building something and I'd be like, 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. Oh my gosh, yes. Thousands of lines of code of Jason 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. 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. 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 that come to be your core thesis?

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 the stock components $1? You'd be a billionaire, but now given how many installs you have. And of course, that's not how the world will open social works. 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?

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 idea is also controlled. 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 Stile Components of React Boil Plate, if I had charged from my open source projects, nobody would have used them, right? 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 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 have 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. Kind of jump into present a little bit on that same note.

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, consider 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. 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.machim maximalist at this point. but do you feel like that core thesis you had back in those days of style components, etc., carries to today's present world? 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. It is in some ways, right? Like OpenClault recently became the most popular open source project of all time. 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 are successful people tried and they went, oh, this works exactly the way I would think it would.

That's great, right? I don't even need to read the documentation. I just know how to use this because it just makes sense. But then making that abstraction work was really, really difficult. That was a lot of work on our part to make that happen, right? That magic, that simplicity wasn't simple to create and took a lot of code for us to figure out. to figure out. Now, I don't know that AI is at a point yet where it could create style components

from scratch if we just gave it the abstraction, but it seems inevitable that it will 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, you know, since I joined Open AI in December, I've shipped many, many PRs here and made lots of changes to chat GPT. 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. Yeah, it's so wild to that for a while there was taboo to say we're using an agent. it was actually expected because we want it to complete the line. We wanted to complete the thought. We didn't want it to have the thought, so to speak. And 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.4, maybe 5.3, I think, is what it was in December. And now 54 is just so revolution. 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. I think we're in such a uniquely different world here today at the end of March 26 that we definitely were at the tail end of March 2025. Like it's dramatically almost like a 180 in terms of difference in how we code or not code. 100% agree. I think I still think

even if code is not the mechanism anymore it is valuable to provide things to the world whether there are ideas or solutions to problems

I think that is always a valuable thing to do both for the world and for yourself I just don't know that the shape of that will be code

anymore sometime soon 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 ChangeLaw 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 not bad.

It's great. It's a really great platform. 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, 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 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. I still have to tell love it or leave it, Codex, but I still have to tell Codex how to navigate TypeScript and Node. Like there was so much wrong with the type interface in my application.

And I don't think it's me because I told it we're using TypeScript. And we're using Node.js 24. 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 Nose 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. 100% agreed. I think at the same time, the trajectory of where things go is quite impressive. 100%. And the question is just where even when it asymptotes, right, will it slow down or will this trajectory continue for a long time?

I certainly feel the difference from even September, December, as we're talking about now, to today, it was a wild jump and it just keeps getting better and better. 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 the saying of, like, 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 wants to make sure that 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 and a different devil in a different way. That's most of the time that I've 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 spend most of my time. I did want to chase a couple of those 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 can probably gush deeply about it. And you get to AI maximalists in a room and they'll talk for hours about what they're working on and how cool it is and whatnot. But back of the Dev Spectrum, when you all invented this, this new way to give coding communities discussions and community. 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 spinoff from that or the same team? Help me clarify that before we go deeper.

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 Brin and my two co-founders, they were running this podcast network called Specfm. And they had, I think, four of five podcasts at the time that they were running as part of Specfm. 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, 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 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 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. 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 DMD just DMD me on X on Twitter. And I was like, hey, Max, we hit this bug that I think is a style components bug. Have you seen this before? And I had known of Bryn 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 cul-based 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 Bulletplate at the time which was used by many people and then style components which was used by many people And part of the part of the challenge of managing or large open source projects like that is that The maintainers end up being the sole

Supporting pillar that answers every single their every single support request gets answered for them Every single bug report gets triaged by them every single incoming contribution gets your out trashed by them and it ends up being a huge volume of work and And sometimes other maintainers step up. And in the case of style components and Rick Bolloplay, both, I was very fortunate of some really great people step up. But overall, it's 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-south projects that I have the same problems. I want the same solution. And so I end 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 Brin and Brian. And so the world is hopefully greatly from me-in-menting style components. But in return, I got this great journey of founding a startup with two of the first. my now best friends and had lots of learnings and growth through that that really defined my career. Well, friends, I'm here with a good friend of mine. Michael Grinich, founder and CEO of Work OS. Michael, Offer agents. I feel like this is burgeoning. It's kind of happening all of a sudden. What's the state of the world for auth for agents? Yeah, it feels like author agents is one of those things that nobody 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 WorkOS Pipes. It's actually more of an integrations product. It helps you take your agent and connect it to your customers Google Drive and connect it to Salesforce and HubSpot and connect Slack and all the other stuff that they're going to use and doing a way that's safe and secure and managed. That's one type of off 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 its name? That's really coming from the enterprise identity systems that are out there. If you look at Microsoft's Entra agent ID,

They're doing a lot of interesting work there. There's also expansions to Open ID Connect and skim for agents. We're building all of this into the WorkOS platform. So if you're looking for an identity stack that will support agents, again, feature proofing. WorkOS is a great place to go. But it's changing really quickly. None of us were talking about OpenClaw, you know, like weeks or months ago. And that's a new paradigm.

I think we're going to see not just within consumer software, but in the enterprise too. So it's an area of very, very rapid development. Well, it makes me think about agents versus people, not negatively, but this world where we'll have more agents than people. You know, today if we have seven or eight billion people on the planet, in the future, we're going to have trillions of agents going off and doing things. And so the challenge around identity authentication for agents is actually significantly bigger than just how people interact. In the same way, like, you know, GitHub 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. All right,

friends, the next best step is to do what I've done, which is use off kit. Okay, that's how I authenticate my CLYs, my APIs, my applications, all that good stuff. WorkOS.com is where you go. Try it out today. A million users with AuthKit for free. You can't beat that deal. It's literally free. Again, workOS.com. Try it out today. What was your, so you came in through stock components and a 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 it was like, hey, you are joining, you're all making a company. Can I join it? And what was your role in the company to sort of begin building the product? I think it was all very fortunate. circumstances. Brin and Brian were building this platform, but they initially, I think we're really building it just for Specfm, which is why the name ended up being Spectrum. It was meant to be a play on words.

Yeah, that's why you even messed it up initially when I asked that question. I thought it was called Spectrum.com, but then I was like, maybe not. And so you corrected me. So even in my own brain, I'd had the podcast network spectrum in my brain. So that is exactly where the name came from. 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 benefit from this or other people could benefit from this. I think they sort of decided,

hey, maybe we should actually try to make this a company. And then they were both designers written 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, you know, should code or not. Which I think now with coding agencies is 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, at least prototypes. You know, production code, you know, we'll get there.

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, they, I think, saw a need for having somebody technical in a company in order to build things. And so I joined as a 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 at using to connect their users together before we got acquired by GitHub. And it was just us three in our bedrooms hacking together this community platform that we loved. Did you take on any funding or seed investment?

How did you sustain initially? We had raised a small pre-seat rounds that sustained us for that year and a half. And in fact, 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 like 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 index, people can find answers after they're given, 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.

We just didn't find a way to build the business out of it. And we tried a few things and none of them really worked. 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 that, there wasn't a big business to be built here unless we were going to do ads which we didn't want to do

uh and so we were like this we couldn't find a business model that would work and so then we said maybe we just got this as part of kids up yeah that's interesting definitely don't want to 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 get up 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 not become discussions.

How did that conversation initially play out? Yeah, there's this other guy named Max, Max Schroding, who 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 to foster this sense of community.

And they wanted to see if we can bring part of that to GitHub. And we ended up through 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. That turned into GitHub discussions about a year later that now is used by

every single repository pretty much on GitHub. So the initial conversation, wasn't, hey, let's just turn this into, they didn't have a preconceived idea. They just were like, you are doing cool stuff. We eventually need what you're building. Let's figure it out. That seems a little ambiguous. Yeah, no, that was very much what happened.

They saw that there was a need for this in the community. But there wasn't like a preconceived idea of like, oh, exactly. It should be a tab on repositories that says discussions. And each discussion should look exactly like this. like that preconceived notion didn't exist. And in fact, for a while, we explored whether we could bring, if you think about the spectrum was a sort of combination between Slack and the traditional forum.

It was real time, but also had threads. People were meant to chat live. If you think about GitHub discussions, it's not exactly chatting live, right? It's not, it doesn't feel like Slack. And so in between those two steps, there was a lot of exploration in GitHub that we did around can we bring real-time chat to GitHub at GitHub scale

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, a lot of the difficulty at GitHub scale at the time I think I 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, that really wasn't Slack was a relatively new thing itself. Like, nobody really figured out how to scale real-time that well at that scale. And so for GitHub to take a bit, to build all this real-time infrastructure for what was a minor

part of the platform, ended up just not being worth it 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 GitHub discussions and is independently very valuable. is not the same as Slack or real-time chat would have been. 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 needs. needed necessarily. I think there could still be some cool real time there, but my gosh, the maintainer burden on that would be through the roof. And so many people probably just quit GitHub completely, if that were the case. But is there any part of you that, or even

maybe the three of you if you can speak for them, that were chasing this particular product direction and then the acquisition slash aqua hire change the trajectory? It 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? For sure, for sure. I think I had lots of complex emotions at the time that I don't think I actually processed 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 taken on the market couldn't have worked. And then for what GitHub needed, GitHub discussions made total sense too. 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, you know, 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 what should I call it, like online course creation. They focused more on sort of those sort of more commercially viable communities. And they've built what from the outside looks like a great business around that.

But it wasn't necessarily what we were interested in doing. We really wanted to connect these communities together that naturally emerged, that exist around these non-commercial projects. And it's difficult to build a business around non-commercial projects, as many people know. And so there's a wistfulness, but also I'm very happy with how it all turned out and how my life turned out. So we've jokingly, Bryn Byn and I jokingly talked about buying Spectrum back from GitHub. But it was never more than jokes 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 replacements that the internet has to a sense of community. But other than that, nothing really exists, especially nothing in search index, that really creates and fosters a deep sense of community and belonging. And so it's an unsolved problem.

I don't know if maybe those things are at odds. Maybe they aren't. Maybe somebody will eventually solve it, but it certainly still is 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 Nuneaker. Do you know John Nuneaker, if any chance? I know you both worked at GitHub probably at the same time. I don't, actually.

John Nuneiaker. 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'd come in with. I think it speaks to 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's joking, but I bet they would because, like, it's just IP sitting there books that it's like, we have to keep maintaining this at some point. We probably,

they probably own the spectrum IP, you know, 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 the 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. You know, it's a fun circle back around to what we're talking about at the beginning. It is always beneficial to give things to the world. It will come back around to

you at some point. Yeah, I agree with that. Gosh, don't be selfish. It's so hard 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. 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 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 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? Honestly, I had great fun working at GitHub. I actually really enjoyed it, I think, contrary to some other acquisition stories. 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 worth spectrum.

But for the most part, I really loved working there. 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 know, you hear these acquisitions and then the founders get grumpy and they leave and that's all this public. feud that sometimes happens. But many of these acquisitions, they work really well. And people are very happy at the company that they go to. It really just depends on where you end up with. And so we were very fortunate to be able to join Getsup at that time and I had a really great time. 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? Yeah, after GitHub, I joined another startup called Gatsby that was building a static site generator. And we're sort of trying to build a cloud business around that. And they were a C.S.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, that some of which eventually spilled out publicly. And so the company kind of, quite frankly, imploded itself. you know, when I was there, we had 60 people, and then when I left, we had 25, 30 people maybe.

And UCO 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 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 chips cool things that the world needs. 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. And the third reason why I ended up going back

to founding Mount Starbys 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 pressures of building a company and all the different things that requires, forces, it's like a pressure cooker for growth. And 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 the world and be better at understanding myself and all these things. And I do that every day. And being in that pressure group 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, right? Like 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 when I say really big business, I mean like a VC-backed,

you know, companies who are trying to become trillion-dollar companies or a billion-dollar companies, you know, like 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 founders 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 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 entrap the world. And so those were the three reasons why I went back to founding a sort of. It was personal growth. It was feeling like 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. 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 team. Or to be a team. a giver, like you have been an open source, and to be seen as somebody that's worth trusting or has a track record of success, but building a team that's cohesive that has similar

attributes and similar moral direction even. 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 where they want to live in the world, how they think about money, all these things really get to. 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? What was the challenge there for you? Was it just easy? No, not at all. It was definitely

not easy. 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 story. Maybe two years into my next company's journey, Steli. We had maybe 15 people at the time. It was a team spread across the world. And we were doing an offsite as a small leadership team, me and my co-founder and our CEO, Sue, and we were looking around and assessing

what isn't working at this company? Why? How could we be better at being Steli? 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 lots of talks on stages and I can interact with people. I'm not, I'm a little bit of awkward nerd, but not as strongly as people might suspect from an natural 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 this connection. 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 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, requires that level of introspection and understanding yourself. Otherwise, you, 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 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 through that, I've gained freedom with myself. And I now know, hey, 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. And 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 Stelietav was really me figuring out who I want to be and Tim figuring out, 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.

And then the second thing I'll say is, we knew that we had no idea what we were doing. We went into Stellade 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 CEO who 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 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, that's pretty wild. 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? Yeah. I think the first piece was really understanding that I felt it was risky. And that's why I was subconsciously not doing it as much as I needed to as the leader of a company. And the second piece then was once I understood this about myself, working with Sue and working with my coach on what tools can I have to feel more comfortable giving critical feedback. And one of those tools that I used to this day is called the Coins Framework, which is just an acronym for context observation impact next step, next steps, coins. 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 of observation, impact next steps, it's like, hey John, in the meeting we were in on Monday, I noticed that you cut off Jack when he was trying to explain why.

he merged this PR that caused this outage. And what I saw on Jack's face was that the, when you cut him off, was almost a look of disappointment or frustration. And I think it might have ruptured some of your, your connection and some of your, some of your, you know, relationship. And so I would really, I would really love it if you could reach out to him and check out with him and then take a look at what and then I would love to take a look at with you what what caused you to interrupt him what what feelings were you having and why did you feel

the need to cut him off before you finish saying what he was saying right and so you go context is what was the situation impact was what 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 you know 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, you know, it would have just lots of things wrong with that way of giving feedback. 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 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 at least 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 land with you, at some point, you know, there's only so much responsibility I can take for our relationship. And so this is a very concrete example of something that I learned that I done that now means a much more comfortable giving redirecting feedback. 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 it seems like it's become embedded in the fabric of who you are today.

For sure. 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 need to. And so I introduced this framing that I learned from Kat as are one of the leaders at the tropify called say the thing, because I really wanted to encourage people to say the thing. It's really, really important to a 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. And so I've run training sessions and I've taught this framework to many, many people now.

Yeah. It's kind of wild how that's become that close to you. How pivotal was you learning that principle? 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 company itself and how you collaborated and worked together, but ultimately the project created because now you can work better together? We got much better at everything we did much faster. Because I was giving feedback to everybody at a higher, more often, more of the things that

Steli 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 before and after. I don't know that anybody could have pointed to, oh, that's what changed at that moment. You know, 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 like to the way we did. But it wasn't like a, you know, everybody's going to point to that moment as that big pivotal moment where everything changed.

It was much more gradual change than that. And also, it was one of many. This is one learning of many that I have 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. 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. You have to make these tweaks or otherwise your company won't succeed. But like I said, I love that.

I want to be better at being myself. I want to be better at interacting with the world. I love what I do. And so it's relentless, but I love it. You know, and so I really enjoyed it. Well, you must have done something right because you were beloved. Churn was near zero. Lots of customers trusted you.

You got to a lot of money in the bank. Ultimately, you were acquired by shop-off. I wish 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 used. Can you talk a bit about what Stellite is and what it did so there's some context? We've been talking around it and mentioned by name, but not really contextually like since we're using the coins framework, but just using the C from that. What exactly was Stellate?

What took you into this GraphQL success, this caching success, and ultimately what led to this acquisition? Why did it make sense? You know what? It all started actually with Spectrum. When Bryn 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 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 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 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 on a GraphQL 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 words 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 a spectrum they're not acquiring a data leak right and so honestly brin brian and i were excuse my language shitting our pants when when they when they said that they were going to do this because we were just three dudes sitting at a bedroom building this product as fast as we could to try and to try and make something

that people wanted and then when people wanted it to try and not may 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, when these pen testers went and they tried to hack Spectrum for a week or eight days, I don't remember. And they came back and they didn't find any major security vulnerabilities. Wow. And I actually largely created GraphQL for that. And it's GraphQL in combination with actually Versale, 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 Burscel and all of 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 and mutation, there had to be an access check. And the access check had to be something like, if users not an admin of this community, they cannot take this action return or through an error unauthorized.

That's it. That's literally all we did. We just made sure that every single query mutation had an access check. And not all of our access checks were perfect. They found some issues with like moderators of one channel, of one community's channel could moderate another community channel or something. Like they found some minor sort of access 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 that access check

that made sure that when you were accessing data, you were actually allowed to access it. And so I actually largely credited ironically GraphQL with, our security posture because although 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.

I enjoyed building the API. I enjoyed using the API. And then the fact that the security aspect was really nicely solved meant I really enjoyed it. And so one of the big challenges we'd had to expect, was as all these open social community started using it, our traffic went skyrocketed. And I had 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 was a database meant for real time. So any database query, you could put dot 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 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 to me 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 it was like, well, how do I, is there a band date 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 cash in front of our graphic. Because of course... So I hit the database. Let's cache things. 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 rights. 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 GraphQL clients do and why they work so nicely on the client, it's because they do a bunch of really fancy denomalized caching that works really well. And so in my head, I was like, why can't I just take Apollo client or Erkel and put it on the server? I'd have a cache for everybody,

but it didn't exist. And so I built a really shitty version of this at Spectrum, like a really rough, like just matched a query and then return the same JSON, like really rough Reddit-based version of this caching. But in my head, I always had this idea, like, this has got to exist.

You can crash 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 told to people about this and blah, and then years later, a common friend of ours, Pinkman, 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 Tim and through that, we decided to found this company that eventually became Stellite. And what we were building was a GraphQL CDN, a GraphQLish cache that took many of the same ideas that GraphQL clients have around caching, but brought it to the server, which has its own set of challenges and edge cases and difficulties that we realized over the next four years. 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 risk level cache that works as well as 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 great reasons. This episode is brought you by our friends, AdNotion. 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 tool. That's the gap that Notion's 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 line. Then you have workers, which are Notions hosted sandbox of your code, no purpose. 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 baked in. That's agents that actually work alongside your team, not in some single player sandbox. Okay, good next step is to learn more about Notion's developer platform today at Notion.com slash change log. That's all lowercase letters. Notion.com slash change log to try Notions developer platform today.

When you use our link, of course, you are supporting this show. Once again, notion.com slash changelog. What was the secret sauce? Can you spill those beans? Or is that part of a... No, no. Okay. So part of the magic is that,

GraphQL has requires the client to do something called field selection. So instead of just hitting an endpoint like slash product slash 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 ID 1, I need the ID, I need the title, I need the price, I need the description, I need the 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 the ID1, 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 it 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, product, 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, all this data that this client needs, needs, what do we actually already have in the cache and what do we need? And then we would only send a request of 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 graphical 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 cash the availability because that's dynamic. And you would only basically ever get requests for the product availability and the product price.

And then everything else, we would try to keep in the cash as much as we can. And so we enable people to get to really, really high cash hit rates with very, very little effort because our cash was natively built on GraphQL. And in fact, if you're listening to this and you're thinking, I need this right now. Staley still exists. It got bought by an agency called the Guild and you should totally go use it. It works amazingly in different and they've done a great job maintaining it. Yeah, that does sound pretty cool.

But only reason GraphQL, is GraphQL still popular? I feel like it's kind of 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? Yes. What I just told you was the story of the product. I would tell you the story of selling the business, 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. You know, in the age of AI, where companies are grading 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 were doing, we launched, and we were a hockey stick. 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 the solution. And so we had finally built a solution. And so we hit this market knee 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. 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 go-to-market enterprise sales, getting our message out there, and then closing deals with large enterprises,

six-figure deals, which is its own kind of magic and challenge. That's difficult. And we close some of those. But truthfully, our growth went, asymptotic hockey stick, and then just flattened out. Wow. And in hindsight, the challenge was we 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 journey. 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 rate limiting, we ended up building graphics and sort of trying to build a more complete suite around GraphQL, which found some traction, but again, not enough to be a billion-dollar company, not enough to lead to a really, really big outcome. And so after three years 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 told Sue, Tim had left at this point, the company and because he got burnt out. And I told Sue and I was like, I don't think this is a, 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, which is obviously an exaggerated statement, but it's actually very true. And at that moment, I gave up after this. 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 just, 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're talking about earlier, I'd spent

many years building a really, really great team, and I'd spend a lot of time working myself and working with a team. We'd hired some amazing people. And so I really had 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 Huma, the sports brand. We were used by some of the biggest car 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. Turn off the CDN and now all of you are down. Right. Like that's ridiculous. And so I realized I have,

I want to go down this acquisition path. I want to go down the path of an acquisition again. I want to try to 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're doing. GraphQL companies, CDN 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 would be like, hey, look, is there a fit here where maybe the team in the park can live on as part of your company? Is that a thing that we could do? And after nine months of lots of negotiations and talking and back and force and this is a whole journey, I ended up with a dual acquisition where Shopify acquired the team. And so the engineering team and the technical team ended up at Shopify. and is still there, and they really 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 in the graphical space, and we're very excited to buy Stellite and take it over and keep it running and maintain for our customers. And so, Stellite still exists. Our customers still use it. 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 it. How do you broker a 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 pejorta, but is it glorified job placement? Yep. And product, obviously, the company itself and the product, not the people, went to the guild. Yes. The way this works is that Shopify did what's called an acquihire,

where they effectively acquihered the team. So everybody got a great deal out of it. They joined Shopify as a group. And so it was, as you called it, glorified job placement, is a funny way of phrasing it. It's a little bit more than that, but that's certainly what happened.

They all got great jobs at Shopify and are 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 acquiring 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 at Shopify, and so we're going to sue you. And so really during an aqua hire, what they're paying for is a license to be able to use the IP that's sell it has, that is irrevocable and global and 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. And so that's how Acquis hires work. And so we did that act we hire.

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 and sell it 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

So they acquired the IP, the product, the customers, the business. They took over that whole thing, which is what acquisitions normally are when they're not acquitiers. 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's delayed 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. We're buying the knowledge and we're buying the people and so we're paying you money for that. The Guild wanted the part of the customers and so the whole negotiation was effectively

there was a lot of nuance to it and other small pieces. But the key piece really was the Guild of Creed 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 still keep selling Shopify's deal happen 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, etc. 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. That's exactly right. And they knew this just to be clear. Like this wasn't like, you know, this was very much.

Yeah, it was by design. It wasn't a sneaky thing, I'm sure. Exactly. 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 tan, which is really interesting because you acquired the entire address. market. You know, like, that's not frequent in a business.

Like, you look at your TAM and you look at your Sam and it's like, well, what can we actually do here in those circles? And they're all concentric. But 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. So you were smart in the fact that you're like, we can't grow anymore with the pivot. 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 the way you've sequenced that acquisition and the process 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 purchase 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 to,

it's funny when you look back at things that are genius that are like quite logical. Like 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 in the accountability in a very, a very good way based on what I'm here from the story.

Thank you. That makes me feel warm and fuzzy. Well, good. 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 slash one, which is like an API endpoint.

And where else do you have, you know, the world's largest shopping network, so to speak, Shopify. That's cool. You know, so it was a good deal and you ended up somewhere cool. How did that, how did that curtail into you stay there for three months, wrap up the IP, the acquisition, et cetera, and then move over to Shopify. What was some of your role? What did you do there? You know, Shopify is a very special company. And I'm, I'm extremely fortunate that I got a chance to play a small part in it. When Toby and Shopify, I call it, buyer, still it. Toby has this philosophy. And I mean, Shopify's a company built around entrepreneurship, right? Shopify's customers are entrepreneurs. They make things and then they sell

them. Shopify helps them do that. And so Toby 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 working, 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, on board Shopify, go, you know, 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 work 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 I ended up happening is that, we found this perfect role for me, which was to be the director of engineering for liquid storefronts. And now, I don't 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 so I joined and I ran this 70 people team that builds the online store editor, the way that these merchants, these entrepreneurs, actually build their online stores on Shopify. And there's a templating language called Liquid that all this is based on that we invented 20 years ago. There's a bunch of deaf tools around Liquid, a VS code extension, a CLI, all kinds of things that we maintain, that my team's maintained. There's the online store editor, which is this website builder, kind of like, looks social workspace or whatever webflow framer. where you can drag and drop, edit your web shop,

and make it look the way you want to. There's all kinds of workflows around this. 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 to bring it back full circle 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 end up being a great, great fit. So masterclass acquisition, and then you have the Shopify world Azure 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 from what I think, 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? I think 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 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 then Toby has built Chopperfiance this really unique culture that really values great product thinking,

great engineering, 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, I 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 sorfronts and not the only sore faced. And then also, over the course of Stelaide, 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. And part of that actually is that I exude a lot of energy into my team. We did lots of anonymous 360 reviews 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 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. and 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. Anyway, lots of work happened. And nine 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. Well, usually it would have taken probably two years. This was a two-year project. And then 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. It was very fun.

Did you go right from Shopify to open the eye where you're at now? You're nodding for the audible audience. He's nodding. 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. 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. I loved being at Shopify. I was doing really well. I 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 I didn't want to leave and yet my friends who are at opening eye 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 let me just entertain this 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 JadGPT 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 at 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, and they kept saying Spotify. And I kept keep explaining it. to them, but no, that's something different. We don't quite focus on music.

And I realized as I was thinking through its 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 had 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 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, tried to keep me. And it was, I had to keep telling people that I, that I really respected and loved that I, I just, I can't say no to this. I have to, I have to go take this opportunity. And so despite how painful it wasn't, I swear to go, it really was. If you ask, if you ask my partner, she's going to tell you, but that was a painful three weeks of thinking through that. But I, I just realized I have to be here. I can't say no to this opportunity. Well, now I have to ask 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 Chait GPT is. I mean, it's changed my wife's life. My wife runs 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. 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 disappoints you or maybe need the coins framework, so to speak, you know. Because ChachypT 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. But it's this layer that was never there before, this magic box.

or this magic box just to sort of say hello to. So I clearly know how important chat GPD is. I personally use chat GPT. I will model ideas that I then take to Codex because, you know, that's just there's still change there where you can actually connect the chat to codex. And I'm sure you will solve that like clot is done. But I will model ideas. I'll think about ideas.

I'll speak into it. It'll make kid 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? Yeah.

I work on the JadGPT app store, which is not called the plugin directory. And so the goal is in order for JGPT to be even more useful 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 chat chvety. And these are MCP servers, so there's two calls and there's resources. But also, we worked with the MCPUI creators and then turned the MCPY into the MCP app spec that allows MCP servers to serve actually 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 Jad GPD, you actually get a Zillow. map inside of Chachapit and you can talk to Chachapiti about the houses you're seeing. If you're searching for a hotel with Expedia, you can talk to Chachapitia about the hotel you're seeing. And so we're exploring new ways that we can combine the world outside of Chachapit with Chachapit and our intelligence and our models. So how deep are you into that exploration? Is it pretty well done in terms of being, is it still the hockey stick or is it plateauing?

No, no. This is an extremely active area that we're working on very hard. 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 cannot install and look to the directory and connect to things they use every day. And so this is an incredibly active area investigation. And in fact, it's a really active area of collaboration because a big part of this is our partner saying what they want to accomplish, What would they love their apps to be able to do in J Jad GBT? 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 JadipT in different ways. And so it's very fun. Can you speak to the MCP server serving UI? That seems, I didn't hear that before. Yeah. So there's now an official spec extension to MCP that's called MCP apps.

and we work with Liot and Ido and some people on that, that allows MCP servers to serve resources that are HTML-based in a very specific way. And when you do that, clients that support it, which include JadGPT, 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 call with the data that you return.

And so we can build these really interesting experiences where you can get ChachapD to do a tool call and then Jajibati can show you custom UI that you built on top of that. And it's all based on the MCP spec. There's a, there's a now, like I said, an extension to the MCP spec called MCP ops. And you can, like I said, build UI. Interesting. What is the relationship with partners? Is that a platform? I'm not familiar with it.

And you can tell me what you can or what you can't. But if I wanted to build, let's say a podcast. player for the changeable network inside of chat GPT. Would I have to pay Open AI for that kind of access? What is the relationship between the partner and having their plug-in slash app inside of chat GPT? It's a totally open directory. We review every kind of like the Apple App Store.

We review every app that comes in to make sure it's safe and that it works for our users. Interesting. But it's a totally free directory. Yes, you can build a change log podcast listener. MCP app and it will render inside of chat chabit when people use it. They would have to have the plugin slash app and what do you call them? Plugins or apps?

They were called Are they interchangeable? Yeah, they're now introducing this concept of plugins that also contain skills. That's a whole thing that we're trying to figure out. Yeah, naming's tough. Name is, name is really hard. But these plugins, you can build

a changeluk plugin and if people have it installed, they can go at changelok, find me an episode about GraphQL and it will hit your tool that searches through all your episodes. and then we'll render a little change lock player widget. And it can play right in there? Yeah, they can play right. It's just HTML CSS in JavaScript.

So anything that the web can do, we just eye frame your widget into chat chabitian. So anything that the web can do, you can do. So you can just have a player in there. 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 yourself 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 poor taste let's just say

how do you deal with that? I don't have poor taste but let's just imagine for this hypothetical situation I do have poor taste. That isn't called Adam. That's right. We certainly review all the submissions

and make sure that they are high quality because ultimately you know the last reported number externally was that we have 9 of million weekly active users and for something to hit the 900 million weekly active users' phones, there's just a certain bar that you have to hit. But within the bounds of it being a good quality experience,

you really have a lot of freedom to render, to express your own brand, because ultimately these things are, you know, if I go talk to the change log and then it renders the change log player widget, that widget people know that it's the change log. And so it's looking like change log is totally a reasonable thing, right? We're not going to make it look like chat chbtee. entirely. And so people can certainly express their own brand in these widgets. You know, this makes me think because of the intelligence that is inherently behind

Shack GPT 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, but I'm just thinking, like, if someone's trying to browse something, Do I want to build that browse intelligence in my app? 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 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 on to the change on website right now pick any episode but there's no intelligence there even our search is not that intelligence 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 as an SNSS smart new search inside of chat GBT because I have a plug in there for change log 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, you know, what I am or who I am. And then you all can provide the intelligence because at change log, give me all GraphQL or all episodes with Max on it, et cetera. And maybe you get back one for now in any years, maybe two or three, who knows. But now you all deal with the intelligence and I can just skip it. I don't have a good answer to this question, except to say that I'm very, I'm trying all the apps that are coming in. I'm trying to see what kind of fun experiences people are building.

I don't think there's a world where people don't build their website anymore because they can build a JashubT. But maybe there's something people can build in Jad ChubT like you're saying, that they couldn't build otherwise. And that's the kind of thing that I'm really interested in seeing. 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 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 a stream. And we live, like I mentioned, in the pre-call in the hill country here in Austin, Texas.

It's actually called Dripping Springs. If you ever come out in 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. Some like them, cedars, they're kind of ugly. They give me allergies because I have them today. But a lot of great live oaks and various styles of oak trees,

mesquite, you name it, post oak, et cetera. Point I'm getting at is that Zill is probably a better example. Could, if we in the later end, 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 chat gpt to build artifacts that i extract and pull down to my disc and then have to be the API to move them elsewhere i can sort of do this give and take back and forth this smart layer on top of my Zillow search

and help me build out my future five acres next to a stream. That's actually exactly what I'm using it for right now, the Zillow app and in Jad ChhapD personally. We're looking for potentially 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 in Jad Chubit and I'm like, hey, I'm looking for this kind of a house. 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 they'll go, all this property seems like based on the description and the photos, like that could be a really good fit for what you're looking for. Go look at this one first. And so it's been really helpful for that, for that, for sure. That's a great. 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, this, you know, give and take from Zillow and then push back to Zillow. Is that a possibility? I actually don't know off the thought of my head of Zillow has built a tool like that, but they certainly could build it. Is that part of the framework, though? Yeah, for sure. It's just MCP tool. So you can build an MCP tool that's like, hey, I want to save this home to my favorites.

And then JachbD can call that tool with the home that you selected and save this tool to your favorites. Save this house. Save this. Yeah. There's a lot of directions you could take that. Man, wow. Okay, cool. It makes sense than why you left Shopify to say yes to this because that seems pretty

pretty cool to build on. Yeah, I would agree. Well, Max, I really enjoy going through your journey, man. Like it's, you've had a really wild journey from, from open source to founding a company to working at GitHub to, you know, moving to Gatsby, to building your own company still late and how that I got acquired. And now being an open eye on this plug-in 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?

I just want to say thank you for having me. I've been listening to the change log 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 change log episodes. I've been a long-time listener and fans, 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 I'm really touched that I got to be on here with you together. Man, it's so awesome to have you here. I'm actually, you know, we consolidated some things here on the network. about a year ago, 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 change log as its own 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 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 webpack 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 these new fruits and new labors that I'm working on now that I'm solo again in this endeavor. But yeah, good luck. Thank you for sharing that though. I'm glad you've been a listener for all these years. 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. Oh, 100%. All right, Max, well, thank you for your time. Thank you for your journey and sharing it. Appreciate you. Thanks for having me.

Fun times going through fun times. Of course, from back in the day, spec.fm. Love spec. And of course, Spectrum. Fun times. Herein Max's story. Man, get to work on some cool stuff at Shopify, one of the coolest companies ever.

And now Open AI also one of the coolest companies ever. What a treat. A big thank you to our friends at Coder, our good friends at WorkOS. And our good friends, and 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. But that's it, this show's done. Thank you for tuning in. We will see you next week.