Edward Tsinovoi and the value of a second route

Edward Tsinovoi once interviewed an engineer he was certain he wanted to hire. The candidate was being considered for a principal software engineering position. The conversation went well. Tsinovoi felt the excitement of finding the right person. Then Michael Hakimi declined the offer. Recruitment, like the internet, occasionally refuses to route traffic in the preferred direction.

Twelve years later, Tsinovoi told that story as the co-founder of IO River, with Hakimi beside him as co-founder and chief technology officer. In his April 2024 account, the intervening years had brought gray hairs and fatherhood. The rejected candidate had become a business partner. An unsuccessful interview had acquired a surprisingly long second act.

It is a useful opening to a career spent making complicated systems cooperate. Tsinovoi has led development teams at Dell and Akamai. At IO River, he is trying to make several content delivery networks behave like something a customer can actually manage. His work turns on a question that sounds simple until someone has to implement it: how do you gain more choices without acquiring more trouble?

The engineer inside the machinery

Before becoming a founder, Tsinovoi worked close to the machinery that makes online experiences feel immediate. At Akamai, he led an organization responsible for the core platform, with work spanning end-user performance and edge computing. His speaker biography describes responsibility for core engineering in Israel and the company's core performance. This was experience inside a delivery network, where a software decision could travel a considerable distance.

Content delivery networks, or CDNs, distribute digital content through servers located around the world. The distance between a user and a server matters. So does what the server can do when the request arrives. A network built to deliver stored files faces a different job when content becomes personalized, interactive and dependent on computation.

Talking with Tim Butara in May 2024, Tsinovoi described two transitions: the growth of dynamic content and the expansion of capabilities at the edge. Storage, databases and code execution were giving these platforms more work to perform near users. His expectation was that more functions would move there, while part of the application would remain elsewhere. The practical question was how to operate across that changing geography.

For an engineer, this is an appealing problem. For the person responsible for keeping a service available, it is also a reason to check the calendar before approving a change. Every new capability arrives with something else to configure, understand and trust.

When standing still becomes a strategy

Tsinovoi describes a formative experience at Akamai: after several outages, the network was frozen against changes for a year. This is his account of the decision and the lesson he drew from it. The risk of another interruption had become greater than the value of introducing something new. The company could possess talented engineers and ambitious ideas, yet the safest operational choice could still be to stop.

There is an uncomfortable logic here. A platform becomes useful enough that many businesses depend on it. That dependence increases the consequences of a mistake. The consequences make change harder. Success can leave a system with very little room to experiment.

IO River, founded in 2022, grew from Tsinovoi and Hakimi's experience of this environment. They wanted customers to be able to use multiple providers without building the elaborate internal operation that such an arrangement traditionally required. The ambition was to make switching and coordination ordinary work, rather than a separate engineering department.

More networks, fewer loose ends

Tsinovoi is careful about the invention claim. Multi-CDN architecture already existed. Large online businesses had long understood the benefit of spreading traffic across providers. The difficulty lay in the work around the routing: different interfaces, different configurations and different ways of observing what happened. A customer could distribute its traffic and still inherit several separate systems to operate.

His September 2024 explanation divided IO River's answer into practical pieces. Traffic distribution would consider reliability, performance and cost. A unified interface and API would support management, configuration and monitoring. Application services would operate across the participating providers. These are the jobs the company set out to combine. Sending a request somewhere else is useful only when the destination is ready to handle it correctly.

There is an everyday analogy in changing trains. Another route is valuable when the ticket works, the connections line up and someone knows where the luggage has gone. Merely owning a second timetable does little for the passenger. Tsinovoi's business addresses the connections between the networks, where much of the operational inconvenience accumulates.

In a later explanation of the company's origins, he pointed to a change he and Hakimi had watched at Akamai. Edge infrastructure was becoming capable of running customers' own logic. That opening created a possible foundation for coordinating providers. It also widened the problem: as networks acquired more services, customers needed consistency across more than delivery alone.

The firewall has its own opinion

Security makes the coordination problem particularly concrete. Tsinovoi has described a business splitting traffic between Akamai and Fastly and finding that the two web application firewalls behave differently. A request accepted by one may be blocked by the other. On paper, the business has gained an alternative route. In practice, the routes may disagree about who is allowed through.

IO River's approach includes separating infrastructure from application services and working with independent security vendors. In January 2026, Tsinovoi discussed relationships involving Check Point, Palo Alto Networks and Imperva. The goal is consistent behavior across the underlying delivery platforms. This is also a commercial idea: companies should be able to choose services without having every choice tied to one network.

“Some traffic will pass from one and will be blocked by the second one.”

Edward Tsinovoi, on different providers' firewall behavior

It is a revealing example of how he explains his work. The abstract phrase is edge virtualization. The visible consequence is a customer whose request succeeds on one route and fails on another. Between those descriptions lies the founder's task: making a technical architecture legible to the person who must buy it.

A sales hire before the instruction manual

Tsinovoi entered entrepreneurship with extensive engineering experience and a new job to learn: selling. He chose to bring in an experienced sales leader about a month after establishing the company. Amos Ben Yaacov would help him build customer relationships and a commercial process. Tsinovoi continued participating in sales; he wanted experienced company while doing it.

He also had to learn what language buyers would accept. A new term such as Virtual Edge needed a bridge to the familiar idea of multi-CDN. Infrastructure customers wanted dependable partners, which made aggressive claims of disruption a delicate introduction. The product could challenge an established arrangement while the conversation still needed to reassure the person responsible for uptime.

That tension gives his founder story some texture. An engineering leader is accustomed to explaining what a system does. A chief executive must also understand what the listener fears. In infrastructure, the listener may be imagining the next late-night incident while the presenter is still on the slide about innovation.

The road to Boston ran through Europe

The company initially pursued Europe, where the team's experience and proximity offered advantages, before expanding its American effort. Tsinovoi later relocated to Boston. The sequence reflects a willingness to learn in a market the team understood before taking on a more distant one.

His public conversations also return to the people doing that work. In December 2024, he discussed trust, collaboration and shared vision with Oleg Sadikov, alongside the demands of balancing a CEO's strategic responsibilities with everyday decisions. The subject suits a founder whose partnership began years before the company. Technical coordination is his product; human coordination is part of the job that makes it possible.

The executive biography, the product discussion and the early hiring choice all point toward the same working preference: reduce the amount that any one person or system must carry alone. That is a reading of his decisions, rather than a claim about his private life. It helps explain why a story about networks keeps returning to colleagues.

Capital for a more open edge

IO River emerged from stealth in March 2024 with $5.4 million in seed funding led by S Capital, with Aryeh Mergi and Ronni Zehavi participating. By January 2026, it announced a $20 million Series A led by Venture Guides and New Era, with S Capital and private investors including Ofir Ehrlich and Pavel Gurvich joining. The funding gave the company's argument a larger stage.

The company reported more than 200 petabytes of monthly traffic at that announcement. Its stated direction extended beyond helping customers juggle familiar providers: separating delivery infrastructure from services could create room for regional networks, telecom operators and specialized vendors. Tsinovoi's aspiration is an edge market in which customers have more freedom to assemble what they need.

His July 2026 CrockPit conversation continued into traffic steering, digital sovereignty and the prospect of AI inference closer to users. These subjects extend the same problem into new workloads. As the edge does more, coordinating it becomes a larger responsibility. A new use for distributed computing also becomes another test of whether the underlying arrangement can tolerate change.

The first interview with Hakimi ended without a hire. The company they eventually formed is built around making alternatives workable. There is a pleasing symmetry in that, although neither recruitment nor software is obliged to provide one. Tsinovoi now has a business to run, partners to coordinate and customers who would prefer the infrastructure to attract as little attention as possible. For someone selling a different way to operate the internet, an uneventful day is a respectable result.