Adam Wiggins on Heroku’s Pivot, Building a “Washing Machine” for Web Developers, and Joining Salesforce.com
If you had to name a single company whose storyline weaves through most of the big trends defining Internet startup life in Silicon Valley over the last few years—cloud computing, agile software development, the rise of venture incubators, and the software-as-a-service and platform-as-a-service phenomena—you couldn’t find a much better example than Heroku. From its humble beginnings as part of the Winter 2008 term at Y Combinator to its acquisition by Salesforce.com last December for $212 million, Heroku has had a startlingly rapid rise, fueled in part by the rabid devotion of its customers—Web application developers using the popular Ruby on Rails programming framework.
Heroku is one of the organizations changing what these developers and their employers expect from a Web hosting service. Yes, at bottom it’s still just a place where companies can run their Web applications. The difference is that it was built around a philosophy and a work style that co-founder Adam Wiggins calls “continuous deployment.” With Heroku and similar services like Engine Yard, most of the old distinctions between “development environments” and the “production environments” go out the window; changes in the code can be pushed to users nearly instantly, and the whole infrastructure is geared toward supporting rapid software revisions of the sort that startup gurus like Steve Blank and Eric Ries preach about. That’s made Heroku a favorite among entrepreneurs creating new consumer-facing Internet services, including practically every other Y Combinator-backed startup I’ve ever written about.
But while it may seem from the outside as if Heroku traced a straight path from obscurity to omnipresence, it wasn’t really like that. In fact, the company didn’t start out as a platform for Web applications at all; its original system was more like a sandbox for developers teaching themselves Ruby on Rails. “Externally, you see the success, the meteoric rise, but there were obviously a lot of changes along the way,” Wiggins says.
Wiggins described some of the details of Heroku’s key 2009 course change at Eric Ries’s Startup Lessons Learned conference in San Francisco yesterday, but I got the longer version of the story from him in a rare one-on-one interview last Friday.
I’d originally been scheduled to talk with Heroku CEO Byron Sebastian, but he was stuck on a plane, so Wiggins volunteered to speak with me instead—which is how I wound up in his minimally furnished, dimly lit office inside Heroku’s SoMa headquarters, which is all bricks and ironwork. Wiggins has a bit of a black-T-shirt, heavy-metal bad-ass vibe going, and I’d been warned by Heroku’s PR agency that he can be unpredictable in interview situations. So it was hard to keep my eyes from straying to the medieval battle-axe hanging on Wiggins’s wall. But the Heroku co-founder, who has a much longer resume than you might guess from his youthful looks, warmed quickly to my questions about how Heroku was founded, how it’s different from other hosting services, and how it became one of the emblems of a revolution in Web application design.
Wiggins told me his first few jobs were in the video game business, at companies like Carlsbad, CA-based Angel Studios (bought by Rockstar Games) and Santa Monica, CA’s Treyarch (bought by Activision). Unfortunately, he arrived in the industry a bit too late to gain fame and glory. “The games I played as a kid in the ’80s tended to be made by two or three guys with a wild idea, but by the time I was old enough to have a career, it was focused on Hollywood-style blockbusters, and you were on a team of 30 or 40 people,” he says. “I was theoretically living the dream, but kind of unhappy because I couldn’t have the impact I wanted.”
That was when Orion Henry, a college friend who would later become one of Wiggins’s co-founders at Heroku, called to ask if he would be interested in joining TrustCommerce, a payment processing service for online credit-card transactions. “It was much less sexy than video games, but the appeal was that it would be me and a couple of guys and I could have a big impact on what we were making,” says Wiggins. The gig lasted four years, from 2000 to 2004—long enough to bootstrap the company to “millions a year in revenue,” Wiggins says. (Irvine, CA-based TrustCommerce is still around today.)
Wiggins and Henry liked working together—Wiggins describes the friendship as “yin and yang, where one person has this crazy creativity but on their own they tend to go off into the weeds and not have focus, and the other is a more structured thinker and organizer.” (Henry is the crazy one and Wiggins is the structured one, in case that wasn’t clear already.) But the pair would collaborate on two more ventures before they finally hit on the idea for Heroku. One was a competitor for XDrive, the early cloud storage services. Next came Bitscribe, a business process consulting firm. Without really intending to, says Wiggins, that company wound up with a staff of 20 programmers, helping clients build systems to manage shipping, receiving, and logistics. [Corrected 5/24/11 3:00 p.m. PDT. An earlier version of this paragraph stated that Wiggins and Henry started X Drive itself; in fact they started a competing service.]
Three very important things happened at Bitscribe. First, Wiggins and Henry hired James Lindenbaum, another hacker-entrepreneur who would eventually become the third co-founder at Heroku. “Orion and I had this long working relationship and James folded into that really quickly, and we found that the three of us were a really tight unit,” says Wiggins.
Second, Bitscribe started using Rails. If Ruby, an English-like programming language dating back to 1993 or so, had been conceived to help make being a developer fun again, then the Rails framework—which consists of modules for quickly building common website components such as e-commerce shopping carts—made programming in Ruby much more systematic. Rails “encodes best practices about how to ship software quickly and at low cost, in a way that fits the needs of customers,” Wiggins says.
Together with emerging ideas about agile software development—which emphasize continuous experimentation and revision over exhaustive design and planning—Rails programming offered a methodology for building not just software, but whole companies, Wiggins argues. “It was very empowering and unifying for everyone to have a set of first principles from which you could drive successful products.”
Third, the Bitscribe team got very tired of spending so much time in data centers, setting up servers for their consulting clients. “We’d spend two months building a [software] project and then 6 weeks getting it deployed,” Wiggins says. For the clients, this was usually a one-time transaction cost, but for Bitscribe, “we were deploying new projects all the time, and it just seemed so costly and repetitious and error-prone. And when we were done, we’d want to hand maintenance over to the client, but they wouldn’t have a strong technical staff that knew how to administer a full LAMP stack” (meaning Linux, Apache, MySQL and PHP/Python/Perl—the basic operating system, Web server, database, and programming tools needed to run web applications).
Fast forward to mid-2007. Just as Ruby, Rails, and agile software had come along to make programmers’ lives easier, there was now an option for avoiding the hassle of installing, owning, and maintaining Web servers, in the form of scalable, metered cloud computing utilities such as Amazon Web Services and its Elastic Compute Cloud (EC2). “So you had all these trends emerging right around this time,” says Wiggins. “Ruby on Rails, and EC2 and this great team at Bitscribe and this specific [server management] problem we had identified. We said, ‘This is a perfect entrepreneurial opportunity, we should take it.’”
Wiggins, Henry, and Lindenbaum extracted themselves from Bitscribe and spent the summer and fall of 2007 building the first version of Heroku. But “what we started working on was a little different from where we ended up,” Wiggins says. The original product was designed as a 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 the valuable usage, measured by our ability to acquire customers and how much they would be willing to pay, was on the platform side.” Lindenbaum engineered a three-month transition under which all users of the Heroku Web editor were moved to a new site called Heroku Gardens, while the new Heroku.com, which debuted in January 2009, was a pure platform, running code developers had written on their own.
Well before Salesforce.com came sniffing around, it was clear that the pivot had been a wise move. “The new platform was very sticky,” Wiggins says. “Users kept asking us for more capacity and scale, and that was an indicator that we were on the right path”—so much so that the company eventually decommissioned Heroku Gardens. Meanwhile, in order to scale up its own organization, Heroku brought over most of the old Bitscribe team.
But what has Heroku become, exactly, and how is it different from any other hosting service? Well, for one thing, the company outsources all of the actual processing to Amazon— “We have never owned a piece of physical hardware, not once,” Wiggins proudly asserts. Aside from that, Heroku supplies lots of labor-saving tools, plug-ins, software modules, and services to Ruby on Rails developers, such as custom domain names and SSL for secure Web communications, as well as easy integration with third-party services such as Chargify or Recurly for managing subscription billing, Panda Stream or Zencoder for serving mobile video, or MoonShado for apps that need to send SMS text messages.
“It’s the difference between a bucket of soapy water and a washing machine,” says Wiggins. “With a washing machine, you don’t get in there and deal directly with the washing of the clothes. You have less control, and sometimes that’s a problem because things need to be hand-washed. But the 90-percent case is that you just want to dump your things in there, pick a setting, and come back in an hour.”
I asked Wiggins whether he thought Paul Graham and the other Y Combinator founders admitted Heroku to the incubator because they had some inkling that having access to washing machines would make life easier for virtually every subsequent Web startup to go through the program. He laughed and said no. “Honestly, I don’t think they even completely understood our idea,” he says. “And to be fair, we didn’t either. We had a prototype and some technical design ability. They were investing in us, not the product. But certainly it proved to be valuable.”
For startups—or even larger businesses—the main advantage of an application deployment platform like Heroku, in Wiggins’s eyes, is that it lowers the cost of mistakes. To achieve continuous deployment and get the customer feedback you need to make your product better, you have to push code fast, and “the faster you work, the more bugs you will create…there is no way around it.” Traditional software development deals with that by imposing heavy quality-assurance processes, in a mostly vain attempt to ship defect-free software. Under the continuous deployment model, by contrast, “you just let the mistakes happen, but you make it so that you can correct them easily.”
Given how deeply that philosophy runs at Heroku, quite a few people were surprised that the startup would want to be part of Salesforce.com. The San Francisco-based giant was certainly a pioneer in cloud computing—it took the lead in customer relationship management software by putting all the moving parts in the cloud, so users didn’t have to run any software locally—but it’s no longer what you might call a nimble or lean organization.
But Wiggins argues “their vision has a surprising amount of alignment with ours.” Ultimately, he points out, both Salesforce.com and Heroku believe business software should be delivered as a service. “They started out with CRM, but expanded that out through customization, and the far end of that is just programming—a full programming environment delivered as a service,” he says.
Salesforce.com has “walked down this path in a few different ways,” including building its own Web application platform, Force.com, he notes. But it may be precisely because Force.com has met with limited enthusiasm and adoption among developers that Salesforce.com was attracted to Heroku.
“They are really good with business and enterprise, but they are not necessarily as knowledgeable about how to engage developers,” Wiggins says. “Whereas we have focused 100 percent on developers from day one, and we have the opposite problem, which is that developers aren’t the ones who send you money in the end. You can see why there’s a natural partnership here.”
So far, Salesforce has allowed Heroku to operate with total autonomy. It was part of the understanding, Wiggins says, that Heroku would be allowed to finish building the next major version of its platform, which is due within a few months, before the two organizations start looking for ways to integrate and build on what Heroku has learned. “We have provided the model, but I think now we can expand it out with new types of applications, new audiences, new programming languages, new everything,” Wiggins says. “Sort of the same way Apple came out with the iPod, and they scaled that out to all sorts of endeavors, and now there is this whole Apple way of doing things. I really like that opportunity, in terms of making a big impact in the world.”
And what about Wiggins’s original dreams of being a rock-star video game developer? Actually, he’s never quite given those up—and the situation in the video game development world has now come full circle. With a friend named Miranda Collins, Wiggins developed a Tetris-like iPhone puzzle game called Tetryon; their company, Boomslang Games, sold 10,000 copies before pulling the game from the iTunes App Store. “It was just a hobby, but the fact that two people can, in their spare time, make a production-quality game that 10,000 people want to buy—that was not true five years ago,” Wiggins says.
Don’t expect to see Wiggins leave Salesforce.com to become a full-time mobile game developer anytime soon. But don’t expect him to stay forever, either. “I like a lot of freedom to execute and make choices without having to get a lot of buy-in from people,” he says. “It should be the case in a large organization [that you need buy-in], but it makes it harder to be the lone wolf. So it seems inevitable that I will want to go back. But on the other hand, I am so deeply invested in this mission—and I think we have a lot more to do.”