From Open Source Hits to OpenAI  🔗 **Source:** [From Open Source Hits to OpenAI](https://share.snipd.com/episode/99533be5-5365-41ec-95ae-f75cfcd36efb) ## Highlights - **Open Source Began As Personal Reuse** - Max built many small open source projects to solve his own repeated problems and published them so he could reuse them later. - React Boilerplate and styled-components became popular by chance among ~300 other repos that never gained traction, which shaped his career and network. Transcript: Max Stoiber Think people look at my career and they see all the successes. They see style components, they see Spectrum, they see Stele, they see company. 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. 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 Ball Blade and any of my open source projects became popular, the reason I even started making things open source is ([Time 0:06:07](https://share.snipd.com/snip/94428ddd-85eb-462b-871c-0488c96fd634)) - **Share Work Freely To Build Career Equity** - Share work freely when it helps others because the community returns value through connections and career opportunities. - Max credits both altruism and the substantial career benefits he gained from open source popularity and network effects. Transcript: Max Stoiber Why would you share all these ideas that you have for free? Why wouldn't you charge for them? And I think the answer is twofold. One, I've gotten so much from the community and I build upon the shoulders of giants that I think it's worthwhile to give back and make sure that my ideas also contribute back to the ecosystem. That's the sort of 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 style components or React boilerplate, 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 altruistic motivation, but I think it's also worth saying that there's very much a benefit that I've gotten, a very selfish benefit for my own career, my own life, and Who I've become through sharing these ideas and projects. ([Time 0:08:48](https://share.snipd.com/snip/04068623-b9d6-45c8-b260-22bf7031c3a8)) - **Abstractions Matter More As Code Generation Improves** - Code is becoming cheaper to generate, shifting value toward the abstractions and UX that make code intuitive and composable. - Max notes he now reviews high-level architecture more than implementation details because agents produce much of the code. Transcript: Max Stoiber 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, you know, 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, 10 years from now, you know, in the style components days, part of what made style components so popular was that we found An abstraction that composed together really beautifully and worked exactly the way that you would think it would work. Every time users thought, oh, I need this thing, let me just go try it the way I think it should work, it would always work. That was part of what made style components so successful. People tried it and they went, oh, this works exactly the way I would think it would. That's great, 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. 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 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 and made lots of changes to ChatGPT. I haven't written a single line of code. ([Time 0:11:12](https://share.snipd.com/snip/e93d4f03-39a6-49a7-93e6-ced779184e5f)) - **Spectrum Grew Out Of A Podcast Slack Problem** - Spectrum started as Spec.FM's public alternative to Slack when podcast hosts couldn't afford Slack's scale costs. - Max joined after fixing a styled-components bug and realized the platform would also solve support burden for his OSS projects. Transcript: Max Stoiber 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 a 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 stayed 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 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 hit 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 hit this bug that I think is a style components bug. Have you seen this before? And I had known of Brennan Bryan 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 Boilplate at the time, which was used by many people, and then Style Components, which was used by many people. And part of the challenge of managing large open source projects like that is that the maintainers end up being the sole supporting pillar that answers every single support request Gets answered for 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 play, both I was very fortunate to have some really great people step up. But overall, it quite quickly becomes a very overwhelming amount of inbound interest. And I was like, oh, if I can just take this community platform and I can get everybody that uses style components to use this community platform, then they can ask questions. And other people who use style components can answer the questions instead of me having to answer or us maintainers having to answer every single question. And so I realized I want this. I want this community platform to exist for my open source projects that 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. ([Time 0:19:24](https://share.snipd.com/snip/5bc3edb9-b3c7-4e48-9875-59e56bd3ec83)) - **Acquisition Changed Spectrum Into GitHub Discussions** - GitHub acquired Spectrum after seeing open-source projects using it, but product shape changed when integrating into GitHub. - The team explored real-time chat at scale but settled on static Discussions due to infrastructure complexity. Transcript: Max Stoiber 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. Adam Stacoviak 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. Max Stoiber They saw that there was a need for this in the community. But there wasn't like a preconceived idea of like, oh, exactly, it should be a tab on repositories that says discussions, and each discussion should look exactly like this. Like that preconceived notion didn't exist. And in fact, for a while we explored whether we could bring, if you think about, the spectrum was a sort of combination between Slack and 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, right? It's not, it feel like Slack. And so in between those two steps, there was a lot of exploration at GitHub that we did around, can we bring real-time chat to GitHub at GitHub scale? Or do we need to do something a little bit more static? And so we explored those directions for a while before we eventually settled on the static direction. And quite frankly, a lot of the difficulty at GitHub scale at the time, I think I had hundreds of millions of users probably, doing real time at that scale is infrastructurally really, Really difficult. Now maybe there's a little bit more tooling for it and there's a little bit more vendors that you could use and sort of expertise. But at the time, that really wasn't. Slack was a relatively new thing itself. Nobody really figured out how to scale real-time that well at that scale. ([Time 0:30:37](https://share.snipd.com/snip/bf483f14-6e7c-44ae-a93d-928004ae3a3b)) - **Develop Self Awareness To Unlock Team Feedback** - Work on self-awareness to remove founder bottlenecks; your behavior defines company culture and feedback norms. - Max used coaching and the COINS framework to make critical feedback less risky and more actionable for his introverted style. Transcript: Max Stoiber Maybe two years into my next company's journey, 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 stilly? 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 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 of human nature. And so I find it very risky, personally, to give, I found it very risky to give critical feedback to people, because there was always a chance that that critical feedback could lead to Disconnection, right? 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 the four years of Stellative. It was really me figuring out who I want to be and Tim figuring out, my co-founder Tim figuring out who he wants to be, and through that, what kind of company we want to build and what kind Of team we want to build. And then the second thing I'll say is we knew that we had no idea what we were doing. We went into 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. Adam Stacoviak 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. Max Stoiber I think the first piece was really understanding that I felt it was risky. And that's why I was subconsciously not doing it as much as I needed to as the leader of a company. And the second piece then was, once I understood this about myself, working with Sue and working with my coach on what tools can I have to feel more comfortable giving critical feedback. ([Time 0:45:43](https://share.snipd.com/snip/706cc9a5-989e-4b40-8aba-a0da550c7220)) - **Use COINS To Give Clear Critical Feedback** - Use a structured feedback format like COINS: Context, Observation, Impact, Next steps to make critique specific and less personal. - Max gives a concrete phrasing example to avoid defensive reactions and prompt repair and learning. Transcript: Max Stoiber 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. 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 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? Right? 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 step 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 um 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 that's my role as a leader. I have to do this and we have to get better together. And I'm doing the best I can at giving this feedback. And then if it doesn't land with you, at some point, 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. ([Time 0:50:17](https://share.snipd.com/snip/38ac30dd-1085-45d9-9d6b-00262c0e7803)) - **Stellate Was Born From Spectrum's Database Nightmares** - Stellate grew from a GraphQL caching need first spotted during Spectrum's scaling pains when their database crashed nightly. - Max and cofounder Tim built a GraphQL CDN that did partial query caching by splitting and caching query pieces at the edge. Transcript: Max Stoiber You know, it all started actually with Spectrum. When Bryn, Brian and I were building Spectrum, we were using Firebase at the beginning, and it, at the time, really didn't scale for what we were doing. It was breaking all the time. The security rules were a nightmare to manage. It didn't scale to the number of connections that we had. It really didn't work at the time for what we were trying to do. And so we knew we needed to build our own backend for Spectrum. And so we knew we needed to build an API. And we had heard of this thing called GraphQL that Facebook had released sometime before that made APIs that made it much nicer to use APIs on the client. And so we decided to go, we tried it and then we really liked it and we decided to go on 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 GitHub 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 pen testers went and they tried to hack Spectrum for a week or eight days, I don't remember. And they came back and they didn't find any major security vulnerabilities. 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, IAM, you know, access anywhere. We were just using Vercel and auto-deploying from our repository. And so all of that was managed by them. And the second piece was, our API, we were using GraphQL. And so we had just made sure that in every single GraphQL query 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. And so 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 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 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 bandaid 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 graphical clients do is really fancy caching. If you look at how graphical clients do and why they work so nicely on the client, it's because they do a bunch of really fancy denormalized caching that works really well. And so in my head, I was like, why can't I just take Apollo client or Urkel and put it on the server and have a cache for everybody. But 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 cache GraphQL really smartly and it has a great impact on the client. Surely you should be able to do this on the server. And so then years later, and I told to 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 Tim 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. ([Time 0:56:48](https://share.snipd.com/snip/b7d1f1f7-631f-4bd8-a58b-8d55b4a528c3)) - **GraphQL Enables Superior Partial Query Caching** - GraphQL's field selection enables precise partial-query caching at the edge, boosting cache hit rates by assembling cached subparts. - Stellate split queries by entities (product, reviews, users), cached pieces, and only fetched missing parts from origin. Transcript: Max Stoiber 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. ([Time 1:05:10](https://share.snipd.com/snip/83cb84b3-d3dc-4a38-9c1b-7df47d959ef9)) - **Hockey Stick Growth Then Plateau For GraphQL CDN** - Stellate launched quickly to immediate revenue and enterprise contracts, then plateaued because the addressable market for GraphQL caching was too small. - Max raised $30M, grew fast, then chose acquisition path when growth flattened and founder energy waned. Transcript: Max Stoiber 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 launched it, Tim and I, it immediately exploded. Immediately. We went to six figures in revenue in a month. We started closing enterprise contracts left, right and center. In the age of AI, where companies are getting to $100 million of ARR in whatever, 18 months, this doesn't sound as impressive anymore. But for a B2B enterprise startup, we were a hockey stick, man. We launched and we were a 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 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 graphical caching ended up using us, and then they never left because they still needed graphical caching, which is great. Except there weren't enough of those people on the planet to make it for a venture-backed company. And so then when we realized this, we tried to expand beyond our initial solutions. We ended up building GraphQL rate limiting. ([Time 1:07:54](https://share.snipd.com/snip/4af22220-2043-4e49-9c7e-527bb943102c)) - **Dual Acquisition To Protect Team And Product** - Max executed a structured acquisition process, courting ~70 related companies to find homes for team and product. - The outcome was a dual deal: Shopify acquihired the engineering team and The Guild acquired Stellate's product and customers. Transcript: Max Stoiber 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. I would be like, Hey, look, is there a fit here where maybe the team in the product can live on as part of your company? Is that a thing that we could do? And after nine months of, of lots of negotiations and talking and back and forth, and this is a whole journey, I ended up with a dual acquisition where Shopify 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, a graphical agency based out of Israel, who had built a bunch of open source projects in the graphical space. And we're very excited to buy Stellate and take it over and keep it running and maintained for our customers. And so Stellate still exists. Adam Stacoviak Our customers still use it. Max Stoiber 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. Adam Stacoviak 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. Max Stoiber And product, obviously, company, the company itself and the product not the people went to the guild yes the 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 they joined shopify as a group um and so it was, as you call it, glorified job placement is a funny way of Phrasing it. It's a little bit more than that, but that's certainly what happened. They all got great jobs at Shopify and are working on the interesting things there and are well taken care of. And then the way that works mechanically is that Shopify purchases an exclusive and irrevocable license to the IP of the company. Because the risk of Shopify acquihiring the team is that Stellate could later go, oh, you hired all of the team. Now you're using the knowledge that they gained and the IP that we own at Shopify and so we're going to sue you. And so really during an acquihire, what they're paying for is a license to be able to use the IP that Stellate 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. ([Time 1:12:13](https://share.snipd.com/snip/ef152ad3-04ce-48da-a843-97cf96fdb49a)) - **Entrepreneurs Make Better Product Teams At Shopify** - Shopify values bringing entrepreneurs in-house because founder experience aligns with merchant needs and product thinking. - Max led Liquid Storefronts, shipped Horizon in six months, and applied his composable component thinking from styled-components to storefront blocks. Transcript: Max Stoiber 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 Cellate, 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, go, you know, set up your laptop and all that stuff. But then two, and most importantly was go figure out what the right role is for you. And I 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. These are, you know, I met flower shop owners that wanted to take their flower shop online. And what they cared about was having an online store. And the way they do that is with Shopify. Shopify does the whole thing for them. They don't have to worry about it. And so I joined and I ran this, you know, 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 Onesore Editor, which is this website builder, kind of like Wixos, 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. Anyway, I ended up running all the engineering teams that built 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. Adam Stacoviak 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, 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? Max Stoiber 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 Store and the online Store faced. And then also over the course of Stellate, I had, again, I'd been in this pressure cooker situation of really growing myself. And I turned into quite a formidable leader, I think. 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. And if I collected all of my 360 reviews made a word cloud out of it, I can guarantee you that the biggest word would be energy. People kept, every single person I think kept remarking about how much energy I brought to the team, how much energy I brought to every day, how much energy I brought to the company, how Much energy I brought to them. That was the core piece that I think is really unique to me. I can bring a lot of energy. And so I took over this engineering team that for reasons actually beyond themselves were thought to be very slow. The Liquid Storefronts team was perceived to be extremely slow. They didn't ship enough. In fact, they hadn't really shipped anything for a whole year, even though there were 50 people at the time. And the area was really important to Shopify and innovating there was really important to Shopify. And they had put a great product leader in place, but the engineering team just wasn't keeping up. And so I was like, that is the perfect set of problems for me to solve. I know I am the right person to solve this problem. I'm the right person to work with this team. And so I came in and I brought my energy and I talked to everybody and I connected with everybody. And anyway, lots of work happened. And nine months later, we shipped Horizon, which was the biggest release at Shopify at the time. It was a new default theme with a completely overhauled theme platform that the team had been working on for many years. ([Time 1:20:10](https://share.snipd.com/snip/b92ecdc8-09a0-428b-b42b-65721da95b92)) - **Personal Impact Pulled Max To OpenAI** - Leaving Shopify for OpenAI was agonizing for Max, but he joined because ChatGPT impacts his family and users across ages. - The chance to work on a product his kids and parents use daily made the move irresistible despite strong ties at Shopify. Transcript: Max Stoiber Life it was a really yeah it was a painful painful three weeks of working through that um i i 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 right 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 chat 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 a publicly traded company that's quite well known, my parents kept thinking I work at Spotify. And they kept saying Spotify. And I had to keep explaining to them that, 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. 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, I'd never been in a position to experience that before. And ultimately that and, 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. And I had to keep telling people that I really respected and loved. But I just, I can't say no to this. I have to, I have to go take this opportunity. And so despite how painful it was, and I swear to God, it really was. If you ask, if you ask my partner, she's going to tell you, that was a painful three weeks of thinking through that. But I, I just realized I have to be here. ([Time 1:27:00](https://share.snipd.com/snip/1b331ef2-3358-47b7-a179-6a4c14e9d1e4)) - **ChatGPT Apps Render Partner UI Via MCP Apps** - ChatGPT's app/plugin platform uses an MCP Apps extension allowing servers to return HTML/JS widgets rendered inside ChatGPT. - Partners can build interactive web-based widgets (iframes) that appear next to tool calls, enabling rich partner UIs like Zillow maps inside ChatGPT. Transcript: Max Stoiber 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 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, you know, tool calls and there's resources. But also, we worked with the mcpy creators and then turned the mcpy into the mcp app spec that allows mcp servers to serve actual ui to clients and so for example zillow and xpedia 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 houses you're seeing. If you're searching for a hotel with Expedia, you can talk to ChatGPT about the hotel you're seeing. And so we're exploring new ways that we can combine the world outside of ChatGPT with ChatGPT and our intelligence and our models. Adam Stacoviak 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. Max Stoiber This is an extremely active area that we're working on very hard. And so you'll... I think we now have, we went from dozens to hundreds of apps in the App Store over the last few months that you can now install and look 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 JGBT? 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. Adam Stacoviak Can you speak to the MCP server serving UI? That seems, I didn't hear that before. Max Stoiber 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 JGBT, 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. ([Time 1:31:40](https://share.snipd.com/snip/db090cb3-4203-4b1b-8409-2c7c7612c0ab)) - **Publish Your Service As A Free ChatGPT App** - Build a ChatGPT app to surface your content and let users interact with your product inside ChatGPT; the directory is open and free like an app store. - Max confirms you can create a changelog podcast player widget that will iframe into ChatGPT if reviewed and approved. Transcript: Max Stoiber Plugin slash app inside of ChatGPT? It's a totally open directory. We review every kind of like the app, Apple app store. We review every app that comes in to make sure it's safe and that it works for our users. But it's a totally free directory. Yes. You can build a changelog podcast listener MCP app and it will render inside of chat GPT when people use it. Adam Stacoviak They would have to have the plugin slash app. What do you call them, plugins or apps? They were called apps. Are they interchangeable? Max Stoiber 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 it can play right in there? Yeah, it's just HTML and CSS and JavaScript so anything that the web can do we just iframe your widget into ChatGPT and so anything that the web can do you can do so you can just have a player ([Time 1:35:10](https://share.snipd.com/snip/fe44a966-671b-4cde-bae7-ad108a6522e8)) - **ChatGPT Apps Enable Integrated Two Way Workflows** - ChatGPT apps can support two-way actions (e.g., saving favorites) via MCP tool calls, enabling integrated workflows between user accounts and partner services. - Max uses the Zillow app to search, view maps, and could call a save-to-favorites tool if Zillow exposes it through MCP. Transcript: Max Stoiber To say that I'm very, I'm very, 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. Adam Stacoviak Maybe a better example to zoom into, just because I'm curious, is like a Zillow one. I know folks, I have good friends who just, just search for future properties. They're not even in the market, but they're always watching the market for properties. They want, I have a particular friend who wants about five acres near a, um, 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, etc. If we want to layer into this, is this kind of plugin framework able for me to not just extract, but push back to my Zillow? So if I can query my Zillow or query Zillow in general, and maybe Zillow knows my account, and now I'm not asking ChatGPT to build artifacts that I extract and pull down to my disk and then Have to be the API to move them elsewhere. I 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. Max Stoiber That's actually exactly what I'm using it for right now, the Zillow app and JGBT personally. We're looking for potentially buying a house. I guess at this point, we're also the kind of people that just watch the market incessantly waiting for the right thing to come along. And I just go talk to Zillow in JATGBT 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 of 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. Adam Stacoviak 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? ([Time 1:39:28](https://share.snipd.com/snip/f1cde04d-7652-4a65-9880-f93d03139daa))