Transcript: Code Got Cheap. Bugs Got Expensive | Ilan Peleg (Lightrun)

Opening: San Francisco comes back to life thanks to AI

Ilan Peleg: [00:00] Ilan, welcome. How are you? Great. It took us a while, but here I am. You just got back from abroad, right? It's hot. I told you that you said no, actually it was really pleasant. So you took in half of it, a bit before we started chatting. I was in London, which I've been visiting more lately, and of course San Francisco, which, by the way, is a really interesting story. San Francisco has improved a lot over the past two years. It's become much more colorful again, the way it was before the COVID era. COVID... You surely know this, and the audience here knows it too, but COVID kind of darkened San Francisco and turned it into a place that... There was a mass exodus. I know a lot of people who left. So yes, but now it's become very, very colorful again, the way it used to be, and the vibe there is completely different, much nicer than it was. Interesting. Interesting. AI, AI, AI, and also various sound political decisions, but... AI simply brought back all the companies there, all the sexiness that used to be there. Which is interesting, because the money is going to a handful of companies right now. Yes, but those companies are right there. What crazy concentration. Yes, yes, yes, yes. Take us for a second... There's actually an insane gravity of talent there. Yes. Take us for a minute to London, actually. What interesting companies are in London right now that are customers of yours? I can't name specific companies in London. I can say that we work there with a few... very, very large banks in the region. Maybe tell us a bit about what you do, what you guys do. Right, so broadly, we help some of the largest organizations in the world... with what's called software resilience. It may be a buzzword, but it's becoming more and more timely and relevant these days. We talked about this a bit earlier, but in the era of agents, where agents don't just serve us in building, unfortunately, but agents are also the users of our products, suddenly there's a lot more uncertainty. And a lot more non-deterministic, unpredictable behavior in how our digital products are used. And it can come simply from a security angle, which of course everyone talks about in the Israeli scene. There are many more potential vulnerabilities, but of course there are also many more bugs, a lot more uncertainty, a lot more non-deterministic behavior. So resilience is what grabs the CIO, or... Let's, let's put it simply, because when we came in here, Or, the owner of the studio, asked you what you do and how you're different from Claude. We help find and pinpoint vulnerabilities slash problems slash bugs in code, and in software in general. We started with code and are now expanding to software, because software is... ultimately broader than code written by engineers. To find them, pinpoint them, and fix them before they create impact. Before it reaches production and actually meets someone. Yes, yes. And even if, God forbid, it does happen, and it happens quite a lot, then to fix it as fast as possible, again, before it impacts users, customers, and so on. So broadly, when I take resilience and break it down into simpler words, it's a product that detects vulnerabilities and bugs in code and then also fixes them as they happen. Excellent. Now go on to Or's next question. So how is this different from Claude, right? Yes, sure. So Claude is amazing, and by the way, in organizations that use Claude we're actually more and more successful. In other words, it's a great catalyst for our business and our product. Claude mainly helps us produce code. Of course it also helps with what's called debugging code, but mostly code while it's still in production, sorry, in the writing phase. Now, anyone familiar with complex enterprise environments knows that the more complex bugs there don't happen because the code you wrote is broken or wrong, but because suddenly the code meets an environment, and it's no longer, as they say, siloed inside dev, not in my own sandbox, but suddenly you have millions of users. And the code might come from some open source project you integrate with, or a third-party system you consume a service from, and in large organizations there are thousands of those. So that connectivity to third-party products, where maybe an API broke, or there's a bug there, and now your system wasn't prepared for it, and so on and so on, creates a huge amount of friction, precisely in the places where code meets an environment. That's friction worth a lot of money, right? And it's worth a lot of money precisely because in the AI era, when the pace of code production goes up, and the pace, I mean, your production moves at AI speed internally but also externally, the number of users and the type of users grow at AI pace. So your ability to understand what's happening in production, and accordingly either prevent problems or fix them, becomes all-encompassing when it comes to problems. In the beginning we dealt with bugs. Over time we expanded beyond bugs to everything you want to understand about what's going on, whether it's fixing bugs, preventing bugs, incidents, God forbid, or even all kinds of vulnerabilities. So the places where these things happen in production are much more expensive today. That's where we are. They're more expensive because they're more complicated, because it's not necessarily a person. The scale of digital product consumption is rising because everyone is building digital products today. So when you have a higher scale, and you also have more and more regulation around how software behaves, especially when it meets users with exposed data and so on and so on. So the combination of all these things, multiplied together, creates more and more places to break. The whole thing is exponential. So Claude serves us less in those places. Also, which enterprise would trust Claude specifically, you know, something very generic, for the whole thing, right? Yes, so I think, I think Claude is amazing. By the way, we use Claude today. We... First of all, we use Claude today and we have many integrations with Claude. Claude is amazing, but to me the more interesting question isn't about a specific product like Claude Code, it's how you bring AI into very heterogeneous places, places where... Again, I'll come back to it: imagine a travel e-commerce product that has hundreds or even thousands of integrations with third-party products, because at any given moment it wants to make sure its algorithm offers the cheapest or most attractive offering, the best bid. So you have hundreds or thousands of integrations with third-party products, multiplied by millions of users at any given moment. There's no chance AI can anticipate all the unknown unknowns ahead of time, so you must have some mechanism that lets you look at the data and at the flow of users at any given moment. Not to mention that agents have started doing our online shopping for us, right?

What Lightrun does: software resilience in the age of agents

How it differs from Claude: bugs that appear when code meets an environment

Eyal David: [06:49] So in that world you want to be in a place where you're resilient. No, you mentioned types of users earlier, so I assumed that's where you were going. Tell me, this is really interesting. What occupies you day to day right now in light of this? Occupies your thinking, you know.

Ilan Peleg: [07:05] Yes, a lot of it is understanding what the world will look like tomorrow and how organizations think the world will look tomorrow, in order to solve a problem that isn't just today's problem but also tomorrow's. And tomorrow is fast approaching. I mean, if you used to build a strategy... Speaking of product, if you used to build a product strategy, say, once a year and do a quarterly check-in, and meanwhile the business ran, today you deal with questions of what to build every single day. And when you think about where this world is going,

Eyal David: [07:39] it's very relevant. I really think it's totally relevant, how it's not just about who will develop, it's who will sit next to whoever develops. It's really about where the world of work is going.

Code is cheap: what makes a good developer today

Ilan Peleg: [07:50] It goes pretty much hand in hand in this industry, right? So I think you mentioned I was just in London and San Francisco. You asked about London. What was interesting to hear in San Francisco is that the perception of what a good developer and a good builder is, is changing. I mean, we're in a world where code is cheap. 'Code is cheap' has been said many times, and not by me. What it means is that in a world where code is cheap and everyone can write code, the question of what to build, who to build for, and how to create value is the one that carries the most weight. In my view, a good developer in the new world is one who knows how to identify problems among their customers and solve them, rather than one who writes code. I mean, code is already... By the way, the conversation in San Francisco two or three years ago, or even earlier, compared to today, has completely changed. The perception, or mainly the appreciation and perception of developers, because I also work with developers, has completely changed. Back then, you know, you'd see the conversation was mostly around complex architectures and new technologies, and today it's mostly about how I identify and solve problems for my customers, as big as possible, and, you know, taking as much as possible of that pie of problems that are more business-oriented. So I think you listen a lot more today than you used to. Yes, absolutely. Back then you had a thesis and ran with it for years ahead. Now you keep refining and adjusting that thesis based on what's happening in the market, and there's a lot of noise every day, every hour. What's your latest thesis about the world? Very much on this specific angle, right? I think our latest thesis is that AI can automate a huge number of things, and it will automate a huge number of things. That said, there are organizations that ultimately depend on historical data and on workflows that are quite anachronistic. Inside the organization there's a lot of specific knowledge that needs to be built in order to help these organizations go through this transformation. So of course, as Lightrun, we touch these organizations in the area of resilience, which I defined a few minutes ago, but broadly it's detecting and fixing software problems. And detecting software problems is an area that's much more complex in organizations that are much more complex.

Eyal David: [10:18] OK, so let's park here for a minute and come back to it. You said Lightrun. We introduced the company but didn't say how long it's been around. So tell us who...

From running the 800 meters to software and entrepreneurship

Ilan Peleg: [10:26] But let's introduce you for a moment, OK? Besides knowing that you were also an athlete, do you want to introduce yourself a bit, and maybe touch on that angle too? Sure, with pleasure. My name is Ilan, I just recently turned 34. I live in Tel Aviv, originally from Ashdod. Yes, as you mentioned, I used to be an athlete. It's interesting, there are many parallels. That might be a conversation for another podcast, but there are many similarities between my career as an entrepreneur and my previous career as an athlete. So I was a professional athlete, and long story short, I became an engineer. I always loved building, and a software developer, and from there I founded Lightrun out of a real need that my partner Leonid Blouvshtein and I experienced, over six years ago. That's it, and so far we've raised close to $115 million.

Eyal David: [11:23] Tell me for a second, as an athlete, what did you do? I ran the 800 meters. You ran the 800, individual, OK. Right, I ran the 800 meters.

Ilan Peleg: [11:31] I was on the Israeli national team, I was Israeli champion several times, at least in youth, under-20 age groups. What happened? Why? I also got injured, but that's not a reason, everyone gets injured all the time. It's like an organization with bugs. I mean, from there to sitting down and starting to develop... like, what? What happened? At some point I came to the realization that there are other things, desires, passion, that I'd like to fulfill myself in. Building in the software world always interested me. And I came to the conclusion that I wanted to move on. And up to that point you didn't develop, weren't connected to it, or were you? I wouldn't call myself a physics boy, I was kind of a nerd who loved, I competed in math olympiads and really loved it, I was a science type, a fairly science-minded guy, and I always loved puzzles, I'd do puzzles for fun. But not development, no, no, no, not development. But you know, especially today when code is cheap, yes, it's more that analytical thinking. And the challenge, that challenge is what I always loved. How did you meet Leonid? How did you end up working together? We have a very romantic story. In Ashdod? Yes, in Ashdod. We have a very romantic story that I've gotten to tell before, and... by the way, let me open a parenthesis here. I have a good friend named Tamar, who'll enjoy it if she's listening to this podcast. When we had just founded the company, we came to give her a pitch before we approached investors. What does she do? What's her role? She was a GM at several large companies, and she comes from advertising and marketing, an excellent storyteller. So, like, to see if the story sticks. Yes, in general, the very first deck we ever put together, I think, we came to present to her. I'll come back to my story with Leonid after this, I think it's a good story. With pleasure, really. So we come to present to her, you know, the world of bugs and software is a bit foreign to her, so she stops us. Wait, wait a second, tell me how you met? So I'll tell the story of how we met in a moment, but long story short, we met on a bus, and she went, oh, that's a good story. Remember what I'm telling you: a lot of the investors you'll meet won't understand anything about code or what you're solving, but they'll remember that you met on a bus. And sure enough, I don't know if it flatters us, probably not, but there were some investors I met years after I pitched them, and they really didn't remember what we do. Ah, you're the guy who met his partner on a bus, right? So she was right. So Leonid and I met on a bus. How do you meet on a bus? His face was familiar to both of us, we were both from Ashdod and had mutual circles. I knew he was a kind of genius. And I, as you said, wasn't a builder yet. I mean, I connected to the analytical side of it. By the way, I think a little before I retired from athletics I'd already started playing around a bit and putting together all kinds of things. But he was much more talented and smarter than me, and I understood that from our mutual friends, and I just sat down next to him and started talking with him. I figured it'd be interesting to get to know him, maybe he could also be a partner for the journey, although at the time it wasn't clear for what. I was just interested in sitting and listening to him, learning from him, and we started talking about technology and started building all kinds of things, we were always around that. That's interesting, you were a solo athlete up to that point. Yes, but somewhere, and this might also be for another podcast, but somewhere early in my life I got the insight that if you can't beat them, join them. Because as a very young kid I was very competitive and wanted to be the one with the highest grades and so on, and somewhere in university I realized I wasn't the smartest, so it was actually worth it for me to surround myself with people smarter than me. A lesson I got at a young age, around 20. How do you maintain it today? Oh. So today I'm always looking for smart people to be around, and I really, really love being the dumbest person in the room. It fulfills me a lot. How do you make sure to do that? Because when you build a company you mainly look for people like you, right? It always comes down to people. So first of all, not necessarily. Often you actually look for the people who will complement the skill set missing in the company or the team. Often. That's an interesting discussion, by the way. When you hire someone into a company, you don't necessarily hire the strongest person in their field, you hire the person with the best fit for the company at that given moment. Meaning, sometimes they might be weaker in some skills, but they'll better complement the existing cadre and stay as long as possible. For example, or the... you know, maybe in a certain domain we're already really, really strong, so bringing the best person in that domain isn't necessarily what we're looking for, but rather an area where we're weaker and want to grow.

"We met on a bus": the story investors remember

Being the dumbest person in the room, and hiring for fit

Eyal David: [16:23] That when you hire for a team you don't necessarily hire the best person in their field is a statement that's generally true, but there are often trade-offs. You also want a team player, you want

Ilan Peleg: [16:39] someone who fits the company's DNA and so on. It's also very hard to hire the best person in their field in many cases. Yes, again, I don't want, I also want to say this in a moderate tone, definitely not. You always want to hire the best people, but the best in their field also means they need to be a team player, it also means they need to fit the level of the gap. The best, as they told you, for the role, for the position, right? Also different stages of the company require exactly... so there's no real 'best in their field,' right? I mean, that's very good, that's very true in the context of the company itself and its needs.

The early days: AI Autonomous Remediation on the roadmap

Eyal David: [17:13] So let's talk about the company for a second. You and Leonid started walking together, you pitched, started running, I don't know what you raised, you'll tell us, but this was still before agents, right?

Ilan Peleg: [17:23] No, we were founded before the AI era. AI was always on the horizon, obviously. I mean, AI already existed. I even remember that in our very, very first deck I had four main bullets in the strategic roadmap, really at the very beginning of our journey, and the fourth bullet was, like, AI autonomous remediation. I remember that when I put that bullet in, opinions were divided on whether to keep it or not, because it sounded very futuristic, and even some of the smart people advised me to remove it, it's just fluff, forget the fluff. Focus on what you're going to do. So for some I removed the bullet, for some I presented it, it depended. But here we are and it's happening. So yes, it was before the era of agents. But as I said, this problem has become a more complex problem, and we actually focus on the more complex places, meaning less on the places where all kinds of individual contributors can come and spin up apps with Claude, you know.

Eyal David: [18:25] Yes, the Claude thing was just to challenge you, obviously, before the conversation. But take me back there for a moment. You actually had no background in entrepreneurship before this, like, not the kind where you go and raise money, right? And you built a deck, and suddenly you have smart people telling you yes, no, and in the end you do what you want and adjust messages. How did you approach that? How long ago, how many years was this? It was over six years ago. That's it. How did I approach what, founding a company? Not yet, you haven't founded anything yet. Right now you have a deck. You're saying you and Leonid are building a deck, right?

Talking to customers, from developers to the CIO

Ilan Peleg: [18:57] Yes, even the deck wasn't fully baked. The most important thing for us first was actually to talk to as many people as possible who represent the target audience. Meaning, roughly how many people did you talk to? Dozens of people at the beginning. I always encourage... you asked me whether I'm, like, giving back, before we started, when we were chatting during the warm-up. So I encourage whoever I get to advise, even if you've already raised money and you're doing well and you know you'll raise more, and so on: always, always, always, always dedicate part of your calendar capacity to meeting as many customers as possible who'll tell you about their pain. What does that look like for you? You said you listen a lot more. What does it look like for you today? Yes. A large part of my calendar is simply filled with conversations with customers, either existing customers on every side, or potential customers, but the target audience. And that's even to the extent that, even though we're ultimately a product sold to giant organizations, mainly to an audience of CIOs, Chief Information Officers, very, very senior people, and there are probably dozens of hierarchy levels between them and the developers in the organizations I'm talking about,

Eyal David: [20:10] to this day I still meet quite a lot with developers too. Now I'm talking with the users, beyond the buyers, I get it. To this day, and I'll keep doing it. And how do you do it? Do you come curious? Do you come with, I don't know, do you come with a prepared set of questions?

Ilan Peleg: [20:22] I have a prepared set of questions, but in the end I come with an agenda, I don't just show up to a meeting. I always have an agenda for every meeting, what I'm trying to learn.

Eyal David: [20:31] Which is good, that's how I do it too. Right. Although you do also want to leave some freedom for...

Ilan Peleg: [20:40] In the end, if you know everything, then why have the conversation, right? You also want to leave some freedom for the unknown. So it's a kind of framework of not too many questions. I mean, the conversation shouldn't be saturated with questions, it should be saturated with content that the other side fills in. But yes, I talk both with the most senior person in the organization, at least at the IT and software level,

Eyal David: [21:04] and with the most junior. What do you think about the claim, I agree, but what do you think about the claim that it's strong enough to understand on its own what our users' and customers' needs are, and to approach that on its own, like,

Ilan Peleg: [21:18] how much weight do you think this human side carries? So, uh... in two years' time. So first of all, first of all, before every conversation I ask the AI: what do you think are the problems of the person I'm talking to, what are the organization's problems, and where does this hit the persona. There's alignment, I mean, AI is very good at it, but not always. That's one: it's not always right. And again, not because the AI isn't good, it's very intelligent. That's one thing. The second thing is, listen, in the end there's nothing like hearing it from the user. Yes, in the end AI is... I'm sure you hear this from so many different angles, but it's limited in what it can see as long as it wasn't a user itself. It doesn't know. Yes, maybe if you ask that user's agent, it'll know how to answer much better, but you don't have access to it.

Eyal David: [22:06] The reason I'm asking is that I really believe in listening. This podcast has also helped me a lot in my role. I think listening saves me a lot of time, but I'm saying, OK, I'm cultivating this ability

Ilan Peleg: [22:20] on a timeline of several years ahead. It's very intriguing, very intriguing, and worth investing in. I really, really encourage, as a direct follow-up to what you asked, I encourage, I don't want to say the word force, but I encourage and recommend that our whole team before they get on a call, and in general, be very data-driven. Now, being data-driven is something that's always been common in the product world and in general. Now it's much easier. We also did quite a lot of work to index thousands of calls. Let's explain that, so you come into the call much more empowered, sorry for the English, but basically so I don't show up like a salesperson or a support person, right? Yes, there are many questions that are already redundant to ask because you work with the customer and already have organizational context that's been gathered, so you need to learn from it before you get on the call.

Eyal David: [23:14] Let's take this, I agree with you, and I'll also say that in my opinion investing in this skill, even if tomorrow you end up being a market trader, will serve you. So I, I invest in it. I want to flip this for a moment to where the world is going. We collected some questions in the community: where do you think the development world is going? You started touching on it. So, there are a few vibes, waves, a few big waves and a few sub-waves.

Where software development is heading: the Autonomous SDLC wave

Ilan Peleg: [23:46] The first wave is, like, autonomous SDLC, autonomous software delivery lifecycle. Meaning companies that are code producers and software producers are going to automate the entire software production process, starting from the stage of design and coding, testing, review, all the way to production, operations, and support. Most of it, a large part, is already automated anyway, and a large part that isn't automated yet is on its way to being automated very, very soon. That's the first wave. That's it. I'm probably, in the second wave, it'll get into touching agents on product, so is that the second wave in your view? No, no, so you know what, I'll correct myself. Yes, honestly I didn't plan to touch on that, but it's an additional wave. I referred to it when I said design, that's where I was referring to it. So that too is going to be automated. I mean, there are more and more agents that read your Gong calls and read your calls about what customers want, and then you get epics and features and so on. I call this whole process SDLC, from what to build all the way to when what you built is running at customers and also getting feedback on whether we built the right thing. By the way, about this wave you could have a whole conversation on how it's going to look. I just think that a lot of people, especially in our small country, which is a very prolific software producer, are all still living, or mainly living, the first wave. But there's another significant wave we need to talk about. A large part of the Fortune 500, or the Corporate 2000, or the largest companies in the world, aren't big software producers. They buy software that serves their business processes. I'm talking about organizations that rely mainly on SAP, Salesforce, you know, Workday, what's called packaged software, enterprise applications. And these organizations aren't ones that can get up one day and flip their entire infrastructure, oh, let's put Claude in and everything will be automated. These are organizations that move enormous supply chains, organizations that run enormous factories producing all the products you and I consume day to day, you and I and the rest of the world. So there's another wave of AI transformation in software that is running at their end, but it's not the same wave that we, the cool, advanced Israelis, are enjoying. And they're behind us, and they need a solution too, and they have bugs too, they have vulnerabilities too, they also have what's called software resilience, and they also have productivity gains, and by the way, their productivity gains span tens of thousands and even hundreds of thousands of employees, not fifty, a hundred, 200, 500 thousand. So that's the second wave, and there you have enormous organizations like Accenture, for example, organizations with hundreds of billions of dollars a year, that today, in a fairly manual, project-based way, build products for those companies, or maintain them, not even build products, maintain very, very heavy core systems that still don't embrace AI transformation, and even their infrastructure is too legacy to allow AI to be implemented there. That's it, you, I'm not...

Eyal David: [27:13] That's another wave. Let me stop you for a second. We're very focused on the first phase of the first wave. Because it's much easier for you to approach those companies, that's your audience, right? You start... Not mine as Lightrun, but ours as a nation that knows it very well.

Ilan Peleg: [27:26] What's around me, that's what I mean. We're very much software producers. Yes, yes, because that's what we know. That's what we know, that's what's close to our hearts, that's what's easy for us.

Eyal David: [27:33] And now you're going out and basically going to the more traditional companies, let's say the more industrial companies, let's say. But I was thinking along the way that there are also just huge law firms and accounting firms we all know, where they're not in a hurry either, right? That's a big pill to swallow. They're in a hurry, but they need help.

Ilan Peleg: [27:52] Exactly. And their speed moves at a different pace. So we help both. And by the way, we started with organizations that are very, very, very heavy software producers. The most advanced organizations in the world, yes, say Apple is a customer of ours, yes. They're the most advanced organizations at producing software. I don't know, Apple, SAP, ADP, enormous tech organizations, Salesforce and so on. These are our customers, distinctly technological organizations. But as we grew as a company, we suddenly got to know names of organizations like PPG, a manufacturer of paints. PPG Paints, yes, the largest in the world I think, Fortune 250. So you understand that when you enter this landscape, on one hand, of course we came in through their more modern areas, .NET and Node.js applications, but after we got in, we realized that's a drop in the ocean compared to everything they haven't modernized yet, and there's a huge amount of software there. And by the way, that's the software that's much harder for them to maintain, takes much more resources and money, and also moves the whole organization in a much more massive way than

Eyal David: [29:06] the modernization they did recently. And tell me, does that go through the same point of contact you came into the organization through, or do you have to pave your way? What does it look like? Sometimes you have to pave your way.

Ilan Peleg: [29:15] In the end everything sort of funnels through the CIO, so you go up and pave your way through them, but it's not always easy. That's one. Two, sometimes, you know, these are already natural conversations that happen, meaning they themselves offer the connection and so on and so on. Or, say, the big banks: most of their software is still written on mainframe.

The second wave: mainframes and AI transformation in traditional enterprises

Eyal David: [29:33] That one I actually know. Think about it for a second: most transactions are still on mainframe. Crazy. And still minutes of Claude-written code. I'm dying to ask you a ton of questions, I've written down a few too, but go on with the thesis. So there are two waves.

Ilan Peleg: [29:46] So the second wave is a wave in which all the business processes are going to be automated, and the whole world that can't be automated by adopting AI coding agents, but rather by embedding processes. And when I say embedding processes it sounds a bit fluffy, but to be more specific, it means taking an organizational process made up of a chain of people along the way, which is why it simply isn't automated, and that chain of people is multiplied by a matrix of a chain of organizational contexts or organizational products. It's basically dozens of these times dozens of those. One transaction can pass through hundreds of stations along the way.

Eyal David: [30:31] That's what you talked about earlier, basically getting the IP out of people's heads. I call it IP, but getting the domain knowledge out of people's heads and turning it into some kind of organizational IP.

Ilan Peleg: [30:39] Now you can run on it, that's what you're saying. Yes, yes, that's already kind of about how to implement it, but broadly it's clearly those worlds.

Eyal David: [30:47] So if we give it as an example, just saying: if a company like that now has its whole import and export flow, say, exactly, so there's a lot of regulatory information here, for instance, so you basically take that down, and it's also constantly changing, exactly, so you need to take all of that down again into our mainframe, and now we'll be able to run on it, just as an example. So OK, that's the additional wave.

Ilan Peleg: [31:08] Right, it's an additional wave that's still very much in its infancy. And if we imagine a world where software is autonomous, and when I say autonomous software I mean from conceiving an idea, where that idea is based on customer feedback, needs and so on, all the way to it running in production at scale, serving customers, and they're also happy, then you have to take into account that a large part of the world's software is software that wasn't written in the last two years by Claude, and it's what produces most of the products we consume in our day-to-day, and the food we eat, and delivers it to our homes or to supermarkets. That's what I'm saying. And lets us fuel our cars. Software, yes, runs the world. But most software isn't in a place where it can go through an AI transformation today. Which is interesting. It's very interesting. Very interesting. Very interesting, by the way. You asked me a bit about what I did in London and San Francisco. So less San Francisco, because they really are at the frontier. But when I was in London I met lots and lots of CIOs who are dying to do an AI transformation. But when you talk to one and say, why not just put Claude in? They say, what? What do you mean put Claude in? This is way before Claude. What they'll probably tell you is, honestly, I don't have, I don't know how to do it, right? Yes. And then suddenly you need to go in with them and help them understand how to manage it. So are you eyeing areas like that too? Not at all, right? We are looking at areas like that too. We think we can be a partner to enterprise organizations in everything related to how they redefine resilience in the organization in the AI era. Of course it's easier and faster, with faster iterations, with organizations that are mainly, mainly software producers, but we're also eyeing worlds... I asked that gently because that's also worth money, but you've also carved it out within one organization, so, like, to do edge cases like that. We have giant organizations where, when you always try to understand how you grow within these organizations, a very natural part for us is, let's do more of the same, but in technological worlds that haven't been addressed yet. And honestly, in our phase one as a company that interested us less, because as a startup you usually want to solve problems at the frontier of tech. Once you're in the growth stage, you want to solve, you want to generate revenue, you want to capture as much as possible and create market capture and so on and so on, you want to expand existing customers.

Eyal David: [33:32] So part of the quick win is, like, you told me earlier, maybe you said, I'm a builder, I want to solve as many problems as possible, so suddenly you have another range of problems. Absolutely, and they're different.

Ilan Peleg: [33:43] And they're different.

Eyal David: [33:45] So along the way you also answered what organizations will need, right? Right. They need, organizations will need to go through

Ilan Peleg: [33:53] what's called AI transformation. Before that it was called digital transformation. Keep in mind that a large part of these organizations haven't even gone through a digital transformation yet, and now they have to go through an AI transformation in one go.

Eyal David: [34:04] How does that work? I mean, they're all public, they report today that they're doing things.

Ilan Peleg: [34:13] We have a plan for things, but they haven't yet, it's a plan for years ahead. Yes, now the thing is, the thing is that the plan is years ahead, but over those years the world has completely changed. They constantly need to revisit the plan, and people change, it's complicated. That's a great, great position to get into, I very much agree with you. Very complex projects

Eyal David: [34:31] just to migrate some of their systems. What heavy lifting. Wow. Crazy. OK, I have to ask you one more thing. I'm dying to talk to you about athletics, we'll come back to that, but tell me, what's it like to sell to giant organizations? Because when you were talking I was thinking about it. How does the kid from Ashdod who rode the bus and met Leonid, sorry, no disrespect God forbid, but how do you get to sell to Apple or SAP, who else did we mention, all those giants?

How to sell to giant enterprises

Ilan Peleg: [34:57] Yes. Honestly, man, we founded a company six years ago. When we founded the company we went to the more modern organizations. Say in Israel, I don't know, Taboola, Gong and so on. And then suddenly you're exposed to the big world, and you understand, a bit back to what I said, that a large part of software runs in these organizations, yes, I don't know, organizations that produce healthcare insurance. One of our biggest customers is UnitedHealth Group. That's a Fortune 5 giant, the largest insurance company in the world. They have thousands of developers, and if they don't deliver, or sorry, if they have critical bugs in the product, then cancer patients don't get their medication. When at some point you understand that the ability of software, or the ability of software to deliver what software was ultimately supposed to do, and if there are bugs, or again vulnerabilities and so on along the way, and that prevents the software from delivering the value it's supposed to, it affects human lives, and at the scale of the United States, or global scale. That opens up the world. So a few years ago we started really selling to the largest organizations in the world, and that includes leaders across tech, as we mentioned, a few leading customers. You said Apple, Salesforce, Microsoft, ADP, SAP and so on. In insurance we have Chubb and UnitedHealth Group, which are the biggest there are, and in retail we have, say, Booking Holdings, specifically Priceline, and Inditex, Zara and so on, and in telecom we have AT&T. And you're only broadening the picture of how hard this is, so let's pause for a second. In each of these categories, where you have mission-critical software, where every one of us is ultimately a consumer of these products at global scale. So you understand that when software goes down, or not necessarily goes down but fails, it affects tens of thousands of people. Crazy. Never mind, just take me, OK, let's say

Eyal David: [37:11] you said hire quality people, you probably hired great people, brought excellent leads, right? Suddenly the Apple lead arrives. After some prep work, you get on a call with them. Crazy. You got on the call, you went there, what does it look like?

Ilan Peleg: [37:26] Honestly, it's funny, that one specifically was inbound. By the way, let's talk about, say, a different account, because Apple, we're a bit... Whatever you want, give an example. We're a bit... no problem. A bit under NDA throughout these processes. Go ahead, whatever you want. But in general, first, I'll start by saying these are very, very, very long processes. It can easily be a year-long process. Of course the fruits are also more significant, these are huge deals, and not just huge, also your ability to grow is huge. I mean, you went with it, sorry for jumping in, you went with it, and nobody knows how much of a process it is, you went with it and ran with it like that. Did someone mentor you? How do you approach something like that? Look, in all honesty, like with everything I did as an entrepreneur, or we did as entrepreneurs, most of what we did we didn't know how to do beforehand. So you just, you know, hit some wall or barrier and break through it along the way. Until you've done it enough times to professionalize it, and maybe also hire people who know how to do it better, and if you've done it three or four times, they've done it three hundred times. But broadly, I really, really believe that usually, it's not always true, but usually you want to do, or as a founder you'd want to do most of the functions, at least most of the functions the organization needs to do, say sales, customer success, yes, things that weren't obvious that I'd done before as an engineer, at least a few times, to understand all the ins and outs. Not all the ins and outs, but to understand the ins and outs, you won't understand all of them, so you'll also be able, you know, to guide and coach the people who'll inherit it and will need to do it more at scale. Specifically to your question about selling to the giant organization: wow, that's a huge discussion. I admit that the first few times we winged it. I'll explain what winging it means. Winging it means we didn't know, we didn't have a defined sales process. Today it's a playbook, yes, it's Excel sheets of whether you checked off this step, yes or no, and that maps out the next process, or the continuation of the process, or the next stage. But at the start we winged it in the sense that it was clear the other side had pain. We tried to understand who had budget to pay for that pain, and we tried to get them to map out for us how we move you know, the process from start to finish, and what the processes are along the way, just to satisfy them, and in the end for them to pay us for it. That's what we did the first few times. We didn't know, we didn't set up methods like MEDDIC, MEDDPICC, and standard sales methods for enterprise organizations, which today are very much a playbook. Probably also from that understanding, flat on your side, as you said a moment ago. We didn't know these things. After we did it a few times, we also identified all kinds of common patterns, we learned, and you know, we understood, OK, we need to do this at scale. Let's understand, let's learn how to do it at scale, and we also hired people, and those people... Do you love selling? I love selling. But if you ask me what excites me most, there's the thrill of closing a deal, that's exciting if it's a significant strategic deal. The thrill when the product is finally deployed and solves the first significant problems where our product helps those customers, that's what excites me more. Like, actually the value, the value created, getting past the challenge you sold and showing them value, that lights me up, that excites me every single day. How do you measure it? Like, is it at the level of an email from them? The good feedback, or do you know the usage, and also, and also, and also. Yes, there's nothing here that's different from other organizations. Yes, you also see product analytics of what was used, and also then you can back-channel to ask why you used it, and it helped resolve. Also, organically, you get emails from them: last night there was a severe incident and this helped us resolve it. And then you ask, OK, what would you have done without Lightrun? And then you understand that maybe if we hadn't been with them, back to what I said before, yes, there might have been a delay in delivering medication to cancer patients, and so on and so on. And when you work with giant organizations that are changing the world,

The real value: when a bug affects human lives

Eyal David: [41:42] changing the world, yes, leading the world, together. A tip, listen, because as an entrepreneur I ran, you know what, a ball, no, you don't stop, like, to hear these things. Yes, it's very, very important to understand the value you create every quarter, and you also dig into it, I get it. Yes, yes, yes, yes, you must understand the business of the customer you're meeting. We also,

Ilan Peleg: [42:04] first of all, this comes after a lot of scars along the way, yes, but we were very much a bottom-up organization at the start, meaning you know, developers who built a product, and now developers who use the product, and somewhere in the company's life we understood that we could, that we could actually be could be, and became, a product that's strategic for the CIO in achieving their goals, which revolve around resilience and operational efficiency and so on, things that... They're kind of living in constant risk, that's what you're saying. Exactly. And when you understand the business outcome you create for them, wow, the conversation is completely different, and also your sense of fulfillment is different. You understand that you didn't just help fix a bug. The bug you helped fix could have been a bug that, had it lasted longer, beyond the fact that maybe dozens or hundreds of engineers would have had to sit on it in some war room, a real command center, maybe it was prevented, maybe a disaster was prevented here,

Eyal David: [43:05] at that level. OK, they wrote down a few questions for me to ask you. One, they want to know what carries over, we answered this a bit, let's see if we want to complete it, what carries over between the two worlds, from competitive athlete to entrepreneur.

Athlete vs. entrepreneur: similarities and differences

Ilan Peleg: [43:21] You talked about perseverance, I hear that all the time, right? So there are a few, I have, I have, I have, I have, I have, I have a stock answer for this, mainly because... Give us a real answer, a stock one. I'll give you the parallels too. I remember along the way, because I've given a few talks about it in the past, I was invited. Specifically on the title of that talk. Actually I was at... I was hosted at Adidas, and their leadership invited me to talk about the similarities and differences between competitive athletes and, you know, an entrepreneur's career. So I prepared for it a bit and I'll try to reconstruct it, because it was a few years ago. But in general the deck was in the spirit of similarities and differences. So now, with your permission, I'll recall as I go, but the similarities: first of all, you have that spirit of competitiveness on both axes, right? As an athlete you want to be the best, and as an entrepreneur you want to be the best, or at least a better version of yourself or of your competitors. And that also affects the people I hire and the team I rally around me. I love hiring winners, that's important to me, and in general starting from the hiring stage. Because you try, based on that person's historical data, to distill markers of being a winner. I've heard that before, OK. No, I didn't invent it, yes. So that's the first similarity. Another similarity is of course persistence and consistency, of course. On both fronts you'll often hear no. Often you get some mission that looks impossible to you. You have to set goals that seem impossible to you, also as an entrepreneur. Every end-of-year board, when you set the goals for next year, it always looks impossible, and somehow you get there. Same as an athlete. So setting very ambitious goals and being very consistent, and hard work. Again, it sounds trivial, but it really is like that. Probably also measurement, well, that's obvious. Yes. The differences, there are also differences. The first difference is that as an athlete, sorry, I don't want to say the word selfish, but you mainly take care of yourself. At least I wasn't a soccer player, I wasn't a team player, I was a solo athlete and I represented myself, maybe my coach. Obviously I was part of a team and so on, but broadly it was kind of every man for himself. So I mainly took care of me, myself, and that's where it ended. I was a very independent machine. As a company leader, of course a large part of your day-to-day and your caring and your concern is for the team and the company. You really care about them, and the common good matters to you. So that's a difference. I mean, you no longer care only about yourself. Your leadership includes caring for the many, let's call it that. That's one difference. Another difference is, look, as an athlete, anything that wasn't first place sucks, it counts as failure. Whereas in business, most businesses in the world aren't the ones generating the most profit and revenue in their field, right? Companies like Anthropic are rare, companies like SpaceX are rare, and so on. But still, many businesses do very well for shareholders, investors, founders, the team, customers and so on. So you can absolutely create a lot of impact and be content with what you have as a business owner and as an entrepreneur, without necessarily being Anthropic or the single leading company in the field. There's a wide range of potential customers, so if you create value and you grow fast enough and the problem is interesting and so on and so on, then you can both succeed and be content with what you have, and you're not necessarily first in the world, as, say, in other worlds. So you've let go of the podium, that's what you're actually saying, right? Because, like, there's more. Look, whoever competes with me directly, I'll beat them and I'll take a bite out of them. But you know, when Claude Code is very successful, I'm happy for them, and I think about how I connect to that wave and how I create more and more integrability with them, and the more successful they are, the better for me. Yes, yes, I saw how I lit that up just now. That's something where you also took that winner mode, right? I see you manage to reflect that into the company? It's hard, right? So there's a kind of balance here, right? On one hand you want to encourage the competitive drive, we have to be better, and really, whoever's around us on the plate, everyone knows we'll beat them. On the other hand, we're also all thinking about the ecosystem and how we're a player in the ecosystem, so how we also identify winners and identify trends and join them. And how do you, how do you keep that flame alive, let me ask it that way, because you mentioned you don't have a coach.

Eyal David: [48:45] How, today, do you, you know, keep your eyes on the ball, even when they turn off the lights? What does it look like?

Ilan Peleg: [48:54] Does Leonid do it? Honestly, I don't have those questions with myself. It's somewhere deep within me, and within Leonid too. We wake up every day with a lot of drive, every day there's a ton of work, there are very aggressive goals and we need to hit them. How do the two of you sit together and attack the goals so they're aggressive enough? Do you both see eye to eye on that? We see eye to eye, we discuss it together, but you know, it's no longer just the two of us. There's also a board and a management team. And under the management team there are more middle managers and so on and so on. It's already, you know, it's already a machine. So you succeeded, you're saying you managed to get it into the company's DNA, that's what you're saying. The people at Lightrun are very competitive, very ambitious, they push hard, and it's important to all of them to be the best in their field. And at the same time they're always looking outward, trying to understand the market trends and how we ride the most relevant trends around us.

Eyal David: [49:48] Which is different from 'winners,' I have to say, from the winners slogan I hear from time to time. So, well, listen, the thing that most... You can't be a lone wolf in business.

Ilan Peleg: [49:56] That's for sure. You get it? That's the difference. Depends on the business, but yes. Yes, but usually you're part of some ecosystem. You go into an organization and often they ask, OK, what integrations do you have? If you come and say, I'm a lone wolf, I'm the best of all...

Eyal David: [50:10] I know, I was careful not to go into that area, because it would have taken us in a completely different direction for this episode. I don't know if we'll open that up, so I'm putting it aside, OK? I agree with you. Career advice, do you have something off the cuff? Maybe something you say at your company about the... In what sense? They wrote career advice here for me and voted for it. Ah, career advice. Whether I have career advice. Let's try to set some boundaries for a moment. We'll put you in a box: you have a thesis about reality, you laid out where at least this world is going. What career advice would you give your cousin or your nephew?

Career advice: identify problems and solve them

Ilan Peleg: [50:45] Yes, so the most... he called me. He's just finishing his third year as a student. Sorry, a computer science student. He just started working in high-tech for the first time, and he's a talented guy who's always developing himself and isn't satisfied with just his day job. So he asked me what projects to do. So I told him that today, waving a résumé saying you built A, B, C is, in my view, a bit less interesting. Because we can all build today, and Claude can build too. I tried to steer him toward identifying problems and solving them. You also said, not just any problems. So let's start with him identifying problems. That's a muscle that needs developing. It can be a problem he runs into in his day-to-day, but there he used AI, or software, since he just graduated from computer science, to solve problems. I mean, writing on a résumé 'I built an API system that does A, B, C' is, in my view, less interesting, less interesting. But 'I identified problem A, B, C that affects organizations or people A, B, C, and I solved them,' with the API and so on behind the scenes, that's more interesting. So I suggest that all of us really try to be more builders in the sense of identifying problems and solving them, and using the tools we have today, which are much more advanced, to solve problems, and not just show that you can build something, because that's already less, less [interesting] in my view. Can you add something to that? Sounds great to me. It sounds to me that if I look for a second at your path, and also

Eyal David: [52:26] probably from here you need to move very quickly to try to start selling it too, from the start you need to understand who we're selling it to, right? Of course, start selling it to train that sales muscle we talked about. Of course, of course, excellent. I don't know which people asked this, if they're people currently in the second wave we talked about, then maybe those guys on our import-export chain, there I think there's a completely different suggestion you could give, but let's leave it. We have a few minutes left before the end. Quickly, I think, at least tell us the mistake or failure that taught you the most. That's also a question that came up here.

The mistake: building without verifying the problem was big enough

Ilan Peleg: [53:07] Wow. I have one. It connects. It connects, but it really is like that. There was a period when we assumed we knew what needed to be built and we just built it. I mean, we already had customers. We assumed we knew what needed to be built for say, some of those customers. We built it. Now, let's not be completely naive, it's not that we didn't talk to those customers. But we didn't verify that we were solving a big problem for them. We assumed that was the solution. And that's a mistake. That's a mistake. How did you fix it? Don't even take me to how much it cost. Today the developers, the developers at Lightrun are on a direct line with our customers. By the way, that was always the case, but at some stage, as the company grew, you know, you have a chain of stakeholders in the organization of who talks to whom. Now I make almost the entire organization talk to customers. Again, you need to create order in it, but that's one. Two, you know, not everyone will necessarily be on every call, that wouldn't make sense. But today there are no features developed in the organization, especially when features are already at the developer level, where developers just receive and implement. They always ask what problem we're coming to solve, and they always watch the Gongs and customer calls before they get down to work. Meaning, they don't get an epic ticket and say, OK, let's just write the... So you learned that. Tell me,

Eyal David: [54:58] and I'll actually take the question we already talked about, but maybe we'll manage to nail it down before the end. How do you make sure a problem is big enough? What's your checklist? Excellent. So first of all,

The checklist: how to know a problem is big enough

Ilan Peleg: [55:13] again, let's not be naive, not every problem you'll ever solve is big enough. Sometimes it's some bug or some feature request that just lets your product be used more efficiently and so on and so on. Fine. But if I take your question and translate it into how you know that a strategic direction you're taking in the company is a strategic direction that solves a big enough problem, then you need to verify it from several directions. First, you need to make sure it solves a strategic problem and that it's a priority for your customers. Now, the word priority is also a word I learned over time through blood, sweat and tears, as they say, and we talked about this a bit, we chatted before we started recording. You can solve a very painful problem, but a large organization, and people in general, have many painful problems. That doesn't mean your problem is prioritized. Prioritized means there's budget behind it, there's an owner, someone in the organization responsible for solving this problem, or even several people. And that it's a problem they want to solve now. It could be a problem that exists, is even very painful, and even very strategic, but the organization decided to solve it two years from now. So with the whole checklist of these things, you want to make sure there really is urgency around the problem, there's either an existing budget or a budget where you know where it could come from, maybe replacing existing tools and so on and so on. And now translating that into business metrics, you want to see that it's something meaningful, substantial, I know, right? I mean a significant, bigger check, or something that lets you expand customers or bring in new customers of a different kind, for example. So I'd say: make sure the problem is a priority for organizations, and that it's a priority today or tomorrow, but not the day after tomorrow. The combination is something that, by the way, sounds easy, but isn't necessarily easy to answer, and you have to answer it. And in hindsight we didn't always answer it, we didn't always answer it in hindsight, and that connects to what I said, that we thought we knew which problem we were solving, but we came with the solution

Wrap-up: customers are the moat

Eyal David: [57:24] instead of coming with the problem. OK, that's a good ending for the episode, I think. Yes, I'm sure everyone says this, but everyone also sins against it all the time. So I think that today, more than ever, there's less room for it. Because like you said, I want to win, and if I'm now in a race like what's happening now, then today working closely with customers has become more critical.

Ilan Peleg: [57:49] It's become more critical than ever, because everyone can build everything, so your asset is customers. Your asset was always customers, but your ability to distill problem spaces, in an era where anyone can ask the chat what the top priorities of a Fortune 500 CIO are and it'll give you a list, that's theoretical, compared to working with the Fortune 500, five, ten, fifteen CIOs, as a home of sorts, and distilling through them the problems and also solving them for them. That creates a much more significant moat than the potential moat of some technology or other that you explain on a slide why it's a moat. No, it's a moat because it runs at the biggest customers in the world and we solved that problem.

Eyal David: [58:36] Totally. And I'm thinking along the way, poor guys who now need to talk to the whole world and his wife. Just now I needed to find a few CISOs to talk to. Listen, a nightmare.

Ilan Peleg: [58:45] Everyone, one, that's what... yes, yes. Think how much attention span they have in a world where it's very, very easy to build. When you send all your developers to them, and it's not just you, so I'm saying. Yes.

Eyal David: [58:55] No problem. Ilan, it was a pleasure. So much fun. So much fun. I have to say, seriously, you're one of the most humble guests we've had here. So much fun. Yes, and I really enjoyed talking. So much fun.

Ilan Peleg: [59:07] It really was fun, thank you so much. I'm glad we waited. Yes, I really, really enjoyed it, really. I told you, I don't tend to do many podcasts.

Eyal David: [59:14] Great, excellent, so much fun. OK, bye for now, and we'll also put your LinkedIn so you can respond. OK, bye for now.