Ilan Peleg was on his way to running practice when he met the person with whom he would eventually build a software company. The bus ran from Ashdod to Tel Aviv. Peleg, around 20, was heading to the Hadar Yosef stadium; Leonid Blouvshtein was travelling to his studies. They sat beside one another and began talking about technology. Public transport occasionally delivers more than its passengers.
There was no Lightrun yet. There was an athlete, another young man with technical interests, and enough conversation to make another conversation worthwhile. Their first venture together would involve homemade food. Their later one would concern the considerably less appetising business of finding out why software breaks.
Today Peleg is Lightrun’s co-founder and CEO. The company, founded in 2019, gives developers ways to inspect applications while they are running. Its ambitions now extend to AI-assisted investigation and repair. Yet the interesting part of his route there is how much happened before the supposedly decisive idea: training, an early business, engineering jobs, and a partnership with time to acquire some substance.
A partnership before a product
Peleg and Blouvshtein called their first company Hommyfood. It was a service for selling homemade food, and Peleg says it was acquired after eight and a half months. He has been rather more restrained about that episode than the average retrospective founder biography might permit.
“This wasn’t some crazy exit, but we had a great time working together”
Ilan Peleg, recalling Hommyfood in 2021
That is an unusually useful assessment of an early venture. The acquisition provided an ending; working together provided information. They had learned something about how their abilities fitted together. A partnership had become more than a promising conversation between people going somewhere else.
That sequence changes the usual order of a founder story. The important relationship was already taking shape before the eventual market came into view. They could approach the next venture with some experience of making decisions together. Knowing somebody is good company on a bus is a pleasant beginning; knowing how you work together takes a different kind of journey.
Hommyfood also gives this story a welcome irregularity. A career can look wonderfully inevitable once somebody has edited out the food business. Leave it in, and the route becomes more recognisable: try something, discover whom you work well with, carry that knowledge into the next decision.
Two laps, years of preparation
Before he was building developer tools, Peleg competed in the 800 meters. He won four Israeli national titles and represented Israel internationally. Born in Georgia, he was already on Israel’s national team at 15. He recalls representing the country at an event in Moscow as an early experience of pride and responsibility.
His memories of training in Kenya are particularly revealing. What stayed with him was the discipline of the runners: demanding morning sessions, the group moving together, each athlete helping raise the standard of the others. When he talks about what sport brought to work, he returns to that shared effort.
The comparison with entrepreneurship has its limits. Nobody awards a startup points for an elegant final bend. Still, the 800 meters offers an apt way to read his later decisions. It is two laps with very little room for an expensive mistake. Preparation matters because the opportunity to use it is brief.
Peleg’s preparation for Lightrun included a computer science degree, earned cum laude at IDC Herzliya, and development roles at FireGlass and LivePerson. He had experience of software work before asking other developers to change how they did it. The complaint that became his business belonged to a world he knew from the inside.
The software leaves the laboratory
Development environments offer a comforting degree of control. Real customers have other arrangements. They bring traffic, data, dependencies and combinations of circumstances that a test environment may never reproduce. A program can behave perfectly under observation and become unhelpfully inventive after deployment.
Peleg and Blouvshtein recognised a recurring frustration: troubleshooting during development was comparatively straightforward; understanding an application already running elsewhere was much harder. Developers needed information about execution, but the necessary information had often never been recorded.
Lightrun’s approach was to let them ask new questions of running software. An engineer could add a log or collect a snapshot of execution without shipping another application version simply to investigate. The point was to make a missing piece of evidence obtainable while the problem still mattered.
Peleg also argued for placing that ability inside the tools developers already used. An integrated development environment, where the engineer reads and writes code, was a natural place to understand its behaviour. His emphasis was practical: reduce the distance between a question and the means of answering it.
The distinction is easy to miss from outside the work. A dashboard can tell an organisation that something has gone wrong. The engineer still needs to learn why a particular path through the code produced a particular result. Those questions live at different levels of detail. Peleg chose to work close to the code, where a developer can connect an observation to the instructions that produced it.
There is a small courtesy in that product choice. Someone wrestling with an elusive bug is unlikely to be delighted by an invitation to learn an entirely new working life before lunch.
A company has its own splits
The financing milestones came later. In May 2021, Lightrun announced a $23 million Series A led by Insight Partners. In April 2025, it announced a $70 million Series B co-led by Accel and Insight Partners. The company reported total capital raised of $110 million at the time of that second announcement.
Accel’s investment brought Peleg and Blouvshtein into a portfolio containing other businesses built around developers and their workflows. The case for Lightrun rested on a costly practical problem: organisations depended on software, while engineers still struggled to obtain the evidence needed to repair it quickly.
at the announcement
Peleg’s account of company building is less breathless than a funding headline. He describes an initial period devoted to product-market fit, followed by the work of finding a repeatable route to customers, followed by scaling. Different periods demand different answers.
His question for the selling stage is pleasingly unforgiving: “You’ve proven value, now can you sell it repeatedly?” A customer’s enthusiasm is encouraging. A method for finding and serving the next customer is a separate piece of work.
Read this way, his running background supplies a useful metaphor for his business thinking. A race has changing demands even when the distance is fixed. A company’s leaders must recognise when the task has changed. More effort on the previous task will not necessarily improve the result.
First, let the machine see
AI coding tools have given Peleg’s original concern a new audience. Generating code and understanding its behaviour are different activities. A system that can produce a convincing implementation still needs to discover what happens when that implementation encounters an existing business.
Lightrun’s Runtime Context offering connects coding assistants with information from running applications. Through the Model Context Protocol, those assistants can obtain execution evidence and help investigate failures. The proposition extends the company’s earlier work: the person asking the question may now have an automated collaborator, but the missing information still has to come from somewhere.
In February 2026, Lightrun announced an AI SRE built around live dynamic runtime context. SRE stands for site reliability engineering. The aim is to investigate software problems, generate missing evidence and check explanations against actual execution, rather than rely entirely on information captured in advance.
“AI cannot resolve what it cannot see.”
Ilan Peleg, February 2026
That statement is also a concise account of the business he wants to build. A fluent account of a failure is of limited use if it describes the wrong failure. Peleg’s ambition depends on connecting proposed explanations to the behaviour of the application itself.
His July 2026 Product Builder conversation widened the question to customers and business priorities. A technical problem can be painful without becoming something an organisation will pay to solve. For an engineer turned CEO, learning who owns the problem, and where it sits among competing demands, is part of learning what the product should be.
The value of a boundary
Peleg wants software that can help repair itself. He also talks about limits. In September 2026, he discussed keeping Lightrun’s observability platform read-only in production, even when customers asked for greater autonomy. Being able to investigate a running system does not automatically confer permission to alter it.
That distinction makes the ambition more interesting. Useful automation requires decisions about what a system may observe, what it may propose and what it may change. For a company working around applications people already depend on, those decisions are part of the product.
There is a quieter detail from Peleg’s life that gives his concern with timing another register. In 2021, he described proposing to his fiancée on a cliff outside Tel Aviv, at the place where they had first kissed. Some locations apparently merit a return visit before an important decision.
The bus, the track, the cliff and the debugger make an improbable itinerary. They also give his career a recognisable rhythm: pay attention, build a relationship, learn the conditions, decide when to act. Lightrun’s future is still being made. Peleg’s recurring question is already clear enough: what do you need to understand before you move?