Insoshi, YC Founder Story

Company: Insoshi Founders: Michael Hartl (CEO) & Long Nguyen (Co-founder) YC Batch: Winter 2008 (W08) Industry: Social Networking / Open Source Developer Tools Founded: 2007 | Shut Down: Early 2009 Outcome: Did not survive, but the founder's next product made $750,000+ and got acquired Current Status: Open-source repo frozen since 2010. Michael Hartl went on to write the Ruby on Rails Tutorial, one of the most widely used web development resources in the world.

⚠️ Why This Story Is In The Collection Not every YC story ends in a billion-dollar outcome. Insoshi is in this collection because it failed, and because what Michael Hartl did after YC is one of the most instructive pivots in the entire alumni community. You will learn more from this story than from most success stories.

The One-Line Summary

Two Harvard-educated physicists with PhDs built the "WordPress for social networks" in Ruby on Rails, got into YC, became one of GitHub's most-forked repositories, nearly raised a significant funding round, and then watched the 2008 financial crisis kill the deal in October. The company shut down. The founder wrote a tutorial instead. That tutorial made $750,000 and became the most widely read Rails resource in the world.

Lens 1, The Before State

Who Were They Before YC?

Michael Hartl was not who you picture when you imagine a startup founder. He had a PhD in Theoretical Physics from Caltech, the same institution where he had won the Lifetime Achievement Award for Excellence in Teaching. Before Insoshi, he was writing books about building social networks in Ruby on Rails. His co-author was Aurelius Prochazka; his book was called RailsSpace, a reference to MySpace that tells you exactly what era it was from.

Long Nguyen, his co-founder and Harvard College roommate, had an equally unconventional background: a PhD in Physics from the University of Chicago, followed by a career in enterprise-scale software configuration management, helping large organisations manage version control at companies like Discover Card. If Michael was the builder and writer, Long was the systems thinker who had operated at scale in the boring, unsexy world of financial software infrastructure.

Neither of them came from a consumer tech background. Neither had raised venture capital. Neither had built a social product before. They were two physicists who had grown deeply fluent in Rails, and they spotted a gap in the market that they were probably more technically equipped than anyone to fill.

The Personal Pain They Were Living

While writing RailsSpace, Michael kept hitting the same wall: there was no reusable, open-source foundation for social networks built in Ruby on Rails. Every developer who wanted to build a community platform had to start from zero. WordPress had solved this problem for blogging, anyone could install it in five minutes and have a functioning site. Why didn't that exist for social networks?

Michael wasn't frustrated as a user of social networks. He was frustrated as a developer writing a book about building social networks, who couldn't point readers to a real, production-ready codebase that they could actually fork and deploy. The gap was professional, not personal. And that distinction matters, it was a developer problem spotted by a developer, which is exactly the kind of insight that produces strong YC applications.

Why They Almost Didn't Fit the "YC Founder" Stereotype

Michael and Long were, on paper, the opposite of the typical YC archetype of 2008. They were not twenty-two. They were not dropouts. They had not previously worked at Google, Facebook, or any tech company. They had spent their careers in academia and enterprise consulting.

What they had, and what most YC founders their age would not, was a published book that demonstrated deep technical authority in exactly the space they were entering. Michael hadn't just thought about building social networks in Rails. He had spent a year writing the definitive technical guide to doing exactly that. That pre-existing body of work was their credibility.

Key Insight for Aspiring Founders

Domain expertise expressed publicly, a book, a blog, an open-source project, can substitute for startup pedigree. Michael Hartl had never run a startup, but he had written the book on the technical problem he was solving. That public proof of competence opened the door to YC. What have you shipped, written, or built in public that proves you understand your problem better than anyone?

Lens 2, The Idea Origin

How the Idea Was Actually Born

The idea for Insoshi grew directly out of RailsSpace. While writing that book, Michael realised that what people actually needed wasn't a tutorial, it was a ready-to-deploy, fully open-source social network platform. Think of it this way: WordPress didn't just teach you how to build a blog. It gave you a blog. Insoshi wanted to do the same for social networks.

The original code that would become Insoshi was released under an MIT License in July 2007, months before Michael and Long even applied to YC. This was not an idea pitched in a slide deck. It was code that already existed and was already being used by developers. They came to YC with a working product, a developer community forming around it, and a book that gave them instant distribution into the exact audience who needed it.

The company name "Insoshi" came later, before the YC application, the codebase was simply the open-source code from RailsSpace.

The First Ugly Version

The first version was, by Michael's own description, a social network platform that took about 30 minutes to install. That number tells you something important: it was still too hard. WordPress took five minutes. The Rails deployment problem, needing a server that supported Rails, configuring Passenger or Mongrel, managing dependencies, was a real barrier that even Insoshi's early fans flagged immediately.

On Hacker News, one of the earliest threads about Insoshi noted: "Part of the success of WordPress is that it uses PHP and MySQL, two technologies that are ubiquitous... Installing a Rails app, on the other hand, is nothing to sneeze at." This was the core tension Insoshi never fully resolved: the product was technically impressive, but the deployment gap between Insoshi and WordPress was significant.

The Signal That It Was Working

The signal was GitHub. Insoshi became one of the most-forked repositories on GitHub in 2008, a remarkable achievement for a young open-source project. Developers were not just downloading it; they were actively building on top of it, extending it, and deploying it. An alternative currency system was even built on top of Insoshi to power a local exchange network in Austin, Texas.

That kind of developer adoption is real traction. It's not revenue, but it's proof that people cared enough to invest their own time into the project, which is, in some ways, a harder bar to clear than paying $9/month.

The Pattern This Follows

Insoshi fits the open-source-to-business model, the same playbook that MySQL, Red Hat, and later companies like HashiCorp and Elastic would follow. Give the core product away free, build a community, monetise the managed hosting, enterprise support, or hosted version. The model works, but it requires patience and a clear monetisation path. Insoshi ran out of time before it could build the paid layer on top of its open-source base.

Lens 3, The Application Anatomy

What Made Their Application Work

Michael and Long arrived at YC with three things most applicants don't have:

1. A working product already deployed and being used. The open-source code existed, was on GitHub, and had an early developer community forming around it before YC accepted them.