Peter Morales, CEO of Code Metal, on modernizing the legacy code behind US national security
Transcript
Maggie 00:36
In this episode of the Mission Matters podcast, we sit down with Peter Morales, the CEO and co-founder of Code Metal AI. Code Metal is building the future of code translation. That is taking code written in one coding language and translating it into a different coding language, and then verifying the accuracy of that translation.
Pat 00:57
Code Metal is focused on building code translation and verification tools for several major use cases, including code-based modernization, edge hardware deployment optimization, and code portability. Code translation projects that previously took teams of engineers months of work can now be completed in just minutes with Code Metal. Code Metal's capabilities are a crucial part of the future of efficiently developing software-defined commercial products and has many military applications, helping engineers build software-defined hardware products and bringing modern software capabilities to the US government and other mission-critical customers
Maggie 01:41
Since it was founded in 2023, Code Metal has raised close to $200 million and signed contracts with groups across national security and commercial sectors, including L3Harris, RTX, Toshiba, and the US Air Force. The founding team has deep experience in building AI tools for defense, hailing from MIT Lincoln Labs, BAE Systems, Microsoft, IBM, Data Miner, and more. Peter, thank you so much for joining us.
Peter 02:08
Yeah, thanks so much for having me, guys.
Maggie 02:10
So I wanna start with just a softball question. Can you tell us, why would somebody actually want to translate code in the first place?
Peter 02:18
Yeah. Um, that's a great question, and I think, um, you know, we've gotten that even, even some of the folks that have been here a long time have gotten that question that worked on some languages themselves, so the authors. Uh, you know, language is essentially really how you talk to the hardware and command what it does, and sometimes you wanna move really fast, and you wanna speak really abstractly, and that's what we call, like, high-level languages. They're great for prototyping. They're great for maybe writing some different algorithms you wanna try. But then sometimes you wanna run really exquisitely fast on hardware. You want it to be really efficient, and that means having a lot of say in how you control things. If you think of C++, that's a language where you actually get to decide what you do with the memory, where a lot of other languages maybe don't worry about memory. Um, that level of control gives you optimization, gives you speed, and so being able to translate code into more optimal code, uh, is, you know, one of the hard use cases of what we do.
Maggie 03:15
And I should think of this of, like, if I'm trying to put a computer vision algorithm on a drone or on a satellite or something like that where I may not have access to a whole lot of compute capabilities, that's where I really care about this kind of optimized code. Is that the right way to think about it?
Peter 03:28
Yeah, yeah. I mean, it doesn't have to be a drone, right? You want battery life on your phone. You might want battery life on your laptop. But yeah, being able to be efficient is a real reason for translating code. And then on top of that, you might even have different hardware providers, so maybe you're efficient on NVIDIA, but you wanna be efficient on Qualcomm. Um, having to rewrite your code that, you know, uses their proprietary libraries is a big pain in the butt, but something that I think AI is letting us automate now.
Maggie 03:57
So what does it look like today sans Code Metal? If I am an engineer at a car company or a laptop company or a chip company and I need to build software for these hardware products, or if I'm working in some of these legacy code bases, what does it take to deploy code to these systems, and how can Code Metal fit into accelerating these processes?
Peter 04:19
Well, I, I think there's a really interesting spectrum here. There's sort of, you know, I'm building a product and I need to pick and, and really get locked into hardware. So one of the early use cases that came up was folks were asking not necessarily what hardware c- we could get to, but what's the minimum amount of hardware to make their product as cheap as possible that they needed to run certain code. Um, so, you know, traditionally, that would be maybe you over-spec a bit. You spend a lot of time writing it and hoping it all fits on there, and that means hiring a whole team to do that. Or on the other end of the extreme, we've, uh, we've talked to companies that actually outsource all of their development. They write specs, and they hire contracting houses that are really specialist in the hardware that they've chosen. So maybe they're gonna write FPGA code on a Xilinx FPGA. They've got a favorite shop, and they basically write instructions, wait months for that code to come back, and then have to spend time integrating it back into their product. So it's a wide gamut, but a really, really slow loop that essentially, you know, our mission is to make that instant.
Maggie 05:21
So I know another major use case you all have hit on is the code-based modernization use case. Could you talk a little bit about some of the customer interest there?
Peter 05:30
Yeah. Where, where we've seen a lot of growth, uh, recently is in the Air Force and, you know, DOD writ large or DOW. Uh, you can think of they've invested a lot, right? They pay a lot for software. Um, there's a lot of latent potential in all the different software they've spent But these are old code bases. Sometimes they're reusing systems from the '80s, '90s, even older. Getting those into something that can be cloud distributed across the entire DOW, uh, is something that I feel like is a consistent use case, where they wish they had access to XYZ tool, um, but right now it takes a specialist with hardware that's a pain in the butt to get access to, um, and software, and they need to, you know, basically wait months to get answers back. So we've been taking a lot of code bases in these sort of older formats, or at least more expert-driven formats, and getting them ready to deploy, uh, you know, sometimes in an easy language like Python.
Maggie 06:22
Pat, I know you've talked about how a number of our key weapons systems are written in old programming languages like Ada, which is a programming language from the 1980s. I don't know how many Ada engineers there still are out there today, but it seems like if we wanna have any chance of modernizing these systems or even just maintaining them, these kinds of capabilities that Code Metal is developing are really going to be crucial.
Pat 06:44
Yeah. Actually, it's, it's a mixture of codes. It's even, it's not just one old code. It's COBOL, uh, Fortran, Ada, you name it, uh, uh, develop- large projects the government and industry has developed over many decades is, uh, this in- in- inconsistent, uh, set of, uh, codes that makes it highly inefficient maintaining compilers that are, you know, been out of production for decades, all of that across the board. So that's, that's a real world application of this.
Peter 07:16
Yeah, and I, I think you mentioned the mixture of languages, and it's, that's, that's so true 'cause it's like they're... DOW will buy capabilities, and they're not gonna tell you how to do it. They're gonna tell you, "Meet these requirements." Um, and so, you know, some of these systems we've built that are mixtures of different code bases, it's the contractor's favorite language, and it's, like, something random like a data science language like R, uh, that they were doing. Uh, uh, I think one of my favorite examples ever is we found a, a, a web app. So it had a Leaflet front end and all these sort of features, but it was an R code base, which is, uh, I guess for all the coding nerds out there, just a very crazy choice that when I tell people, they're like, "How did that happen?" And it was really 'cause it was the contractor's favorite language. That's what they knew. And they, like, just kinda squeezed the use case into the code base and the, the software tools they knew. So not necessarily always the best choices even to start with. I've heard people basically looking to start retraining engineers in Ada 'cause exactly that. It's memory safe. They can't hire enough Rust engineers. There's enough legacy Ada code that They're just kind of biting the bullet and, um, for anybody not familiar with Ada, it's really cool formal methods and, um, sort of security built in, but very old language that never got the momentum of Rust, so not a lot of public support out there for libraries. So really these enclaves of hidden code bases that you kind of have to be an expert in to use.
Maggie 08:38
Yeah. So I want to turn to a couple questions about the technical details of the product you're building, something that's really interesting. So unlike a lot of the, the hype out there today, which is, you know, LLMs, AI is everything, you all use a mix of both, you know, LLMs, artificial intelligence, as well as more traditional formal methods and formal verification. So can you talk more about how you architect your system using all these different kinds of technologies to really ensure, uh, trust and verifiability of the code that you're translating?
Peter 09:11
Yeah, I, I think if you step back and it's, it's, it's really, again, a spectrum of, of validation and verification tools. On, on the high end, you have formally verified. That's essentially saying, "I've proven mathematically these things are equivalent." And you can't always do that, but for some use cases, you have to in order to have that confidence. Um, and then on the other spectrum of that, you've at least built up enough evidence that you're giving the customer, you know, sufficient trust that the AI did the right work. And if you think about where we are today in AI, like code almost costs nothing if you're a company that can use some of these copilots. Where you are spending a lot of time is actually validating now this mountain of code. And so the task has moved to human verification and va- validation of, you know, what the code has written or that the AI has written. And so what we've done is we've essentially started pairing together, um, these sort of little powerful code generation tools with a suite of test harnesses. That's where a lot of our IP lives, actually, like validating that these tasks that we think can be fully verified, um, actually are by creating this evidence. This essentially third-party, you know, auditor that isn't AI-driven that's able to check the AI in a way that's automated and lets the teams move really, really fast.
Maggie 10:24
Many of the coding li- languages that you all are working with, and whether it's Rust or Ada or, um, VHDL or others, these are not super common open source programming languages like a Python or React or something along those lines. How well do these AI models work with the languages out of the box, and how much customization is required to actually get these systems working with these more esoteric languages?
Peter 10:50
Yeah, I think that's, that's something that it's been encouraging to see how much better the language models are getting out of the box with just some form of explanation of the languages. Um, but yeah, there is a huge gap between what it's used to working with and sort of these more esoteric... I think VHDL is a great example of a, a language that's more of a hardware spec masquerading as a language, um, that the language models just have trouble grokking because it's so different than, um, the, the normal languages that they're used to working with. So What we do is we actually decompose these really difficult tasks using sort of static analysis techniques into really bite-sized, manageable, provable steps. Um, and again, that sort of pulls in the, uh, the non-AI component of the, the product that we're building. So I think we, we-- You know, our hope is actually that the tools get good enough, the AI tools that is, where we're not doing as much customization as we are at, 'cause there's still the need for validation, verification, all the things that we've invested effort in. Um, it'll just converge a lot faster. So right now, uh, on some of these trickier languages, we do a lot of fine-tuning of models. We do a lot of breaking down the problem into bite-sized steps. We do a lot of, uh, other sort of tricky in-house secrets on getting these things to converge. Um, but you know, we view us to be in synergy with like basically the growth and the capabilities of these models.
Maggie 12:14
And then how do you think about what models to use on the back end? And, you know, maybe carrying a little bit to some of the customers that you work with, a lot of them, you know, are working in air-gapped environments, maybe even classified environments. How do you think about, um, the models that you use that you're able to actually deploy on those systems, and what are some of the, the trade-offs of deploying in some of those high sensitivity systems?
Peter 12:36
Yeah, and I, and I don't want to undersell the commercial space either. If you talk to a Japanese automotive company on their treasured code base, like they won't even tell you what they're doing. So it feels like you're, you know-
Maggie 12:46
They're, they're not all deployed in the cloud
Peter 12:48
Yeah. It feels like a TSSCI SAP program when like you're not even allowed to know what they want to do with your, your product. So, um, def-definitely I think writ large our customers want to have a lot of control of where their data's going, and that means deploying on-prem. I think they're all looking towards deploying in cloud in some way, and some of the business side has deployed some of those tools. But in terms of like, I'll call it their treasured code base, like, you know, AMD isn't putting the IP cores for their, you know, GPUs necessarily in a cloud, um, or at least anything that isn't locally controlled. So I, I think the way we've looked at it is we want to be open to plug and play with any model. Um, you know, from our training stacks to our deployment stacks, we try and support everything. I mean, I think the kind of crowd that we have that work here is The second a model drops, everybody's excited to immediately plug it into our pipeline and see what the baseline sort of results are. So I think there's a fun sort of nerdy culture here in terms of like some new diffusion models are dropping, and immediately the team's figuring out how to get it plugged in and running, uh, benchmarks. But, uh, it, it's keep up with things. Um, you know, defense definitely wants to run US models, which is getting tougher. Uh, China's definitely run quite ahead in terms of performance there, so there's a little bit of a handicap working in that space. But, uh, on-prem and whatever's the latest is the, you know, the way we've taken, uh, our product.
Pat 14:11
Uh, you had mentioned, uh, you are working, uh, in Japan. Uh, what are your thoughts on, uh, navigating international markets that you've...lessons learned?
Peter 14:22
Yeah. Yeah. I think for us, that market is one that, you know, we got excited because there is a real hunger for US technology and moving fast, and there's a lot of socioeconomic reasons where they are looking to adopt AI and looking to adopt new technology. So it's been a country ready and excited for the types of things we're working on. All that being said, time zones are hard. Field deployed engineering is hard. Um, you know, and for us that, you know, less than three years old now, um, it, it's something that I definitely think you wanna go there with a, a, a really sort of locked down playbook. And I think it's something where, um, we had to kind of slow down the, uh, demand that we had because we wanted to make sure the people that we are working with there, uh, we're nailing it for them. So we almost, you know, we had to treat Japan a bit like a wait list situation where we've got our key sort of tent pole customers, um, that we're partnering with now. But I think next year we're gonna be focused on growing that area quite a bit more.
Pat 15:19
Well, speaking about growth, you're pursuing a, uh, dual use strategy with commercial and, uh, government, uh, customers. Uh, what is the difference you see, and what is your advice on how to manage the, those differences?
Peter 15:36
Yeah, it's really interesting, and I think it comes into how you talk about what you're doing. Uh, when I'm talking to commercial space, it really is how are you gonna use Code Metal and sort of fitting to their use case and really focusing in on what our product does. Um, because we're sort of in the productivity tool suite, a lot of the times when we work with DoD, what makes the things we do possible is our technology, but we're talking about the capability it enables for them. And so it's, it's, I guess it's a higher level up, um, in terms of when we're selling DoW versus when we're selling, um, you know, let's say Bosch or something. Talking to each client, you know, I have to tell DoW the ultimate use case, the benefit to the warfighter, and it's just a little bit, you know, higher level in terms of the impact. And with that comes into the way we execute, the way we prepare material, more on site, more sort of, you know, um, longer sort of contract cycles. But all of those things I think, you know, help us because one thing I do think DoW is great for is essentially on those early bets that we're taking at Code Metal, we're looking for DoD to sort of springboard and de-risk and build a technology base that then we take to commercial space.
Pat 16:47
And what are the unique challenges you've found that, uh, founders should prepare for if they're gonna work with national security?
Peter 16:54
Uh, well, contracting is something I didn't realize how little I understood. Um, I think, you know, it was interesting in that like luckily because I have a background in defense, uh, you know, I used to work at BAE Systems, uh, worked at MIT Lincoln Laboratory. Um, but I didn't-- I wasn't necessarily on the contracting side. I was in like the make the customer excited by the things we were doing side. And, um, it was interesting when we had customers who wanted to buy and it, it-- When they don't understand how to buy, and you have to actually go help them navigate, like, their own organization, it becomes really, really interesting. And some of the successful, I think, you know, uh, I'm not sure if neo-primes is the right word, but some of the, the newer defense companies, uh, where I've sort of discussed with them and we've talked about what's worked, it's really being able to help them with that contracting side, helping them with that, like even up to the legislative lobbying side so that they can get what they want. But it's a really weird situation versus commercial, where you have somebody, like, dying for the thing that you're doing, and you have to go help them walk all these steps in order to actually pay you for it. So-
Pat 18:03
Yeah. Besides contracting, another area that's unique to the government that, uh, startups have to str-struggle with is the, uh, working with classified information and the authority to operate. Uh, what was your journey like getting approval for authority to operate on your, for your classified customers?
Peter 18:24
Yeah. I, a lot of this, again, is gonna be driven, and I hate to keep hitting the contract, it's like we had to do so much work in order to even get the permission to submit for ATOs, um, or submit for classifications, and it was all waiting for essentially the contract to say the words that, like, "You shall need this." And then that kinda got everything running, which is its own headache, and it, it's a lot of work, and there's a lot of great companies, uh, spinning up, I think, to help startups with these problems. But at the core, you need somebody to buy in that, "Hey, Code Metal needs a top secret clearance, and Code Metal, uh, you know, needs to submit it to this, let's say, cloud provider," and to really kick off all those processes. And so it was pretty much a crawl in terms of getting these things done, and the second we had the contract in place, uh, I think it was like three months later, we had an FCL, um-
Pat 19:18
Which is a facility clearance.
Peter 19:21
Yeah. And, and I had gone from, you know, basically an inactive TS clearance to now I have my TSSCI. So it was a really fast process once this painful contracting piece had been done in place. And, and friends of mine and, you know, other founders I've talked to, similar sorts of journeys in terms of like either getting a prime, maybe they're subcontracting to you to help them with that, uh, or, you know, their own direct contract.
Maggie 19:46
Yeah. I wanna know, I think you guys have really had a lot of success here just because the customers did get so excited about your product and were ready to go run through walls to help you get the ATO and the FCL. Maybe can you tell us about a moment when you showed the product to a customer and you felt like they really got it, and, you know, what was that experience like and what were they experiencing?
Peter 20:08
Yeah. I think, look, uh, I think as, as venture capital companies in dual use, we have this advantage that we can sort of build ahead of what our customers want and show them and not tell them. And I think a lot of the traditional industry out there is sort of selling through slides, selling through SBIRs. Um, I think you have the advantage of like, you have a customer who has needs, uh, and I don't see enough founders actually think in the dual use space talking to the customer first. And so we-- I'll give you an example of, of what really kicked this off We were working a, a project that was more of a, a favor due to expertise of the company to a friend. Um, but the, the customer that they had essentially wanted to come and visit Code Metal. And so as part of that, uh, I briefed them on sort of code translation and what we do before I got into, like, the detail thing we were helping them with. Uh, and sorry to be a little vague. But we, uh, we, we briefed them on the core capability, and the customer asked, like: "Oh, you know, we have this modernization thing. We're getting bids for about a year to actually take our code base and update it to new. Uh, would you guys be able to do that with your tool?" And I said, "Yeah, sure. Can I get access to it?" And they're like: "Yeah, it's Git owned. We'll send it to you." Um, and I was... Originally, I was asking for more of, like, a, "Can I, like, see it to scope out the work?" And we just went ahead and did it and sent them back the code. And there was this, like, "Holy shit." It was that, like, uh, they went from thinking, "We're gonna take a year to, to modernize this one module," to like, "Hey, we've got about 19 that we wanna do, and, like, we were dreaming about connecting these things and building this bigger platform." And we were like: "That's great." And we, instead of just, like, waiting and trying to do this other end, and, and look, this might not work for everybody, but this is the way we did it. Uh, we just got to work, and we're like: "We'll figure out how you guys pay us. We're just gonna do good work and focus on, on, on starting to build this system." And, and it's paid back in spades. So we, you know, I, I can say fast-forwarding to where we are today, um, you know, they've done a great job in terms of, like, coming back to us and, and paying for the work and then also expanding the opportunity. And they see it, and the sort of reputation, it's a small industry, starts rippling around. You know, we were at an event just now supporting and deploying, and folks were coming by from the other services saying: "Hey, you need to come out to visit me. I see the way you guys are here day and night, day and night. Um, I see what you've done with them, and, like, this is six months from, like, when we talked to you to IOC that we're now running. That's initial operating capability, uh, your platform." So I think- What I can say is we have an asymmetric advantage in that we're trying to build, uh, you know, companies that, that scale and, and sort of play this long game. And you have these customers who have needs, so talk to them. Um, don't try and just invent a thing and then, like, sell it to DOW. Like, there's amazing problems that they have that, like, I don't see people tackling. So I guess that's my advice on selling to them and some of those things.
Maggie 23:06
How have you thought about building trust with some of these mission-critical customers? I mean, I know there's a lot of distrust out there about AI broadly, so how have you approached that?
Peter 23:18
I think what we get a little bit of inherent in what we do is kind of like a practical thing we're solving. So we're not trying to boil the ocean, uh, or, you know, we, we kind of have to limit a bit sort of even the pipelines we do. Like, the North Star is any language to any language. Right now, we have very practical Python to C++, C++ to Rust sort of targets that we're working. And so I think just hear-them hearing the proof points and sort of all the non-AI bits, um, like sometimes I actually get reminded like, "Oh, you can at least also mention that we're using AI," is sort of what we're selling them. Um, and, and we've had pitches and they've seen the product where they've gone like, "Oh, you're using LLM, I didn't know that." Um, and yeah, I, I think that's, that's been some of that trust building, that we're just really trying to hear what their problem is and focus in on, "Here's what we do, here's how we do it, here's the evidence we show you." Um, and, and that's been, you know, a huge part of it.
Pat 24:11
You have a broad experience with, uh, not only national labs but, uh, federally funded research development companies and, uh, academia and industry. Uh, what made you decide to start your own company?
Peter 24:25
Uh, that's a great question. So I was, uh, I was at Microsoft during COVID working on the HoloLens, very, very frustrated in leadership, working very, very hard, um, to, to essentially solve a lot of problems that CodeML solves today. But, um, uh, 100% transparency, Code Metal wasn't the first company that I started. I started another one after that, and I was very naive at that point. I was an engineer first, didn't know anything about startups. I, uh, m-met a fellow who, you know, great sort of partner in business, but maybe not what a VC company would be looking for, and, um, ended up starting a company that, like, got into Techstars accelerator and did these things. And really, I just assumed a startup was like, "Oh, I'm in a job I want and make money." That was, like, the extent of my business knowledge. Um, I remember being in, like, the Techstars whatever, uh, like, cohort, and they asked me, like, "How'd you get in?" I was like, "Oh, I didn't know what this was," but they were talking about stuff I was doing. So, uh, it was, it was a, a big learning curve, and I learned a lot about what a startup was. But the thing I pulled out of that, that, that got me excited was this idea of like, oh, the problems have to be big enough and the founder has to really fit the market to actually, you know, be reasonable as a venture-backed company. And so even though we had a great, you know, I consider it great success that we sold the company that, that I'd started, like, I really got a sense of what is, like, a true venture-backed, venture-scale company look like from that first kinda you know, I'll call it pseudo failure. Um, and, and, you know, that's-- a lot of those lessons went into Code Metal. So part of it was the autonomy of tackling the problems I wanted to tackle. Um, that's a big part of it, like, uh, rather than sort of selling the company to do the things I wanted to do. Uh, and then really understanding that actually that's a great fit for a venture-backed company. When you have the background, you have a problem that's big enough to be r- you know, sort of worth venture backing. Um, you know, it seemed like a great fit and all the things I like to do and the ways I like to work.
Pat 26:22
And you mentioned the, uh, challenges of people working in, in venture companies and, uh, uh, venture-backed companies and, uh, uh, dealing with work-life balance comes up a lot, uh, when you're retaining and growing and motivating, uh, teams. Uh, what have you found is, uh, successful, or how do you approach recruitment, uh, so that folks know, realize, uh, that working in a startup has a huge benefit, but at the same time, it, it's not a normal nine-to-five, uh, five-day-a-week job?
Peter 26:56
There is a great description of people that fit, um, Valve, which is a video game company that I've stolen in, in everywhere I've tried to hire, and it was they look for T-shaped people. These are people with, like, a deep expertise through, like, um, you know, one core topic, but, like, broad exposure to a lot of things, willingness to be flexible. And I think, uh, the reason we look for that sort of T-shaped person is we, we look for people that, like, the thing that they like to do is almost their, like, life mission. Like, one of our pillars is passion. And the reason being is, like, I want these people rambling about formal methods or rambling about optimizing some, you know, embedded CPU core and, like, looking for signal on things where they're doing this in their free time or that they're, like, taking the extra mile on their own to do it. Because then my job is to give a really good North Star that we can all rally around so that, like, on their off days... I'll give you an example. We spent a grueling, like, uh, deployment where it was, like, eleven PM, you know, we were wrapping up, and we were back in there at six AM for about two weeks solid and on the weekend. And, you know, coming at the end of that, I told the team, like, "Get out of here. I don't want to see you for a few weeks. So, like, don't wait to die. Go, go take a break." They're like pushing me things that they like, they still wanted to like fix the problem or, or still work on it. And so I'm getting like architecture ideas or improvement ideas like as they're going away on vacation. Um, so it's, it, it's tough. Like it's a competitive market. Like you need to have people motivated to put those hours and do that work. Um, I don't think you can pretend that like you don't have to put it, but it has to be good work. It has to be thoughtful work. It's not just work for work's sake. If you get your work done and you are, you know, you can leave the office, leave the office. Like we take sort of just get your job done attitude to how we do things. So, and a lot of that just comes from passionate people with broad exposure to things.
Maggie 28:47
You've worked in the defense space for more than a decade at national labs, at defense primes, elsewhere. What have been some of the biggest changes you've seen in the industry over your career, and what are you most looking forward to for the next five to 10 years or most excited about?
Peter 29:01
Maybe this one isn't as like novel, but it's still one I think about a lot. Um, it's been a lot cooler to do defense stuff. And so, um, uh, you know, that, that sort of has its ups and downs. But I remember being, you know, Project Maven kicking off while I was at MIT Lincoln Laboratory and the Google employees sort of walking out, and now you have something similar now with, uh, sort of Claude and what happened, but I think it's a little bit different. Um, but yeah, I, I think just the fact that people see the sort of value in, you know, doing this work, uh, has been something exciting to me. It's easy to recruit. It's, uh, a lot easier to walk on a Stanford campus and, you know, find kids that are excited by the stuff that you're doing. Um, I think that was one change that I still sort of really appreciate. Uh, the other is I think more recent in this idea of like trying to figure out new ways to actually fix these issues in acquisitions and, and contracting and, um, I'm, I'm actually super excited by it. I think it's one of the things we are getting right, at least trying things. Um, and so yeah, I'm looking forward to seeing the next two, three years where that goes.
Pat 30:11
Today, you're having a board of directors meeting. Uh, what are your thoughts about, the benefits or how best to leverage a board for founders and investors that are, um, listening to this podcast?
Peter 30:27
Yeah, I, I think it's really hard when you're a founder and you're waking up every day and thinking, "What's the most important thing I need to do?" And at some point you're gonna need to raise funds and build your board. And it's like, it feels like a luxury when you get told like, "Hey, pick board members you like. Pick-- Work with people that you wanna work with." Um, I, right now I do, which is what I feel very like lucky that we get to do that. But, um, in terms of like horror stories I hear from other founders and, and things that like basically they blame the company going wrong on, it, it's a non-insignificant percentage where it's like board dynamics. So I think it's, it's really important to actually like when it feels desperate and you're like, "Oh man, I really should take this check." And like I, I get it, as like a founder you might, you know, wanna take money for a certain reason from a certain fund. If there isn't that fit with like, "Hey, I can work with this person," um, it, it's really stupid sort of repetitive advice that every founder gets, but like I'm just stressing it as like, yes, like listen to that. Figure out how to like extend your runway a bit or whatever it takes to like take the right capital in because you are tethered to these people. Um, and at least the way I've looked at it is at different stages of the company, we've needed different sort of help, and we've looked for people that, one, fit the, you know, had the background to provide that type of help, whether it be like technical product guidance or it be, um, you know, sort of moving to commercial is, is another example. Um, you know, giving us connections and top cover as we do defense work. All of those things were the criteria in how we targeted who we targeted, but first and foremost was, hey, I gotta work with this person forever maybe. You know, I have to pick people that I wanna work with.
Maggie 32:15
What lessons, if any, have you taken or has Code Metal taken from overseas conflicts in Ukraine and the Middle East? Or has it changed your approach to the ecosystem and your product?
Peter 32:27
Yeah, I think in, at least in Ukraine, there's this notion of like, hey, the acquisitions process does not work for a war that's adapting, you know, every week, every, you know, month. How do we actually start building, uh, ways of acquiring and reacting to, um, immediate sort of situations? So without getting into too much detail, obviously a company that's like built around like immediately deploying hardware, the latest idea, you know, benefits from, from that sort of change in thinking. So it, it's one of the things I think DoD still hasn't quite figured out how to acquire and pay for that consistent adaptivity. Um, but it's something that's an open question and, and obviously first and foremost important.
Maggie 33:10
As I say, you guys have done some work as a, a subcontractor to larger primes. Is that right?
Peter 33:15
Yeah, absolutely.
Maggie 33:16
I'm curious how you think about those kinds of arrangements as a way to get access to some of these government customers that might be difficult to access otherwise. Could you talk a little bit about your experience with subcontracting?
Peter 33:29
Yes. There, I mean, there are calls for proposals, customers that you won't get to see as a startup. Like, they won't exist to you, they won't be in the market to you, but maybe you actually solve exactly what they do. Uh, thinking about that early when you're partnering with the primes, like wanting to be in the room when things get presented, wanting to get that connection is something that maybe when you're trying to close a deal doesn't feel like a order one priority, but it kind of is if you're trying to build a long-term company. So I can say from experience, um, that was one of the things that we pushed back on wanting with some of the agreements that we had. Like, "Hey, we'll work together on this, but we wanna be in the room for certain aspects of this." And again, to get exposure to the company or the, the customer who doesn't have the luxury of... You know, I think there's a lot of saltiness in the DLE space about like, oh, they're giving it to the same people or whatever, but they need stability. They need like repeatability. Like they can't just be trying everything in a lot of these critical industries. So, you know, there's some empathy to the customer in terms of like going with the same solutions over and over again. And the primes are a great way to actually start bootstrapping that exposure and, and relationship.
Pat 34:39
And what's your vision for how you see your company growing and the product, the use and adaption, uh, adopting, um, the products that you've developed?
Peter 34:50
Yeah. I view we're starting with a, I think, a really strong baseline in our defense clients, and it's, it's just industries that we know it's a great place for developing, uh, deep tech technology. Uh, but it is a general use technology. Like it doesn't just impact, uh, DOW. And so you do this first tranche about growth and, and defense of our, you know, sort of core positioning and the things that we wanna care about. Uh, and then, you know, we've been growing now out into more sort of initial landing and exploratory work in the industries like automotive, like semiconductor, uh, that skew more pure commercial. So I think that'll be our phase two. And you know, personally, one of the mantras I've said to the team is we don't wanna be a series Z company. Like we wanna get to, you know, reasonable, predictable revenue and IPO in, you know, three to four years.
Maggie 35:38
What have been some of the biggest surprises building Code Metal?
Peter 35:42
The AI market was moving Fast, but, like I said, the last six months to me have been, like, absolutely insane. So I think, um, I've liked it 'cause we've had a clear focus on who our customer is and who our market is, so we've gotten to, like, kinda avoid the noise. But man, does it sound crazy out there. So, uh, that's been, um-- It's been interesting watching, to tie back to us, like, how smart our customer has gotten in a very quick amount of time. So I can think about two years ago what it was like to talk to them about AI code generation to today, and it's interesting, like, seeing their evolution across these sort of legacy industries.
Maggie 37:44
Great. Well, Peter, thank you so much for the time, and thanks so much for coming on the podcast.
Peter 37:48
Yeah, thanks. It was great to talk to you guys.