The Shift to Infrastructure as Code, with Guy Eisenkot, VP of Product & Co-founder of Bridgecrew

(Intro Narrator at 00:00:04) Hello, my friends. Today, we're talking to Guy, Vice President of Product and Co-founder of Bridgecrew. And we discuss how Guy's expertise in world history impacted him as a founder, the industry transition of moving to infrastructure as code, and strategies to master time management. All of this right here, right now, on the Modern CTO Podcast.

(Joel Beasley at 00:00:34) This is the Modern CTO Podcast. I was hoping that you could start with just giving me a brief background of how you got into technology and how you got to where you are today.

(Guy at 00:00:50) So the story starts about twelve years back. I finished a technical position within a seven-year period of service. And then I got out. I was looking for opportunities, and I joined up with a startup that had just raised a $2 million seed round back then. I started out just looking around, checking out what they're doing. Really loved how you could just compile a group of people from different backgrounds and start building software and seeing if there's an enterprise buyer for it. And ended up spending about five and a half years there. So moved from a bunch of different roles, eventually landing on product management. And then that company's CEO eventually became my co-founder for this company after that startup got acquired. We stayed on around for about a year and then founded Bridgecrew about fourteen months after that. So I've been doing product development, product management for about ten years, and then those first two years were just getting to know the business.

(Joel Beasley at 00:01:51) And is this the first company you founded, or was the one before—were you also a co-founder?

(Guy at 00:01:56) No, I wasn't a co-founder, but I was part of the founding team. I was employee number six or seven. It became probably a forty-, fifty-people-strong company when they were acquired. So saw that entire journey from a front-row seat. So I feel like I was part of the founding team and really felt empowered to give this a go as a co-founder in this company.

(Joel Beasley at 00:02:17) Yeah. Well, being close to the founders, you got to see all the ups and downs and realize, is this something I really want to do? You probably had a real accurate understanding of the difficulty.

(Guy at 00:02:26) Yeah. And it's funny how a startup sometimes, even if you do just once in a row as a product manager over the course of three years, it's actually three different roles. So you do some inbound initially, then you move to some outbound. And then after we were acquired, it was mostly about managing it there.

(Joel Beasley at 00:02:41) And then your background at school is in history, correct?

(Guy at 00:02:45) It is in history. Yeah. I did my bachelor's in history and economics. Yeah.

(Joel Beasley at 00:02:50) And that was at Tel Aviv University?

(Guy at 00:02:52) It was. Yeah.

(Joel Beasley at 00:02:53) And when you're learning history there, are you learning world history or Israeli history?

(Guy at 00:02:58) It's a good question. You can choose. I like world history, so you can kind of get a taste of everything. And it kind of worked, I think, really nicely with economics where you can really tie things together. It's like understanding just, you know, chronology, but also how things ended up. I think that was very interesting to me. I did most of my works and papers on trying to identify these interesting correlations between things that happened in history, but then they have economics as a way to explain their physics.

(Joel Beasley at 00:03:29) Yeah. Well, they're inexplicably tied and one shapes the other, right?

(Guy at 00:03:33) Exactly. Yeah.

(Joel Beasley at 00:03:34) And so I'm curious to know that experience learning about economics and history—has that translated? Has that been useful to you as a founder?

(Guy at 00:03:43) I've given that a lot of thought. I think what you can definitely learn from history is storytelling, which now we can really articulate how important that is for entrepreneurship. Being able to compile a coherent narrative out of the separate pieces is just something you inevitably do when you study history and when you try to kind of build your own analysis of artifacts. So I think that's totally correlated. And I think that's probably my biggest takeaway from those years.

(Joel Beasley at 00:04:17) So when you're pitching investors and going through all the process of, you know, working with new customers and you're telling the story of Bridgecrew and why it exists, what's that story?

(Guy at 00:04:26) It's a story of history. I think where I like to start is actually with the previous company. We didn't say, but the previous company was Fortscale. It was founded in 2013. It did machine learning-based analytics for cybersecurity. The reason I like to start with that is because it was a category that had formed and was coined very quickly, but had become part of mainstream security analytics pretty quickly. So apart from it showing us a process where the industry goes from not understanding a problem all the way to understanding it and actually, you know, getting customers to pay good money for it, it really helped us, or helped me, comprehend what it would take to build a differentiated product in a very crowded and fast-paced market, which is cybersecurity. And Bridgecrew starts at 2019. My two co-founders and I meet up. We get a group chat together. We have one co-founder, Dan, that was in San Francisco back then. Myself and Barak, our third co-founder, were here in Tel Aviv. And we started a process where we start to interview—not podcast interviews, but professional interviews of people from our personal network, people that we've worked with, people that we have considered to be industry insiders—and started to understand what their problems are which relate to cybersecurity and specifically cloud security. When we tried to identify the patterns and the recurrent themes, and once we nailed in or zoomed into a few themes that seem to be novel enough and that are not getting solved by the current toolset, we started exploring the possibility to raise venture capital and to start building something that might compete in that, as I said, crowded space.

(Joel Beasley at 00:06:04) What was that problem that kept coming up over and over and you decided, let's narrow the focus, let's make our world small and really get this one thing right. What was that thing?

(Guy at 00:06:15) That thing was cloud security. There was a disconnect between developers—the people that actually write applications, deploy them to the public cloud, and essentially are in charge of the ongoing development and maintenance—and security teams that at that point, this is, you know, 2019, didn't necessarily have neither the tooling or even the visibility to the problems that may arise in a cloud-based environment or an application that's hosted in the public cloud. We met security teams that were in charge of, you know, some of the biggest companies in the world, and we found out they don't even have permissions and access keys to create a full inventory of what they have. So that's the origin problem. And then we understood there was a gap between developers and security that has to be mitigated somehow. And that kept coming up, you know, different shapes and sizes. So organizations had described that problem in different ways, but it was very clear that these two important functions are not working in tandem in the way that they should, with their full realization of how big of a problem cloud security is going to become.

(Joel Beasley at 00:07:19) And I'm not actively working in larger companies, so that's one of the areas where we run up to my limitation of experience. But the difference between developers and, let's say, cloud or security people—you said that there's a disconnect, right? Are those cloud security people, are those people that configure networks or are they software developers that can also configure? What type of person is that?

(Guy at 00:07:42) So there I would just think between two profiles. And let's just take cloud-native companies as a subset first, because when you go to those very big enterprises that are in that digital transformation journey, it gets complicated. But for a cloud-native company, let's take an Airbnb or Netflix as an example. Anyone that's an application developer is an infrastructure developer. It's not like, you know, when you develop on a cloud provider, on a public cloud service, you don't have to ask someone to wire a new router or hook up a new database or spin up a new virtual machine for you. It's as a service. You do this alone. So even if you are a data scientist or even if you're a front-end developer, many times you own building and provisioning that infrastructure that you're going to eventually develop on top of. So I don't want to oversimplify this, but eventually for cloud-native companies, infrastructure or application developers are the same. And then the subset or a second group is DevOps. And DevOps or platform engineers, infrastructure engineers—as companies grow in size and scale, they understand that there's undifferentiated work that doesn't need to happen on every developer's workstation. So they can have, you know, three or four people that are in charge of creating reusable infrastructure that everyone that develops that application on top of can kind of reuse and spin up with very little effort. So those are the people that understand the problem, have full access, you know, are kind of entrenched with the ongoing issues of maintenance and security. And then I think the other end is the core, what I call corporate security, that's used to managing endpoint security and network security. Didn't completely make the transition to understand that their digital footprint has moved into the public cloud. So that's essentially the profiles in which we saw the disconnect between.

(Joel Beasley at 00:09:35) And which one is the one you focus on the most or is the largest part of your customer base?

(Guy at 00:09:41) I'd say groups one and two, but predominantly DevOps. They're the, you would say, the hands-on users of our software. They take our tools, deploy them, and actually review results and use them to deploy guardrails and policies, et cetera. But there's second- and third-hand users that are not necessarily working on our console, but are, you know, enjoying the benefit of us running in the background because we kind of prevent some of the bad things from even getting into their production environment at all.

(Joel Beasley at 00:10:11) And then for the people, like these DevOps people—you know, you and I are both open source people, right? So you will experience a problem. First, we go see if there's open source, if there's an availability, a possible solution over there. What's the problem that those DevOps people are like, I'm going to go search for a solution?

(Guy at 00:10:29) Yeah. And just before I answer that, it's not only that DevOps people will land on a problem and look for the solution in open source. If you look at the standard DevOps stack for the last five years, it's been mostly open source. These are the types of people that really are either people that build themselves and contribute back or are heavy users of some of this open source code because it's just, you know, it's just community maintained. It's up to pace. It's innovative, novel, everything. I would say the problem they ran into is creating consistent baselines for infrastructure as code deployments. So we didn't talk about infrastructure as code, but infrastructure as code was a breakthrough moment for understanding what could potentially bridge between security and developers. Spend a minute on that, but infrastructure as code is essentially using a programming language to describe how infrastructure or cloud infrastructure should work once it's declared and developed. And the nice thing about infrastructure as code is that because it is a programming language, you can enforce practices directly into the language. It's very structured, so we can introduce different development practices and guardrails that ensure that people are using, or developers are using, you know, security and compliance best practices when they build, you know, just in a free-form programming language. So DevOps would have the problem of developers on their team using either prepackaged or self-sourced templates and modules from the public Internet, but there's no consistent way to vet and validate that those templates are actually up to standard with regards to how DevOps wants infrastructure to eventually get provisioned and deployed.

(Joel Beasley at 00:12:08) So you almost took static code analysis and built it specifically for infrastructure as code?

(Guy at 00:12:17) Spot on. Yeah. So static code analysis was one of many techniques where you need to do also composition analysis because some of the code is actually imported from the public Internet. So it's a combination of static code analysis and composition analysis.

(Joel Beasley at 00:12:32) Oh, yeah. I simplified it a lot.

(Guy at 00:12:33) I'm just trying to wrap my head around it because when you were talking about that—when the podcast started to take off, we've been doing this for five years. And I'd say for the past four years, I haven't been writing software on a daily basis. Before that, my entire life, basically, since I was a kid, writing software daily. I just found that I sort of satisfy that need getting to talk to great people like you. And what I remember was four or five years ago, just starting to play with the infrastructure as code. It probably came out way before that, but at least it came on my radar then. I think I was using something called Terraform. Is that a tool that does it?

(Guy at 00:13:06) It's the most popular one. The most popular tool to do it.

(Joel Beasley at 00:13:10) Okay, cool. I'm glad that what I happened upon became the most popular one. So are you a replacement for Terraform, or you would be analyzing the Terraform configuration against a set of standards?

(Guy at 00:13:21) So the latter. So Terraform is just one flavor. There's—we currently support thirteen. Every cloud provider has now their own version of Terraform. You can use Terraform across all clouds, but there's actually domain-specific languages for every specific cloud, and there's some specific languages for different types of use cases. So if you want to kind of, you know, focus more on networking or do something that's more related to managing databases or compute as a control plane, you can use different types of languages. But yeah, so Terraform, definitely number one. So we'll take Terraform wherever, whenever it's built. We'll perform these checks—essentially static analysis checks, composition checks, a few others. And as you code or when you push out a pull request, you'll get different automated responses from our bots. Something like, hey, you have not used a proper logging method for this new data storage resource. So you're spinning up a database, but you're not writing the logs anywhere. So you won't be able to charge. So that's one common misconfiguration that we try to help DevOps harden into developers' workflows.

(Joel Beasley at 00:14:35) I want to take it up a level for the business side of things as co-founders. So, I mean, it's great. Make developers' lives easier, help connect these DevOps and programming and help everything flow smoother within the company. That's a little bit ambiguous. From a co-founder or founder standpoint, why am I expending capital on this? Why can I say, okay, I allocated capital to this because of that. What's the benefit to the business?

(Guy at 00:15:01) Let me tell you a story. My co-founder, he thinks that we're, as product and engineering organizations, constantly in a state of migration. Whereas, you know, ten years back, you would do a database migration every two years, actually our company introduces a new database every six months. New types of features, new types of business requirements now drive the need to be constantly on the move and utilizing both from an economics perspective, but also from an efficiency perspective, the best that cloud providers have to offer to us as CTOs, as architects, et cetera.

(Guy at 00:15:38) So assume that we are constantly in the business of migrating to get that for efficiency. Infrastructure as code essentially unlocks that for you. So it makes infrastructure provisioning something that's much less cumbersome, much less manual, and much more automated. So you can lift and shift a hypothetical application from one database to another with twelve, thirteen, fourteen lines of code. Those lines will effectively define the new database, define a job that copies the data to the new storage, and also make sure that everything that was routed to that last database now flows to the new one.

(Guy at 00:16:13) So that's the type of business process that application and infrastructure developers find themselves doing in the public cloud every month, every quarter. So utilizing infrastructure as code just makes that a hundred times more simple than just doing it manually and just helps evolve and build better applications much, much faster.

(Joel Beasley at 00:16:34) So are some of your customers actually in that transition of just starting infrastructure as code?

(Guy at 00:16:40) I would say that everybody's in somewhat of a transition. You mentioned correctly that four or five years ago, infrastructure as code and specifically Terraform has started to catch on as a de facto language to provision infrastructure. A lot of companies used other languages previously or used other custom tooling they built themselves. So it's not really about moving everything into infrastructure as code, but rather understanding that an application infrastructure is almost like archaeology. There's different layers.

(Guy at 00:17:11) You know, there's the stuff you built four years ago that's much harder to migrate, but there's the stuff that you built six or seven months ago that might not need any maintenance at all and may already be written in infrastructure as code. Our challenge as technology leaders is to be able to adapt to both types of layers, even if they are or even if they're not managed through infrastructure as code and provide consistent security for both.

(Joel Beasley at 00:17:35) So do you come up against, when they're coming to you, do you find yourself selling them the concept of infrastructure as code, or have they already made it over that—they already have infrastructure as code, and they're using you to help optimize it, make it more secure?

(Guy at 00:17:49) Actually, I would say more of the former, but we see both. I think if you are in the business of transitioning your application stack into the public cloud, you probably have either us or our open source on your radar. We're having both those types of conversations. Our current customer base is much more leaning towards people who already made a disproportionate investment into infrastructure as code and now want to make a disproportionate investment in making sure that it's essentially secure.

(Joel Beasley at 00:18:18) So you find yourself almost in a consultative role in some of your sales, helping people understand the benefits of infrastructure as code?

(Guy at 00:18:26) I would say so. It's not even just the consultative part, but also somewhat of an adviser. Right? So sometimes we come in—we do have a very opinionated mindset when we look at how people have implemented infrastructure as code. So we try to not only consult, but really provide the operationalization path towards getting into a world-class infrastructure as code practice.

(Joel Beasley at 00:18:50) Yes, I like it. Now do you have a sales team, or is it just people finding you through your open source offering and then upgrading to paid?

(Guy at 00:18:57) Yes. So let's just tie off that story. So Bridgecrew, the company, was acquired—yeah, it was not yet acquired. It was founded in 2019, but only two years later, it got picked up, and we had the privilege of joining the biggest cybersecurity company in the world, Palo Alto Networks. So now we benefit from both developers coming from the broad internet who use our open source, but also Palo Alto has an amazing sales force that goes out and makes sure that their entire amazing customer base has the opportunity to utilize our portfolio of tools and products.

(Joel Beasley at 00:19:27) That's brilliant. Because you need to tap into their entire customer base, all of their sales infrastructure. You can be an upsell on things. So you're now inside of their ecosystem, so that'll help you continue to grow. But what's the next thing for you guys? What are you excited about? What's getting you up out of bed in the morning?

(Guy at 00:19:45) That's a great, great, great question. I think our benefit was that we got acquired early, so we were able to fulfill a small dream by getting our early product, or almost our MVP, out to market so fast, which has been a brilliant experience, an amazing experience. After tapping in and capturing that market, we just understood how big the opportunity is. Just seeing—I think it's clear, but almost every company with a digital footprint in the world is a Palo Alto customer. So we had profound conversations with CIOs, CTOs, CISOs, and their kind of long tail of problems that are not yet solved by Palo Alto.

(Guy at 00:20:23) And the next hill for us to climb, and we've been chiseling on this problem for the last year and a half, is essentially combining infrastructure and application security into one cohesive set of tools and platforms for both developers and security. And the cloud really generates a great opportunity for that because if in the past, application security was this own almost legacy market with a few very big standalone vendors that have kind of done their thing—you talked about static analysis for the last ten, fifteen years. The cloud turns that upside on its head. It just introduces so many types of new dependencies into your code.

(Guy at 00:21:01) I like to say that almost every company now is almost an open core company. We use so much open source internally where it's hard now to differentiate between our custom code, our own pre-built, manufactured code, and everything that we brought from the outside. And those lines in the cloud get even more blurry because you use code from your cloud provider that you can't even see, and you don't have full visibility into how they manage their practices. So huge challenge for big enterprises to understand how that footprint affects their applications' posture. And we've been thinking of new innovative ways to create a single point of view, both from developers and security, to be able to comprehend their infrastructure and application security risk in the way that they actually do combine.

(Joel Beasley at 00:21:49) So we want people to go download and try the open source. Yes. Is the product that's going to merge application security with infrastructure as code—is that product actually out and available for people to play with right now or no?

(Guy at 00:22:03) It will be once we publish this.

(Joel Beasley at 00:22:07) Okay, perfect. How do people access both of those things? How would I go about playing with either of these tools, or is it just one tool that has two features now? Explain that to me.

(Guy at 00:22:16) Okay. So everything connects to our open source. It's called Checkov, C-H-E-C-K-O-V. Check it out on GitHub. It's our one-stop shop project for everything that has to do with cloud code security scanning. It has about 200 worldwide maintainers. It's been downloaded 10 million times from PyPI, and it's great. People who want to secure their Terraform, that's probably their first go-to tool. We've essentially mounted everything that we built for application security into Checkov. To unlock that, you will need an API key.

(Guy at 00:22:52) You can get that from either a Prisma Cloud deployment from Palo Alto or from our own Bridgecrew SaaS, which is publicly available and even has a free community tier. And that unlocks everything. It unlocks infrastructure as code security, image scanning, secret scanning, software composition analysis, a bunch of good stuff that helps you secure your cloud-native application.

(Joel Beasley at 00:23:16) And then your website is what?

(Guy at 00:23:18) It's bridgecrew.io.

(Joel Beasley at 00:23:20) Do you have a careers page on there?

(Guy at 00:23:22) We do. Yeah. We'd love to have you, Joel. Come on.

(Joel Beasley at 00:23:25) Yes. Asking for a friend. Yeah. So you guys have a careers page. You're currently hiring, I assume. Correct?

(Guy at 00:23:34) We are. That's correct.

(Joel Beasley at 00:23:35) Alright. And have you done any partnerships with, like, Terraform so when people are exploring that, they see that your offering is a way to help secure it?

(Guy at 00:23:43) We have. So we have three big partnerships within the ecosystem. One big one was with HashiCorp, which is the commercial company behind Terraform. And we've had a long-lasting relationship where, you know, we're both helping people who contribute to open source Terraform build out better and more secure modules. This started back in 2019, 2020.

(Guy at 00:24:06) We just directed people to use Checkov. We helped them identify different places where their modules were not using the best security and compliance best practices, which was great. We've built out a great commercial relationship where both the Bridgecrew and the Palo Alto tools have just great bidirectional integrations into Terraform Cloud and the HashiCorp stack. And if you're using both products and you connect them together, you just get the best of both worlds. We also built out great relationships with source control management providers.

(Guy at 00:24:35) So GitHub, GitLab, and Bitbucket. We've built out these deep integrations where we just utilize their native APIs to inject a bunch of this automated reasoning directly into the developer's console. So if you write a pull request in a repository that is connected to us on the back end, you just get all of this great context as you type, as you write. It just makes your pull request ten times more secure than they were.

(Joel Beasley at 00:25:03) Dude, it's becoming so crazy advanced. When I saw that new GitHub typing, the predictive coding or whatever—I forget the name of it. But, man, when I saw that, I was like, wow, have we come far really fast, you know?

(Guy at 00:25:18) We have. And actually, for infrastructure as code, you get the same benefit. There is so much you can do. I have this hypothesis that developers just need to get the right input at the right time because, you know, developers should be very intuitive. You're writing something, you have an objective. You want to make something work. You don't want to search up API documentation. You don't want to start reading these long articles on Google, understanding how to do things. And I think a good developer tool is one that understands you're now tackling a problem and helps you resolve it as fast as you can. So we're really implementing that philosophy into our over thirty ecosystem plugins, trying to do exactly that.

(Joel Beasley at 00:26:00) That is super, super amazing. So people can go to Checkov—is the GitHub project—or bridgecrew.io, and that's where we want to direct people.

(Guy at 00:26:09) Please. Yeah.

(Joel Beasley at 00:26:10) Awesome.

(Guy at 00:26:10) Let us know what you think.

(Joel Beasley at 00:26:12) I want to talk about time management. So this morning, I read an article, and it was about the chief marketing officer that used to be Bill Gates' speechwriter, and now he's the chief marketing officer of Microsoft. And he said when he traveled the world with Bill for two years and wrote all the speeches as he did all of these things, and this was in, I think, '97 to '99. So it was during one of the big explosive parts of Microsoft. And he had said that, you know, Bill struggled with time management like everybody did, and he came up with a system where he would divide his day into 25%, four buckets, and then allocate a theme to each bucket, and they describe it in the article.

(Joel Beasley at 00:26:49) And I thought that was cool. I see a lot of different time management techniques and a lot of different management techniques in general. And what I've discovered personally from all of these interviews is the successful people, they have something. It's not necessarily all they have the same thing. It's they all have something, some way, some discipline of looking at how they run their calendars or they run their lives.

(Joel Beasley at 00:27:13) And so I'm always interested to find out how people approach that. So that's a long-winded way to ask, how do you approach managing your time?

(Guy at 00:27:23) It's a great, great question. I actually have just talked about this with my team a few days back. It's one of the things that I'm very much occupied with. As I move between different roles as the company changes in size and scale, I ask myself, how should I be utilizing my time? And maybe because of, you know, we do mandatory military service here in Israel, I've adopted some of the practices and some of the discipline of a military schedule. And I think if you look at my calendar, the main thing you'll probably find is that I believe in recurring meetings with dedicated topics that really reflect my values and my priorities.

(Guy at 00:28:07) So I try to insert different types of cadences, not just for my one-on-ones, but for my actual hands-on projects, the things that I want to manage personally. And I allocate a frequency based on how I perceive that project to require my attention. So everything from, you know, our strategic roadmap all the way to tactical launches, future launches, I'll try to translate that into a set of recurring meetings with different types of people that help me sample reality in a way that can help me capture exactly—to capture the points in which I can make a decision or make an impact and doesn't impact their velocity.

(Joel Beasley at 00:28:50) Well said. Sample reality so we have the information to change it.

(Guy at 00:28:54) Many times, Brian. I like it.

(Joel Beasley at 00:28:56) This is great, man. This has been a complete blast. I want to make sure that we cover everything that you could possibly want to get out there to the world. Is there anything that we didn't discuss that's on your mind?

(Guy at 00:29:07) Maybe our launch with regards to software composition analysis.

(Joel Beasley at 00:29:11) Yeah. Is there an event? Is there a big ordeal? Is it just an email newsletter going out? What's the launch actually look like?

(Guy at 00:29:18) Yeah. We'll do it all. It's a big Palo Alto-themed launch, so there was 150 different action items going everywhere. It is going to be quite a big launch. It's our, you could say, our debut into proper application security after really mastering the infrastructure side of cloud security.

(Guy at 00:29:34) But I wanted to throw two stats at you that I thought were pretty staggering. We've been scavenging data and trying to understand, are people using secure templates and best practices? And we found some staggering results. We found that out of all of the infrastructure as code Terraform templates you can find through Terraform, almost 50% contain at least one misconfigured item. That means that if you download that module and you do nothing to it apart from deploying it into your public cloud, you're essentially at a one or two risk of deploying a new misconfiguration.

(Guy at 00:30:06) And those could have dire results in anything from opening it to the public internet or just using sloppy credentials that can be picked up by someone who performs counterintelligence and identifies those weaknesses. Same goes for images. We all use images on Docker Hub. We analyzed Docker Hub, and we found over 90% of the latest images that are used by a bunch of different very popular distributions for some of the biggest projects that people use for data processing and compute—about 90% have at least one medium or high severity vulnerability in them.

(Guy at 00:30:42) And that just gives you the sense of how profound the problem was with the current state of the code we're importing into our applications. The best practices are just not implemented, and the baselines are just not good enough. And I think one thing that we're trying to do with Checkov, and the reason we're keeping it open source and trying to contribute as much of the content to make sure that as many developers use it as possible, is because we've had such a good experience doing the Terraform community a service and just mitigating potentially hazardous configurations from the public domain and making sure that people use security fonts. And we're just hoping we can expedite that with open source packages and popular distributions of images that are used throughout.

(Joel Beasley at 00:31:26) So we don't just download random things off the internet and put them into our projects? That's a no-go, exactly. Oh, man. Well, Guy, this has been absolutely fantastic, man.

(Joel Beasley at 00:31:36) We made a podcast. How do you feel?

(Guy at 00:31:38) I feel great. There's some good stories there. I owe you a ton of things.

(Joel Beasley at 00:31:42) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.