tool to help non-programmers learn how to use Ruby on Rails to scale up their business software systems—the kind of office management aids that can be cobbled together using tools like Microsoft Access, Microsoft Excel, or Filemaker Pro—and turn them into true Web applications. “The product we built was an editor that lets you edit a Ruby on Rails app right in your Web browser, then flip it around and instantly see the application running,” Wiggins says.
Previously, that would have meant setting up an external production server and re-uploading the new code after each change (and mastering all of the requisite Unix commands and encryption protocols). Now Heroku would handle all of that, using software that automatically secured the needed cloud server resources from Amazon. “Our early positioning was, you can get started instantly, make an edit, and see it two minutes later. There’s still a lot of learning involved, but it’s a smooth ramp-up—there is no point where you hit a wall and have to learn a new set of crazy skills.”
Thanks to a mention in the blog Ruby Inside, Wiggins, Henry, and Lindenbaum wound up with a few thousand users by late 2007. But the team was still living in Los Angeles, and felt that geography was working against them. “We had always heard that moving to a software hub like San Francisco or Boston was a good thing to do, and I had always dismissed that a little bit,” says Wiggins. “But I really underestimated how valuable it would be to be surrounded by peers and mentors and other people who had been through this before, not to mention investment capital.”
It was in search of all those things that the Heroku team applied for the Winter 2008 term at Y Combinator, even though the company, with its veteran co-founders and thousands of users, was quite a bit more mature than the typical YC startup. Being in Y Combinator was “incredible,” Wiggins says, and before the 12-week term was halfway over, the company had won $3 million in funding from Redpoint Ventures.
But there was a looming problem: Heroku was having trouble getting its users to pay for anything. Here Wiggins refers to a concept that Andreessen Horowitz co-founder Marc Andreessen talks about a lot, “product-market fit.” That’s the idea that you can have a brilliant team and a great product, but if the market doesn’t want it, your company will fail; conversely, if the market really wants your product, you can do everything else wrong, and you’ll probably still succeed. “We had demonstrated our ability to execute and we had produced something innovative and stylish, but I would say we had not achieved a scalable business model,” says Wiggins. “We had struck on something that people liked a lot, and that people were going to use, but not necessarily pay for.”
As is often the case with startup pivots, however, Heroku already had the makings of a solution—it was just buried under everything else. As a side experiment, the team had opened up a mechanism that allowed outside developers to ship their code—or “git-push” it, in coder lingo—to Heroku so that it could run on EC2, right alongside the code being written by users of the Ruby editor. “If you looked at our whole technology stack, users interacted with the Web-based editor and used our Web page to write and run their applications. But underneath was this hidden platform that we didn’t expose—it was just the plumbing to let you use the Web tools,” explains Wiggins.
The more code developers git-pushed to Heroku, the more it looked like the plumbing was actually the valuable part, because it saved Web developers from having to deal with servers and system administration. And more importantly, it was a service they would pay for.
By September 2008, about six months after finishing Y Combinator, Wiggins and his co-founders had decided to shift gears officially. “We went a while trying to support both paths,” he says. “But when you are a startup you have to be laser-focused, and it was clear that
