Turn this teardown into a decision-ready prompt for ChatGPT, Claude, or your agent.
If you only have a few minutes to spare, here’s what investors, operators, and founders should know about Eivod (S07).
Eivod was a peer-to-peer video-delivery startup associated with Carnegie Mellon, Project Olympus and YC Summer 2007. The surviving record is thin: a few institutional biographies establish the product category and origin, while YC supplies a founder list and inactive status.[1][2]
The likely technical thesis was clear for 2007. Viewers' upload capacity could reduce the server bandwidth required for on-demand video. What happened to the company is not documented. No observed source gives a shutdown date, buyer, customer, traction figure or founder account, and the current domain no longer identifies a video business.[3]
Carnegie Mellon identifies Matt Humphrey as a co-founder who developed Eivod with colleagues while in business school. A later university presentation dates the company to 2006 and calls it a video-delivery provider.[4] The university's 2016 event biography is more specific: Eivod was a peer-to-peer video-delivery company, the first Project Olympus PROBE, and later received YC funding.[1]
YC records a different founding team: Joe Damato, Wei An Wang and Bob Dimaggio. It does not list Humphrey or describe the product.[2] The sources may describe different team stages, but no observed document resolves the discrepancy.
The period explains the technical attraction. Video-on-demand concentrated delivery cost at the origin server. Microsoft Research analyzed whether viewers could redistribute the same video they were watching and found that peer assistance could sharply reduce server bandwidth under the right conditions.[5]
The research did not surface two reliable founder quotations about Eivod. Humphrey's later slide gives one terse lesson, "Think customer before you think tech," but it does not explain whether that judgment came from Eivod or another company.[4]
The only dependable product description is "peer-to-peer video delivery." In that model, viewers receive portions of a video from other viewers as well as the origin. Their upload bandwidth can reduce the provider's peak server traffic.
That simple description hides hard coordination. On-demand viewers start different videos at different times and seek to different positions. Peers leave without warning. A system has to find a nearby peer holding the needed segment, reconnect after failure, keep startup delay low and avoid turning its control network into a second bottleneck. Contemporaneous research identified asynchronous arrivals, fault recovery, quick joins and control overhead as the central design problems.[6]
No observed source shows Eivod's interface, deployment model, content relationships or whether it shipped beyond a prototype. Claims that it served a particular customer segment or used a specific protocol would be invention.
The likely buyer was a video publisher or delivery provider paying substantial bandwidth costs, but no Eivod source names a customer.
No company-specific market estimate survives. Peer-assisted VoD mattered because video traffic was expensive and growing, not because Eivod disclosed a serviceable market.
Eivod sat between conventional content-delivery networks and other peer-assisted systems. Its economic advantage required enough simultaneous viewers with spare upload bandwidth. Its operational burden was persuading publishers, viewers and networks to accept a client that redistributed traffic.
No pricing or revenue model was found. A plausible model would have charged publishers against bandwidth saved, but that is a rebuild hypothesis, not a historical fact. Funding beyond YC is also unknown.
Read the complete post-mortem, the rebuild playbook, and the exact reasons Eivod is still worth studying now.