Composability Summit Panel
Panelists discuss the build-vs-buy conundrum for composable architectures, sharing real-world insights and developer perspectives
Episode Description
A panel of developers and architects debate when to build vs. buy components in a composable tech stack at the Composability Summit.
Episode Summary
This JavaScript Jam Live panel, recorded during the Composability Summit on July 27, 2022, brings together Theo (Ping/ex-Twitch), Mahaela Mazinga (CTO, Valtech North America), Chris Hough (Solutions Architect, Commerce Tools), and Ellery (Director of Engineering, Edgeo Expert Services) to discuss how teams should decide which parts of a composable architecture to build themselves and which to purchase from vendors. The conversation opens with common misconceptions about composability, including the warning that simply having APIs doesn't make a stack truly composable and that teams migrating from monoliths often replicate old patterns. Theo introduces his "Ship of Theseus" philosophy—every component should be replaceable—while Ellery uses a Play-Doh versus Lego analogy to illustrate the goal of loosely coupled systems. The panel converges on a core principle: buy commodity services like payments and search, and invest your build effort where your business differentiates itself, particularly the front end for e-commerce companies. They explore the risks of open source maintenance, the value of open standards over open cores, the role of developer experience in buy decisions, and the dangers of incomplete strangler-pattern migrations. The discussion also touches on Kubernetes overhead, the emerging "service as a platform" trend, and the importance of organizational culture and technical leadership in driving successful composability transformations.
Chapters
00:00:00 - Introductions and Conference Setup
The panel kicks off with some technical housekeeping as hosts Scott Steinlage and Ishan Anand get the simultaneous Twitter Spaces and YouTube stream running for the Composability Summit. Theo notes this was actually his first conference talk, and he reflects on how live conference presentations differ from his usual content creation workflow, where real-time chat feedback helps him catch mistakes before publishing.
Ishan frames the panel's central question: in a composable architecture made of Lego-like pieces from various services, how do you decide which bricks to build yourself and which to buy? He outlines the format—structured panel questions in the first half, open audience Q&A in the second—and then each panelist introduces themselves, covering backgrounds spanning SaaS platform development, commerce architecture, and high-performance headless e-commerce.
00:06:01 - Misconceptions About Composability
Ishan asks the panelists what the biggest misconception is when teams first adopt a composable or API-first stack. Mahaela warns that having APIs doesn't mean you're truly API-first, and it's easy to end up rebuilding a monolith through poorly orchestrated microservices. She stresses the need for an internal champion who understands true composability. Theo offers a litmus test: if you can't swap out any given component because its inputs and outputs aren't standardized, it's not composable.
Theo then explains his "Ship of Theseus" concept—the idea that every piece in the stack should be replaceable over time—using his own startup's migration history as an example, moving through multiple databases and frameworks without full rewrites. Chris adds that customers coming from monoliths often try to replicate all their old data structures in the new front end, when the storefront shouldn't care about order fulfillment. Ellery uses a Play-Doh versus Lego analogy to drive the point home about avoiding tight coupling.
00:18:06 - The Build vs. Buy Rubric
The panel shifts to the core topic: what rules or litmus tests do teams use to decide what to build versus buy? Ellery argues that e-commerce companies should buy almost everything on the back end and focus their build effort on the front end, where performance is the true differentiator. He notes that companies doing hundreds of millions in revenue can run on off-the-shelf back-end components glued together with an open-source front-end framework.
Theo pushes back slightly, arguing that frameworks like Next.js aren't just front-end tools—they're capable back-end frameworks too, and developers shouldn't immediately reach for separate API services when server functions within Next.js can handle the job. Ellery agrees, and the two find common ground warning against unnecessary Kubernetes adoption. The panel then converges on a broader principle articulated by Mahaela: buy commodity components like payments and search, and invest your build effort where you drive unique business value.
00:26:19 - Open Source, Maintenance, and Standards
Ishan raises the question of how maintenance factors into the build-versus-buy decision, especially the temptation to adopt open-source tools and maintain them in-house. Mahaela argues that maintenance rarely belongs on the list of things unique to your business, making it a strong reason to buy a SaaS product that handles upkeep for you. Ellery echoes this, noting he focuses on uptime, SLAs, and performance rather than looking behind the curtain at how products are built.
Theo offers a nuanced take, saying he values open standards above open cores. He uses PlanetScale as an example: its value isn't that Vitess is open source, but that it runs on MySQL, a standard he can migrate away from if needed. He contrasts this with a cautionary tale of an open-source database whose core team disbanded, leaving users to maintain the project themselves. The discussion underscores that long-term viability and portability matter more than whether the source code is available.
00:30:22 - Team Culture, Hiring, and Training
The conversation turns to how team dynamics, hiring preferences, and organizational culture affect build-versus-buy decisions. Mahaela emphasizes that prior knowledge of a specific technology matters less than a willingness to learn, since the landscape will shift again within five years. She advocates for strong internal learning programs, ideally hands-on POC projects that teams build over 30, 60, or 90 days to internalize a new paradigm.
Chris adds that platforms should make onboarding easy through multi-language SDKs so customers don't have to specialize just to get started. The panel discusses how long composability migrations typically take, with answers ranging from three to four months for fast-moving organizations to two years for slower ones. Chris shares an example of a large retailer migrating off a custom AS/400 system to Commerce Tools checkout in just four months using a strangler pattern, illustrating that composable architectures enable incremental adoption.
00:37:08 - Audience Questions: Kubernetes and Service as a Platform
Audience member Bro Nifty makes the case for Kubernetes in mature, data-heavy organizations that need cloud-agnostic infrastructure for analytics and data pipelines, while agreeing it's overkill for startups and direct-to-consumer products. Mahaela adds that managed Kubernetes offerings now exist as a buy option, cautioning against self-managed clusters. Theo reframes it through the differentiator lens: if you're not selling developer tools, you probably shouldn't be solving infrastructure problems with Kubernetes.
Jacob from Cloudflare then introduces the emerging concept of "service as a platform," where products bundle compute capabilities on top of traditional services like databases. Theo explains how this trend increases vendor lock-in while reducing initial friction, warning that building APIs directly inside a vendor's GUI creates dangerous dependencies. The panel discusses how this consideration differs depending on whether your end user is a consumer or another developer, with Ishan noting it's "turtles all the way down."
00:48:13 - Developer Experience, Technical Leadership, and Wrap-Up
Ishan asks how much developer experience should weigh in buy-versus-build decisions. Mahaela argues it matters significantly since better DX drives quality and efficiency, while Ellery frames DX as a dollar value—easier tools mean faster delivery—but warns against choosing tools just because they're trendy or resume-friendly. Both stress the need for technical leadership that can align tool choices with business objectives rather than developer enthusiasm alone.
Chris highlights the value of integration partners who bring cross-component expertise so internal teams don't have to learn everything at once. The panel discusses the strangler pattern for migrating off monoliths, with Mahaela offering a word of caution: strangulation requires a clear end goal, or organizations risk running old and new systems indefinitely. Theo closes with practical advice for the hosts about Twitter Spaces audience ramp-up times, and Scott wraps the session by encouraging listeners to register at composability.dev and join future JavaScript Jam discussions.
Transcript
00:00:00 - Scott Steinlage
We are live.
00:00:02 - Theo
There we go. Hold on.
00:00:08 - Ishan Anand
Live, live, live.
00:00:11 - Scott Steinlage
Let me bring you up. I thought I'd share the co-host, man. It's just waiting. I'll just add you as a speaker.
00:00:39 - Theo
What's up, yo? What's up, nerds?
00:00:45 - Scott Steinlage
Hey, hey, hey, hey. Ellery. Why is that not working? The co-hosting is not working. Hold up. Do it one more time.
00:00:59 - Anthony Campolo
Theo, this was your first conference talk.
00:01:01 - Theo
Is that true? Yeah, that's true. Is that that unbelievable?
00:01:08 - Anthony Campolo
I mean, when I see people who create as much content as you, I just assume you're also in the conference game, because it's all the same crap at the end of the day.
00:01:20 - Theo
You know, I actually disagree. I found that significantly harder for myself than any of the content-creation stuff I do. I really love the live-creation workflow because if I do something wrong or stupid, somebody in chat will call me out immediately and I can fix it before I post the video. With this, that's a lot harder. And I found myself checking my notes and making sure everything was as agreeable as possible ahead of time.
00:01:43 - Anthony Campolo
Yeah, I just ran through a demo, like I was just doing a livestream, so there's partly the expectation you kind of put on yourself due to what you do. But you probably did a better job than me, so I will give you that.
00:01:56 - Ishan Anand
Well, so, Scott, you want to kick us off? I think we have all of the panelists.
00:02:01 - Scott Steinlage
Absolutely.
00:02:02 - Ishan Anand
Yeah. Let's.
00:02:03 - Scott Steinlage
So excited. Oh my gosh. All right, so, y'all, check this out. We are obviously streaming live on Twitter Spaces, but we're also streaming this live on YouTube. Insane. It's working. I can see it. And I'm also sharing my phone screen so we can see all the talking heads. Yes. This is a beautiful thing. So thank you all so much for joining us today. Welcome to this week, July 27, 2022. This is Composability Summit day. How exciting. Y'all, give me some claps, some
00:02:39 - Chris Hough
high fives, some whoop, whoops.
00:02:41 - Scott Steinlage
Yeah. All right.
00:02:42 - Ishan Anand
Yeah. It's actually just day one. There's two more days.
00:02:47 - Scott Steinlage
Absolutely.
00:02:48 - Ishan Anand
This is just the first launch day, but sorry, keep going.
00:02:50 - Scott Steinlage
No, you're good. Yes. Today's the first day. We have the 28th and the 29th to follow with lots of great talks. We've already had so many great talks go out today, and we've got several premiering tomorrow. So if you haven't registered yet, go do that. Go to composability.dev and register now so you don't miss out, folks. There are some really amazing people speaking there, and we have several of those speakers on this stage today. So you're gonna get to hear from them during this Build vs. Buy composability talk panel, I guess you could call it. Really excited. Thank you all for joining us. And remember, typically this is an open-mic kind of environment, but we're going with this panel for today for the Composability Summit. We will bring people up later on, and I think Ishan is going to go more into that. Let me introduce you to Ishan, who is the VP of Product for Edgeo and obviously the co-host here at JavaScript Jam. Thank you so much, everybody, and I can't wait to get this thing started. Let's go.
00:04:01 - Ishan Anand
Yeah, thanks, Scott. As Scott noted, we're going to do this a little differently than a normal JavaScript Jam open-mic-night format. We're doing this during the conference, so we decided let's bring the conference to JavaScript Jam live. So we'll start with the panel discussion, and our topic is Build versus Buy for Composability. Your composable architecture is a set of Lego bricks pieced together from various services and systems. How do you decide which of those bricks you're going to build yourself and which ones you're going to buy, potentially from a vendor, or take something open source and try to maintain it? The format today is we'll start the first half really with myself and the panelists having questions, and then the second half will be more like our typical JavaScript Jam format. We're going to stay on topic for Build versus Buy, but I invite the audience to raise their hands. We'll bring them up to the stage, and they can ask questions of the panelists on Build versus Buy, and we can go from there. Really looking forward to it. And as Scott noted, we're also recording this and simulcasting it to the YouTube stream for the conference as well.
00:05:05 - Ishan Anand
So with that, let me just briefly call out our speakers. Then what I'm going to do is ask them to go around the room and give their name, their title, the company they work at, and a one-minute description for the audience, and then I'll start off with questions really quick.
00:05:21 - Theo
Where are you guys streaming this? Because I can't find it on the YouTube. Is it unlisted? Maybe accidentally?
00:05:26 - Ellery
It's possible.
00:05:27 - Ishan Anand
Scott, do you have an answer to that one?
00:05:32 - Scott Steinlage
I am looking into it. I'll let you know.
00:05:34 - Anthony Campolo
Okay, I see it, but it's not [unclear]. It's waiting.
00:05:40 - Ishan Anand
It might not be synced up with the premieres on the composability.dev website because this one is live and the others are.
00:05:46 - Theo
Is it on the same YouTube channel though?
00:05:48 - Scott Steinlage
It is on JavaScript Jam. Yeah, it should be.
00:05:51 - Ellery
Yeah.
00:05:51 - Theo
You're not live on YouTube right now.
00:05:53 - Scott Steinlage
All right, well, I'm showing a preview of it, but.
00:05:58 - Ishan Anand
Okay, I will let Scott.
00:06:00 - Theo
I'll look into it.
00:06:01 - Ishan Anand
Thank you, Theo, for the QA with that. Actually, let's start out with the first panelist today, Theo. He's also a speaker. In fact, the talk just before this panel at the conference that premiered was Theo's. It was called Buying Time. It was really about the same topic, Build versus Buy. Theo, why don't you just tell folks a little bit about your name, title, where you work, and a one-minute background.
00:06:27 - Theo
Yeah, of course. I'm Theo. I used to work at Twitch. I now run a company called Ping. We just did the Y Combinator Winter '22 batch. TL;DR, we're making it easier to do collaborative [unclear], especially for streamers, YouTube creators, things like that. The talk was mostly about how I make decisions around long-term investment in technologies, as I've worked at a big company like Twitch and moved over a bunch of things from bad early decisions to good later decisions. And now I'm in a position to do that again, as well as help other startups. So I think a lot about not just what technology makes today better, but what technology makes tomorrow easier.
00:07:04 - Ishan Anand
Thank you. Okay, next up is Mahaela from Valtech. Mahaela, why don't you tell us your name, title. I mentioned where you work. You're also a MACH Alliance ambassador. And just, you know, one minute about your background.
00:07:16 - Mahaela Mazinga
I am. Thanks, Ishan. So, Mahaela Mazinga. I'm CTO for Valtech North America, and I have about 15 years in the SaaS platform development space, and also some time on the commerce side at Sharper Image as their ex-CTO. So, a ton of experience building commodity SaaS offerings and also buying them and composing them.
00:07:43 - Ishan Anand
Great, thank you. Next up is Chris from Commerce Tools. Chris, why don't you tell us a little bit about yourself?
00:07:51 - Chris Hough
Sure thing. Hey, guys. My name is Chris Hough. I'm a solutions architect at Commerce Tools, and Commerce Tools, for those of you that don't know, is a commerce portfolio company that kind of kicked off composability within commerce. Most of my time is spent working with customers that have already bought into the composability concept and bringing them on board to Commerce Tools, but we do deal a lot with which components to decide on building versus buying. I've also spent the greater part of the last 15 years or so in an architecture consulting role on SaaS platforms. So, happy to be here, excited about this subject.
00:08:39 - Ishan Anand
Great. Thanks, Chris. And then rounding it out is Ellery, who leads engineering for the Edgeo Expert Services team. Ellery, why don't you introduce yourself? Thanks.
00:08:51 - Ellery
It's great to meet everyone. As Ishan said, I'm Ellery. I work at Edgeo Expert Services, so I'm the director of engineering for our Expert Services team. My group helps customers build high-performance websites using Jamstack architectures, and specifically composable architectures, for the ecommerce vertical. So we focus on building headless websites that are high-converting and, in many cases, exceed Core Web Vitals by a wide margin. We've helped customers achieve 99 Lighthouse scores on their websites, so we're very focused on performance. Looking forward to the conversation. It's great to meet everyone.
00:09:30 - Ishan Anand
Great. So let me actually start off with the unexpected, and we'll get to how you decide on build versus buy. But what do you think is the biggest misconception you see when teams first jump headfirst into an API-first or composable stack, that they either have misaligned expectations and how that translates potentially into build versus buy? Mahaela, I'll start with you since you've actually helped lead teams through this in multiple contexts.
00:10:11 - Mahaela Mazinga
Number one, I think that the concept itself, although maybe not new to us at large, is still going through a period of adoption. So having APIs does not mean that you're API-first, and you have to really understand what that means and why that's important. And I also don't think that having composition in places means that you have a composable stack. So those are two very different animals. And it's incredibly easy to get the architecture, orchestration, integration wrong and, quite honestly, end up with a monolith via composable APIs and microservices anyway. So I think you need a champion, an expert on your team, whether you also buy that or build that through internal expertise, to really carry forward the sense of what true composability means.
00:11:14 - Ishan Anand
I'll turn it to you as a follow-up, or anybody else on the panel. Is there a litmus test for when you're truly composable? I like that concept that you may have thought you built it composable, but you ended up with a monolith anyway. So is there a suggestion for how you can evaluate that so you don't have to?
00:11:31 - Theo
The most important piece is that the inputs and outputs for any given part are standardized enough that you can swap it out. Something like Hasura I wouldn't consider composable in any way, shape, or form because the thing that is storing your data is its own standard that you have no access to. But the thing you're accessing that data through, GraphQL, is a standard in the vaguest sense of this is a way to define an API, but it's not a standard in the sense that that's an API you can take and port to other things. Like, I've had more luck moving from Postgres to MySQL. I've had more luck moving from Worker KV to MySQL than doing anything on an [unclear] server-based codebase.
00:12:07 - Ishan Anand
Interesting. And I know one of the concepts you talked about in previous episodes of JavaScript Jam Live, but you didn't mention it in your Buying Time talk. You have an analogy you're famous for called the Ship of Theseus. Do you want to just explain that rule of thumb to folks? Because I think that really dovetails nicely to what you just described.
00:12:27 - Theo
Yeah, I'm a really big fan of any given piece being replaceable because as much as you think you know when you make a decision, it isn't necessarily going to hold as you keep going. So I really like to think in terms of not just how expensive this is to adopt, but more importantly how expensive it is for us to move off this in the future. The Ship of Theseus is a meme that the community has come up with where every piece in the stack can, and often should, be replaced when new things come out and different solutions happen. Like the codebase for Ping, for example, started as a styled-components Vite codebase that I moved over to Tailwind, Next.js, tRPC. I moved the data from Worker KV to Postgres on RDS to Postgres on Heroku, where I stayed for like a day before I realized my mistake and moved over to RDS, eventually moving over to PlanetScale with MySQL. But the ability to swap any one of these parts at any given time is one of the most valuable parts of composability. Rather than having to rewrite the whole codebase when you run into problems, you rewrite the parts that are causing the problems.
00:13:28 - Ishan Anand
Do you want to explain the Greek parable for those who aren't familiar with it?
00:13:32 - Theo
Yeah, of course. The meme is based on the parable, the idea of a ship traveling the waters and parts keep breaking and being replaced. If, once you've replaced every part of that ship, is it still the same ship?
00:13:47 - Ishan Anand
Yeah, I think it's a really good way to think about composability.
00:13:50 - Anthony Campolo
And does it help TypeScript? Does TypeScript help the ship transition?
00:14:00 - Ishan Anand
I'll then turn it over to Chris. What do you think? Especially, you mentioned you have a lot of folks who come to you guys maybe a little further on the composability maturity curve or headless curve. Do you still see common misconceptions, or what do you need to educate prospects and customers about as they embark on this journey?
00:14:23 - Chris Hough
Yeah, from a couple different points. From the platform or product side, I think composability, if your features and functionality are coupled such that you need to utilize a specific module on your platform for other functionality, then you're going to have a tough time calling yourself composable. On the customer side, if we're talking about implementing composable solutions, I do see a lot of customers that come from the monolith space, and their technology teams from an architecture and development standpoint want to mimic all the business entities and functionality that they see, or that they're currently using, on their monolith. And I'll give you an example: for Commerce Tools, from a commerce perspective, you want your storefront front-end application to be as performant as possible. But a lot of these customers coming from these monoliths try to stuff in all the data for the product catalog that they're used to having.
00:15:42 - Ellery
Right.
00:15:42 - Chris Hough
But really, your storefront front-end application doesn't care about your order fulfillment.
00:15:49 - Theo
Right.
00:15:49 - Chris Hough
That should be completely decoupled.
00:15:52 - Ishan Anand
Got it. That's a really interesting, tangible example. I'll then turn it over to you, Ellery. What do you see as the common misconception when they migrate to a composable stack?
00:16:10 - Ellery
I think Mahaela made a really good point about what it really means to be API-driven. A good example here is if you think about Shopify, for example, which is an out-of-the-box ecommerce platform, and you can build headless websites on it using Hydrogen or the Storefront API. But there are a lot of customers who just use the traditional Shopify theme, and that's an API. They give you clear documentation for how to integrate with it. But now your UI is tightly coupled with the platform. And you made a comment about Legos earlier, that you want to build your composable stack out of LEGO blocks. In the past we used to explain this a little bit differently, where we would show them a picture of different-colored Play-Doh in a ball and then a picture of LEGO blocks and just tell them we're trying to take you from Play-Doh to LEGO. Let's make sure nothing is tightly coupled. You can very easily replace components as much as possible. And as much as possible, avoid building things that are unnecessary. Don't go build wrapper API layers on top of third-party components in case you might swap them out because you're worried about one of the API interfaces changing.
00:17:18 - Ellery
Try to grow organically and smartly and pick things that are easy to swap things out of. And I think from a composable standpoint, you really want to try to go pick what are the best products for you. There's no such thing as the best ecommerce product or the best content management system, or the best inventory management system, marketing or MarTech product, et cetera. So go find what works best for you and your team, glue it together through a headless framework like Svelte, Next, Nuxt, get something out the door ASAP. If you do that, you're set up so that if you run into a scale problem with one of your products or you realize something doesn't really meet your needs, it's pretty straightforward to go rewrite that part of the application. Just change the interface and migrate your content over.
00:18:06 - Ishan Anand
That's actually a good segue to the build versus buy. Now you're basically advocating to take a very agile, progressive, incremental approach. Build some piece of viable value first rather than a big-bang rewrite to totally de-risk it. If I'm to extrapolate, when customers or prospects do that, first to Ellery and then I guess next to Mahaela for you, since you advise a lot of folks through Valtech, where do you see customers deciding on build versus buy? What are the rubric or the rules or litmus tests they use to decide which components they end up deciding they have to build in that process, and which ones do they buy?
00:18:49 - Ellery
Yeah, so let's talk about ecommerce specifically for a minute. If you're in that industry, performance is a really important thing to you. Back-end flexibility, less so important. But you want to make sure you have a very fast website, it's very clean, users don't feel a sluggish experience, you want them to come back, and you want them to convert at a very high rate. So for a lot of our customers, we tend to emphasize build the front end that meets all of your needs and use composable building blocks for the back end. Whether it's open source and you can see how it's built, or they're very transparent with how they work, that's probably less of a concern. And we've helped customers build websites that do hundreds of millions in ARR, over a billion [unclear], with a lot of off-the-shelf components comprising their back end and just an open-source front-end framework gluing everything together, hosted on a platform like Layer0, for example. So I don't think there's a strong inflection point where you need to go start building things, especially on the back end. It really comes down to when do you need to be a differentiator in the market, and for an ecommerce company or for a startup, I think getting time to market, getting visibility with your customers, is really important.
00:20:06 - Ellery
If you're building a platform, then it becomes very different because now your differentiator is the features you provide, your performance becomes a differentiator as well, down to milliseconds. Whereas for a lot of other customers, that's not really the place you're in right now. So I think for the vast majority of people, if you're ecommerce and you're thinking about adopting a headless architecture and really adopting MACH, for example, I would strongly recommend build as little as possible aside from your front end, because if you use a site builder you're not going to get good front-end performance. But everything else, try to find what works best for your teams and build off of that.
00:20:45 - Ishan Anand
Interesting. So it's basically, if I was to summarize, it's buy for everything except where your differentiation is, and that's where you focus where to build.
00:20:55 - Theo
Correct.
00:20:56 - Ishan Anand
Okay. Mahaela, you know, as a MACH, I
00:20:58 - Scott Steinlage
I think Theo has his hand up.
00:20:59 - Ishan Anand
Oh, Theo, go ahead. Yeah.
00:21:02 - Theo
I think I mostly agree, but there are some... I love
00:21:09 - Ishan Anand
when panels disagree, because that's when you get the most interesting discussion. So feel free to disagree. I'd love to hear your thoughts.
00:21:15 - Theo
Believe me, I'm incapable of not disagreeing when I disagree. So I think that when your situation is simple enough that you have a single differentiator, I don't know if that's the point where I would start betting on composability. If the other parts of your stack are simple enough, then thinking about them at all almost feels like a wasted investment. Like if I am to build an ecommerce storefront, yeah, absolutely, go hop into Next.js or Hydrogen. And then when you need the back end, those frameworks aren't just front-end frameworks. I get in this argument a lot. Next.js is a back-end framework. It happens to have a really good front end built into it, but it is backend. It serves you HTML or JSON from a server. It is a really good starting point to be that layer when you do need to make a back-end call. And I think that people, once they are in Next.js and they need something that looks like a backend, they start reaching for NestJS or Hasura or all these other things, when Next.js actually provides everything they need right there. Just write a server function, write 100 server functions, write a thousand of them.
00:22:18 - Theo
And once you run into a scaling issue with that framework, the functions you wrote are just JavaScript functions that are Express-compliant. You can port them to anything else in the world. So I think that Next.js isn't just good as a way to build the front end and then figure out which API service to buy after. It's a great place to build that API service as well. And if your API is simple enough that you can work with one of those third-party providers, like a Hasura or a Firebase, you should not, and instead own that thing, because it's so much cheaper to have it in the same codebase.
00:22:48 - Ellery
I completely agree with that. I would definitely advise people, just use Next routes or Nuxt routes to build your APIs. Don't go overboard and say, oh, I've heard of Kubernetes, that sounds great, we need to go spin up EKS or AKS or whatever KS, depending on your cloud provider. Now you're just bringing in a lot of operational overhead to manage a Kubernetes cluster. There are costs associated with it, it's not going to be elastic. So you're going to pay for this stuff at night while no one's browsing your product, and it just adds unnecessary complexity.
00:23:20 - Theo
Totally agree. I was going to make a joke about Kubernetes earlier. I'm genuinely curious how many of the ecommerce places that you're advising are on Kubernetes, because that just sounds like a disaster.
00:23:30 - Ellery
No comment.
00:23:34 - Ishan Anand
So is there a common, and I'll open this up to Chris and Mahaela as well, is there a common set of components that you can point to and you'd say greater than 50% of the people we've worked with, they ended up buying this thing because they don't feel like building it themselves? Whether it's, I don't know, database hosting or the payment system, where do you most commonly see people decide to build that component, and where do they buy? Or is it that you can't actually draw those lines? There isn't any commonality.
00:24:10 - Theo
Please tell me everybody's not building payment systems anymore.
00:24:14 - Chris Hough
Yeah, I'm going to agree with that. So payments, one hundred percent. I would say definitely greater than 50%, but close to 100%. But even some of the other things that are almost commodities, difficult to implement but not difficult to integrate with, like search, greater than 50% of our customers are also hooking up with some sort of search provider alongside payments.
00:24:49 - Ishan Anand
Yeah, go ahead. Are there other ones you'd add to that?
00:24:51 - Mahaela Mazinga
Yeah, I mean, there are tons of undertones here that I agree with, and I think you want to buy commodity, right? I think today is different than it was many years ago because there just weren't as many commodities to buy. So I think the ecosystem looks very different today, and there are a lot of incredible, cost-effective options for brands or clients, et cetera, to really harness so they can focus on their core business needs. So I think the closer the tech gets to the customer is probably where you're going to be more creative. But I think it also underlines: where do you need scale? So truly, you can build small features that are likely to not get used by a large customer base. But if you actually need an incredible amount of scale, even as it applies to the front end, then you're likely still getting into buy conversations versus build. So for me it's truly about maturity. Of course, I wouldn't want to build a payment system, but who knows why somebody would want to take that option. And it's all about maturity and what the business actually needs.
00:26:10 - Mahaela Mazinga
So focus on what you need to drive value for the business and buy everything else.
00:26:19 - Ishan Anand
You mentioned scale. How much does maintenance play a factor here? And I bring this up because it may be tempting for some folks to say, here is an open-source version of something, and maybe there's a hosted version of it, maybe there's not that's been productized, but it can be very tempting to say, oh, we can just adopt this and maintain it ourselves. Have you seen that work out well? How important is adopting a product that has an open core or open-source component to it in this decision?
00:26:49 - Mahaela Mazinga
I mean, if you are adopting an open-source product into your composition that you need to maintain, that's different than purchasing a product that has open source as part of its framework. It matters a lot. Again, I'm advocating for you to focus on what's unique to your business, and probably maintenance is not going to make it on that list. And that's part of the reason, an additional part of the reason, why you buy, because all of that maintenance is offloaded to a SaaS company. It's no longer keeping you up at night, and you can spend that time on a much higher level of execution for the organization.
00:27:32 - Ellery
Yeah, and I would say you probably can get me onto an airplane where the computers are running Windows as the operating system. But at the same time, I don't look too closely behind the curtain at how a lot of these SaaS and PaaS products are built. I focus a lot more on uptimes, SLAs, performance, and these types of indicators.
00:27:55 - Ishan Anand
Theo, I believe you look closely at this in your decision-making. Do you have a different take in terms of how important it is that it's got an open core? Because I know you talked earlier about being able to migrate off, and maybe open source, at least having an open core, gives you some kind of mitigation plan or escape strategy if you need it.
00:28:16 - Theo
Rather than an open core, I look more for standards on top and bottom. I think that PlanetScale is a really interesting example here where they are, I guess, an open core in the sense that Vitess is the core of their whole business and the tech that they ship. But it is not necessarily the part I think about. There are nice DX wins and a generally great deployment story overall. So I've never been worried about the scale of my DB, but if I ever was, or I was having problems with PlanetScale, or the price were to spike in a way that was unpleasant, it is still MySQL. I can still do a MySQL dump off it and move to something else. The standard that it's on top of is one that I understand and am confident enough in to make the move if I ever have to. I don't necessarily look for open cores, although they do help me build stronger confidence. What I look for is open standards on top of there are plenty of things with open cores. Like, I think it was EdgeQL. No, it wasn't EdgeQL.
00:29:08 - Theo
That's actually cool. There was some EdgeDB that was entirely open source, but the core team just shut down one day. They all left. And if you had bet on that database, sure, it's open source, you can maintain it yourself, but now when you were betting on something because you thought it would be easier to use, now you're maintaining an open-source library to keep using it.
00:29:26 - Ishan Anand
That's the long-term viability of the service. And that's something you mentioned in your talk that was on the conference earlier today. That really puts it in sharp relief. Let's move on to the softer considerations. How much does it matter, the ecosystem and hiring and team preferences around a particular technology, when you're trying to figure out what goes into the stack in terms of buy versus build? And especially when you've got maybe a team that's gung ho about building things and it just sounds exciting to use whatever might be a hot buzzword like Kubernetes, how do you put into the right perspective whether it really is a realistic idea to say, hey, we're going to build all the...
00:30:22 - Mahaela Mazinga
I think you had a twofold question in there, Ishan. In terms of the people, I'm a strong believer that I expect people to learn new things. Prior knowledge in a specific tech means almost absolutely nothing to me because I also expect that it will change five years from now. We're going to be talking about something different. But in terms of preparing the team for a new paradigm, you have to have really strong learning and development programs that you can tap into to make sure that they're learning something that has a very specific point of view as set by the organization, and that it's consistent, and you're going to get the same quality of the learning program and the message for each individual. Again, you really need that advocate internally that does understand the paradigm that you're moving to well, to be able to disseminate that and really be a champion within the org for it.
00:31:30 - Ishan Anand
Thank you.
00:31:31 - Chris Hough
I think from an offering standpoint, from a platform, it's important not just to be unopinionated, but especially if you're new, you have to make it easy for the developers and users out there to get on, right? So is it possible to create SDKs across the board in different languages so that you don't require that your potential customers specialize or upskill just to onboard?
00:32:13 - Ishan Anand
You mentioned, Mahaela, this idea that you need to have a training and onboarding program. You've worked with a lot of companies at different scales. Just outline what that might look like, just to make it more concrete for the audience.
00:32:30 - Mahaela Mazinga
I suppose it all depends on the type of transformation that you're after. So let's recognize, I think all of the speakers here look like they come from SaaS backgrounds. So it's very different from an organization that has been on a monolith for 20 years, because that also means something very different to the ways of working and their level of agility. So I think the approach that you take to create the program has to be really specific to the team that you understand that you have, their learning styles, and ultimately your end goal. But I'm certainly a fan of hands-on type of learning and development. So create a fictional POC that encompasses all of the technologies that you're targeting and pass it over to the team in a guided manner and have them build something in 30, 60, 90 days. I don't know that in periods of transformation that you're going to get anything more effective than that, because we all know that hands-on learning is always exceptional to reading.
00:33:44 - Ishan Anand
You know, this brings up, I think, a baseline question we should have started with at the beginning. And by the way, we're past the halfway point, so feel free to raise your hand. We'll bring you up to the stage, and we can start having audience questions for the panel. But the question that maybe we should have raised earlier, especially for Ellery, Chris, and Mahaela, you guys have helped a lot of companies go through it. I think, Theo, you've been in a case where it was what I'd call a net-new build from scratch. But where you're taking an existing company and you're trying to migrate them over, or help them migrate to composability, what's the range of times you've seen that actually take in terms of months or weeks or quarters, typically, for a customer to get, say let's call it the first unit of output that's composable, not necessarily migrating the whole stack?
00:34:37 - Mahaela Mazinga
Highly variable, in my opinion. And again, I think that it all depends on who you can leverage within the organization to move that initiative forward, and their expertise and their background. But the biggest question also is: how do you not get yourself in the same position again in 20 years? So really, are you building a culture of innovation? Do you understand what that means? So it's constant, it's iterative, it's curious. And if you haven't had that, it's probably why you've stagnated for 20 years on the same type of technology. So this is more of a culture shift, and it takes more than just tech to transform. A lot of that equation is people. So it also depends on how fast the organization can move in a transformation. If they can move fast, you're looking at three or four months. If they can't move fast, then you're looking at two years.
00:35:46 - Ishan Anand
Great.
00:35:46 - Theo
That's why it's entirely the number of people. It's the people and their willingness more than the tech itself.
00:35:52 - Ellery
Almost always.
00:35:54 - Chris Hough
Yeah. I will agree with both of those points. I can provide an example. We have had a very large retailer go live with a small subset of their purchases on our commerce platform within four months. And they did so migrating off of a custom-built AS/400 solution. But I think that's one of the tenets of a composable solution, right, is that you are able to have such a small feature set, or such a decoupled feature set, that you can use a strangler pattern even though you're coming up from a monolith. All they need to do is build up the services in between to communicate. So this company actually came on board and was accepting orders just using checkout. So they had that tangible thing live within four months that they could use as kind of their starting point.
00:36:54 - Scott Steinlage
Wow. So AS/400, that must have been a manufacturer. I was gonna... Bro Nifty wanted to come up and ask a question, I think, here.
00:37:08 - Bro Nifty
Yes, thank you, thank you. Yeah. I wanted to touch on the current fad-interest
00:37:16 - Chris Hough
Buzzword.
00:37:17 - Bro Nifty
The Kubernetes thing. I would say that, and this kind of ties into Theo's Ship of Theseus story on the infrastructure, data-pipelines side of things, Kubernetes is not something that you'd need for a startup that's going to build a product to go direct to consumer, even ecommerce or streaming or anything like that. You wouldn't need it. But if you're an older, mature company that uses data to make business decisions, like you need executive dashboards and a bunch of analytics and data warehousing, maybe machine learning, and doing all these kinds of things deep, and you have a whole bunch of analysts and stuff like that, that's when you would need data pipelines, business intelligence, data warehousing. And cloud was the shift from on-prem to cloud through the 2000s to the mid-2010s, 2015 or so. But then more recently the shift is going to Kubernetes, and what it does is it takes the emphasis off the
00:38:47 - Bro Nifty
particular cloud where you have vendor lock-in, like whether it's AWS, Google, Azure, or one of the other ones. And it abstracts it out like the Lego blocks, where you can have one Kubernetes logical layer on top of one or the other cloud, or multiple clouds, and you can swap out the components or whatever. It doesn't matter once you put it on Kubernetes. It's a build-once, run-anywhere kind of platform for pipelines and stuff like that. So that's all I want to say.
00:39:21 - Mahaela Mazinga
That's also a great case where you can buy that now. So Kubernetes was certainly a part of a massive transformation that we did, and it has its place. It's a mature tool. And also, if we're talking about self-managed Kubernetes, I mean, right, you're in for a lot of long nights. So again, the more mature the tech is, the more you have to configure. It's advisable that you go a different route if you don't have the team to support that.
00:39:59 - Theo
I like the point that was made earlier, the idea of what are your differentiators. If you're not selling developer tools and your company isn't directly facing developers trying to solve weird infra problems, you probably shouldn't be solving weird infra problems with things like Kubernetes. Kubernetes is a great tool for those specific problems if that's the problem space that you live in. But very few people here, statistically speaking, are going to be in that problem space. The average developer faces users, not other devs. And those technologies are much better for when dev teams are facing another company's dev team.
00:40:35 - Ishan Anand
I think we have another person from the audience. Jacob, did you have a question for the panel?
00:40:42 - Jacob
Yeah, kind of a question slash statement also. What's up, Theo?
00:40:50 - Anthony Campolo
Jacob?
00:40:51 - Jacob
Hey, Anthony. I guess one thing I'd throw out there is what would be everybody's take here for things like, I guess it's kind of a newish concept. So you have the Cloudflare Workers developer platform, and then Sunil put it way better, and Theo probably has more context on this with his conversations with Sunil Pai, who I work with, along the lines of the platform as a service for platforms as a service, kind of like you're buying a way to build for other people that are building for people to buy.
00:41:38 - Theo
The way Sunil put it, and we're still working on words for it, was service as a platform. So rather than you buy some database and then you call that database with your database client, instead you might buy something with a database in their web system, write a quick JavaScript function that outputs whatever format you specifically need, and then you call that from the database system. So it's like, what is the in-between of database as a service and GraphQL as a service? It's database as a service with a service on top where you can write your own custom code. And that's a trend that we're starting to see more of, things like the Supabase functions, things like Cloudflare's data store. From both sides, we're seeing the convergence of the platforms and the services almost inversely from how we're used to. And it is an interesting trend. I would argue a lot of the companies doing this are doing it because it forces more buy-in in a space where there wasn't any. PlanetScale has kind of fragile ground right now because if your company gets big enough, or the price of PlanetScale gets too high for you, you can move off somewhat trivially.
00:42:46 - Theo
The core pieces are open source, and the standards are pretty standard too. But if I built half my company's APIs literally inside of PlanetScale's GUI, I'm screwed.
00:42:56 - Ishan Anand
It's a form of lock-in, basically. You see this sometimes with AWS. If you've got a million different services across AWS you've maybe set up, then having to migrate off all of that, service by service, is going to be a bit of work.
00:43:12 - Anthony Campolo
Well, there's also like SDKs because if you think of like you could use Supabase just for Postgres and then you could port that anywhere you want that supports postgres. So if you build everything around Supabase SDK, then all of a sudden your code is no longer portable.
00:43:28 - Theo
Yep.
00:43:30 - Ishan Anand
But this feels like a question for, I think, people who are building platforms for others, so to speak. Is that an accurate statement here compared to, I forgot who said it in the panel earlier, but the closer the tech gets to the user or the customer, that's where you focus and the rest you kind of abstract away. And so if you are really close to the customer as a business, and you're not building a platform for somebody else to get close to the customer, it feels like that's the litmus test you would use here. If your customer is somebody building a platform, then you worry about this. If your customer is an actual user, then you don't worry about this. Would that be a fair statement?
00:44:20 - Chris Hough
Yeah.
00:44:21 - Jacob
So this is actually what I was really coming up here to emphasize, was there was a lot of conversation that was really leaning toward and favoring the idea that the user, quote unquote, is going to be some sort of customer, client, somebody at the other end of an ecommerce or blog website or whatever it may be. Whereas a lot of the people that are users for the stuff that I'm building right now at Cloudflare, they're engineers. So it's like we still have to keep the same things in mind, though. We have to consider UX or DX, whatever you want to call it. We have to consider how abstract we want to make it or how low-level we want to make it. These are all the same, like how much of it do they really want to build and how much do they want to buy?
00:45:22 - Ishan Anand
So yeah, it's actually a really important and interesting point, one that's near and dear to my heart personally because what we do in my day job at Edgeo is we build products for developers. Our customers are developers. I think most of the folks in this audience are developers. And so that's a different set of users and different set of concerns. And you're right that the way we've laid this out is really about the consideration of build versus buy for that audience and not for the people who are building platforms for developers. It's kind of like that old story of, they say, what does the world sit on? It sits on, I think, some turtles, or an elephant that sits on turtles. And then the question is, what's below that? Turtles all the way down. And so it's that layer beneath. It is another dimension of consideration that I think we haven't really touched on. But it's worth noting, and definitely one that's near and dear to our heart as well.
00:46:30 - Theo
I tried my best to frame this as people who are facing users that aren't developers. And I have always felt like developers think as though their customers are developers too, a little too often. So I try to intentionally push really hard the other direction. Back to service as a platform and how that fits here, though, if you're a developer company facing developers, especially if you're facing newer developers or adoption problems because your stuff involves too much buy-in on the other person's side, things like adding the ability to write JavaScript in a REPL to transform that data shape as a service on top of your platform are nice wins on that side. And I get why the developer companies are doing it because it increases lock-in, which obviously they want. And it reduces friction to make the thing work the first time in a demo or a getting-started project, stuff like that. It helps those companies get adopted more easily, and it makes it harder to move off of them in the future. On the other side, though, if you're a company that's facing users, how do you decide if you should use one of these new things?
00:47:33 - Theo
I think it depends largely on what the expectations for that project are and how bad the cost is of having to... are you going to use this for two functions that are never going to change, or are you going to use this for all of your functions in a codebase that's going to grow from two developers to 20? I think that's really what my talk was meant to be about. Those types of functions have really low buy-in cost, normal, medium maintenance cost, and then really high buy-off costs. So you have to be conscious of that as you make the decision if you're not building a developer platform. But yeah, if you're Cloudflare, go build a bunch of this shit. It's going to make people really happy and it's going to make you a lot of money. But on the other side, be careful when you use these things.
00:48:13 - Ishan Anand
So let me then turn this over to Mahaela and bring Mahaela, Chris, and Ellery in. When you're making a decision on buy versus build, how much does the developer experience that the people who are creating the platforms have created matter in the decision?
00:48:34 - Mahaela Mazinga
I mean, it matters a lot. Of course, it depends on what you're buying, because not all things that you buy will necessarily matter in a developer experience. But again, those are certainly things that aren't part of your core business. So buying something that has an incredible developer experience, again, to get quality and consistency and efficiency for the team, should absolutely be a target.
00:49:10 - Ellery
Yeah, that developer experience is dollars, right? If you have to invest a certain amount of time to build something, it's easier for your team to build it, they want to use that platform, and they're emotionally invested in it, then that's a value-add in that case. Now, if it's contradictory to the business needs, then you shouldn't do it. And you see that sometimes where the tech team is hard-set on using some tool or some framework, when really there's no business alignment, and you need to make the right decision there and not do that. And this goes back to Mahaela's point that you should find people who are smart and eager to learn. It's not always about picking the new shiny things. Sometimes you need to pick something more reliable or learn something new because you have a tool looking for a solution, and you need to flip that around.
00:49:59 - Ishan Anand
Do you often see that the products that people will buy into this stack rather than build themselves, I would imagine, have a better developer experience? Because one of the things a company around a service can do, in addition to maintain it and add new features to it, is also invest in the better developer experience. And that's where teams might think, oh, I'll build this thing. But if you buy it, it'll actually have so much less friction and so much more productivity than if you had to build it yourself. There's a graphic, I think it was actually bytes.dev, who has a really great newsletter. They had an example of a painting: this is what happens when you buy a service and then when you try to build it yourself. It was like somebody hand-drew the face. That's always really stuck with me. It's like, which would you rather use? Do you feel that it's a usual rubric, or is that not always the case?
00:51:02 - Ellery
I don't know if that's the usual rubric per se. Oftentimes if you're buying a solution, it's because if you didn't do that, you would need to go buy and configure a bunch of point products and manage them, handle orchestration, et cetera. This goes back to, we all want to avoid Kubernetes if we can. So if you look at something like Edgeo App Platform or Cloudflare Workers, sure, you could go find a hosting platform for JavaScript, manage scalability, et cetera, but do you really want to do that? Do you want to be on the hook for disaster recovery, high availability, patching, security, et cetera? Or based on where your scale is today, should you just go buy a product that works out of the box? You have a bit of vendor lock-in, but if your business 10x's or 100x's, then you can look at bringing that in-house. But do you need to do that right now? And almost always the answer is no, you don't need to do that right now.
00:52:02 - Mahaela Mazinga
Ellery and Ishan, I guess what you really need is the right person in the room to make those decisions the proper way and really employ true tech strategy in terms of how it is that your business is going to harness technology to bring value. So unfortunately, that's sometimes counter to what a developer might think. And the world and the business is bigger than all of us. So you need to have the right technical leadership to have those conversations and to lead the team toward the right decisions.
00:52:43 - Anthony Campolo
So you need to be in the room. That's what you gotta do.
00:52:48 - Theo
Yeah, well, you need to be objective.
00:52:50 - Chris Hough
Right.
00:52:50 - Ellery
This isn't about using the latest and greatest tools. It's not about picking something that will look great on your resume. We're always in pursuit of meeting business objectives, and we need to stay mindful of that.
00:53:04 - Chris Hough
I think also, especially if you're building something or part of a composable ecosystem,
00:53:12 - Theo
Right.
00:53:12 - Chris Hough
I think part of that is the partnerships for the different parts that function together. We have a lot of customers using integration partners such as Valtech.
00:53:25 - Ellery
Right.
00:53:25 - Chris Hough
And they bring the expertise across the board for the different components that can help.
00:53:30 - Scott Steinlage
Right.
00:53:31 - Chris Hough
So you're not reliant on your internal resources to upskill quickly and learn all of these different components right off the bat.
00:53:42 - Ishan Anand
That's a really good callout. Do you find that when customers are migrating to a composable architecture, or they're doing build versus buy, that there's a temptation, especially if they come from, shall we say, a more legacy mindset, that it just feels like too many services? Though the flip side of that, and there's a temptation to try to buy all the services from one? Or is it very clear they're like, we don't want to put all eggs in one basket, and they're trying to overcompensate for that?
00:54:16 - Chris Hough
What I have seen is kind of a sequential composability. So maybe they're just buying the initial components. Personal experience here, they come and buy Commerce Tools, right, and they start their migration plan, and then we get through solutioning with them and make the determination, oh, you're going to want to replace your search functionality or your product catalog management. So I don't see a lot of customers really going all out and purchasing so many different components that they're overdoing it. It's more sequential. They might get two or three off the bat, but it would be more of an iterative approach, I would think.
00:55:07 - Ishan Anand
You mentioned the strangler pattern earlier. Do you want to just explain that to the audience who may not have heard of it?
00:55:14 - Chris Hough
Yeah, and it comes from an old article that an architect, I can't remember his name, came up with about the strangler fig, which is a tree in Southeast Asia that kind of nests in the top of existing trees and then drops its roots down. So the analogy here is that your solution, especially coming off a monolith, is you would take the approach of breaking out features, components, and slowly replace the monolith features and components with those. So eventually, you strangle it out and kill the whole thing off.
00:55:57 - Ishan Anand
Yeah, I think that was Martin Fowler. Mahaela, I think you wanted to add something, but go ahead.
00:56:02 - Mahaela Mazinga
Word of caution. Strangulation is a more mature model, and at some point you have to end it and you have to be complete, because you run a very, very high risk, if you're not mature enough to employ that model, of then being stuck in the middle. And now you're running both your old systems and your new systems. So I know there's this notion in the marketplace that nobody likes big bang. I think that's a very individual decision of how you approach that transformation. And strangulation could be the appropriate choice. But recognize you need the end goal and you need to be accountable to getting to the end goal, because otherwise you will create a massive mess for your organization.
00:56:57 - Chris Hough
I completely agree with that, and I'm sorry if we just have a minute. So the concern there is that a lot of these customers migrating off of monoliths or legacy tech, that stuff is so ingrained that it is difficult to strangle off the features, build out the components, while keeping the rest of it running.
00:57:20 - Scott Steinlage
Yeah. So we do have two minutes left, just to be mindful of all the panelists' time. But I know Jason did come up here to, I believe, ask a quick question if possible. We would like to allow for that.
00:57:36 - Theo
No, I didn't have a quick question, but I'll yield back my time if someone else wants to ask a quick question. Quick pro tip for Ishan and Scott: Twitter Spaces tend to take about half an hour to an hour to ramp up and get their core audience. It might be worth finding a way to structure these where there's like an hour of just chitchat, then the meat of it at that hour point. If you can find a way to do that in the future, it might help with, like...
00:58:00 - Scott Steinlage
Yeah, I've noticed that throughout these, near the end we really start getting excited. People start, you know,
00:58:08 - Ishan Anand
Yeah.
00:58:09 - Scott Steinlage
Going at it. But either way
00:58:13 - Ishan Anand
That's really good advice. Well, we only have basically a minute left, so I'll just say thank you all, panelists, for the discussion today and really encourage everyone to check out composability.dev, and hand it over to Scott to take us out.
00:58:32 - Scott Steinlage
Awesome. Well, I just want to thank again all the panelists for coming up here, as Ishan said, and joining us today. Really some wonderful conversations were had, and maybe like Theo said, we should plan something out in the future to do maybe a couple hours just in the calendar. It may not go that long, but hey, it may. And so there could be some really good conversations had that could create thought leadership throughout the niche that we're in and what we're trying to accomplish here, and just really improving the lives of developers and businesses as well, so customers absolutely, yes, that is definitely at the forefront. So thank you so much, everybody. Thank you for joining us here at JavaScript Jam Live. Don't forget, we do this every Wednesday from 12 to 1 o'clock Pacific Standard Time. So if you want to join us again, please jump in. We would love to hear more about this as far as scheduling more panel stuff out. I'm sure we'll be doing that more in the future too. But typically we have this open-mic kind of conversation, which these do turn into, even the panel ones, you know.
00:59:49 - Scott Steinlage
Yes, it had a category that we're on, but I think it really went well. So either way, thank you all so much for joining us today, and we will see you next week. And don't forget to go to composability.dev and register to be a part of this community, because we're creating this awesome community here. We've grown so much. We've grown from 80-something people on JavaScript Jam to well over 450 today. Just keep it up, keep sharing. If you got value from any of the speakers up here, please feel free to follow them. Click on their face, follow, because if they're on anywhere else, you know, well, you're probably going to get value from them there too. All right, so thank you all and appreciate it, and we'll see you in the next one. All right, coming back in for the outro music if you want it. If not, then leave the room.
01:00:53 - Mahaela Mazinga
My favorite part.
01:00:57 - Scott Steinlage
Here it comes. Yeah. All right, y'all, see you next time.
01:01:30 - Theo
Hit it.