Why Your GPU Investments Are Running at 40% Efficiency, and How Zymtrace Fixes It

The biggest pain right now is essentially AI themselves. Like, people have been investing in this for over the last 4 years. It's been a lot of investment going into this. Now, in 2025, that was a year that AI went into production. And going forward, people are now more conscious of when are we going to get return on investment? Do you keep throwing money at a problem or you suck out all of the performance juice you can from this heavy investment that customers have made? So in terms of the challenge, It's pretty much the business driver is ROI. Hello everyone, and welcome to Built Not Born, the startup go-to-market podcast by Venture Guides. I'm Sage Nye, and around here we believe that great companies are built, not born, one smart decision at a time. Each week we take you through real conversations with founders, investors, and go-to-market experts on what it really takes to land customers and scale your startup. Now let's get to work. Hello and welcome to Built, Not Born. I'm Sage Nye, partner at Venture Guides. Today I am joined by Israel Ogbole, CEO and co-founder of Zimtrace, an infrastructure optimization platform that helps teams debug and optimize the efficiency of their general purpose and GPU accelerated workloads. Despite massive investment in AI infrastructure, most organizations still run their GPUs at only 20 to 40% utilization. Why are they stalling? Where is performance being lost? And once you find it, how do you fix it? These are all questions that we'll talk about with Israel today. The AI race is no longer about who can buy the most GPUs. It's about who can extract the most useful work from the hardware that they already have. Efficiency, not raw capacity, is the new competitive advantage. So in this episode, we will explore what it takes to optimize AI infrastructure at scale, from profile-guided optimization to cluster-wide visibility across heterogeneous workloads. Israel, welcome to the show. Thank you. So happy to be here. So I'd love to start with a bit of context for our listeners. Do you mind sharing some brief background about yourself and Zimtrace? I'm Israel. I'm based in the UK, and we decided to start the company Zimtrace to help organizations optimize CPU and GPU-based workloads better. In today's world, obviously, you know, GPUs are everywhere, but they're super expensive. And what we then decided to do was essentially, how do we help users get better visibility into these workloads and how do we help them optimize it? But let me take a step back a little to my background and how I got here. I used to work for a company called Yammer, and then Yammer, I was looking after customers and looking after production environments there. And then we got acquired into Microsoft and I had built some DIY solutions and to monitor the applications and that wasn't working very well, simply. And, um, I tried New Relic and it was pretty much like walking into a dark room and turning the lights on. It was amazing. The level of visibility was great. And when that happened, obviously Microsoft grew too big for my liking. And then I decided, let me look for another startup organization. And that was how I joined AppDynamics. And as you know, AppDynamics is also another observability company. They were doing very great in the UK at the time. And, um, there I became a solution architect. So it's pretty great. I went around nearly All customers that I worked with, 100% onsite, helping them to implement AppDynamics. And then I also grew into becoming a product manager right there, looking after cloud monitoring and observability. Now, in all of those experiences, being at Microsoft as a user and now at AppDynamics as a vendor, I saw there's a huge gap in monitoring observability. Customers never get the full ROI from it because it's so hard to use. So I saw this little company called Optimizer Cloud. That we're doing it in a very, very new way. Technology called eBPF to introspect the entire application, profile whole system, get visibility that you need. I saw it and I was like, that is the future of observability. Like no doubt in my mind. And then not long after, Elastic acquired this company. When Elastic did, I joined them and grew the business, integrated what used to be called Profiler into Elastic Universal Profiling, grew it substantially large. And then we, I led open sourcing and donate into OpenTelemetry. So that's been my background. And the reason we started Ximtrace was essentially when Llama 3.1 was released, we saw a huge amount of customers at the time wanting to use data in Elastic to train and distill their model. And the existing market at the time was really, really not good. So we decided, okay, how about we start Ximtrace to help users get better visibility into these workloads and into the GPUs so that obviously know where inefficiencies lie, optimize it, save cost, and make things faster. Very exciting. One thing that you've talked about before in some of our conversations was when Llama 3 came out, I think you said you even used it at home. Can you walk us through a little bit about what that moment was like? So here's a story. I was taking a walk, listening to a podcast, and I heard Llama 3.1 announcement. And I was like, OK, what is this again? I went home, looked it up quickly. And I deployed it locally and it felt like having ChatGPT literally on my box at home. I literally had goosebumps. Wow. I knew that this thing was gonna change the world, the way inferences and the way people are gonna train and distill their model. Like it was gonna change the world. But then at the time, GPUs were so expensive to buy and to get this efficiency out of them, you gotta run them on GPUs. This model is on GPUs and no surprise NVIDIA was doing great. In the market there. And those were the signs that led us to build Ximtrace. Like, if people were gonna run this, if it's gonna be big and massive, it means that efficiency must be key to it. And existing solution at the time just sucked, terrible and not great. And then we built Ximtrace to solve that problem for users. That was a great experience. Like, when it happened, I told my wife, this is the time I'm gonna go solve this problem. And talk about an amazing experience. I mean, you were working on probably one of the most cutting-edge products in the market when you were at Elastic, and then to say, okay, I love what I'm doing here, but I see where the market's going and we have to go solve that. It's such a great story. So, you said this a little bit, but there were observability tools on the market and they were all missing something. Can you give us a little bit more insight into how should we think about a profiling solution? Versus the other ways that we can observe software and applications? So existing observability solutions look after like what the people call the three pillars of observability. You look at metrics, you got logs, you got tracing. The way I like to explain it is imagine that John, a random John, is sick. He goes to the hospital, right? And when he's there, the nurses or the doctors would attend to John. One of the things they ask John is try to take John's vital signs, you know, what's your body temperature? Do you have a swelling on the head, or how did you come about this headache? Have you been drinking enough water? You know, have you been getting enough sleep? Or maybe in my case, too much coffee. You've been drinking too much coffee. You know, all of those questions that he asks, maybe taking the temperature, etc. Just think about that like metrics, for example. Obviously they will ask me several questions or ask John several questions. They're trying to do tracing, they're trying to trace the cause of the problem. Now when they can't find the root cause as to why John is ill, they may then refer John to go take an MRI scan or an X-ray. And that's exactly what profiling does. Profiling is like taking a continuous MRI scan of the entire system and then letting users know where inefficiencies lie. On the CPU world, it's more like, what is it that's consuming all of my CPU cores? By the time you take this MRI scan, you can clearly see which program or which code is consuming your entire CPU cores. And in GPUs, it's quite reverse. It's more like, why is the GPU not being fully utilized? So I'm taking a step back. It's distributed tracing metrics and logs. They're great for general purpose applications, especially distributed tracing, right? I can trace a call as it hits an endpoint and I can trace it through the entire microservices, through the spans. It's fantastic for that. What it doesn't do very well, and it will struggle is the AI infrastructure. We go with AI infrastructure, you want to go deep into the stack, right? If you got a GPU or a cluster of GPU, you're concerned about what is this that's run on the GPU. And with profiling and what we do, for example, we start tracing the code as it begins to execute on the CPU until it invokes a CUDA kernel and then traces to the kernel, up to the GPU instructions as well as the storage. And so it's more like going deeper as opposed to going horizontal that tracing does. Does that help? Wow. It definitely does. And actually, I like your focus on the MRI because one thing we talk about a lot in like health is if you could have a continuous MRI of your body, not only do you know what's going on, but you can catch things ahead of time cuz you can see if things are changing or if there's cells that aren't supposed to be there or something. And it sounds like continuous profiling is the same offer. It's, it's actually not just do you get to go really deep in a period of time, but if you profile it over time. Then when things are starting to go wrong, you have the comparison to be able to see that and catch it early. That's a great analysis, too. So in order to do that, the question then becomes, why are people not profiling enough? And it is because of the history. Profiling has been around for a long time, but people don't do it enough because it's traditionally very hard, and traditionally it's got a lot of overhead to it until we solved this problem that I talked about at Elastic, where we then open-sourced the solution. And the approach was pretty much— or prior to that time, it was pretty much get a profiler, a Java profiler, a Go profiler, a Python profiler. Essentially, you change a number of code and then to get the profiling done. When you do that, it adds a lot of overhead. And not only that, engineers usually don't want to waste time trying to change code in order to get profiling data and then go analyze them. But using this eBPF approach, it meant that you drop the agent out of the box. And you do nothing else. Super efficient, that even so much so that the program that you are profiling doesn't know you're profiling it because you sit in the kernel and getting all the necessary information out. And I wish that most people know about it and they can go use profiling because once you get this continuous MRI scan, you may as well not even need any of this extra information that you spend a lot of money on. Well, if not a lot of people know about it now, then hopefully more people will know at the end of the podcast. Sounds really powerful. I'm curious, you know, you're doing all of this work with customers and with the market, and you're seeing so many customers struggle with running large distributed workloads across both general purpose and also GPU accelerated infrastructure. What are some of the biggest pains that you're seeing? So the biggest pain right now is essentially AI themselves. Like, people have been investing in this work over the last 4 years. It's been A lot of investment going into this. Now in 2025, that was the year that AI went into production. And going forward, people are now more conscious of when are we going to get return on investment? Do you keep throwing money at a problem or you suck out all of the performance juice you can from this heavy investment that customers have made? So in terms of the challenge, it's pretty much the business driver is ROI, but it's hard to do in the sense that existing solutions, the customers that we speak to, they're either using PyTorch Profiler, which goes back to what I said earlier on, you gotta go change code, you know, or you go use NVIDIA Insights or NVIDIA Compute, and you need a PhD level to figure out what's going on there. It adds about 200x overhead when you try to use that, especially on the Compute. And then NVIDIA Insights would not let you profile more than 5 minutes. Not a lot. Yeah. And this is documented. It's actually there. It's in the document. So there isn't a lot of options left for AI and ML engineers who really just want a cluster-wide visibility. And let me double-click on what I mean by cluster-wide visibility. Now, if you use PyTorch Profile, you gotta change the code, deploy maybe on your dev machine. If you use NVIDIA Insight, you gotta literally SSH to the box one at a time. So imagine if you have hundreds or 200 GPUs or nodes of GPUs, you cannot SSH into each and every box trying to find where inefficiencies lie. Or try to isolate the problem that you have. So what folks have asked us for, it's how do we get easily a cluster-wide visibility across the entire GPU-based workloads? And that's exactly what Ximtrace does. Once you deploy the agent, we immediately provide whole cluster-wide visibility for customers and then give recommendations that tell you exactly where inefficiencies lie. So you don't need a PhD level anymore. You get all the traces that you need, and you just go optimize, essentially. That's amazing. And that's one of the things that we've loved about working with you and Joel is you're so focused on the customer and how do I make their life better and how do I make it easier? And it's fantastic. You've really built a solution that not only gives them this super valuable data over time, but does it in a way that is digestible and understandable, which is great. When we think about the future a little bit and we think about what you can do with profiles, you've written a lot about profile-guided AI optimizations for layers like the compiler and, and others. What does that look like to you? Or sort of, can you share a little bit about how you see the future and, and what enterprises can do to run more efficient AI workloads? I coined that word profile-guided optimization from an existing concept called PGO, an existing concept called profile-guided optimization. What that does is because compilers are essentially, once they're built, they're coming with a set of heuristics that determines what is the best path to compile an executable. Right? And that's why when you compile the same code twice, you get different executable signatures, essentially. And now what PGO does is like you compile once, you profile the code, it does have some context, and then you pass that profiling information onto the compiler for the next time the compiler sees your code and recompiling your code, it knows, oh, you know what? I've gotta make optimizations in this area because that's the hottest path in the code. So compilers are built to do that. Most compilers are built to do that. And if you apply that to AI world, you've got LLM today that can do fantastic work at looking at different patterns and trying to make sense of those patterns. And what you see people do traditionally is like you ask LLM to just randomly or blindly optimize a code, it will try, but you get a lot of garbage that won't work, including CUDA kernels, it is say. So the idea of profile-guided AI optimization is we profile the code and then customers use MCP to pull this data onto the IDE. And by the time you pass it to Cloud Code or any of this LLM, because they have full rich context already, they go ahead and optimize your code without you again being an expert. You don't need to know deep down CUDA kernel. You don't need to know any of that. Just put the data using natural language from your IDE. Zimtrace automatically pulls it down, analyze it for you, and then apply recommendations locally. Wow. So we talk about context for LLMs. I mean, everyone's saying LLMs need context. They need context. What better context than a profile? So good. It's so good. Now, even some of the models that are not as great, the moment they have that context, a full stack trace, a full— it's more like a full story of the entire execution of that code. They do a great job at it because of the context that you pass into it. Israel, this is so great. Do you mind telling us any customer stories that you can share just to really tell listeners more about what we're talking about. Yeah, so we got a few customers using Zimtrace already, but they're pretty big enterprises. I'm not allowed to mention their names just yet, but one of the ones that recently signed with us is Enam.ai. Enam.ai. These guys are fantastic. They build conversational AI for you, like build live persona, human personas for their customers, and they run a massive amount of compute on GPUs. Now what they've done traditionally has been PyTorch profiling or NVIDIA Insight. And their desire was pretty much how do we easily get cluster-wide visibility into the entire GPU cluster? They tried some other solutions out there, but just didn't work for them. And when they saw Ximtrace, actually, I actually did a demo of Ximtrace to them and literally the guy's face was like, this is what I've been looking for. And Just after we finished the meeting, Joe, he then messaged us. He was like, I've just installed Ximtrace. Can you send me the GPU license? And Joe and I was like, he already did? We had no idea that he already did. So the main pain points was pretty much they had this problem where they wanted to troubleshoot GPU-based work, a specific performance issue, which I can't go into detail on, but Ximtrace found it immediately. They optimized it. And save about 2.5x latency. That's huge. Immediately, where you go to around 50%. See, and the beautiful thing about that too is that they are actually not using Ximtrace directly like everybody else. They are using the Profile Guide AI optimization we talked about heavily. That's their workflow, pretty much. So NVIDIA now making a lot of wins on GPUs and optimizing GPU-based workloads using Ximtrace, which is amazing. That is so exciting. And your focus on customers— talk about such a great customer story with a huge impact. Really amazing. Thank you. I mean, we are really excited to have them on board and we'll be doing a joint blog post pretty soon, so look out for that. Absolutely. I'm sure our listeners will. All right. Well, so if we switch gears a little bit, building a company is hard and you've worked in a whole bunch of startups, but this is— you and Joel are building Ximtrace and you took a huge leap of faith and you've had remarkable growth so far. If you had to pick something, what would you say is the hardest part of the journey so far? There are loads to talk about. That's a great question. So I would say that a company is a group of people that you put together, give them a mission, and then they go execute. And to be honest, I don't see Ximtrace today as a company yet. I see it more like a product. All we've got is a product. You've got to make this product big and very successful. Then that translates into the company. I just see the company right now as a shell, as an entity, as a necessary entity. So all our focus is right now on the product. And what that means is that to answer your question, the biggest challenge so far has been getting the right set of people to work here. I can tell you that's very, very challenging because of what we do. We need a special kind of humans, special kind of engineers that go low level and they're able to introspect the code. And if you're working in the CUDA ecosystem, as many people who may be listening would know, it's fully closed source. So you need this kind of people to come on board and do their magic, figure out how to do all of this great magic in order to give you better visibility and make life easier for users. So that in my mind has been, I think, one of the great challenging aspect of it. There's a ton of other things I can mention, but, uh, I just wanna say, yeah, finding people, like finding great people on board is super challenging. I was gonna say, from the outside looking in, you make it look so easy. You have a truly incredible team and you and Joel are such strong leaders. I know it's been hard, but it's amazing to watch. And on a technical front too, he's been pretty much like what we are doing, obviously when we started, there was no blueprint to follow, right? So we had to go down and we knew that it was So there was a lot of risk involved in what we're doing. We had to quickly de-risk it. We were not talking to nobody. We're like, we got to de-risk this thing before we go. And that time of focus was also extremely challenging for the entire team. I'm really impressed. Thank you. The next section that we normally do is a rapid-fire section where these are a lot of questions that we've heard from other founders or other potential customers of Solutions that we'd love to hear your perspective on. And the first one is, how do you know if you're building a solution that the market needs? Versus just a nice to have? Nice to haves are a good distraction. So the way you know what customers will need is build a prototype quickly and go test your solution, test ideas, have them tested. Now it's not enough to just test it once. They use it, test it, or have a product, talk to 1 or 3 people. These days it's easy to build a prototype if you're doing software like we're doing. Talk to enough people that you can. And you'll be surprised that people are actually very nice. Like when we started Ximtrace, I went, you know, look for people at Meta, people at Qualcomm, NVIDIA, literally asking them, what's your challenge? Tell me more about it. So by the time you get all of that, you form a mental picture and then you build something based on that challenge you've heard and then test the idea quickly. That in my mind. So when users see maybe a prototype, and they're like, okay, I like it. The next question that most founders forget to ask is, would you pay for it? So it's one thing to like it, it's also something else to be willing to pay for it, because we're not charities, right? You got to pay for it. And then once they say, yeah, I'll pay for it, the next question is actually ask them, how much would you pay for it? You know, how big is the pain? How big is the problem? Because if you're a founder, like, you put in all your life on this goal and it's a long journey and you want to know that somebody can actually care a lot about it to pay for it. So if the user then says, maybe I like it, but I may not pay for it, or I may just pay you $1 or so for it, then you know, maybe this is a nice to have, it's probably not worth your time. So that's how I would test it. Like literally go out there, get into the trenches and test your product ideas. Yeah, I think that's a great point. I mean, I was talking to someone on our team the other day about the difference between a science project and company or a product that you can build a company around. And the difference comes down to, are you impacting customers positively and are they willing to pay for it? Because otherwise it's a science project, right? And it can be a great one, but it's a science project. So the next question comes back to what you were talking about with your team, which is as you are building out your team, first of all, you and Joel have an incredible relationship. So I'd love to hear any character traits that you think people should should look for as they think about finding their co-founder and working with a co-founder, but then also when you look at early employees who in many ways act like co-founders, or at least they're bought into the mission, they're there from the early days. What do you look for in, in those early hires and those people that buy into the mission? You've gotta look for passion. Passion is a keyword there. Like this, how much does this individual care about the space? For Joa, when I conceived the idea, I looked in my network. There were about 2 to 3 people that I had in mind, and Joel was the first guy I approached. Reason being that he has passion for performance a lot, and I've seen his work. So there's nothing that can replace passion. Like, I mean, I can give you so many other traits, but just look for passion because when things get hard, and I guarantee you things will get hard in the journey, Passion is what keeps you going. And so I would look for somebody that is passionate about this space. And the way you find that is look through their previous history, not what they intend to do in the future, but what they've already done. Look through their past history. What have they done in that area? And then use that to qualify them. And once you find that, it's also, don't forget it, like you've got to also have somebody that you can easily relate with. A co-founder is almost like, as a matter of fact, you may spend more time with your co-founder than you spend with your wife or kids. So you gotta be comfortable with them in your skin. So it's more like, can you relate with this person? Can you talk with this person? Because you, you become friends, you actually become more than friends. To summarize that, I would look for passion and I would look for how comfortable you are in relating with this individual because it's a long journey together. Absolutely. All right. This next question is one that I know you have a lot of thoughts on. Which is when you're fundraising and you have term sheets, is the best one always the one with the highest price, or is there something else that you look for? Oh no, especially if you're doing a pre-seed or seed round. So I wanna qualify the answer. Best term sheet is not the one that has the highest valuation. Please don't do that. Usually it's the other way around. You've gotta go with a VC that believes in your mission and can help you build. And look beyond that to the people as well. I use a word called dumb money. Don't take dumb money early stages because it's really gonna cripple the company. You want investors that can open doors for you. You want investors that can bear with you when things get hard, and it would always get hard. You also want investors that would almost act as a mentor for you. And that was exactly why we picked Venture Guides. We literally had eager tempships. Well, we had to look inwards and say, we've gotta go with VentureGuys because of the people, because of the guidance that they can provide. And especially from a go-to-market point of view, Joan and I are first-time founders. We can build the best product ever, but you gotta be able to sell it. You gotta be able to go to market strongly with them. And we chose VentureGuys because there's a great track history of VentureGuys in doing this successfully. So to answer that is don't take the township that has the biggest valuation, because if you get the rudiments right, if you get a foundation right, bigger valuation will certainly come someday, but you gotta get the valuation right first. I know you know this, but I agree. And I also agree that you and Joel and the whole team are building a company that is gonna be so valuable and you are gonna get those huge valuations because customers need it. All right. The last question is, as you think about advisors, and I know that you have a lot of mentors and advisors that you've worked with who adore you, and I think that you adore as well. What is something that you look for in those people? I tend to get advisors in specific areas of need for me, and it's almost like I see myself as the middle, the guy in the middle, and then you try to build a fence around me. So what I look for for them is For example, when I was going to start Zimtrace, I had Thomas. Thomas has done this before, Thomas Dillion, and I went to him and said, hey, I'm going to start this thing. I'm going to need help, a lot of help, a lot of mentorship. So he was one of the first guys that came. He's done it before. He's walked the path and he's extremely technically great. So you want somebody that you can actually rely on and has walked the path and is able to take you along as well. The other guy too that I speak to quite often is Asaf Ezra, who is based in Israel. Similarly, Asaf Asaph and Thomas were once competitors because Thomas had Profiler, Asaph had Granulate. Intel bought Granulate and Elastic bought Profiler, but both of them collaboratively helping me through the process as well. Again, those are just a few examples, but I look for more advisors that in areas of help that I need, specific areas of help that I need, and I go to them and ask. So, uh, for anybody listening to this, what I would say is like, Take a look inwards. What is it that you are not very good at? What is it that you are struggling with? And then look for somebody that you can genuinely open up to. You know, there has to be that trust element there as well. So look for trust as well. I'm picking up on trust as a critical piece, and we agree with you. When you're building a company and you're spending all of these hours, basically committing, you know, the next many, many years of your life to it, you want to make sure you have trust with the people that are working with you. Absolutely. All right. Before we wrap, I have a couple reflective questions for you, and I think the next one's gonna be probably the hardest one I've asked you so far, but what is one of your favorite memories of building Zoomtrace so far? There's been quite a few. I think one of the things that stood out to me was the first time when we got Zoomtrace started, one of our second hire actually came from Google, and then Joey and I sat back and we're like, we literally convinced somebody at Google. He was doing very well. And we said to him, come and join us. And it took a while, but that was exciting. Like, we was like, we just started this company a while ago and we're able to convince somebody to leave Google to join us. Like, that was amazing. Like, that was great. So that's for me looking back. And if you, if you can see the theme there, I care about people that work here a lot. And so most of my answers are going to go back to people somehow. People. For me, that was very exciting. And then we went on again to hire some of these great people that were just doing their thing. And then we were able to convince them, show them the light, and was like, come join us. That's been great for me. The other thing that I also wanted to mention, maybe it's When we started Ximtrace, we were just going to do SaaS, you know, like everybody else, build a SaaS solution. And then we did quite a lot of interviews and quite a lot of interviews, and then we realized, oh, hang on, the type of users that are going to need Ximtrace would actually not use a SaaS solution. Then I went back to Joel and I said to him, just very randomly, very casually, because he started building stuff already, and I said to him, dude, stop that. We are not doing SaaS, we're doing on-premise. His face, he was like, such a disappointment. I don't know, like, because obviously SaaS is great. It's easy. You get telemetry. Like, the permutations are different. So his facial reaction too was like a favorite moment because I told him the other day, I wish I could just snap you, take a photograph, and just put it on my wall. Fantastic. Okay. Another question that I actually am curious about, which is, What's a leadership lesson that you wish more founders understood as they're growing their businesses? Maybe two, if I can mention two. The first one is you're going to be in a position to make some very, very serious decisions. Decisions that would not only affect you, but would affect the company and decisions that would also affect the people that have trusted you to come on the journey with you. So when you are not sure, take some time, sleep over it. You must not give an answer. And that sounds like very dumb advice, but I was like, just sleep on it. When it's a very critical decision, don't rush into it. Sleep on it because one misstep can end the entire life of the company. And when you're dealing with people and customers, I would just say, if you are not dead sure about your answer, sleep on it or go ask an advisor. So that's one thing. The other item that I also wanted to mention is that always, always put customers first. No matter what you do, put customers first. They are first, center, and last in my opinion. You know, like literally go after them. Anytime that you see an engineer, if you look into your roadmap, if you look into tickets, if you look into progress update of engineer, I mean progress update because at Zendesk, we are a distributed company. So engineers post progress updates. Every day at the end of the day. So if you look into progress updates and then you see that everything that folks are working on, all the roadmap, they are not directly tied to a must-have in the company, cut it short. No diplomacy, cut it short. It must be a must-have. A startup, you have to focus solely and squarely on one thing, and that's pretty much what moves the needle. Everything else is a distraction. So to summarize, that is Focus. Secondly, rest. Sleep on it. I gotta say, first of all, to your point, you've in many of our conversations said, you know, I need to think about this. It's a serious decision. And I've seen how seriously you take that because you value trust and you know that people have trusted you and it's been a, a really amazing thing about working with you. With that said, I also know that you don't sleep a lot because you are up at hours when I'm going to bed and you're in a different time zone. So, thank God for coffee. Absolutely. Israel, this has been so great, and I think you've opened up a lot of people's eyes to the power of continuous profiling and why it's so critical, especially as we reach this new platform age, as you talked about generative AI and GPUs and all of that. I'm sure that there are many listeners that wanna learn more about you and about Zimtrace. So where can they go to learn more about you and Zimtrace? Oh, I'm very active on LinkedIn, so go find me there, Israel Ogbole, and I will show up immediately. I also write a personal blog post where I put in some of the things that are going on in my life. So if you care about my life, not corporate stuff, go to IsraelO.io. You'll find all my details there. Fantastic. Awesome. Well, thank you so much for joining us today. This has been fantastic, and I know that customers are excited to go check out you, your website, Zimtrace's website, your LinkedIn, all of this, because it's been a truly insightful conversation and hopefully eye-opening for many, many enterprises. So thank you. Thanks for having me. It's fantastic. Build Not Born, the startup go-to-market podcast, is brought to you by Venture Guides. To find out more about Venture Guides and how our Venture Capital Plus guiding model helps early-stage startups build scalable, go-to-market strategies and grow faster, visit VentureGuides.com. And then make sure to search for Built Not Born in Apple Podcasts, Spotify, YouTube Podcasts, or anywhere else that you listen. Hit subscribe so you don't miss any future episodes, and we look forward to building with you. On behalf of the team here at Venture Guides, thanks for listening. Until next time, keep building.