# From Open Source to AI: Strategic Shifts in Tech Leadership

**Podcast:** The Changelog: Software Development, Open Source
**Published:** 2026-06-05

## Transcript

What's up?
Welcome back.
This is the ChangeLog.
I'm Adam Stachowiak, and today I'm joined by Max Wilber talking about the long road from open source to open AI.
Max has shipped a ton of open source.
He helped build Spectrum with the Spec.fm crew, sold a GraphQL CDN after realizing he captured almost the entire market.
He helped Shopify ship Horizon in six months.
And now he works on the chat GPT plugin directory and the app platform.
A massive thank you to our friends and our partners 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, 4Coder.
Nicky, what is a 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 DevRel 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 laptop set up and ready to start doing their first time of code.
And, you know, the time to first commit is a metric that almost everybody knows.
And the reason they can't do that is because there's a lot of tribal knowledge out there.
They got to go talk to other developers.
What are we using?
Where do we get our dependencies?
Are we getting them from public?
Are we getting them from private repositories?
But there's also the security and the supply chain aspect of this.
When you have local machines.
out there.
Look at like the Shai Halud, you know, that virus that went out not long ago.
This was a compromise of the NPM public repositories.
They went and downloaded things.
NPM did what it did.
Next thing you know, you're compromised.
But when you use something like what we're doing with cloud development environments, then you can mandate and you can put restrictions on there to say, hey, you can only go get your packages from our private repo.
Those packages are expected to have been thoroughly vetted.
We know that they're clean.
Now, does this stop everything like Shai Halud?
No.
If that compromised package gets into your private repo, you can still have that.
But it really reduces the surface area of the attack.
And it also reduces the blast area of the compromise should it happen.
Because if your laptop gets compromised and you have to kill the laptop for whatever reason, that's weeks out of work while you're either fixing that or you're getting a new laptop in.
The cloud development environments allows you to kill that, start back up fresh, and you're back and running in five minutes.
You don't have to wait all that time.
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 Stoiber.
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 left within three months because I was like, this is not at all what I want to do.
What I want to do is make things for people.
And so that's always been what's driven me through my open source work, through my startups.
I like making things for people.
I like getting things into people's hands and having them use it and then get something out of it.
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 style components, React boilerplate.
What were some of like the earlier inputs and I would say like small but big wins that you've had that built you into the person that could be part of the team that built Spectrum, that got acquired by GitHub, et cetera, et cetera?
I think people look at my career and they see all the successes, right?
They see style components, they see Spectrum, they see Stele, they see Shopify.
That's what I see.
What people don't see is all the things that didn't work.
And so I think really my story is one of making lots of things.
Like in the open source world, I made React boilerplate early on that got really popular for a while, and then I made style components that got really popular for a while.
And both these open source projects are wildly popular, top 200 projects on GitHub by stars.
All this, lots of lots of usage really changed the way people think about React and developing applications.
What people don't see is the 298 other open source repositories that I've made on GitHub that no one has ever heard of 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 React, I played and any of my open source projects became popular.
The reason I even started making things open source is because I got really annoyed when I had to solve the same problem multiple times.
I would be building something and I'd be like, ah, 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 JSON that if one little line was a little bit wrong, the whole thing would fall apart with an error message that told you nothing about what was actually wrong.
It was really hard to debug.
It was a whole mess.
And so the reason I started making open source projects is because I ended up solving these problems over and over again as I was building things.
I was like, that's really annoying.
Let me just go put this on GitHub so that I can reuse it.
And some of those things like React Boilerplate ended up, turns out that other people also have those problems and also wanted a solution for it that they could just reuse without having to solve the problem themselves.
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 that component $1?
You'd be a billionaire by now, given how many installs you have.
And of course, that's not how the world of open source 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...
One, I've gotten so much from the community and I build upon the shoulders of giants that I think it's worthwhile to give back and make sure that my ideas also contribute back to the ecosystem.
That's the sort of, you know, beautiful altruistic motivation, but also a very selfish motivation.
I really benefited from the things that I made becoming popular.
And of course, if I had charged for styled components or React Boilplate, if I had charged for my open source projects, nobody would have used them, right?
There's no commercial, 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 ultra-sign motivation, but I think it's also worth saying that there's very much a benefit that I've gotten, a very selfish benefit for my own career, my own life, and who I've become through sharing these ideas and projects.
And so I think it's that combination of I get to help the world and also in return, I get rewarded by the world.
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, considering where you're working at, every single daily life?
Like, I'm a daily active Codex user, just to be super clear.
I love Codex.
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 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 OpenClaw 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 a successful.
People tried it and they went, oh, this works exactly the way I would think it would.
That's great, right?
Like, 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.
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'll get there if it's not there yet.
And at that point, abstractions are the only thing that matters because they make a big difference in how people use it.
But then beyond that, if AI gets even better, do abstractions even matter?
Or are we just going to be programming in English?
I don't know.
But I know for myself, since I joined OpenAI in December, I've shipped many, many PRs here and made lots of changes to ChatGPT.
I haven't written a single line of code.
I'm just managing codex agents now, you know?
And I know many people in the industry since December have had much of the same experience.
And that's crazy.
Yeah, it's so wild that for a while there was taboo to say you're using an agent.
You know, it was actually expected because like we want it to complete the line.
We want it to complete the thoughts.
We didn't want it to have the thoughts, so to speak.
And, you know, for me, a lot of things changed back in September, I want to say last year, and a big swing when Opus 4.5 came out, and then obviously the advancements you all made with Codex and GPT, I think it was 5.4, maybe 5.3, I think is what it was in December.
And now 5.4 is just so revolutionary in terms of how it helps me think.
And yeah, I mean, I can probably go on deeply about that, but...
a lot of things really change for everyone.
And I think we're in such a uniquely different world here today at the end of March, 2026, than we definitely were at the tail end of March, 2025.
Like it's dramatically almost like a 180 in terms of difference in how we code or not code.
A hundred percent agree.
I think, I still think even if code is not the mechanism anymore, it is valuable to provide things to the world.
whether they're ideas or solutions to problems.
I think that is always a valuable thing to do both for the world and for yourself.
I just don't know that the shape of that will be called 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 a 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.
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 we're using Node.next and we're using all these different things to make TypeScript play well with Node.
There's still that problem there.
It will get more and more solved, but there's still this required incumbent knowledge to direct these things.
Like a rando who doesn't know about developer, landscapes or different trustworthy platforms like Node has been for so many years.
Sure, I know BUN is amazing and it is up and coming, but it's not quite there yet to Node's level.
And the people behind Node are very smart and very articulate with how they direct Node to be a runtime, not a compiler, which I respect.
And so there's still this dance from TypeScript to Node to platform to running.
It's not just prompt and magic.
100% agreed.
I think at the same time, the trajectory of where things go is quite impressive.
100%.
And the question is just, if and when it asymptotes, 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 a 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 he wants to make sure the boxes are drawn in the right way and connect together in the right way.
And I feel like that's what I spent most of my time on now.
The implementation of it, I review much less than thinking about the overarching architecture and the boxes that exist and how do they interface with each other?
How do they talk to each other?
Is that actually the right level of abstraction?
Or should we be solving this problem at a different layer, at a different level, in a different way?
That's most of the time that I spend 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 could probably gush deeply about it.
And you get two 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 in the day of 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 Bryn, my two co-founders, they were running this podcast network called Spec.fm.
And they had, I think, four or five podcasts at the time that they were running as part of Spec.fm.
And they were using Slack at the time as their community platform.
They were trying to connect their listeners together.
And so they created the Slack instance.
And eventually the Slack instance grew to tens of thousands of people.
And Slack came to them and said, 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, the classic sort of state old forum style conversations.
But that wasn't really an equivalent to a Slack that was public.
And so that's where 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 DMed me on X on Twitter and was like, hey, Max, we hid this bug that I think is a style components bug.
Have you seen this before?
And I had known of Bren and Brian for a long time, and I'd been an avid listener of that podcast.
And so I replied back, and I was like, hey, just give me access to the code base, and let me take a look.
I will go see if it's a bug in style components or something with how you're using it.
I'll go figure it out.
And when they gave me access, and I realized that they were building this community platform, I realized that that is exactly what I need for my open source communities, because I was having the exact same problem.
I had made React Bodyplate 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 large open source projects like that is that the maintainers end up being the sole supporting pillar that answers every single support request gets answered to them.
Every single bug report gets triaged by them.
Every single incoming contribution gets triaged by them.
And it ends up being a huge volume of work.
And sometimes other maintainers step up.
And in the case of Style Components and Break Bullet Plate, both I was very fortunate to have 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 source projects.
I have the same problems.
I want the same solution.
And so I ended up joining them and we ended up co-founding Spectrum.
And that's really...
where it all started was from their podcast network and them using style components and then reaching out to me.
And I think that's a great example of a case in my life where if I had never made style components, I would have never been connected to Bryn and Brian.
And so the world did hopefully greatly from me inventing style components.
But in return, I got this great journey of founding a startup with two of my now best friends and lots of learnings and growth through that that really defined my career.
Well, friends, I'm here with a good friend of mine, Michael Greenwich, founder and CEO.
of WorkOS.
Michael, Auth4Agents, I feel like this is burgeoning.
It's kind of happening all of a sudden.
What's the state of the world for Auth4Agents?
Yeah, it feels like Auth4Agents 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 auth for 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 customer's Google Drive and connect it to Salesforce and HubSpot and connect to Slack and all this other stuff that they're going to use and do it in a way that's safe and secure and managed.
That's one type of auth for agents, kind of data access auth.
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 OpenID Connect and SCIM 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 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 and 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 AuthKit.
Okay, that's how I authenticate my CLIs, my APIs, my applications, all that good stuff.
WorkOS.com is where you go.
Try it out today.
A million users with 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 was it like, hey, you are joining, you're 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.
Bryn and Brian were building this platform, but initially I think we're really building it just for Spec.FM, which is why the name ended up being Spectrum.
It was meant to be a play on words.
Yeah, that's why I even messed it up initially when I asked that question.
I thought it was called Spectrum.FM, but then I was like, maybe not.
And so you corrected me.
So even in my own brain, I'd had the podcast network Spectrum in my brain.
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 also benefit from this, 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, Bryn a little bit more than Brian, and they had sort of...
code it together.
They were designers, but they knew how to write code.
They were designers who coded, which I know back in those days was a big discussion, should designers code or not.
Which I think now with coding agencies, 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.
Production code, 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 the co-founder and CTO.
And then for the next year and a half, we built out this community platform that lots of open source projects mostly ended up using to connect their users together before we got acquired by GitHub.
And it was just us three in our bedrooms 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-seed round 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 indexed, 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 a 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 there wasn't a big business to be built here.
Unless we were going to do ads, which we didn't want to do.
And so we were like, we couldn't find a business model that would work.
And so then we said.
Maybe we just got to do this as part of Kitsub.
Yeah, that's interesting.
Definitely don't want to do ads and a thing like that.
I mean, there's a temptation to, but that becomes a version of a lifestyle business in a way.
But then, you know, I'm curious how GitHub came to be.
Was it just that you had natural gravity and they came to you?
Was it that you knew somebody who knew somebody and they're like, hey, we need issues isn't enough.
We need what has now become discussions.
How did that?
conversation initially play out.
Yeah, there's this other guy named Max, Max Schoening, whom 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're 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, Spectrum was a sort of, combination between Slack and a traditional forum.
It was real-time but also had threads.
People were meant to chat live.
If you think about GitHub discussions, it's not exactly chatting live.
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, you know, 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, but it's not the same as...
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 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 acqui-hire changed the trajectory?
While 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 taking 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?
It's 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.
Right.
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 Bynne and I have 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 those, 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.
You know, the one person that I know who bought something back from GitHub was John Nunamaker.
Do you know John Nunamaker by any chance?
I know you both worked at GitHub probably at the same time.
I don't actually.
John Nenemaker.
But he had worked at GitHub similar to you.
And the way in was early GitHub.
Like when it was just Chris and Tom and a few people, it was super early GitHub.
And they came through an acquisition of their company.
And then on his way out, in his exit, he left with the company.
He came in getting acquired.
And that was kind of interesting was that he was able to take back what he had come in with.
I think that speaks to 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 was joking, but I bet they would.
Because it's just IP sitting there books that it's like, we have to keep maintaining this at some point.
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 they acquired you all for.
That's something interesting about GitHub and what I know at least through John's story and I think maybe your story to some degree because I bet you they'd be generous and be like, here you go.
Go ahead.
Have fun.
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 all I see about that.
Okay.
So take me into, you know, what, what more important is to share about that spectrum journey from spectrum to GitHub?
Was it a harsh reality check when you first got into GitHub?
Was it uniquely different?
Did it help you grow in certain ways?
What, what really manifested for you when it came to three dudes building the thing in their bedrooms, as you said, to getting acquired to now we're.
exploring more and building out what has become GitHub Discussions.
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, for the, there were ups and downs as there always are, and there also were at Spectrum, but for the most part, I really loved working there.
And, you know, years later, With my second company, when we were going down the acquisition path, I think that was definitely an important data point for me to know that these things can work out okay.
Because often in the industry, you hear these acquisitions and then the founders get grumpy and they leave and there's all this public feud that sometimes happens.
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 Getsub at that time and I had a really great time.
How did you go from You know, 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, you know, they were a Series B startup.
And ironically, they had all the classic chaos that you've heard about.
of Silicon Valley startups.
It was extremely chaotic internally and a bunch of drama happened, some of which eventually spilled out publicly.
And so the company kind of, quite frankly, imploded itself.
When I was there, we had 60 people.
And then when I left, we had 25, 30 people maybe.
A new CEO was brought in.
And then some years later, it got taken over by Netlify and became a part of Netlify.
But that chaos and that drama was really kind of frustrating to me because I felt like Gatsby had all the right ingredients to succeed and was sort of stumbling in spite of itself.
And so seeing that as an employee and not really being able to do much about it 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 a team without all that drama that really enjoys working together, that really has a good time and gets along and just ships cool things that the world needs.
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 my own startup 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 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 cooker situation was like a magnifying glass upon how fast I could grow when I'm put into a situation where I have to grow.
And so I wanted to go back to that.
I like to say that as a company, Companies are limited by the growth of the founder.
And I think that's something that people who aren't close to founders maybe don't necessarily understand.
But the really, really great founders, all of the really successful ones, when you talk to them, you realize they're incredibly self-aware humans.
They know exactly who they are.
They know exactly how they are received by the world.
And then they can play with that and they can integrate that.
having spoken with many of those folks, it really becomes very clear that they're all, that really unifies them, that really ties them together.
And I think that's not by accident.
In fact, I think it's a requirement of the job in order to build.
And when I say really big business, I mean like a VC backed, you know, companies who are trying to become trillion dollar companies or billion dollar companies, you know, like building a really fast growing hyper growth startup that is trying to swing big and go, you know, go for home runs.
It requires an immense amount of personal growth on the founder's part.
And if that growth doesn't happen, it's a limiter to the whole company.
And so in a way, founding a startup is a forcing function for you to grow faster.
Or it was for me, at least, for me to grow faster than I'd ever grown before.
And so I wanted to get back to that level of growth.
I wanted to grow that fast.
I know, I know, I feel my potential and I feel that I could really achieve something and that I could really figure myself out and figure out how I interact with the world.
Those were the three reasons why I went back to founding a startup.
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 really much harder than meets the eye.
I mean, it's nice to have a network for sure, right?
Or to be a giver, like you have been an open source and to be seen as somebody that's 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.
Because there's a lot of things that break down a team that begin with morals.
I think we're all pretty good people, but some people have uniquely different perspectives on life.
The way they raise their children, where they want to live in the world, how they think about money.
All these things really.
to get 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, my co-founder, and our CEO, Sue.
And we were looking around and assessing what isn't working at this company.
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 an awkward nerd, but not as strongly as people might suspect from an actual introvert.
But part of being an introvert is that I actually really value human connections.
I value talking with humans.
I actually really enjoy that element of human nature.
And so I find it very risky, personally, to give critical feedback to people because there was always a chance that that critical feedback could lead to disconnection.
And so then all this effort that I 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 it requires that level of introspection and understanding yourself.
Otherwise, I don't think you can succeed in building a really great team because you have to understand yourself and how you interact with the world and then be willing to 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 Stellative.
It was really me figuring out who I want to be and Tim figuring out who my co-founder Tim figuring out who he wants to be and through that, what kind of company we want to build and what kind of team we want to build.
And then the second thing I'll say is we knew that we had no idea what we were doing.
We went into Stellative and we thought we can do a better job.
But also we knew we had no idea how to do a better job.
We just thought we could go figure it out.
And the way we went and figured it out is we got help.
We talked to lots of people.
And eventually we found Sue, our eventual COO, who 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.
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 that I felt it was risky.
And that's why I wasn't, that's why I was subconsciously not doing it as much as I needed to as the leader of a company.
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 use to this day is called the coins framework, which is just an acronym for context observation impact 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 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 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 relationship.
And so 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 caused you to interrupt him?
What feelings were you having and why did you feel the need to cut him off before you finished saying what he was saying?
And so you go, context is what was the situation?
Impact was...
observation is what happened?
Impact is what impact do I think it had and the next steps is let's talk about what we do now and so 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 the you know, it would have just Lots of things wrong with that way of giving feedback And so by focusing it on the thing about 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 it leads to this connection, then that actually isn't as...
harsh to me anymore because it's, that's my role as a leader.
I have to do this and we have to get better together.
And I'm, 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 worked on that now means I'm much more comfortable giving redirecting feedback.
Yeah.
I mean, it's so ingrained in you, it seems that you were able to just.
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 Kaz, one of the leaders at Shopify called Say The Thing.
Because I really wanted to encourage people to say the thing.
It's really, really important to the success of a company and of a team that people say the thing to each other.
And so people feeling comfortable doing that is a key unlock in making a better team.
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 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 it.
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 you 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 Stelit 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 business-y 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 the big pivotal moment where everything changed.
It was a much more gradual change than that.
And also it was one of many, you know, 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.
I love it.
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 Shopify, which we could talk about that story.
But whatever you did worked.
Whatever you did from a product standpoint, a company standpoint, worked to build something that the community used.
Can you talk a bit about what Stellate is and what it did so there's some context that we've been talking around it and mentioning it by name, but not really contextually like since we're using the coins framework, but just using the C from that.
What 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 Bynne 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 some time 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 GraphQL and Spectrum.
And so our entire API Spectrum was a GraphQL API.
And when companies acquire other companies, they want to make sure that they don't buy any liability.
And so when Gitsub acquired Spectrum, they did a big pen test with one of the worst leading pen test agencies where they put eight pen testers for a week to try and hack Spectrum.
because they wanted to make sure that when they acquire Spectrum, they're not acquiring a data leak.
And so, honestly, Bryn, Brian and I were, excuse my language, shitting our pants when they said that they were going to do this, because we were just three dudes sitting in our bedrooms, building this product as fast as we could to try and make something that people wanted, and then when people wanted it, to try and not have it break.
And so it's not like we had security people on staff.
It's not like we had security experts who really knew what they were doing.
And so anyway, these paint 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.
And I actually largely created GraphQL for that.
And it's GraphQL in combination with actually Vercel, funnily enough, because we weren't doing our own hosting.
So we weren't managing AWS, IM, you know, access anywhere.
We were just using Vercell and all 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 user is not an admin of this community, they cannot take this action return or throw an error unauthorized, right?
That's it.
That's literally all we did.
We just made sure that every single query and mutation had an access check.
And not all of our access checks were perfect.
They found some issues with moderators of one community's channel could moderate another community channel or something.
They found some minor 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 an access check that made sure that when you were accessing data, you were actually allowed to access it.
I actually largely credit, ironically, GraphQL with our security posture because our security posture basically consisted of use hosted providers and then have access checks in every single create mutation, which I know sounds ridiculous to any real security people, but actually worked well enough for the scale that we were at.
And so I was a big fan of GraphQL from that experience.
I enjoyed using it.
I enjoyed building the API.
I enjoyed using the API.
And then the fact that the security aspect was really nicely solved meant I...
I really enjoyed it.
And so one of the big challenges we'd had toward Spectrum was as all these open source communities started using it, our traffic went skyrocketed.
And I'd chosen this database called WeThinkDB that was a startup that was building this big database.
And the big selling point of WeThinkDB 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 fix it.
It was like a nightmare.
And so while this database was crashing every night and I got paged and woke up, I realized we were going to have to switch database.
We could not keep this database.
We had to switch to something else.
But that was going to be a major project.
And so I was like, well, how do I...
Is there a band-aid fix that I can put on top of this so that while we're switching over the database, we're not crashing every day?
And the thing we ended up doing was we put a cache in front of our traffic.
Because of course...
Let's not hit the database.
Let's cache things.
Exactly.
It's the obvious solution.
And also our use case was very public and read-heavy.
It's a public forum.
Most of the data is public.
Anyway, 99% of our traffic is reads.
There's very few writes.
It's perfect for caching.
Now, unfortunately, nothing for graphical caching existed at the time.
Even though, ironically...
Everything that GraphQL 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 denormalized caching that works really well.
And so in my head, I was like, why can't I just take ApolloClient or Urkel and put it on the server?
It'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 match the query and then return the same JSON, like really rough Redis-based version of this caching.
But in my head, I always had this idea like...
This has got to exist.
You can hash 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, blah, blah.
And then years later, a common friend of ours pinged me and he was like, hey, my friend Tim has built this prototype of a GraphQL CDN.
Isn't that what you were talking about all these years ago that you needed?
I think you should go talk to him.
And then I had known of Tim, but I never met him.
And so I met him.
And through that, we decided to found this company that eventually became Stellate.
And what we were building was a GraphQL CDN, a GraphQL edge 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 rest level cache that works as well as that, that works generically.
You can build custom caches, of course, as lots of people do, but you can't build a generic solution that works as well as our solution did with GraphQL for various reasons.
This episode is brought to you by our friends at Notion.
You've got a coding agent that writes solid code.
But when you point that coding agent at your actual project, the specs, the roadmap, who owns what?
And it's guessing.
The smartest agent gets stuck without the right context and the right tools.
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 Notion's hosted sandbox of your code.
No provisioning infrastructure.
You write it, deploy, you're done.
And then you build on any tool your agents need with the predictability, parallelism, and the custom logic MCP cannot deliver.
And because the workspace and the platform you build on are the same thing, it's built for teams from day one.
Permissions and governance 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 changelog.
That's all lowercase letters.
Notion.com slash changelog to try Notion's 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 requires the client to do something called field selection.
So instead of just hitting an endpoint like 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 one, 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 on either 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 ID 1, 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, products, reviews, users, the authors.
and then we would cache each part individually.
And then when a new query came in, we would look at everything we had cached and we would go, okay, all of this data that this client needs, what do we actually already have in the cache and what do we need?
And then we would only send a request to the origin for whatever piece we didn't have in the cache yet.
And then on top of that, we could stream back all the data that we had in the cache already to the client because GraphQL clients support this.
And so we were a completely transparent layer that sat in between the GraphQL client and the GraphQL server.
And all you had to tell us was, of the product, you can cache the title, the description, and the photos.
But you can't cache the price because that's dynamic, and you can't cache the availability because that's dynamic.
And you would only basically ever get requests for the product availability and the product price.
And then everything else, we would try to keep in the cache as much as we can.
And so we enabled people to get to really, really high cache hit rates with very, very little effort.
Because our cache was natively built on GraphQL.
And in fact, if you're listening to this and you're thinking, I need this right now, Stelite still exists.
It got bought by an agency called the Guild and you should totally go use it.
It works amazingly and definitely.
We've done a great job maintaining it.
Yeah, that does sound pretty cool.
But only if you're using GraphQL.
Is GraphQL still popular?
I feel like it's kind of like not popular.
It's been fraught with challenge.
What's your take on the state of GraphQL as a tech you should pick up today?
Yes.
What I just told you was the story of the product.
I will 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.
In the age of AI, where companies are getting to $100 million of ARR in whatever, 18 months, this doesn't sound as impressive anymore.
But for a B2B enterprise startup, we were a hockey stick, man.
We were doing relaunch and we were a hockey stick straight up.
We were doing really well.
And it was because lots of companies were using GraphQL and some of them had this problem and nobody had built the solution.
And so we had finally built the solution.
So we hit this market need just dead on with a really great solution and exploded onto the market.
And so we raised a bunch of money.
We ended up raising $30 million.
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 closed some of those.
But truthfully, our growth went...
asymptotic hockey stick and then just flattened out.
And in hindsight, the challenge was we had built a really great product for a market that was just too small to build a venture-backed company in.
The product that we built was amazing.
We had effectively near zero 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 GraphQL caching ended up using us and then they never left because they still needed GraphQL 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 GraphQL rate limiting, we ended up building GraphQL metrics 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, because he got burnt out.
And I told Sue and I was like, I don't think this is going to be successful.
We're going to have to either pivot completely, do something else entirely, like just throw everything away that we have and do something else entirely.
Or we're going to have to shut this company down somehow.
And you know this is saying that companies fail when founders give up.
And in fact, companies only fail when founders give up.
Which is obviously an exaggerated statement, but it's actually very true.
And at that moment, I give up.
After three years of trying really hard, I was tired.
I did not want to go from scratch again.
I did not want to start from zero.
We had lots of money left in the bank.
I could have done something with it, but I personally didn't have it in me.
I 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 were talking about earlier, I'd spent many years building a really, really great team.
And I'd spent a lot of time working with myself and working with the team.
We hired some amazing people.
And so I really wanted to take care of the team.
And then I also had worked many years with these customers that we had that relied on us as critical infrastructure.
We were a big part of the reason why their products didn't go down.
We were used by Puma, 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.
That's ridiculous.
And so I realized I want to go down this acquisition path.
I want to go down the path of an acquisition again.
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 were doing.
GraphQL companies.
CDN companies, companies that were using GraphQL, API companies.
It ended up being a list of maybe 70 companies and ended up talking to probably 90% of them.
I just treated it like enterprise sales and I went and talked, I got intros to every single company, ideally to the founders or to the leadership.
And I would go to them and I would explain the situation and I would be like, hey, look, is there a fit here where maybe the team at the product 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 forth.
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 projects in the graphical space and we're very excited too.
to buy Stellate and take it over and keep it running and maintain for our customers.
And so Stellate still exists.
Our customers still use it.
It is still a great product and they keep making it better.
And then the team ended up getting a great outcome in joining Shopify.
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 pejorative, but is it glorified job placement?
Yep.
product, obviously, company, 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 acquihired the team.
So everybody got a great deal out of it, and 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 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 acquihiring the team is that still it could later go, oh, you hired all the team.
Now you're using the knowledge that they gain and the IP that we own at Shopify, and so we're going to sue you.
And so really, during an acquihire, what they're paying for is a license to be able to use the IP that Sellit has that is irrevocable and global and blah, blah, blah, all these things.
And then because of that, they can hire the people without any legal risk on their side, and that's what they pay money for, basically.
And so that's how acquihires work.
And so we did that acquihire, and then I told Shopify, I was like, hey, it's part of this deal.
I'm going to come on board too, which is what they wanted.
I'm going to stay behind at Steli for a little bit because I'm going to do another acquisition to try and take care of the product and the customers, and I'll be there in a couple months.
And Shopify, much to their credit, were okay with that and said, you do what you need to do for the next three months, and then please join us in three months.
And so I then spent three months negotiating with the guild who acquired the actual IP of Steli.
So they acquired the IP, the product, the customers, the business.
They took over that whole thing, which is what acquisitions normally are when they're not acquiters.
As part of this, the really interesting piece was that I had to negotiate between these two parties because the key critical load-bearing, literal single line of legalese that really mattered to this deal was that the Guild would agree to honor Shopify's irrevocable license to the IP that Slate had.
That was a critical piece because all Shopify cared about was we want to be able to hire the people without having the legal risk of you suing us later if we use their knowledge.
We're buying the knowledge and we're buying the people and so we're paying you money for that.
The Guild wanted to depart 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 agreed to honor Shopify's license to the IP and so Shopify was happy with it and then the Guild was happy with it because they were like, well...
Shopify can use it, but for everybody else, we'll still keep selling Shopify as Stellate.
Right.
So Shopify's deal happened first.
The Shopify deal happened with you, Stellate, as you were still founder.
You hadn't left yet.
And so it was a deal that was built into the company that the guild was purchasing, the IP, et cetera.
So they were purchasing not just the IP, but one critical liability, which was the in-perpetuity usage of the license of irrevocable to Shopify.
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.
The reason why I bring that point up so clearly or try to make it so clear.
And 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, this thing I'm kind of aware of that I do.
But the reason why I bring that clarity here 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 as a founder that you either needed to have more gas in you to continue to climb.
or you had to pivot because the market just didn't have enough TAM, which is really interesting because you acquired the entire addressable market.
That's not frequent in a business.
You look at your TAM and you look at your SOM and then 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.
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 and that's how I have to go.
And I'm also done with this.
I'm done with this product and this company and I want to do right by it.
But the way you sequence that acquisition and the process is a masterclass, honestly.
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 and the accountability in a very good way based on what I'm hearing 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 talked about product slash one, which is like an API endpoint.
And where else do you have the world's largest shopping network, so to speak?
Shopify.
That's cool.
So it was a good deal and you ended up somewhere cool.
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 and what did you do there?
You know, Shopify is a very special company.
And I'm extremely fortunate that I got a chance to play a small part in it.
When Toby and Shopify acquired Sellate, Toby has this philosophy.
And I mean, Shopify is a company built around entrepreneurship, right?
Shopify's customers are entrepreneurs.
They make things and then they sell them.
And Shopify helps them do that.
And so...
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 work in, but kind of like a GitHub, nobody really knew what I would do.
I joined Shopify and my first week, I didn't have a job effectively.
And my job was really one, obviously onboard Shopify goal.
set up your laptop and all that stuff.
But then two, and most importantly, was go figure out what the right role is for you.
And I worked with my manager, Matthew, and then Toby and Vanessa, the product leader, and a bunch of other people.
And we looked at a bunch of different options and I talked to a lot of people.
And what ended up happening is that we found this perfect role for me, which was to be the director of engineering for liquid storefronts.
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.
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 Toby invented 20 years ago.
There's a bunch of dev tools around Liquid, a VS Code extension, a CLI, all kinds of things that we maintain, that my team's maintained.
There's the Onesor Editor, which is this website builder, kind of like Lixos, Squarespace, or whatever, Webflow, Framer, where you can drag and drop, edit your webshop, and make it look the way you want to.
There's all kinds of workflows around this.
And anyway, I ended up running all the engineering teams that build.
All of that, which was a great fit because it turns out it's highly related to what I thought about with style components 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 it ended up being a great, great fit.
So masterclass acquisition.
And then you have the Shopify world as your oyster to choose from.
Like, that's kind of cool.
So what attracted you to the liquid storefronts?
Like, 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 so, and then Toby has built Shopify into 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 Storefronts and the online store faced.
And then also, over the course of Stellate, I had, again, I've 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 at Stellate to try and get better at who we are.
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.
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.
I'm the right person to work with this team.
And so I came in and I 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 of Shopify at the time.
It was a new default theme with a completely overhauled theme platform that the team had been working on for many years.
And we got it done in like six months.
What usually would have taken probably two years.
This was a two-year project.
And 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 OpenAI, 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.
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 OpenAI kept telling me to come talk to them about it and kept telling me that I should think about working here.
And they kept pinging me and they kept pinging me.
And eventually I was like, whatever, let me just entertain this.
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 JAT-GPT contained something that I had never had before, which is working on something that my kids and my parents use.
I've only ever worked on DevTools and then on Shopify, and even Shopify, I was working on Shopify's DevTools for the most part.
And even Shopify, which is, you know, is a publicly traded company that's quite well known, my parents kept thinking I work at Spotify, and they kept saying Spotify.
keep explaining to them that no, that's something different.
We don't quite focus on music.
And I realized as I was thinking through this opportunity to work on ChatGPT that working on something that my kids and my parents use is something that I've just never done before.
And there was some very, this is very like a caveman-like alluring element of like, oh, I work on something that the people that I love the most, that I hold very dear, use pretty much every day.
And I can...
improve this thing for them.
And so that felt, I 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, I just, I can't say no to this.
I, I have to, I have to go take this opportunity.
And so despite how painful it was, and I swear to God, it really was.
If you ask, 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, there's limited ability to share.
Too much, but what, I mean, I know what ChatGPT 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 ChatGPT.
Like, if it wasn't for...
The fact that ChatGPT exists and even therapeutic 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.
Because ChatGPT has this full framework of who she is, it's able to see her and what she's truly doing in a different light and be her worst and best critic and her best encourager when she feels inadequate.
And she's totally adequate, but it's this.
It's this layer that was never there before, this magic box just to sort of say hello to.
So I clearly know how important ChatGPT is.
I personally use ChatGPT.
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 Claude has done.
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 JATGPT app store, which is now called the plugin directory.
And so the goal is, in order for JATGPT to be even more useful in our in our users' lives, it needs to connect to more and more things that our users use every day.
And as part of that, we're building on a platform that allows other companies to build apps that integrate into ChatGPT.
And these are MCP servers, so there's tool calls and there's resources.
But also, we worked with the MCP UI creators and then turned...
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 JGPT, you actually get a Zillow map inside of JGPT and you can talk to JGPT about the houses you're seeing.
If you're searching for a hotel with Expedia, you can talk to JGPT about the hotel you're seeing.
And so we're exploring new ways that we can combine the world outside of JGPT with JGBT 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 I think we now have, we went from dozens to hundreds of apps in the app store over the last few months that you can not install.
through the directory and connect to things they use every day.
And so this is an incredibly active area of investigation.
And in fact, it's a really active area of collaboration because a big part of this is our partners saying what they want to accomplish, what would they love their apps to be able to do in JGPT, 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 JGPT in different ways.
And so it's very fun.
Can you speak to the MCP server serving UI?
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 Liat 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 ChatGPT, when those tools get called, they will render the UI.
that are attached to those tools.
And so there's now a spec for how you have to build these UIs.
It's all web-based, so it's all HTML and JavaScript and CSS.
You can build these widgets that then get rendered next to your tool call with the data that you return.
And so you can build these really interesting experiences where you can get JATGPT to do a tool call, and then JATGPT can show you custom UI that you built on top of that.
And it's all based on the MCP spec.
There's now, like I said, an extension to the MCP spec called MCPops.
And you can, like I said, build UI.
Interesting.
What is the relationship with partners?
Is that a platform?
I'm unfamiliar with it, and you can tell me what you can or what you can't.
But if I wanted to build, let's say, a podcast player for the changeable network inside of ChatGPT, would I have to pay OpenAI for that kind of access?
What is the relationship between the partner and having their plugin slash app inside of ChatGPT?
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.
But it's a totally free directory.
Yes, you can build a changelog podcast listener MCP app and it will render inside of JGBT when people use it.
They would have to have the plugin slash app.
What do you call them?
Plugins or apps?
They were called apps.
Are they interchangeable?
Yeah, we're now introducing this concept of plugins that also contain skills.
That's a whole thing that we're trying to figure out.
Yeah, naming's tough.
Naming's really hard.
But these plugins, you can build a changelog plugin, and if people have it installed, they can go at changelog, 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 changelog player widget.
And they can play right in there?
Yeah, they can play right in there.
It's just HTML, CSS, and JavaScript, so anything that the web can do, we just iframe your widget into ChatGPT, and so anything that the web can do, you can do.
I 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 yourselves very seriously, which you are.
How do you deal with rando like me putting my thing in your thing and you accept it and I got 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 900 million weekly active users.
And for something to hit the 900 million weekly active users' phones, there's 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 changelog and then it renders the changelog player widget, that widget, people know that it's the changelog.
And so it's looking like a changelog is totally a reasonable thing, right?
We're not going to make it look like JHPT 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 ChatGPT and everything behind it, obviously, the different models that come out.
Do you see this as a potentially new way to just skip building a website, potentially?
Not so much skip it altogether, 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.
as any individual.
I don't want to only trust you all because I want to give you a lot of trust, but there may be a point where the relationship fractures.
And if I've only built my house on your foundation, then I have no foundation.
But I guess what I'm getting to is like, how, how much of the future or how much of the direction can you share in terms of how people are thinking about how this works?
Because right now you can't go on to.
I mean, you can go into the change on website right now and pick any episode, but there's no intelligence there.
Even our search is not that intelligent.
It's just kind of like dumb old search.
Let's just say that should be an acronym.
DOS, a different DOS, dumb old search.
But if I can take this, you know, the smart new search, SNS, smart new search inside of chat GPT, 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 ChatGPT iterates on every single day.
I could just feed my UI and my data, basically, what I am or who I am.
And then you all can provide the intelligence because at changelog, give me all GraphQL or all episodes with Macs on it, et cetera.
And maybe you get back one for now in a year, maybe two or three, who knows?
But now you all deal with the intelligence and I could just skip it.
I don't have a good answer to this question.
Except to say that I'm trying all the apps that are coming in and 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 JotGPT app.
But maybe there's something people can build in JotGPT like you're saying that they couldn't build otherwise.
And that's the kind of thing that I'm really interested to see.
Maybe a better example to zoom into, just because I'm curious, is like a Zillow one.
I know folks, I have good friends who just...
Just search for future properties.
They're not even in the market, but they're always watching the market for properties.
I have a particular friend who wants about five acres near a stream.
And we live, like I'd mentioned in the pre-call, in the Hill Country here in Austin, Texas.
It's actually called Dripping Springs.
If you ever come out this direction, there's lots of wineries, distilleries, breweries, amazing food because it's Texas, and lots of beautiful space because it's the Hill Country.
And the Hill Country is just like, Texas is notoriously flat, but here in the hill country, it's kind of rolling hills and beautiful.
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 Zillow is probably a better example.
Could, if we want to layer into this, is this kind of plug-in framework.
able for me to not just extract but push back to my Zillow.
So if I can query my Zillow or query Zillow in general and maybe Zillow knows my account and now I'm not asking ChatGPT to build artifacts that I extract and pull down to my disk and then have to be the API to move them elsewhere, I 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 in JGPT 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 and JGPT 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 it'll go, oh, 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 sure.
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, you know, give and take from Zillow and then push back to Zillow?
Is that a possibility?
I actually don't know off the top of my head if Zillow has built a tool like that, but they certainly could build it.
Is that part of the framework though?
Yes, for sure.
It's just MCP tools.
So you can build an MCP tool that's like, hey, I want to save this home to my favorites.
And then Jachipity, call that tool with the home that you selected and save this tool to your favorites, save this house to your favorites.
Yeah, there's a lot of directions you could take that.
Man, wow.
Okay, cool.
It makes sense the way you left Shopify to say yes to this because that seems pretty cool to build on.
Yeah, I would agree.
Well, Max, I really enjoy going through your journey, man.
You've had a really wild journey from open source to founding a company, to working at GitHub, to moving to Gatsby, to building your own company, Stellate, and how that got acquired.
And now being at OpenAI on this plugin app directory, 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 a listener to the Changelog for, I don't even remember.
It's many, many, many years.
I've listened to many, many episodes.
I think I've listened to every single Founder Talk episode specifically.
I've listened to lots of Changelog episodes.
I've been a long time listener and fan.
So thank you for putting out something in the world that's been really, really fun for me to follow along with on my own journey.
And I'm really, 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 ChangeLog 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.
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 edges and stuff like that.
So we still have all that in this mix.
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 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 on your team.
Thank you for sharing that, though.
I'm glad you've been a listener for all these years.
And I'm so thankful that you're thankful to come on the show.
Because that means that what I do matters to you.
And I appreciate that.
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 hearing Max's story.
Man, get to work on some cool stuff at Shopify, one of the coolest companies ever.
And now OpenAI, also one of the coolest companies ever.
What a treat.
Well, a big thank you to our friends at Coder, our good friends at WorkOS, and our good friends at Notion for supporting this show.
And of course, to our friends and our partners at Fly.
Check them out, fly.io.
And to the Beat Freak in residence, those beats are banging.
Well, that's it.
This show's done.
Thank you for tuning in.
We will see you next week.