From Open Source Hits to OpenAI  🔗 **Source:** [From Open Source Hits to OpenAI](https://share.snipd.com/episode/ce15dd76-73bf-4ca3-aa13-889a3948ddf7) ## Highlights - **Make Many Things To Find The Few That Matter** - Max attributes his career to making lots of projects, most of which fail, and a few of which catch on by chance. - He created tools to solve his own repetitive problems (Webpack, configs), and those became reusable open source hits like react-boilerplate and styled-components. 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 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, back in the days, it used to be, now I have to configure Webpack again. And I don't know if you were around in the 2015 Webpack days, 2016 Webpack days. It was like thousands of lines of code of JSON that if one little line was a little bit wrong, the whole thing would fall apart with an error message that told you nothing about what was Actually wrong. It was really hard to debug. It was a whole mess. And so the reason I started making open source projects is because I ended up solving these problems over and over again as I was building things. I was like, that's really annoying. Let me just go put this on GitHub so that I can reuse it. And some of those things like React boilerplate ended up, turns out that other people also have those problems and also wanted a solution for it that they could just reuse without having To solve the problem themselves. But that was really more by chance. ([Time 0:06:07](https://share.snipd.com/snip/4c8084ec-547a-4c57-899c-0f4c257e114d)) - **Open Source Your Tools To Create Career Leverage** - Share work publicly rather than charging for small developer tools because open sourcing amplifies career opportunities and community contributions. - Max says openness yielded indirect career returns: connections, reputation, and new opportunities like co-founding Spectrum. 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. ([Time 0:08:48](https://share.snipd.com/snip/e3022005-3988-404d-b1bc-cbf5c5178c92)) - **Abstractions Matter More As AI Writes Code** - AI is changing the shape of contribution: code may matter less while abstractions and architecture matter more. - Max now spends most time reviewing abstractions and managing code-writing agents rather than writing lines of code himself. 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. I'm just managing codex agents now. ([Time 0:11:12](https://share.snipd.com/snip/d0c33690-e35d-4a11-ba7b-005b3413fc45)) - **How A Bug Fix Turned Into Spectrum Co-Founder** - Max joined Spectrum after fixing a style-components bug in the Spec.FM codebase. - That bug fix led Bryan and Brian to invite Max to co-found Spectrum so it could serve open source communities beyond Spec.FM. 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/da10b137-93e1-47a9-a37e-209407be44e1)) - **Invest In Founder Growth To Unlock Company Growth** - Founders must grow personally because a company's limits mirror the founder's growth; invest in self-awareness and leadership development. - Max credits hiring experienced operators like COO Sue and outside mentors to learn feedback, team building, and scale. 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? ([Time 0:45:43](https://share.snipd.com/snip/e6bc1a86-560c-46f7-b173-b7dda13bc539)) - **Use COINS To Give Safer Critical Feedback** - Use a structured feedback template to reduce risk and increase clarity: Context, Observation, Impact, Next steps (COINS). - Max uses COINS to frame feedback about behaviors (interrupting in meetings) and propose concrete next steps for repair. Transcript: 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. 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. ([Time 0:49:50](https://share.snipd.com/snip/b793c37b-b9a8-4212-b788-488ee0cc1e0f)) - **A Nightly Database Nightmare Sparked GraphQL Caching** - Spectrum's scaling issues led Max to add a crude Redis-based GraphQL cache to reduce database load. - That early bandaid seeded the idea for a GraphQL CDN years later when Tim built a prototype Max recognized. Transcript: Max Stoiber 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. ([Time 0:56:51](https://share.snipd.com/snip/3f41b2d5-22f9-4768-b46a-5e6365a183dc)) - **GraphQL Field Selection Enables Smart Edge Caching** - GraphQL's field selection enables powerful partial-query caching at the edge, letting the cache assemble only missing pieces and stream cached parts to clients. - Stellate split queries into parts (products, reviews, authors) and cached them individually to achieve very high hit rates. 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. And in fact, if you're listening to this and you're thinking, I need this right now, Steli still exists. It got bought by an agency called the Guild and you should totally go use it. ([Time 1:05:10](https://share.snipd.com/snip/45419af5-c9bb-4a5b-8c28-3dec6c441dc4)) - **Stellate Found Product Market Fit But Hit A TAM Ceiling** - Stellate launched and hit six-figure monthly revenue fast, closing enterprise deals, but growth later plateaued. - The product served almost the entire addressable GraphQL caching market, limiting TAM despite excellent retention and product-market fit. Transcript: Max Stoiber 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. We ended up building GraphQL metrics and sort of trying to build a more complete suite around GraphQL, which found some traction, but again, not enough to be a billion-dollar company, Not enough to lead to a really, really big outcome. And so after three years of lots of ups and downs and challenges and successes, I sat down over Christmas. ([Time 1:08:07](https://share.snipd.com/snip/bd3c9655-b12d-47fe-a4bb-772d9af578fe)) - **ChatGPT Apps Can Embed Partner Web UI And Tool Calls** - ChatGPT's app/plugin platform (MCP Apps) allows partners to render HTML/JS widgets inside ChatGPT and perform tool calls, blending external services into chat experiences. - Zillow and Expedia apps show maps and hotel info inline; partners can build interactive widgets that call back to their APIs. 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. ([Time 1:31:40](https://share.snipd.com/snip/2de1b466-9623-4fa9-a98e-d69fc5be3944)) - **Submit An App To ChatGPT Directory For Free** - The ChatGPT plugin directory is open and free to submit, but OpenAI reviews each app for safety and quality before listing. - Max says you can build a Changelog podcast player as an MCP app and have it render inside ChatGPT if it passes review. 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/0caf466c-40bd-4d6a-bd94-335834681d74)) - **ChatGPT Apps Create A New Complementary Surface For Software** - Max doesn't think websites will disappear, but ChatGPT apps can offer experiences developers couldn't otherwise build, creating a new complementary surface for software. - He's experimenting with many incoming apps to find novel use cases beyond traditional websites. 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. ([Time 1:39:28](https://share.snipd.com/snip/4d362132-0734-4423-bf4a-70239bddb2c4))