What's up, welcome back, this is the Change Log. I'm Matt Stikoviak and today I'm joined by Max Wilbur, talking about the long road from Open Source to OpenAI. Max has shipped a ton of Open Source he helped build Spectrum, the spec.fm crew, sold a Graph QL 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 changelog.com, learn more at fly.io. Okay, let's do this. Well friends, this episode is brought to you by friends at coder.com secure environments where developers and agents work in parallel.
And I'm joined by Nicki Pike, field CTO, forecoder. Nicki, 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 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 developers.
Not really though, we're putting them in a cloud development environment and 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 of the fact that it could be stolen, you could lose it, it breaks, and you're out of work while you wait for a new one. But there's also just the consistency you got there. We all know developers, developers are gonna be looking for some of the latest and greatest, and if you're not really controlling how they get out there, that's where you get this. It works on my machine, it doesn't work on production, 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, the onboarding statement, as average I think is like four to five weeks for a new employee to really get their local laptops set up and ready to start doing their first time of code. And 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 gotta go talk to other developers.
What do we use and 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 Shaihulad, that virus that went out not long ago. The compromise of the MPM public repositories. They went and downloaded things, MPM did what it did. Next thing you know, you're compromised.
But when you use something like what we're doing with cloud development environments, then you can mandate and you can put restrictions on there to say, hey, you can only go get your packages from our private repo. Those packages are expected to have been thoroughly vetted. We know that they're clean, not as is stopped, everything like Shaihulad, 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 have happened 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-host environments, 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 Deliber. 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 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, it's going to university and studying 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 actually lived within three months because I was like, this is not at all what I want to do, what I want to do is make things for people.
And so that's always been what's driven me through my open source work, through my startups. I like making things for people, I like getting things in people's hands and having them use it and then get something out of it. And so I guess the asking 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. It's quite humbling that this guy from Austria has influenced the world in that way. It is about 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 out to be in that kind of position.
You come from a different, like before spectrum, was a thing that you're already doing things like stock components, react boilerplate, what were some of 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. I think people look at my career and they see all the successes, they see style components, they see spectrum, they see style decisions. That's what I say. 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 make my call up later on, I got really popular for a while and I make style components, I got really popular for a while. Both these open source projects are widely built to 200 projects and get to buy stars. Lots of lots of users should really change the way people think about react and developing applications.
What people don't see is the 298 other open source repositories that I've made on GitHub that no one has ever heard of or 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 we had built it, I mean, you know, I was sort of speaking popular.
The reason I 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 a bit back again. And I don't know if you were around in the 2015 with back days, it was like thousands of lines of code and Jason, that if one little line was a little bit wrong, the whole thing before the part was 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'm making open source is because I ended up solving these problems over and over again as I was building things. And 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 Rek Balloplyt 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. And, 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 you, 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 did you just charge everybody that uses that components $1? You'd be a billionaire, but that would give them how many installs you have. And of course, that's not how the world opens source works. But the sentiment is the same.
Why would you share all these ideas that you have for free? Why would you charge them? And I think the answer is twofold. One, I've gotten so much from the community and I've built upon the shoulders of giants that I think it's worthwhile to give back and make sure that my ideas also contribute back to the ecosystem.
That's the sort of beautiful altruistic motivation. And also very selfish motivation. I really benefited from the things that I made becoming popular. And of course, if I had charged with the outcome of the regular play, if I charged from my open source projects, nobody would use 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 altruistic motivation. But I think it's also worth saying that there's very much a benefit that I've gotten the very selfish benefit for my own career, my own life and who have become through sharing these ideas and projects. And so I think it's a combination of, I get to help the world.
And also in return, I get rewarded by the world. And kind of jumping the 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 what you're working at, every single daily life, like I'm a daily active codec user, just to be super clear, I love codecs. 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 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 AI maximalist at this point. But do you feel like that core thesis you had back in those days of stock components, et cetera, 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 health necessarily isn't code anymore. It is in some ways, right?
Like Open Cloud 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 codes 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, 10 years from now? In the stock components days, part of what made stock 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 stock components successful people tried. And they would work exactly the way I would think it would. That's great.
Like I don't even need to read documentation. I just know how to use this because it just makes sense. And making that abstraction work was really, really difficult. That was a lot of work on our part to make that happen, that magic, that simplicity wasn't simple to create and took a lot of code for us to figure out.
Now, I don't know that AI is at a point where it creates out components from scratch if we just gave it the abstraction. But it seems inevitable that it will get there if it's not there yet. And at that point, abstractions are the only thing that matters because they make a big difference in how people use it. But then beyond that, if AI gets even better, do abstractions even matter?
Or are we just going to be programming in English? I don't know. But I know for myself, since I joined OpenAI in December, I've shipped many, many PRs here, lots of changes to Jatch IT. I haven't written a single line of code.
I'm just managing code extensions now. And I know many people in the industry since December have had much of the same experience. And that's crazy. Yeah, for a while there was Taboo to say we're using an agent.
It was actually expected because we wanted to complete the line. We wanted to complete the thought. We didn't want to have the thought, so to speak. And for me, a lot of things changed back in September.
I want to say last year, and a big swing when Opus 4.5 came out and then obviously the advancements you all made with Kodak's and TPT, I think it was 5.4, maybe 5.3, I think it was what it was in December. And now 5.4 is just so revolutionary in terms of how it helps me think. And yeah, I can probably go on deeply about that. But a lot of things really change for everyone.
I think we're in such a uniquely different world here today at the end of March 2026 that we definitely were at the tail end of March 2025. Like it's dramatically almost like a 180 in terms of difference in how we code or not code. 100% agree. I think I still think even if code is not the mechanism anymore, it is valuable to provide things in the world, whether they're ideas or solutions, problems.
I think that is always a valuable thing to do both the world and for yourself. I just don't know that the sheeple that will be code anymore sometimes. 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 Change Law 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 really great platform.
There's some challenges that I'm trying to solve. And that's actually still really hard to build to generate a little bit of code to do a function or to do a feature is fairly easy to do with the good spec, like you said, coding in English. But to turn that into cohesive product that's usable by one person is somewhat hard and then turn that into something that's useful 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. Like I still have to tell, love it or leave it, code X, but I still have to tell code X 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.js24 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's up and coming, but it's not quite there yet to node level. And the people behind node are very smart.
And very articulate with how they direct node to be a runtime and a compiler, which are respect. And so there's still this dance from TypeScript to node to platform to running. It's not just prompt and magic. I think at the same time, the trajectory of where things go is quite impressive.
100%. And the question is just where, even when it hasn't told us, 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, has a typing to face.
I'm really making sure that it's less right for Lawrence, the saying of like, he's always said that he said he was a draw the right boxes, and whatever's in the boxes is fine, but he wants to draw the right boxes. He wants to make sure the boxes are drawn 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?
What, how do they talk to each other? Is that actually the right level of abstraction? What 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've been thinking, actually, more about the architectural overall system versus the individual lines of code, like is this statement correct?
That most of those are correct, but abstractions, I agree with you, where I spend most of my time. I did want to chase a couple of those rabbit holes in the speed, 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, and we can probably gush deeply about it. And you get to AI maximalists in a room and they'll talk for hours about what they're working on, how cool it is and whatnot.
Back at the day of Spectrum, when you all invented this, this new way to give coding communities, discussions, community, it was wild to watch your progress because it helped me understand this is correct or not, is Spectrum that you all built the same as the Spectrum podcast network? Was that a spinoff from that, 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 Brynn and my two co-founders, they were running this podcast network called Spike FM, and they had, I think, people were stuck at the time that they were running this part of Spike FM, and they were using Slack at the time as their community platform, and they were trying to connect their listeners together, and so they created Slack, and since they mentioned this, Slack and since grew to tens of thousands of people.
And Slack came to them and said, we can't do this, I think it'd pay us, so we have to go find someplace else. And the payment required would have been like hundreds of thousands of dollars a year, not money that it's published, 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 people can find them and contribute to them.
And so that then exists, you know, there were community forums, you know, the classics are sort of, say, old forum style conversations, but that wasn't really an equivalent to a Slack that was public. And so that's what the idea of Spectrum was born, was can we take a public community forum and make it feel more like a real-time conversation like Slack, and it still have it be such and have the benefit of the open web, have the flexibility and findability of the open web. And the reason I go connect to them, and this circus background to what we're talking about, is because they were using style components for building their first version of Spectrum, and they hit some kind of a bug that I don't even remember, and bring just the Mian on X on Twitter. And I was like, hey Max, we hit this bug, I think this is our components bug, have you seen this before?
And I had known I've been a Brian for a long time, and I've been a listener for podcasts, so I replied, I was like, give me access to the copies, and let me take a look, I will go see if it's a bug in components, or something that I'm using, it's what I'll go figure it out. And when they gave me access, and I realized that they were building this community platform, I realized exactly what I need for my open source communities, because I was having the exact same problem. I made React both of the time, which was using the main people, and it's not components, which is using the main people. And part of the challenge of managing a larger open source project like that is that, the Mian is end up being the sole supporting pillar, that answers every single, every single support request gets answered, and every single bug report gets re-attached by them, every single income contribution gets re-attached by them, and it's being a huge volume of work.
And sometimes other Mian is stepped up, and in the case of Stock and Point, I'm very fortunate to have some really great people step up. But overall, it's quite quickly becomes a very overwhelming amount of in-bounds interest. And I was like, oh, if I can just take this community platform, and I can get everybody that uses Stock and Point, it's a user's community platform, and they can ask questions, and other people who use Stock and Point, can ask the questions instead of me having to answer, or ask me to answer every single question. And so I realized I want this.
I want this community platform to exist for my own subject. I have the same problems, I want the same solution. And so I end up joining them, and I end up co-founding a spectrum, and that's really where it all started was from their podcast, and I work in them using stock components, and then reaching out to me. And it's a great example of a case in my life where, if I had never made stock components, I would have never been connected to Gwynne Bryan.
And so, well, hopefully greatly from me and my main things, stock components. But in return, I got this great journey of founding and starting 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 Brinich, founder and CEO of WorkOS. Michael, author agents.
I feel like this is burgeoning. It's kind of happening all of a sudden. What's the state of the world for author agents? Yeah, it feels like author agents is one of those things that nobody knows what it means, but it's very provocative.
Everybody wants to talk about it. Practically speaking, I think there's two things here. The first is when you say author agents, you're talking about how do I get the data into an agent that it needs to do its job. And for that, we build something called WorkOSPIPPIP, it's actually more of an integrations product.
It helps you take your agent and connect it to your customers, Google Drive, and Connect to Salesforce, and HubSpot, and Connect to Slack, all this other stuff that they're going to use, and doing a way that's safe and secure and managed. That's one type of auth for agents, kind of data access. The other type is actually authorization. It's like permissions for what the agent is going to go do, because you connected 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 do a bunch of crazy stuff? That's a lot of stuff we're building today. We don't have a product announced to have 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 throughout there. You look at Microsoft and Microsoft's Intro, Agent ID.
They're doing a lot of interesting work there. There's also expansions to Open ID Connect and SCIM for agents. We're building all of this in 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 Open Claw weeks or months ago. And that's a new paradigm I think we're going to see, not just within consumer software, but in the enterprise, too. So it's an area of very, very rapid development. Well, it makes me think about agents versus people, not negatively, but this will have more agents than people.
You know, today if we have 7 or 8 billion people on 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 agent decoding 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. OK, 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 begin the product? I think it was all very fortunate circumstances. Burn and Brian, we're building this platform.
But initially, I think we're really building it just for specifime, which is why the name of the name of it's being spectrum. It was meant to be a play on board. Yeah, that's why I haven't messed it up initially and asked that question. I thought it was called spectrum.fm, but I was like, maybe not, and so you corrected me.
So even in my own brain, I had the podcast network spectrum in my brain. So I was like, 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 decided maybe we should actually try to make this a company.
And then they were both designers, Britain a little bit more than Brian, and they had sort of coded together. They were designers, but they were new how to write code, they were designers of code, which I know back in those days was a big discussion, you know, should I just go to know? Which I think now with coding agencies very much, that really should no longer be a discussion. I hope we know I have to talk about your designers code because all designers cannot code.
At least part of the time, you know, production code, you know, will get there. But anyway, 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 us, the co-founder and CTO.
And then for the next year and a half, we built up 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 big rooms hacking together this community platform that we loved. Did you take on any funding or seed investment? How did you?
Yeah. How did you sustain initially? We had raised a small, pre-seed rounds that sustained us for that year and a half. And in fact, part of the story here is that we got the seed funding that really allowed us to explore this problem space.
And then a year in, we had built something that lots of people were using, but we hadn't really found a good way to build a business out of it. We realized there's really a need for this. Lots of open source projects, and lots of open source projects, especially started using the spectrum to connect their users together and foster conversations. And so our initial thesis, I think, of people wanting 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, some of the things that's more of us in the 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 of 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 we built here.
Unless we were going to do ads, which we didn't want to do. And so we couldn't find a business model that would work. And then we said, maybe we just got this part of the zone. Yeah, that's interesting.
Definitely don't want to do ads in a thing like that. I mean, there's a temptation to, but that becomes a version of a lifestyle business in a way. But then, 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, is it enough? We need what has not become discussions? How did that conversation initially play out? Yeah, there's this other guy named Max Max shooting who, who, who, who, who were really connected with it was at the time working with that.
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 company is very different than doing it as a free person. So that turned into GitHub discussions about a year later that now is used by everything that repulsed for you 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, in the, in the community. And, but there wasn't like a preconceived idea of like, oh, exactly, it should be a tab on the repository that says discussions and each discussion should be exact.
Like that preconceived notion didn't exist. And in fact, for a while, we explored whether we could bring, if you think about the spectrum was a sort of combination between Slack and the traditional forum. It was a real time, but also threads people who went to chat live. If you think about GitHub discussions, it's not exactly chatting live, right?
It's not, it doesn't feel like Slack. And so between those two steps, there was a lot of exploration and 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 version.
And quite frankly, a lot of the difficulty at GitHub scale at the time, you know, I think 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 tremendously to use in sort of these. 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 will at that scale.
And so forget to take a bit to build all this real time infrastructure for what was a minor part of the platform and not just being worth it for them, I think. And so they ended up deciding to go down the static path and sort of more, which now turns into discussions. It's independently very valuable, but it's not the same as Slack or real time chat. What have you been?
Is there a 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. You have that with the case. But is there any part of you that, or even maybe the three of you could speak for them that were chasing this particular product direction and then the acquisition slash aqua hire change the trajectory while it gave you more runway, gave you more opportunity in your 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 have been a business by itself. So I think like default, the sort of angle that we've taken on the markets couldn't afford.
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, there's players now in the market like Circle who've built very successful businesses around communities. They do a completely different angle and they focus more on professional communities, they focus more on online course creation, they focus more on sort of more commercially viable communities.
And they built what from the outside looks like a great business around that. But it wasn't necessarily what we were interested in doing. Right. 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, how my life turned out. So we've jokingly, I've jokingly talked about buying spectrum back from itself, 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 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 aren't, maybe they aren't, maybe somebody would 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 done in a maker.
Do you know John in a maker, funny chance? And he both worked at GitHub probably at the same time. I don't I don't need a maker. But he had he had worked at GitHub similar to you.
And the way in was early GitHub, like when it was just Chris and Tom and a few people, it was super early GitHub and they came through an acquisition of their company. And then on his way out in his exit, he left with the company, he came in, getting acquired. And that was kind of interesting was that he was able to take back what he'd come in with. I think it speaks to a lens of of GitHub that many people don't really think about.
Is the generosity or the flexibility to do something like that? I'm not sure how serious, like you said, you just said it's joking, but I bet they would because like it's just IP set in their books that it's like, we have to keep maintaining this at some point. We probably probably own the spectrum IP, the brand and things like that, because they actually bought it. Like, you know what, we don't really need this.
You know, sure, take it back. Here's 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, or John's story, and I think maybe your story does undergree because I bet you it'd be generous.
You're like, here you go ahead. Have fun. You know, it's a fun circle back around to what we're talking about at the beginning. It is it is always beneficial to give things to the world.
You 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, that's how I see about that. Okay. So take me into, you know, what, what more important is to share about that spectrum journey from spectrum to GitHub?
Was it a harsh reality check when you first got into GitHub? Was it uniquely different? Did it help you grow in certain ways? What, what really manifested for you when it came to three dudes, building the thing in their bedroom, as you said, to getting it acquired, to now we're exploring more and building out what has become good possessions.
Honestly, I had great fun working at GitHub. I actually really enjoyed it. I think I'm trying to some other acquisition stories, uh, working on the product that I use 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 ups and downs, as I always are, and that they're also where I spectrum, but for the most part, I really love working there.
And you know, years later, when I second company, when we were going down the acquisition path, I think that was definitely an important data point for me to know that these things can work out. Okay. Because often in the industry, you know, you hear these acquisitions and then the founders get quampy and they leave and there's all this public few that has something that happens. Um, but many of the acquisitions, they work really well and people are very happy at the company that they go to.
Um, it really just depends on where you end up with. And so we're very fortunate to be able to join GitHub 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 a lot of sort of called Gatsby, the most building an aesthetic site generator and we're trying to build a cloud business around that. And 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 happens, that some of which eventually spilled out publicly. And so the company kind of quickly imploded itself.
Uh, you know, when I was there, we had 60 people and then when I left, we had 25, 30 people maybe, uh, and you see it was brought in them. Some years later, it got taken over by by Netlify and became perfectly fine. But that, 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 a, as a, as an employee and nobody being able to do much about it, uh, was felt very disempowering, I guess.
And when I left Gatsby after that drama, I realized I had this, I had this idea in my brain that I feel like I could pull this off. I feel like I could build a company in the team without all that drama that really enjoys working together that really has a good time and gets along and just ships cool things that the world needs. Um, and I had this other chip on my shoulder from the spectrum days where I really wanted to build a big business. I, I really thought I could build a big business.
I have, I have the ingredients in me actually to go put the horsepower on the road. Um, and the third reason why I ended up going back to founding known services, I wanted to grow again, the spectrum days were the days at that time where I grown the fastest of all the times that I'd had, the, the pressures of building a company and all the different things that that requires forces, it's like a pressure cook for growth. And if, if I'm a 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 track with the world and be better at understanding myself and all these things. And I do that every day and being in that pressure group situation was like a magnifying glass upon how fast I could grow when I put into a situation where I have to grow.
And so I want to go back to that. I, 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, they can integrate that right?
Having spoken with many of those folks, it really becomes very clear that they're all, that really unifies and 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, because 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 for home runs, it requires any immense amount of personal growth on the founders part. And if that growth doesn't happen, it's a limited 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 want to get back to that level of growth. I wanted to grow that fast and I know, I know, I feel my potential and I feel that I could really achieve something that I could really figure myself out and figure out how I'm trying the world. And so those were three reasons why I went back to, to find me a startup.
It was personal growth. It was feeling like I could build a company in a team that really, I could build a team, quite frankly. And then I thought it was, I could build a big successful outcome. Yeah, but a team is really much harder than meets the eye.
I mean, you, it's nice to have a network for sure, right? Or to be a giver, like you have been an open source and to be seen as somebody that's willing to work, trusting or has a track record of success, but building a team that's cohesive, that has similar attributes and similar moral direction. Even there's a lot of things that break down a team that begin with morals. I think we're all pretty good people, but some people have uniquely different perspectives on life, the way they raise their children, the world, the world, how they think about money, all these things really 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, no, no, no.
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, Steli, we had maybe 15 people at the time.
It was 19, right across the world. And we were doing an offsite as a small leadership team, me, my co-founder, or CEO, so we were looking around and assessing what isn't working at this company. Why? How could we be better at being Steli?
And the thing that came up as the number one challenge that we're facing is that people internally don't give each other enough quick 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 actually get a lot of energy from being by myself. And I can present this next story and I've given lots of talks on stages and I can interact with people. I'm a little bit awkward nerd, but not as strongly as people might suspect from a natural introvert. But part of being 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 it was always a chance 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 it 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 thing 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 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 now I've 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 understand yourself and build a kind of team that you want to build. And so that was really the journey of the four years of Selive.
It was really me figuring out who I want to be and Tim Fingar, who Michael Fung, Tim Fingar, 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 Selive 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 to figure 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, tons of experience building with the 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 I felt it was risky. And that's why I was subconsciously not doing it as much as I needed to as a 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 what I was supposed to do is they called the coins framework, which is just an acronym for context observation impact next step. Next steps coins. And it's a structure that you can use to give feedback that alongside making it about the thing and not about the person means that feedback has a much better chance of being received well because it's coming from a place of genuine intent.
And so to give you a couple of complex information impact next steps, it's like, Hey, John, in the meeting we're in on Monday, I noticed that you cut off Jack when I was trying to explain why he merged this PR that caused this outage. And what I saw on Jack's face was that the when you cut him off was almost a look of disappointment or frustration. And I think it might have ruptured some of your your connection and some of your 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 I would love to look at with you.
What caused you to interrupt him? What feelings were you having and why you should have the need to cut him off before he finished saying what we were saying? Right. And so you go context is what was the situation impact was observation is what happened impact is what impact was in the next steps is talk about what we do now.
And so, you know, I didn't just say, John, you really messed up in Monday's meeting. I think you're an idiot because you cut off Jack, which immediately would have led to a very defensive posture that you know, it would have just lots of things wrong with that way of getting feedback. And so by focusing on the thing and other person making it and framing it in this coins framework, it ends up feeling to me a lot more comfortable to give. I'm reading the feedback critical feedback because I feel like 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 more because that's my role as a leader. I have to do this and we have to get there together and I'm doing the best I can at giving the feedback and then if it doesn't end 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 good example of something that I learned that I worked on that now means I'm much more comfortable giving me feedback.
Yeah, I mean, it's so ingrained in you, it seems that you were able to just spell it out, literally for us. I like that. It's a cool framework and it seems like it's become embedded in the fabric of who you are today. For sure.
I Shopify where I was last. I noticed that our team has some of the same tendencies to not give as much feedback as we get to. And so I introduced the framing that I learned from CAS are one of the leaders and I'm sure what I call it. I say the thing because I really wanted some people to say the thing.
It's really, really important to a success of a company and of a team that people say the things to each other. And so people feeling comfortable doing that is a key unlock in making a better team. And so I run training sessions and I've taught this framework to many, many people. Yeah.
It's kind of wild how that's become that close to you. How pivotal was you learning that principle when I believe he said it was you and your COO kind of discovering that it was you being the bottom, you being the challenge. How did that change things? Because you said that's when you discovered it and then you implemented, I'm sure you did.
How did that change the fundamental shift in not just the company itself and how you collaborated to work together, but ultimately the project created because now you can work better together. We got much better at everything we did much faster because I was giving feedback to everybody at a higher, more often, more of the things that's deleted across all of our departments and 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 or whatever, but something changed and it felt different. It was a much more gradual change that I think in hindsight made a huge difference to our performance, which is like a very businessy term, but to the way we did. But it wasn't like a, you know, everybody's going to point to that moment as the big pivot moment where everything changed. It was 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 track it, what about how I want to build teams that I've had over the course of building the 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 I, like I said, I love that. I want to be better at being myself. I want to be better at tracking the world. I love what I do.
And so it's relentless, but I love it. You know, and so I really enjoyed it. We must have done something right because you were beloved, term is near zero, lots of customers trust to do. You got to a lot of money in the bank, ultimately required by Shopify, which we talked about that story, but whatever you did worked, whatever you did from a product standpoint, a company standpoint worked to to build something that the community used.
Can you talk a bit about what Steli is and what it did? So there's some context that we've been talking around it and mentioned by name, but not really contextually, like, since we're using the coins framework, but just using the C from that. What exactly was Steli? What took you into this GraphQL success, this caching success and ultimately what led to this acquisition?
Why did it make sense? You know, it also started actually with spectrum. When Brin and I were building spectrum, we were using Firebase at the beginning and at the time really didn't scale for what we were doing. It was breaking all the time.
The security rules were not managed. 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 back end for spectrum.
And so we knew we needed to build an API and we had heard of this thing called GraphQL that we had released sometime before that made APIs that made it much nicer to use APIs on the client. And so we decided to go, we tried it and then we really liked it and decided to go on a GraphQL spectrum. So our entire API spectrum was a GraphQL API. And, you know, when companies acquire other companies, they want to make sure that they don't buy any liability.
And so when we get to a acquired spectrum, they did a big pentist with one of the words leading pentist agencies, where they put eight pentesters for a week to try and hack spectrum. Because they want to make sure that when they acquire a spectrum, they're not acquiring a data leak. And so honestly, Brian and I were, excuse my language, shooting our pants when they said they were going to do this. Because we were just, we do it sitting in a bedroom building this process.
We could try and make something that people wanted. And then when people wanted to try and not maybe have a break. And so it's not like we had security people on staff. You know, it's not like we had security experts who really knew what they were doing.
And so anyway, when these pentesters 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 for sale, funnily enough, because we weren't doing our own hosting.
So we weren't managing AWS, I am, you know, access anywhere. We were just using Brazil and all the point from our repository. And so all 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 accreditation, there had to be an access check. And the access check had to be something like if users are not in admin of this community, they cannot take this action return or it's for an error unauthorized. Right? That's it.
That's all. 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.
There were some, they found some issues with like moderators of one channels, of one community's channel, or could moderate another community channel or something. Like they found some minor sort of access checks that weren't quite right, but weren't dangerously wrong. But other than that, they didn't find anything because everything had at least an access check that made sure that when you were accessing data, you were actually allowed to access it. And so I actually largely credit, I run GraphQL with our security posture because all our security posts are basically because instead of use holds of providers and then have access checks and every single creation, which I know sounds ridiculous when you're 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 guy and using the guy. And then the fact that the security was really nicely solved.
And I really enjoyed it. And so one of the big challenges we had to expect was as all these open source communities started using it, our traffic when the sky rocketed. And I'd chosen this database called Reasing to be that was a startup that was building this database. And the big selling point of Reasing to be the time was that it was a database meant for real time.
So any database query could put both changes at the end and you would get a real time feed of updates for that database query. Unfortunately, while I 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 had gone down and I had to restart our database.
It was like a nightmare. And so while this database was crashing every night and I got the page and woke up, I realized we were going to switch. We could not switch to something else. And I was going to be a major project.
And I was like, well, how do I? It's very band-aid fix. I can put on top of this. So that I was what you want the database without crashing every day.
And the thing we had to do was crash in front of our graph. Because of course, I hit the database. Let's cache. Exactly.
It's the obvious solution. And also our use case was very public. It's a public forum. All it is mostly the data is public.
Anyway, 99% of our traffic is reached. There's very few writes. It's perfect for caching. And 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 thing, all that's caching that works really well. And so in my head, I was like, why can't I just take Apollo client or Erco and put it on the server? I'd have a cache for everybody.
But I think it's just, and so I built a really shitty version of this spectrum. Like a really rough like just match the query and then return the same thing. Like a really rough, ready-space version of this caching. But in my head, I always said this idea like, this is going to exist.
You can crash GraphQL really smartly and has a great impact on the client. Surely you should be able to do this in the server. And so then years later, and I told people about this and I'm about about that. And years later, I come in front of ours, being like, hey, my friend Tim has built this prototype over 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'm not looking but I never met him. And so I met Tim and through that, we decided to find this company that eventually became silly.
And what we were building was a GraphQL CDN, a GraphQL itch cache. It took many of the same ideas that GraphQL clients have around caching, but brought it to the server, which has some challenges and itch cases and difficulties that we realized over the next four years. What we built, what I honestly think still to this day, is the best API cache on the planet. Now, it only works with GraphQL.
But there's no way any cache can work as well. Any API cache can work as well as ours did with GraphQL. There's no way you can build a risk level cache that works generically. You can build cache level of course, it works with people who can build a generic solution that works as well as ours, which we did with GraphQL for the first reason.
This episode is brought to you by our friends at Notion. You got a coding agent that writes solid code. But 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 Notions, new developer platform closes with the recent launch of custom agents. Notion became the collaborative AI workspace where teams and agents work side by side. And now their new developer platform is turning that workspace into infrastructure developers can build on.
So here's what matters. There's a CLI called N-T-N Notion. And that authenticates in one line. Then you have workers, which are Notions, hosted sandbox with 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 Notions developer platform today at Notion.com slash ChangeLog. That's all our case letters Notion.com slash ChangeLog to try Notions developer platform today.
When you use our link, of course, you are supporting this show. Once again Notion.com slash ChangeLog. What was the secret sauce? Can you spill those beans or is that part of the AI?
No, no. Okay. So part of the magic is that GraphQL has requires the client to do something called field selection. So instead of just hitting an endpoint like slash product slash one to get the product one's data, you have to send a query and that query includes exactly which fields the client meets.
So it'll say off the product we say D1, I need the idea and the type of line of the price, I need the description, I need the whatever is in stock, I need whatever images for each image I need a URL, you really have to do this field selection. What that means is that at the caching layer, we can understand exactly what data the client needs and what data we have in the cache and match them together with intelligently. And so we ended up building this thing called partial query caching, whereby let's say you fetch a product, let's just leave it as a product, and then off the product you fetch the list of reviews, and then if you 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 AI D1, 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 come in, we would look at all everything we had cached and we would go, okay, well 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 so, and then on top of that, we could stream back all the data that we had in the cache already to the client because the graphic client supported this. And so we were a completely transparent layer that sat in between the graphic client and the graph customer, and all you have to tell us was, all the product, you can cache the title of the description and the photos, when you can't cache the price, because that's dynamic and you can't cache the ability because that's dynamic. And you will only basically every request for the probability and the price and everything else, we'll try to keep in the cache as much as we can. And so we enabled people to get to really, really high cache it rates with very, very little effort because our cache was made up of the background graph.
And in fact, if you're listening to this and you're thinking, I need this right now, I still exist to go by agency called the Guild and you should totally go use it. It works amazingly and definitely done a great job maintaining it. Yeah, that does sound pretty cool. But only reason GraphQL is GraphQL still popular.
I feel like it's kind of 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, the story of selling the business, which is that we built this graph for the caching solution. And when we launched it to an I, it immediately exploded immediately. We went to six figures in revenue in a month. We started closing enterprise and center.
In the age of the I, we're competing to $100 million in whatever, 18 months. This doesn't sound as if I said anymore. Before it beat to be enterprise startup, we were a hockey stick, man. We were doing relaunch and we were a hockey stick.
We were doing really well. And it was because lots of companies were using GraphQL and some of them had this problem and nobody had built the solution. And so we had finally built the solution. So we hit this market new, just dead on with a really great solution and exploded onto the market.
And so we raised much money. We ended up raising $30 million. And then we plateaued, which is hard plateaued and it stopped growing. And then we had a bunch of hypotheses as to why.
And so we tried a bunch of things. We tried 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, which is still kind of magic and challenge and difficult. And we closed some of those.
But truthfully, our growth went, it's in fact, a hockey stick. And I'm just, I'm not. And in hindsight, the challenge was we built a really great product for a market that was just too small to build a venture-backed company. The product that we built was amazing.
We had effectively new zero-journed outside of companies that we used to go out of business. Nobody ever turned out of a product because nobody else solved the problem that we solved. Never mind solving it as well as we solved it. And so everybody that needed GraphQL caching ended up using us.
And 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, re-limiting.
We ended up building GraphQL metrics and trying to build a more complete suite of our GraphQL. We found some traction. But again, not enough to be a building that I company, not enough to lead to a really, really big outcome. And so after three years 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 you, it's in the left at this point, that the company, because he got burned down. And I told you, 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. 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 this is saying that companies fail when founders give up. And in fact, companies only fail when founders give up, which is obviously an exact rate of statement. But it's actually very true.
And at that moment, I gave up. After three years of trying really hard, I was tired. I did not want to go from scratch again. I did not want to start from zero.
Lots of my left in the bank. I could have done something with it. But I personally didn't have it in me. I just gave up.
And so then the question was, OK, this is not a venture-back business. What do we do? And what I really cared about was I built this great team. I can go back to what I was talking about earlier.
I spent many years building a really, really great team. And I spent a lot of time working 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 a critical infrastructure. We were a big part of the reason why their products didn't go down. We were used by Puma, the sports man. We were used by some of the biggest car magazines on planet.
And they relied on us in order to keep their businesses alive. And so I knew I couldn't just turn this way. I'm like, OK, stay there now. I'm really proud of the CDN.
And I'll all of you are down. I got so ridiculous. And so I realized I want to go down this acquisition path. I want to go down the path of an acquisition.
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 anybody related to what we're doing.