The story of Heroku

Well, Adam, we’re really honored to have you on the show, man. This is awesome. Thanks for coming on.

Thanks for having me. I’m a fan of podcasts, so it’s quite an honor to be here.

You don’t do too many podcasts. You do your own shows, but you’re not on too many podcasts.

I’ve been on a few. I had a really great conversation on Design Details, which is – yeah, obviously a design-oriented podcast, with someone I like a lot… So that was really nice. But yeah, for the most part, when I’m talking into the mic, I’m doing it in my own venue, which is nice, because I get to set all the terms, and do it on my own instigation and my own concept… But I think there’s a lot that come out in someone else’s venue as well, so I’m looking forward to what you guys manage to get out of me.

Well, I was thankful when I got the email back to say “Yes, I will come on your show”, but you agreed to do a two-parter, because we want to talk about Muse, what you’re working on now… But then also this big history, this big question mark of where things begin with Heroku, the journey etc. your journey, how that all intertangles, all that good stuff. So listeners, we do have a two-part planned; we’re gonna see how this shakes out, but we’re gonna do our best to get most of Heroku out today, most of your journey out today, and come back for a second session, and go deep on Muse, and the lab, and all the things you’ve done since your exit, essentially. Maybe even some of that in this story here, so we’ll see how it shakes out, but… That’s the plan.

Yeah, and I should say this is a Changelog exclusive, right? Because I actually made a fairly strict rule for myself some years back, which is I’m just not going to talk about the Heroku era anymore, because I’ve done a lot of that… But it’s now - if you account from the start of the venture, it’s 15 years in the past, or 10 years, more than a decade since I’ve moved on to other things… And it’s always tricky to talk about the past. Of course, memory is a little bit of a lossy format, and in some ways – I don’t know, it feels stale. Maybe it’s just an entrepreneurial thing. You’re always thinking about what’s new and fresh, and that sort of thing. And I didn’t feel like I had a lot more to say… But because Heroku remains the biggest success of my career, it might be the most successful thing I ever do - which, I would be totally fine with that - it naturally it’s the thing that comes up a lot. Or Twelve-factor, people following up on that, asking me to present about it, asking questions about it… And I just don’t have something good to say, because it’s sort of in the past. But I felt talking to you both would be such a special opportunity here, and especially if we can put it in the context of how it did evolve my career, and then switch in Muse, which we’ll get to, I guess, in part two.

Yeah. The motivation for us is because we are just big fans of Heroku. Big fans as users, big fans of your work, and just because of being such big fans - I mean, this is the kind of show, the Changelog is the kind of show that goes deep on this kind of story, this kind of passion, this kind of rich history, this origin… Why does it exist? Why did you scratch that itch? Why were you so ahead of the times in terms of like being the apex DX experience, that still is today trying to be replicated? Trying to be replicated; not has been, but trying, is still the thing out there. And I think that’s why we approached this with such reverence, is because it’s your story, but it’s Heroku, it’s the thing, it’s the best, you know?

Right. In many ways, it’s kind of all of our stories as well, because so many of us - myself included, Adam, I’ve built a business on top of Heroku, both on websites I create for myself, as well as my customers… I’m a long-time software contractor, so I’ve got tons of customer sites… And once Heroku hit, and you guys drilled that experience, I was just like – I’ve been a Heroku fanboy for years, and just continue to use it to this day. And so in many ways, your story is a lot of our stories, because you kind of enabled a lot of us to succeed in this industry, and that is just amazing.

Well, thank you so much for all those kind words. I and my colleagues were building something that was, I guess, in our hearts, but also just reflected something we wanted, and perhaps because we were in precisely the same business as you, which was we were doing consulting, and we would deploy site after site… And of course, we discovered Rails, and fell in love with that, but the deployment side was still, let’s say, not at the same level of joy and ease as the development of the application.

[06:17] Right. It was always the hard part. And I go all the way back… And even this podcast, Adam, you and Wynn started this podcast about the same time that Heroku relaunched as the platform that we all know it as today. Of course, it’s changed quite a bit since then, but like that big relaunch… I remember when it first came out - like, I can’t recall if you guys were Y Combinator or not, but something was like Hacker News homepage, and it was this Heroku thing. And it wasn’t “git push heroku master”, it was like “Write your Ruby code inside of the browser.” And you guys had this snazzy IDE… This was like 2007-2008; you can help us with the timeline. And it wasn’t what it is, but it was still super-cool. But that super-cool thing for me as a Rubyist, who’s already happy inside of Vim and TextMate, I was like “This is cool”, and then I closed tab and I moved on. I wasn’t gonna actually use it. So tell us about that part, too. Tell us about that, because you guys changed your minds about that, and I’m sure that was a tough decision… But it started off as like an in-browser editor, didn’t it?

That’s right. So we began life as a web editor… And I would say that today, you have something like Replit, or GitHub Codespaces has taken that concept and made it a reality. I think we were too early in a lot of ways… But yeah, ultimately we didn’t find product-market fit with that; precisely, as you said, there was a lot of “Wow, that’s cool” factor, but not a lot of “Oh, this is something I want to use.”

So yeah, if we go to the really beginning, this would be me and my co-founders, James Lindenbaum and Orion Henry working at a consulting shop we called Bitscribe in Los Angeles, circa 2006. And we had discovered Ruby, and Rails, and Agile, and decentralized revision control, and some other things in the process of working on what was mostly a pretty – I don’t quite call it boring, but pretty straightforward enterprise software; warehouse management, and that sort of thing. We could go really deep on the development process. And indeed, as we were sort of scaling up the team there to do more client projects, we got really interested in how can developers be more effective, productive. And then as developers ourselves, we came back to this just making the process fun, joyful… And so the kind of Ruby philosophies that we read about from Matz, about sort of developer happiness, and optimizing for that really, really spoke to us… But seemed to fit in with the goal of the business, which is - developer are your biggest cost; true then, still true today. Doing things to make them both more productive, but also happier seems like just an obvious win.

So we had kind of explored that world of stuff through our consultancy, and then I don’t know where I quite got the idea, but I think as I was playing around with making some open source, just little plugins for the Ruby world, and playing around with increasing capabilities of the browser, which of course were nowhere near what they are today, but core features had started to pick up a lot of steam… And I somehow ended up with this idea of actually a debugger, a Ruby debugger in the browser.

I liked the idea that you could be running your Rails app in production, and kind of hit the Pause button and dig into a stack trace. And I’d worked a lot in debuggers back when I had been in the video game industry; you really relied on this, and this was something that the web world had a lot less of. And so I managed to put together a prototype, essentially, of a thing that had your code in one window, and there’s a stack trace in another window, and like a little Console/REPL thing in like a third pane, and then maybe the application output in another pane. I kind of got all that working, and it was pretty – it seemed like a really potentially useful and impressive piece of technology. And we went from there to thinking “Hey, maybe this could be a business. Maybe want to spin this out as product, or do something differently here.”

[10:05] And then I was attending RailsConf in 2007. That was really a catalyzing moment of seeing this growing community of people who I really felt an affinity with, like I really felt I had found my tribe in a way that I had not felt meeting other kinds of software engineers over the years that I’d been in the business. So I said, “Wow, there’s this great community of people, there’s all this energy in this world, but it’s still small. And then in the meantime, we’ve got this prototype product that could be really useful to this community; maybe there’s an opportunity here to build for people like us.”

So what do you think it is about that first iteration, when you all put that out there, and impressed your friends and non-friends, people like myself, who were in the Ruby community, and thought it was really cool, and even tried it out and signed up? …but you quickly - at least according to Wikipedia history, you quickly started a new, kind of a ground-up rewrite, which became more of the platform angle. I believe the original idea had to have deployment involved as well, I would think; you can confirm or deny that… But what were your signals that “This thing isn’t working. We have to do something different”? And that seems to take a lot of humility to actually make that change, so I’d love you to speak to that.

Yeah, well I think from the debugger, we pretty quickly - and working on that thing, we just realized, “Hey, there’s a code window here. You should be able to edit it.” And then that pretty quickly morphed into a whole web editor in your browser… Which was a pretty novel idea at the time, I think. And that it would be end-to-end, right? You’re running your application there, you also have your database there, the runtime is there, the editor is there; it’s all-in-one.

And this actually connects to one of the underlying ideas that went into it, that we’re to this day still very passionate about, which I usually call end user programming. So this concept comes from an academic book, from the early ‘90s, which basically looked at things like spreadsheets and said, “Okay, we typically think of programming as this really highly skilled thing, that only a very small number of people in our population can do”, but they’re looking at a lot of examples, like spreadsheets is a good example, where many people can write pretty sophisticated spreadsheets, and they don’t think of themselves as programmers. And there’s a lot of examples of this. One that I always find inspiring, when I was doing that consulting was FileMaker Pro, or Microsoft Access, where you come into some organization, they’re hiring you to build a new, I don’t know, thing to track their warehouse, but you go and you say, “How were you doing it so far? You have this huge warehouse”, and it turns out one person who’s a total non-programmer just used like Visual Basic or something to wire together some monstrosity… But it works, it works really well, and in many cases, it almost works better than software that’s made by professionals, because they know the business. They know their domain, the way that a software engineer can’t, because of course, their brain is filled up with things like SSH keys, and model view controller.

So we really liked this concept, and the end user programming, and just putting it all in one package, particularly with Ruby on Rails, which is such a joyful experience to use. We felt it could make really powerful programming accessible to everyone. And of course, in hindsight, it’s easy to see, and indeed, we did realize somewhat quickly that that was too much for like any one company to bite off, especially then… But that was our vision going into it, and that’s why we thought the web editor would be a key component of this complete runtime. So we didn’t think of deployment as a separate thing. It was just - it’s all one thing.

So there was no deployment. It was just deployed when you were writing the code; it was already deployed, it was already in production then?

Exactly. Well, to start with, you would basically start with a blank – the equivalent of rails new, you would start with a blank app, and you would go into this editor. And at some point, we added a feature where you could import an existing app. But in this case, I think it was like uploading a zip file on a webpage… And we thought of it as like a one-time operation, maybe sometimes someone’s already started an app… We thought of it as like not something people would use a lot, but maybe it’s good to have…

[14:12] And observing user behavior, we pretty quickly saw that some of the stickiest people or some of the heaviest users were people who were not really using a web editor at all. They were using this import page over and over again. So essentially - like, I sometimes call this a folk practice in the product design world, which is the idea of like someone’s using something in a way that’s not really quite how it was intended or it was designed for, but they’re pointing the way towards their true problems. So someone who exactly - as you were describing there earlier - doesn’t really care, or actually explicitly doesn’t want the tools for editing; they already have their local development environment, they like that and they don’t want to change it. But this instant deployment aspect - well, that’s really nice.

Well, who wants to do ops, right? I mean, especially back in these days with Rails; like, I can recall deploying–

Capistrano?

Yeah, I mean, deploying a Rails app was challenging, super-challenging back in 2006-2007 days, whenever you were prototyping and thinking and assuming the future, but getting it wrong, and pivoting, and whatnot… I mean, it was a different world with deploying it back then. Even today it’s still challenging, but back then it was super-challenging. There was nothing.

Yeah. And the discussion in the Ruby community about how to make it easier really centered around the success of PHP, and mod_php, and Apache, for those that are old enough to remember that… And basically, the idea of making a mod Ruby that worked as well as mod_php, so that you can just FTP your Ruby files to the – that was kind of the… I won’t call it quite the state-of-the-art thinking, but that was the big dream. And at the time, we were working on this, and when I see folks talking about this online, I’m like “No, no, no. That is totally a dead end. That’s not where we want to go.” But the only way to express the idea, I think, was by building it.

One thing that actually catalyzed me on the deployment side was - there was a product called, I think it was TextDrive. And I don’t want to pick on them in particular, but I think there was a link from the Ruby on Rails website to this shared host. They said, “This is Rails-specific hosting.” And I can’t even remember what it said, but there was some kind of pitch, that at least in my retroactive, perhaps edited in hindsight memory, said something like “Push button Rails Deployment”, and just instantly, a picture popped into my head of what that would be like. Again, deployment that was sort of as easy and fun and straightforward as rails new, or something like that.

And then I went to try the product, I signed up and became a customer or whatever to it, and they direct you to the, “Here’s how you get started with a Rails app”, and it’s like eight pages of “Okay, install Apache. Now set up your SSH keys. Now…” You know, this kind of just editing config, and all this stuff; like eight pages just to get to the point where you can show that Hello World. And that led me – that contrast between what I pictured when I read the pitch, and what I actually got, which was a huge amount of operations work when I actually signed up for the product was also part of what made me think there was a really important problem to solve here.

Do you recall the era of hosting back then? Since you’re talking about Rails hosting, I recall Engine Yard, Ezra Zygmuntowicz, and this sort of new ground that was being done… I think Rackspace was in the space then, too. I wasn’t really quite sure what Rackspace’s role was, but there was a lot of people vying for being the home of Rails. “Put your Rails app here”, essentially. Do you recall that, or can you talk about that timeframe, since that was essentially the same timeframe of Heroku being born?

Yeah, absolutely. I think the players in, my mind were… You had classic shared hosts, which everyone knew to be – you know, they were cheap, but they were just really kind of… You didn’t have a lot of control, and CPU was bad, and it just wasn’t good for anything other than a really tiny hobby app.

[17:57] And then you had - VPSes were a bit of an emerging thing. Slicehost was another inspiration for us. I had been using Slicehost, one, just because it was a great product, they just did a really good job with it… But they used virtual private servers to make it – basically, slice servers into smaller pieces, to make it more possible to get started with a small app.

I mean, I spent a lot of my time during that consultancy, and actually for the rest of my career - you know, when I wanted to get a new production app spun up, the thing I would do is order a rack mount server, and then it arrives weeks later, I install Linux on it, I physically like put it in the trunk of my car and take it to a colocation facility… This was the state of the – let’s not call it the state of the art, but that was the standard thing to do. And at least a VPS was a step up from it; it was a little bit more on-demand, even though you still had to wait like 24 hours for your thing to be provisioned, or something. But that was lightning fast, and very low effort compared to racking and stacking your own servers.

So certainly Slicehost I think was an influence for us, at least in the relative ease of provisioning something, and the fact that they could cut the servers into smaller pieces. So you’d get the $10 a month one or the $20 a month one; you didn’t have to go straight to the big, beefy server that was probably in the hundreds a month, let alone the upfront cost of buying it.

Then you had Rackspace, which was also in that same kind of business of racking and stacking managed servers, and had some other offerings… I didn’t fully track what they were, but they were traditional hosting, as far as I was concerned.

And then you had EC2 as the new big player, and that also was a piece of the origin story of Heroku. We had been playing with it as part of trying to compete for the Netflix prize. I don’t think we ranked particularly high, but just for fun, we were competing in that, and used EC2 to spin up some compute, and saw that there was something pretty interesting there, for as low-powered and simple as it was at the time… You triangulate that and Slicehost, you see there’s something interesting happening with this whole virtualization thing, even though it’s very kind of toy-like in the moment.

So I think those are the things going on. And then Engine Yard, yeah, was probably, again, also more on the traditional host side of things, but they had a very high degree of Rails and Ruby focus; they employed people who were luminaries in that community, they did a lot of contributions to open source work… So you went with them because they had the expertise. So more like Red Hat, probably would be the closer thing. But ultimately, I think the thing they offered you was - apologies to any engineering people that might be listening, if I’m getting this wrong, but I think it was basically managed hosting, and had this extra layer of “We’re part of the Ruby community, we’re contributing, and also, we’re experts on this. So when you hit challenges with your app, we’re going to be in a really good position to help you.” And notably, the Engine Yard office was down the road from us, and we hung out with them quite a lot, and we were part of the same communities.

We had an app there at one point back when I did consulting, and… Deploying a Rails app was challenging, but then also keeping it in production, which is sort of like still the problem with Ship It, like the podcast we run, Ship It. It’s like, ship it and see what happens, which I believe is one of your philosophies, Adam… But you could speak to that at some point, I’m sure, in your story is… You know, we got it out there in production, but we had issues; we couldn’t keep it up, we had a database issue, so we needed somebody who specialized in Ruby on Rails applications… And sure, if we had it hosted somewhere where it was welcomed, basically, and then also had people behind the scenes who could manage and help us keep our servers up, or help us if there was a database query that was going crazy, or whatever might happen.

You know, one thing was deploying, and one thing was actually hosting it, but then actually keeping it running was a whole different spectrum for Ruby on Rails, because it was newer. So newer people were getting into application development, and deploying an application production, keeping it in production, keeping it running was a whole different world. And being in a place like Engine Yard at the time was very welcoming, to have that managed support behind the scenes.

Yeah, they were awesome for what they did. And remember, this is a time before – the term DevOps didn’t exist, the term cloud didn’t exist… Like, this was a different a different time, right?

[22:04] Just thinking about that timeframe, you brought me back, mentioning EC2, or Slicehouse as well, I was like “I haven’t heard that name in a long time.” Ultimately, I think Rackspace ended up buying Slicehost, and trying to provide some VPS services of their own through that acquisition… But I’m just thinking about all of the things that were burgeoning at this time that Heroku, that you guys started to execute. You had Git and GitHub around the same timeframe, you really had the birth of AWS, specifically the EC2 offering; I believe it was at the end of the 2000s; what do you call them, oughts? I don’t know. Like 2008-ish was EC2. S3 was a couple of years earlier… So you have like the actual – your guys’ access to that ability - you can talk about how you built the platform out, but building Heroku on top of that.

Then you had Ruby on Rails, of course, which had been around for a while, but it was becoming so successful that your potential customer base was exploding, and then the pain of deployment for Rails being kind of the sore thumb of what is otherwise an excellent building experience. There were so many things lining up for you; I’m not trying to take anything away from your execution, but when we talk about reasons why businesses, startups succeed, a lot of it is timing… And you guys were in a very fertile ground to build something like this.

Absolutely. They say “Luck is preparation meets opportunity”, and there was a huge amount of opportunity here. It was a confluence of so many different things; communities, technologies… We happened to be well positioned to take advantage of it, or to do something that contributed, I hope, as well as benefit from all those trends ourselves. And I think this is always an important thing to keep in mind, for anyone in your career; I think of - and I’ve heard YouTubers talk about getting viral hits, and once you get that first thing that goes viral, and you just think, “How do I replicate this? How do I do this again?” and you kind of can’t. It’s really – yeah, it is really just serendipity. But if you keep making good content, the likelihood that you might find that serendipity again is much higher than if you don’t. And I think it’s the same thing for any kind of creator, whether you’re a software builder, a company builder, whatever it is. I think it’s good to take pride for yourself in your execution of the idea, and hopefully spot good ideas, but ultimately, there is a huge amount of things that - I don’t know, I could sit here and say, “Boy, weren’t we prescient that we saw all these opportunities and took advantage of them?” And some of it was that, but honestly, a lot of it was just following our nose and building the thing we believed should exist in the world, and then we happen to get very lucky with all those things coming together at that time.

Yeah, I was talking about that too with just the command git push heroku master, like how ingrained that is into our brain, in terms of like the apex of DX, and just how that simplicity was like “I can get an app– all things aligned, I get the app into production with Heroku”, given that, like, GitHub being a thing, and Git being a thing, and just all these things happening at once… It’s a good time to be solving that problem, I would say.

Yeah, for sure. Yeah, well, I guess coming back to that timing of that first year, you asked about the pivot, there’s the Git and GitHub piece of the story as well… If you put it all together, you end up with this thing where, you know, we had been working on this open source project on the side, went to RailsConf, felt like we really wanted to make that a business, also had been reading Paul Graham’s essays… Y Combinator was not very well known at the time, but we kind of felt like maybe we should move to San Francisco and do this YC thing. We did end up doing that, joined in the winter 2008 batch… And then it was shortly after that that we raised money, and shortly after that that we realized that our core product of the web editor, while sort of impressive, wasn’t really sticky, and we needed to pivot to this platform.

So all of this happened between – I don’t know, RailsConf was in like the summer, late summer of 2007, we were in YC in 2008, and then we started to work on this pivot sometime in mid-2008.

[26:11] And coincidentally, or not coincidentally, around that time was when we had started to experiment with what an API would look like, and I sort of ended up doing this essentially as a – I wouldn’t call it a side project exactly, but it didn’t seem to be related to the main development of the product. I just had this idea that we could make a command line tool that you could install with Ruby gems, so gem install heroku, and that furthermore, that we could integrate to your version control, because it’s already the case that you want to ship changes to your host. And uploading a whole zip file of your entire app every time, as we were doing through our import panel, obviously didn’t seem to make sense. I thought, “Well, you’re already in your version control.” And I actually did build the first version using Subversion, because that was what was popular at the time, but it really didn’t work. There were just so many ways that the centralized revision control just didn’t fit together with the vision I had in my mind.

And I’d gotten interested in decentralized revision control previously, and I said, “Well, let me let me see if I can make this work with Git”, and that just fit beautifully; completely beautifully. But I remember having a debate with my partners at the time, which is like “No one uses us. What is the point of integrating to a thing that no one uses?” He said, “Well, I don’t know, it seems like it’s getting more popular. Maybe they can use it – because you can use it alongside Subversion if you really want to, and you can just use it for shipping changes…” And anyways, we debated that quite a bit.

But anyways, this Ruby gem, that gave you this Heroku command line tool, and the publishing things with Git - that was just a weird thing on the side that existed for quite a while, and wasn’t part of the main product, and not even that many people used. So it was kind of just a little experiment, sitting off to the side.

And the Git thing ended up being also, again, coming back to that timing thing, ended up being quite good, in the sense that that’s when I met Chris Wanstrath and some of the other GitHub founders, and they had basically just started on this project, and they said, “We think Git’s really exciting. We want to make a painless way to host it.” And yeah, I ended up getting to try out their early product. Actually, I think we were in Engine Yard’s office in South Park, so it was… They basically said, “Hey, I’m working on this Git hosting project; I see you’re using Git… Do you want to put some projects on our thing?” I said, “Yeah, sure. Why not?” and I was kind of explaining what we were doing. And so again, very, very serendipitous, but in no way did it seem strategic, in the sense of “Here’s what developers are using.” We were just drawn to this different way of doing things.

That’s exactly how Chris describes he and Tom’s initiation of GitHub; they were in a bar, it was serendipity. It was like, “Hey, I’ve got this Git web interface thing I’m working on, and I’ve got this thing over here”, and they kind of combined the things to create GitHub, essentially, which you probably know this… But it’s funny how both of these stories, which are like, you know, pivotal; so many folks’ ability to 1) collaborate on code, and open source code, and find and create community, and now with the commercialization of open source projects becoming products and companies, building companies… But then also being able to host their applications with Heroku, and ship and stuff like that. It’s just crazy how both of your stories is essentially steeped in serendipity.

And I think San Francisco at that time also helped create that serendipity. I can’t speak to today, I don’t live there anymore, but the fact that there was this very tight-knit Ruby community… We would meet for – there was a little meetup group called ‘I Can Has Ruby’ lots of great folks were there. I saw a demo of New Relic by the founder the first time there… And yeah, it was like a really small, tight-knit community, you would run into these folks on the street, everybody’s offices or whatever were all right near each other… And so there was this incredible concentration of people that were really like-minded, and that also, I think, had a lot to do with why so many things came out of that time and place.

So let’s go back to what you presented to Y Combinator then. So what you presented to get into the summer of 2008’s batch was the IDE. And then through the process of Y Combinator you found out that that was the wrong direction. What were some of the indicators that that was the wrong direction? Was it feedback from the newfound support in Paul Graham and others that come along with Y Combinator, or was it feedback from customers, or would-be customers? How did you get to like “This is the wrong direction”, the thing you were building on the side with the CLI and the platform, this was a better angle, or “This is the direction we should go”?

Yeah, the pitch we used for YC was FileMaker Pro for the web. That was really that kind of end user programming, FileMaker Pro, and citizen developer concept. And I don’t think that it was being in that program that helped us recognize or decide to make the pivot, the value. I think what we got out of the program was more around access to and information about venture funding, as well as maybe much more general advice for how to run your company, and how to scale up over time… Probably there was some sense of recognizing product-market fit, and what that even meant, and realizing that we had all this enthusiasm… And even if you looked at basic metrics, like active users, they seemed like they were going up, but if you looked more closely, you saw that people didn’t really stick around. They would try it, be enthusiastic for a little while, and then kind of drop off. And that’s, of course, a sign that people were excited for the concept, but it didn’t really stick with them.

So yeah, I think we had I think the sequence was we were in YC, we ended up raising a series A, which back in those days a series A it was a lot less money than it probably is today, before the program was ever over… So we didn’t even do the demo day experience, which is sort of too bad. I feel like maybe I missed something in that case.

And then of course, we had this money, and we could start hiring, and so forth… So there’s – and this is a place where I think having money in the bank that sometimes prevents you from focusing, or you’re thinking more in terms of expansion of what you’re currently doing, rather than changing… But yes, somehow it just really penetrated our collective consciousness. I’d be hard pressed to say exactly how that on one hand you had the people that were using the deployment part of the product, whether it was through this import form, whether it was through a command line and a Git API-ish thing we added on the side, that those people were doing more serious things, that even though we weren’t charging money yet, they were the sort of people that were more willing to pay, and that represented a better direction for us than the citizen developer direction… Which - that side of things would be very good for people, for example, learning to program. And again, I think if you look at something like Replit, that was at least a lot of their starting place maybe, was making it easier for people to get started. But given that we had taken venture money in, and given what our goals were… Our goal was to make citizen developers, which is not quite the same as someone who wants to learn to program for its own sake, if that makes sense.

So yeah, I guess we just sort of followed the energy, we followed what our users seemed to be saying was the valuable part of the product. And eventually, that did lead to this pivot, which I think finally we did execute and launch that towards the end of 2008… And there were some things that were painful about that. We loved the editor, there was a lot of people that did love the editor, and we were cutting something away; there was something lost there, in the sense that we were exposing a lower level of infrastructure than we really wanted to do… But we also knew it was the right thing. And certainly, right after launch seeing the way that things picked up in terms of the sense that we had truly found a sticky product made it really clear it was the right move.

[35:48] Quick tangent… The source code for that editor - where does it exist, as part A, today, if it does at all? And B, do you think you could get it running today?

[laughs] That’d be a fun exercise…

Two very good questions… I would only imagine that they are somewhere in – because we ourselves switched from Subversion to Git, I remember, around the same time that I was doing the integration. So the various earliest versions would have been in our Subversion repositories, which are, I’m guessing, probably lost to the dustbin of histories… But it’s quite likely, I think, that some of the later versions of the editor would actually still be in the Git history for the applications that make Heroku today. I don’t know, it’s been 10 years, so I don’t know, maybe all of the codebases have been cycled out in exchange for new or different components… But somewhere in there, there’s probably a code repo.

Getting it running - that’s interesting… It seems likely, but it also did rely on a lot of hacky kind of system-type integrations, like shelling out to do system things that were sort of way outside the realm of just the normal application… So it was a Rails app itself, of course, and that stuff was way outside the realm of – we broke all the rules of the system… So I’m guessing it would be a big project to bring that one back.

That’d be an awesome PhD thesis, or something… Like, if somebody had access to the source code, like archaeologists, and then bringing it back would be really cool.

Yeah, it makes me think of these – the digital preservationists that work at archive.org and other places to try to, for example, get old video games running, or whatever.

So let’s take one step down in fidelity. Are there any screenshots out there? Are they available on the Wayback Machine, or somewhere where we could like –

Yes, you can definitely find that on –

It’d be cool to compare it to like today’s VS Code-based web things, or Replit, Glitch… They’re a dime a dozen. no offense y’all… But there’s a lot of them today. I don’t mean that to belittle them. There’s a bunch of them today, but that was over 10 years ago. It’d be cool to see what it looked like.

Yeah. So here’s a TechCrunch article from the launch. I think this was back when every company that went through YC was news, and deserved its own TechCrunch article… So yeah, “Heroku lifts Ruby on Rails development into the cloud”, February 7th, 2008. That’s got a little – actually, a decent quality screenshot there, of the web editor.

So git push heroku… This started off as a side project in the CLI, and quickly at some point became kind of the de facto way of deploying. And at this point, as Adam said earlier, is - at this point, still, I think, the best developer experience for deploying code in 2022. People are replicating it, or trying to… Sometimes you get two steps, sometimes you get one, but I’m curious, from the point that you built that… Conceptually, after the innovation was done - maybe you didn’t know it yet, but that, I think, accomplishing that, from my perspective, is why I wanted to use Heroku all the time. Once I did that once, I was like, “Why would I go back to VPS’es, ever, if I can just do this?” And I think that’s probably what most people thought, that became your regular customer.

So I think the innovation was done, but like the tech to accomplish that… We were talking about your serendipity, and the fact that you were at the right place, at the right time… We’ve taken away a lot of your effort, because y’all invented a bunch of tech… I remember there was like this routing mesh, there was like a lot of blog posts coming out, there were various programming languages that you were using… I think maybe Erlang, and then Go was something you guys talked about a lot… So you guys were very much pushing the edges of the Ruby community into these new and weird and interesting places to accomplish Git-based push deployments. So dive into the tech a little bit. Go nerdy with us, and talk about all that you had to build in order to actually accomplish that developer experience.

Yeah, there’s a lot to it. And I don’t think at any point we thought that these innovations, or inventions, or whatever you want to call them, that any one of them was particularly meaty, like the sort of thing you would write a computer science PhD on, or something like that. Most of them were hooking into the operating system.

[40:10] It probably helped that, on one hand, we were application developers, and so we sort of knew what application developers wanted, which a lot of times infrastructure engineers, I would say, struggle to understand that. At the same time, we had enough experience - and in particular, I had done, and one of my colleagues, had done quite a lot with Unix. I’m a big, longtime, lifelong lover of sort of Unix, and the Unix philosophy, and small, sharp tools, composability, pipelines, all that sort of thing… And in past business ventures had used various things, something like inetd to spawn off little processes, and had done a lot of socket programming back in my college days when I ran a MUD. So a lot of these system-level technologies that maybe application developers wouldn’t normally have much use for, were things that I just enjoyed working with, or I had done things on in the past for random reasons… And we were able to put a lot of those together.

So quite a lot of what we were doing in terms of spawning off processes and managing those proxies - we were able to use a lot of the default Unix system tools… And we were warping them in probably a little bit of weird ways, but we were able to get a lot of it done without necessarily needing to write a kernel patch, or something like that. So we had this user-facing interface that could be a Rails app, or even the API, once there was a command line… It was just a REST API, and stored stuff in a Postgres database, and so on. But then when it came to actually managing the processes, the user processes, the user databases, and that sort of thing, then we could use a lot of those default Unix tools, and put those together.

Now, the routing mesh is a very interesting one. So the story here is that we started by using - I guess Apache, which was the gold standard at the time, as (call it) the load balancer; it’s probably a strong word for it, but you know, when traffic comes into the… And back then, all of the apps were just on something.heroku.com. So when traffic comes into start.heroku.com, we would figure out how to route that. And the way we did that was to rewrite httpd.conf every single time a user process started or stopped, and then restart the process. That didn’t work at all for Apache. That’s when we discovered NGINX, which had a SIGHUP signal that basically said “Reload the state from the config and reconfigure it yourself.” And it was very, very good about finishing all the current connections before it brought up new connections. So things wouldn’t get like interrupted in a weird way.

Now, I think this kind of dynamically writing the config file, and doing the SIGHUP thing, that worked up until the point where you’ve got a few hundred in there, and then a few thousand, and then you’re doing it a few times a minute, and then eventually you’re doing it a few times a second… And we did actually get to the point where I had to write a C module for NGINX, that would basically maintain the routing table in memory, and be able to do this more dynamically, because just the – we just reached the limit of what we could do with the tool this way. And actually, that was my RailsConf talk in 2008, I believe, was writing a C module for NGINX to do dynamic routing… One which I don’t think was very well received, because I think writing C is not that interesting to a bunch of Ruby application developers… Which maybe shows you how far off the edges of the – how far off the defend we had gone, which in the end did turn out to be a good exploration, but… And then even that didn’t – at some point, we hit the limits of what that could do, and I and a couple of my colleagues, including Blake Mizerany, the inventor of Sinatra, he had come to work at Heroku, and he kind of came to the same conclusion I think I did… Or we sort of simultaneously realized the same thing, which is, “We really just need to write our own load balancer.”

[44:08] I think we maybe had started experimenting with HAProxy, but even that wasn’t going to do the trick. Just, no one had tried to do what we were doing before, running thousands of processes where they’re constantly dynamically reconfiguring themselves. And that made us kind of realize we need to write our own HTTP frontend.

And actually, this was such a radical idea that we actually had someone quit on our team, where are they basically – basically, it was someone that was more from the operations background, they said, “Let me get this right… You think that you want to replace one of the most battle-tested and important pieces of the web stack with your own custom written code? This is the worst case of Not Invented Here I’ve ever heard in my life. Like, I’m out of here.” [laughs]

Wow.

Which was fair. And again, it could have been one of these just incredible yak shaves that didn’t provide real value, but it did turn out to be the keystone piece of making it possible to dynamically bring up and down these processes, which we had since decided called dynos. Nowadays we would say containers, but of course, that whole concept of containerization didn’t exist at all back then.

And so the idea that you would bring those up and down dynamically, and they would be able to just sort of like speak to some load balancing layer, so that they could be discovered on the network by inbound traffic, and then managing the traffic so that it looks like one single seamless application behind one domain name, but going out to all these sort of like dynamically-provisioned processes - that turned out to be the piece of magic technology. And I think eventually others replicated that, but for a little while, that was probably a pretty unique invention that we had in our arsenal.

Dynos… That makes me think about the Heroku style. So Adam, you can probably speak to this - Adam Stacoviak; namespace conflict… In addition to all these things that we’re talking about, there was something about Heroku that was just cool. I mean, the name was cool, you had the whole Japanese thing going, the purple, the samurai… I remember the automated app names that you guys would generate were all poetic…

Haiku names…

Yeah. And there was just something – it had taste, and…

Style, for sure.

Yeah, there was a style to it, that just made it like “Oh, these guys know what they’re doing, because they even sweat these details”, or something. I don’t know what it is. Maybe speak to the style, maybe the Japanese influence… I don’t know, where did that all come from, and how did it coalesce so well?

Yeah, well, first of all, thank you. That was certainly something we did very consciously going into the business of what I knew was – we always wrestled with the term hosting, even though you could argue that’s what it was; or it was a new kind of hosting. Actually, our very first website, which you probably can pull up with the Internet Archive, our tagline was “Hosting is obsolete.” This was part of a debate we had, which was - I said we’ve got to mention hosting, because that’s clearly the category we’re in. And my colleague, James, basically said, “No, I want to like draw a clear delineation between – in the same way that like an iPhone is not a computer, Heroku is not hosting it.” I said “Yeah, but you run your app there.” So this was the compromise we arrived at, was we sort of like positioned it as sort of not that.

But additionally, I think in thinking about infrastructure of any kind, you instantly think of stuff that’s kind of stodgy, boring, clunky, annoying… I don’t know, you think of all that enterprise software we’ve ever used; hosting in general, whether it’s low-end, like shared hosts, but even high-end, like managed servers, it’s rarely cool, or slick, or has a good user experience, or anything like that. And so we had basically – it wasn’t even an idea, in the sense of “This is how we should build our business.” It was more like “That’s not how we like to do things. We like style.” And if we were making, I don’t know, a consumer product or something, you would be like “Yeah, of course, you have a brand, you have a style, you try to make it cool…” That’s the thing companies do. But it wasn’t a thing companies do that were building hosting, or developer tools, or anything like that. And so I think that ended up, in a way, being sort of an innovation, and again, one that others simultaneously at that same time were discovering - GitHub, Twilio, New Relic… Many of our contemporaries I think did a similar thing, which is user experience, design, a sense of visual flair, a brand that’s not just completely practical, that’s worth doing.

[48:28] And my basic thinking on that, kind of post-hoc rationalization, is “Developers are people, too. Developers like stuff to be slick, and look nice, and feel nice, and have good user experience, and look good, so why do we always have to behave like it has to be just completely utilitarian?”

The name is amazing, too. I mean, the name is part of the style. Heroku is a cool name. I mean, nothing against Slicehost, or Engine Yard. Those are cool names, too. But Heroku is a cool name.

Well, thank you. I actually think Engine Yard is a great name, and especially in tandem with their logo, and their connection to the Rails community… That makes them a way cooler name than most hosts; you know, Dream Host, and Slicehost, and Rackspace, so just these very pragmatic, just kind of like “Does what it says/Says what it does” kind of thing.

Yeah, so the Japanese influence is 100% from Ruby’s Japanese origins, and I’m happy to say that – there is a way that could have gone badly, borrowing from a culture that you don’t… Even though we’ve been to Japan, and we like a lot of things about the culture there; I think a lot of nerdy folks are drawn to some of that culture’s history. But we’re not Japanese people, we’re Americans, and there’s a lot of ways that maybe could have gone wrong. I was happy to say that many years later, when we did get to hire Yukihiro Matsumoto, and basically was able to put the question to him directly… Actually, he asked me first; he was like “Heroku - it sounds Japanese, but I don’t know what it means.” I’m like “Okay, well, that’s… That’s good.” There’s one version where it doesn’t sound Japanese, and then we sort of failed on that front, and there’s another version where it means something that doesn’t make sense. And we did put some effort into talking to Japanese speakers, and making sure that it would be a name that made sense.

But actually, the name came from a combination of the qualities that we wanted to bring across… And it was sort of a portmanteau or some kind of a mashing together of heroic and haiku. And haiku, again, reflected Ruby’s Japanese origins, the fact that it was a very succinct language, very elegant, or from our perspective elegant, beautiful language, in the sense of how it looks on page, so to speak. And then the heroic side - this has often been misinterpreted; there was so many articles on “Heroku’s trying to be a hero”, or something of that nature. But our view is we want to make a product that makes you a hero. And we were calling back to our experience as consultants, which is if you’re someone that goes in and builds a piece of software that helps a business, or helps your client do what they do – in many cases, they usually call the consultants too late, and everything’s on fire already anyways, and whatever… And so if you do that well, you’re a hero; you feel like a hero, you are a hero for that business. And so we wanted to make something that would be a tool to help you be heroic, especially combined with that early end user programming/citizen developer vision that we only partially fulfilled, I’d say.

Yeah. Well, congratulations on mashing those two together so well, because - I mean, it seems Japanese, and thanks to Matz for clarifying whether it is or it isn’t, and at least giving you the credibility of having the creator of Ruby on your team… What more significance could you have besides Matz on your team? It’s been a while since we’ve talked to Matz. We’ve talked to Matz for Ruby’s 10-year anniversary… Wasn’t it, Jerod, 10 years of Ruby? 11, maybe 12… I don’t know, it was an off year. I think we wanted 10 years, but we couldn’t make it happen.

It was like some off number, like 12 years of Ruby. No, it had to be like 23 years of Ruby… I don’t know what it was.

[52:06] Yeah…

Yeah, he’s been at it a while…

Yeah… It was a while back.

Very well done, though. Very well done.

Yeah, so I guess there’s a juxtaposition then that just kind of strikes me… Which is all that you’ve just described of the name Heroku, plus the style that we’ve been talking about, the way you guys have a perspective, and you put it out there, and it’s very intentional, and polished… And then Salesforce, which - Salesforce, even the name Salesforce, it’s very much like saying Slicehouse. It’s like, “Well, we’re going to provide your sales force with Salesforce software.” So the sale to Salesforce came pretty quick. Looking back on history, 2008 was the time that we’re all talking about, the time of that Crunch article; then you had the pivot from there… And then you have 2010, according to Wikipedia, Salesforce. Tell us the story of Salesforce and the sale of Salesforce.

Yeah, sure. So briefly, the timeline there was 2007, let’s say RailsConf was kind of inception, 2008 was Y Combinator, and then later that year was the pivot into the platform… And then we had the various stacks - them Aspen, Bamboo, and then Cedar, which actually came after we had already been acquired. And the acquisition to Salesforce I think was announced in December of 2010; so depending on how you count that, it’s three, three-and-a-half years.

In some ways, for me, I count the journey somewhat including some of the earlier work we had done on the open source project… But yeah, depending on – let’s say it’s three, three years and change, which obviously, is very quick by most standards.

Yeah, that’s a rocket ship right there, just taking off… And then landing at Salesforce. So from just a pure business perspective, that’s a Grand Slam, right? Like, you spent a few years, you innovated, great timing, great style…

And an amazing multiple on the dollars in, right? 13 million… That’s nothing in today’s dollars.

Yeah. And of course – so the acquisition, officially, 212 million…

In cash…

Yeah, that’s 2010 dollars. That’s not 2022 dollars. So nowadays, we’re like “Hah! Figma, 20 billion. 212 million is for pikers.”

Adam’s like “I should have waited…!” [laughs]

Yeah… But we’re talking about the world in 2010. A massive success, by any measurement… And how did it come together? And then how did you back then reckon with selling this thing you’d been sweating over…? Of course, you stayed on, so there’s more to the story, but… Take us back.

Yeah, so most of the credit for putting that deal together goes to my colleague, James Lindenbaum, as well as Byron Sebastian, who we’d hired as an outside CEO, and great guy, that I now count as a friend… So they put the deal together while I was sort of heads down in product development. But really, what happened was once we started to have this buzz that came with both the sticky product that was expanding in the Ruby community, and also just making waves broadly in the developer world, and at the same time, you had – as you said, all those trends were really just on the up and up and up. Cloud was becoming a very, very hot space, and we had seemed… We weren’t getting into this business because we thought we were starting a cloud company, but indeed, people would lump us as one of the seminal sort of cloud companies. Something similar for - not necessarily Ruby as much, but maybe kind of startups, and companies practicing agile development, and developer tools, and developer experience, which is a term that I’m not sure if we’ve coined it, but we’ve certainly helped popularize it… And yeah, again, those other companies I mentioned, like GitHub, and Twilio, and New Relic. So there was just this huge lift in the market, and then we had - yeah, the timing was just right that we were a big part of the conversation there.

[56:09] So pretty early in the company, we started getting acquisition offers. And I didn’t really know how to think about those, because I hadn’t ever been – even though I’d been a business owner in the past, I’d never been a venture-backed business owner… And yeah, I just didn’t know how to think about it when, for example, Amazon came knocking, and basically said, “Maybe we’d like to buy you, and how does (I don’t know what they said) 30 million bucks sound?” something like that. And it’s just - I didn’t even know how to think about that, and certainly what would that mean for me, my partners, our investors, our employees… “Should we even think about this seriously? We’ve barely even gotten started on the product development, but boy, that sounds like a lot of money, maybe we should at least talk to them… I don’t know…”

So there was a number of these kinds of opportunities that kind of came across our desks, so to speak, and mostly my colleagues there that I mentioned, would engage with that in good faith, because… I don’t know, I guess you should do that probably.

And one that actually went very far was VMware. So we actually were pretty far in the – I don’t know if it was due diligence, or something like that. I think we had a letter of intent. So we were pretty seriously planning to join VMware. Hopefully, it’s been long enough now. I think the NDA has a statute of limitations or whatever, but the price there was 70 million that they were going to buy us for. And this was two, two-and-a-half years in. So that was just - as you said, even that was a huge multiple. And I did see it as, okay – VMware was a company I really respected, and I liked all the people I met there, I like their brand, even though they are much more pragmatic sort of like infrastructure software. But I saw it as like, okay, as we had gotten further and further in this business, and especially once we went all-in on the platform, where the deployment side was important, there was this huge component of infrastructure… And a lot of that was about things like virtual machines, and Zen instances, and stuff like that. And I said, “This isn’t really what I got in it for, and we need to build this expertise on our team”, and we were indeed doing that, and hiring people, and just learned it ourselves as we went, and so forth… But I just saw that as being potentially a really good fit, in the sense that they had that expertise, and we could be the ones that were on the developer experience, application focus, in touch with these kinds of current cutting edge application development practices, like decentralized revision control, and so forth.

So it seemed like a really good fit… And oh, by the way, everyone involved would get rich out of this, right? Obviously, of course, you think about yourself, but also all of our employees, many of whom were – this would be really life-changing for them. Also, the investors who had believed in us. Also Y Combinator, which at the time was an unproven thing.

So I wanted to find a good home for the business to continue what I was doing, and indeed, the way that we thought about it a little bit is – it’s not that different from taking venture capital. You’re getting another source of funding that comes with it, and of course, all sources of funding comes with strings attached. This will come with some strings attached, but it also comes with some real strategic benefits.

So we were pretty far in that discussion, and I think I was ambivalent about it. I didn’t know what to expect from it. I saw a lot of ways it could go wrong, and most of all, I was not done at all building the product. I had way more to say, particularly around what we were calling the polyglot platform, being able to deploy languages other than Ruby, and so forth. So I was really trepidatious about that being interrupted by something like an acquisition like this. But I also saw all the benefits that potentially were there.

[59:49] So that was a VMware deal… And that was eventually interrupted by one of our investors, Steve Anderson, who basically came to our office one day and pulled us into a room and basically said, “You know what? I think this is too cheap.” And we’re looking at him like “He’s crazy, because –” I mean, $70 million… I couldn’t even fathom that number. I don’t know, maybe – again, maybe Silicon Valley these days is just full of like eye-popping numbers if you’ve been around in that, but I’m just some kid from Los Angeles, I’ve started a lot of businesses, but most of them I’m lucky if they get into the millions in ARR, at best. And so just these eye-popping numbers, and him saying “No, there’s more potential here. You’ve gotta hold out” was quite striking. But he was really passionate about it, he made a good case for it, and we basically put together a new financing round that would let us let us continue independently.

That was your series B in 2010 then. Is that what you’re talking about, your series B in 2010?

Yeah… So I think, if I’m remembering it right - and again, you’ll forgive my hazy memory here, but I think it was something like early 2010 is when we were talking about VMware; we ended up doing the series B in mid-2010, and then the Salesforce acquisition came.

So essentially, what happened was not all that long after that, Salesforce showed up… So there’s another acquisition offer that’s on the table, but now the number there is way higher. And the reality is, yeah, the higher the number is, the more you should really listen.

[laughs] Yes…

And indeed, the number they put on the table got our attention, to at least open the conversation.

I’ve never been in that position, obviously, because I have not built Heroku, and I did not have it acquired by $212 million in cash by Salesforce in 2010… But you know, considering what you’ve done in your career, I just wonder – obviously, you’re rich, and you’ve made some good money, and people around you got rich too, so that’s part of the positively version of fallout of this acquisition and this direction. But do you have any regrets with that? Do you feel like, given where Heroku is at now, the potential that you put into it and has been in it, and some would say even the lack of innovation from Salesforce… And I’m not belittling anybody’s work there, because I know a lot of people inside of Heroku that have done amazing work. I’m not trying to say negatively whatsoever about the work… But like, you’re a specific co-founder of this thing, a CTO, your baby… I guess Jerod’s question was coming from that direction, like - can you describe the story around selling your baby, essentially? Do you have any regrets? Like, was there any, like, “Man–” In hindsight, today’s dollars, that’s not a lot of money in comparison; let’s say Figma, for example, as a comp… Is there any regret to this decision?

Selling your baby is a good metaphor… It’s really hard to – right on the surface, I would say not really a ton of regret. Maybe some vague – you know, you always think about the road not taken… But I do think it’s important to compare to what were the other possible outcomes, right? So put aside acquisition… Let’s say we went IPO, or something like that. My piece in this was – I guess I’m a zero to one guy, and so I’m always interested in those earliest days… And in particular, I guess I think of like building companies as sort of my art… It’s not quite like painting a painting, but I usually have something specific to say. And once I’ve said that, I don’t have as much to contribute, if that makes sense… And so one of the things that was scary for me in considering any of these acquisition opportunities, including the Salesforce offer, was I knew I still had a lot more to say. And it was the following year, in 2011, was when we delivered the Cedar stack, which allowed you to run multiple languages, and added the workers, and the logging, and all the things that to me were what kind of completed the vision for the platform… And it was also when I published the Twelve-factor App, which was kind of the companion piece that sort of explained the philosophy of the platform.

And I knew that I was – I was working actively on that stuff, and I thought “If this acquisition disrupts that, for me, that wouldn’t be worth any amount of money.” Now, there’s many other people who need to be considered here in my wanting to paint my painting thing. It’s not the only consideration when you’re making hard-nosed business decisions. But for me, that would have been a real disaster. And that’s not what happened at all. We were able to continue to execute, and indeed, we were able to actually get help from Salesforce, and particularly their Java team… Some folks on their side, who were really good with Java, came over and helped us with some of those parts of the platform, and it was actually a real boon to us.

And the Salesforce name opened a lot of doors, basically enterprise sales, that we had been trying to get into… Basically, our sales folks had been kind of like knocking on the door, trying to close deals for a while, and that suddenly greased a lot of wheels. So at least in the short term, let’s talk about the first year or two after, I felt like I saw a lot of really positive effects. So if you’d asked me then, I would have been very, very positive. And that’s totally aside from the financial impact.

When you fast-forward longer, and you say, “Okay, 10 years later is Heroku not doing as much innovation-wise as we did in the very early days” - that’s probably true. But in any circumstance, including going into an IPO or something, I probably would have finished what I had to say around the same time anyways. And so would the organization – and maybe this points to failings as me as a founder, or others there that we didn’t build something a little more able to weather. Go to, for example, become a public company, and keep that spirit of innovation… Which honestly, is a very, very hard thing to do. I don’t think a lot of companies manage to do that. So that could have pointed to something else.

But yeah, is the Heroku as a public company - I’m not there either way. What would that have looked like? Would it have been better or worse than what we can see in the Salesforce path? It’s really hard to say. But my instinctive feeling is I’m not sure that that would be better. And for me also, the biggest single thing is just “Is Heroku still a product I want to use today?” And it is. I’m running my current business on it, and I’m so thankful.

Wow.

It does exactly what I need it to do, and all these years later, it works really well. And you can talk about innovation or whatever, but in many cases, what customers want is not innovation; what they want is a product that solves their problem and continues to work well and reliably over the long-term.

Stability, yeah. They want a stable platform, a stable product. I ask you that because we have to ask you that, right? Because, like Jerod’s question, it seemed from the outside - and by no means am I saying this the case; it seemed premature in terms of an acquisition. It seemed early in its career.

In retrospect.

[01:09:43.08] Right, in retrospect. Because you were so early in the game; you were only a few years in. Like, was that good timing? And we don’t know. And that’s truly a true question, because only you can speak to that year, year-and-a-half, as you said. Like, if you weren’t able to deliver seed, or if you weren’t able to deliver Twelve-factor App, and those details; like that have been crushing to you, and so not worth it to you, regardless of the amount of money. But you were able to, and you were able to stay there for three more years. roughly, I think, from what I understand from your history… And accomplish your mission, and do what you want to do. And step aside, which - we did say this is a two-part show, so we’ve barely scratched the surface of Heroku and some of your journey there… But after that, you went to Germany, you’re still in Germany now… Like, this has been many years later; there’s so much more to your story than what we’re covering now. But in hindsight, it seemed early.

It was very early, yeah. For sure. And making the decision to do it then came with this huge risk that it would be this interruption, and this distraction, and would keep us from delivering on the promise of the business. And of course, that would have been greatly to Salesforce’s detriment as well, because they were paying for what we could become in the future, not what we were at the time. And the fact that those first couple of years did work out so amazingly well. So again, it’s hard to see a better path through – it’s hard to imagine things having gone better through some other path in terms of staying dependent, a different acquirer etc. Again, what comes after that… It’s really hard for me to speculate about –

I did, a couple of years ago - I think I saw a news article of New Relic going public, and the same fellow that I knew from that Ruby community gets to go into the stock exchange and ring the bell, or whatever, and kind of the feeling like “Oh, that might have been cool.” On the other hand, I know people who either run, or are high up the chain in public companies, and I know that that comes with all kinds of weighty business building stuff that is, I think, important for if you want to build a large and enduring company… But for me, again, I’m that zero to one product guy, and so for me, the way that we did it kind of served my purposes well.

I just wonder if it was delayed three years, and instead of millions, it was billions. Because that’s what happened with GitHub. Like if you’re in the era of GitHub - GitHub was roughly the same time of inception; obviously, that number, like $7.5 billion from Microsoft… I just wonder if like a three to five-year delay on the acquisition would have been billions versus millions.

Okay, yeah, so if thinking just purely in terms of like financial outcomes here… And again, you have a fiduciary duty to do this. So I can sit here and say, “Oh, I’m an artist, so I want to pick the best home for my baby.” But in the end, you’ve taken investor money; your job is to maximize returns for them. And again, early employees had that same element; they’d taken stock options, lower salaries than they might get otherwise, believed in something, etc. So it is not just a legal obligation, but I think a moral one to try to do well to maximize that return. So from that perspective, would have waiting three years or five years been able to get like a GitHub-style outcome? Yeah, maybe.

I’d say for sure, from the outside. I’d say for sure. From the outside it’s a guarantee, Adam.

Assuming they could survived that long, right? So you have all these infrastructure costs…

That’s true…

I mean, your AWS bills had to be just astronomical, right?

I think risk and time-value of money are two things… The 200-some odd million cash-in-hand today is quite different from hypothetical billions years down the road. And of course, startups, and doing any kind of venture is all about taking calculated risks, and what can – you know, do you let it ride, or you cash in your chips now? But in this case, that was part of the calculation, was saying, “Look, when we’ve kind of gamed out a little –” Again, we, the more business-savvy people on the team, my more business-savvy colleagues basically gamed it out and said, “Okay, even if you figure there’s a 30% chance of an N-billion-dollar acquisition four years from now… Okay, who actually are the acquires that could do that?” And again, here we’re talking about an earlier time. Microsoft was not in this acquisitive state back then; it would have been probably like IBM, or SAP. Those were the only kinds of companies that would have been able to afford us. Are any of those better than Salesforce, in the sense of being a good home?

[01:14:23.17] And vibe-wise, you see, where Salesforce doesn’t quite match up with the sleek Japanese thing, but there is a lot of reasons why the companies were similar in values, right? Salesforce was basically the original cloud company, right? They didn’t believe in on-premise software; they believed you should move everything to the cloud. Similarly, they invented like the term platform-as-a-service, which we eventually adopted as the name for sort of the category we were in.

So there was a lot of reasons to think they would be a good a good home for us. So that, combined with these much more kind of just pragmatic calculations of “Okay, this much money in our pocket for sure right now, our collective pockets, versus the potential longer term.”

But yeah, I don’t know… Again, you play the counterfactual, and… And again, if I do have any regret, I think it is “What were those roads not traveled?” For me it’s not about “Oh, we’re having an exit that is counted in billions versus millions on my CV.” I don’t really care that much about that. It’s more about impact, and making something that makes the world a better place, I hope, and shares some ideas that are important to me about, in this case, how I think software development and deployment should work.

Yeah, I think if people want to hear more of your voice on this front, they could probably read your series called “Making computers better”, which I have only touched in a little bit, but I think from what I’ve read of it so far, a lot of what you’re saying here right now is embodied in - I think there’s like eight parts to that, roughly. And I think it’s a great read. Somebody should go check it out; we’ll put in the show notes. But I’m a few chapters into it, and leapt through most of them, because I’m preparing for our call, and all that good stuff.

So I like the way you think about it… I appreciate you letting us ask you these hard questions too on those hypotheticals… Because we’re not trying to attack you, by any means, like your choices, but more like just “What do you go through to think through that stuff?” Like, these are hard decisions; acquire early or wait later, that risk… I mean, only you and your team, and the people who work with you closely can express the anxiety of those decisions. And we get to wait ten years and ask you about them.

Yeah, the process of thinking through that is – I mean, there were so many things that were singular about that experience… Being in YC early, coming and discovering Silicon Valley, being part of the Ruby community in this golden time, many, many other things as well… But how to think about the existential question of an acquisition opportunity like this, including from these companies that in many cases I respected a lot, where the numbers were just bigger than I could even just reason about… And how do you even think about that at all? It sounds – well, it certainly sounds like a champagne problem, but honestly, it’s a lot of responsibility. It’s hard to think about, and you can’t – there’s a lot of secrecy around these things. I think in the case of the Salesforce acquisition there was only a very small number of people that knew about it; even most of the people on the team didn’t find out about it until like an hour before the announcement that morning… As you kind of have to do this for publicly-traded companies, etc. trying to get the maximum impact from the announcement.

But yeah, it’s really tough. It’s a very small number of people, you can’t really go easily seek advice or input… Or even getting advice or input, because the number of people in the world - and there’s probably more of them now that Silicon Valley has made more of these things happen… But like the number of people you can even go to ask about this, or to like get input on the emotional side, the existential side, how’s it going to change my life, how’s it going to change everyone else’s life…?

[01:18:02.22] Yeah, it’s really tough. It’s this huge decision, it’s on your shoulders, or a small number of people’s shoulders, you don’t know how to think about these big numbers… And in the meantime, you don’t want to get distracted from what you should be doing, which is running your business and building your product. It’s not an easy thing.

It’s a good thing during that time too that you were heads down on the product, and focused, because you needed to remain that way. Because I think if you had to pause and been distracted, then obviously seed would have been delayed, and Twelve-factor may not have been as thorough or as polished as it was… You know, those kind of things.

Yeah. I think we could have done better with that. Definitely, there was a lot of – and I think we entertained seriously three or four acquisition or merger type opportunities… And every time, it just sucks up a lot of your soul, I guess. You’re trying to think about how everything is going to be different in the future, and… Yeah, like I said, it’s not that easy.

And so in some ways, there was a kind of relief to take the Salesforce offer, because once we went through the due diligence, and the dog and pony show related to the announcement and so forth… I mean, once we were on the other side of it, then we were just going to build. And we don’t need to think about funding rounds, and we don’t need to think of acquisition opportunities… It’s just the only thing there is to do is build your product and make it as good and successful as you can.

So in a way, the year after the acquisition was one of the least clouded, most joyful, most just in-the-zone, in-the-flow shipping and delivering on something. And it helped that we already had this vision teed up… But honestly, it just took away a lot of the existential worries that are part of an entrepreneur’s life.

Well, you only get one path through the maze, so like you said, there’s no counterfactual. We can play what ifs all day long… And it is interesting, and sometimes helpful to do that. I poke fun at Salesforce… Ultimately, I think they’ve been a great steward of the project, of the business… Yes, has the innovation slowed coming out of Heroku in the last couple of years compared to when you were there? I think absolutely, as a customer and just as an onlooker. But like yourself, I happily use Heroku to this day, when it fits my needs, which is in many cases. It’s a great platform, and it continues to be that apex of developer experience that other platforms try to aspire to. Could they have taken it further by now? Of course, we hope that it would… But it is, I guess, as they say, what it is.

I’m curious with regards to the most recent stuff though… So now you’re like a decade past; you’re doing your own thing. Emotionally, your mind space has moved on… You’re looking back. And we do see moves recently coming out of Salesforce with Heroku; the biggest one, taking away the free plan, and just this new direction which is very enterprisy, kind of counterculture to what Heroku began as, which was like the hackers’ platform, like the indies, and just the ability to play, and try something new, and start something from scratch, and have a runway before you have to get serious about it was always part of that Heroku aura for me. And so a lot of people are upset about this, thinking either a) we’re just mad because we had a free dyno and we don’t have it anymore, or b) this is kind of like the changing tide of something that we once loved, and it’s gonna start heading in a different direction. I’m curious, did you have an emotional reaction to that? Does it matter to you anymore? Do you feel like your legacy could be tarnished, or no? What are your thoughts around like - now you’re far gone, and they’re starting to change it in more substantial ways, that seem like they go against what Heroku was all about.

[01:21:49.13] Because your kids are all grown up and out in the world doesn’t mean you don’t still love them and have emotional reactions to things transpiring in their lives, right? Yeah, for sure, that that one was tough for me to see, because it was part of our original vision, or somewhere in that early vision, that it’s quick to get started. And it’s not about it being free exactly. It’s that you don’t need to make too many decisions to start a new project, and get it on the internet. And that’s something that – actually, I think open source was the thing that really kind of opened my mind to that originally, which is… I remember years ago when you wanted to - or at least my early experience with SQL databases was things like Informix, where you needed to go get a license before you could even use the software. So if you have an idea for a project late at night, you’re not just going to like spin it up out of nowhere. There’s this whole ritual that is involved. Now there’s the money, of course, and then that leads you into “Okay, is this project really important enough to spend the money?” and like needing to frontload that decision. So for sure, being able to like just get something up and running quickly and frictionlessly, and the free is part of that… So yeah, I was quite sad to see that.

I have a lot of sympathy for the business decision, because having been on the inside of that machine, even all those years ago - I’m sure it’s changed a lot since then, but it is a huge amount of… “Work” doesn’t even capture it. “Responsibility”, “stress”, I’m not quite sure. But being responsible, or a steward in some way for all these applications is just this huge job, and there’s really a lot of clutter with the free apps. And I probably, looking back, would have done it a little differently. Actually, we did make some big changes… This was kind of right around the time I left… Actually, I’ll give a shout-out to my colleague, Peter van Hardenberg, who’s now running the Ink & Switch research lab… But he was one of the ones that helped lead the project of setting up these hobby dynos, and something where there was like a little bit more restrictions on the free stuff… So if you’re like “Okay, yes, you get started with a quick side project, but if you really are going to make it be a longer-term thing, and you’re getting value from it, you should pay some amount. It doesn’t have to be a lot; just a little bit.” And that’s a way – it’s less about the money in the sense of like paying for the runtime or whatever, and it’s more about just sorting out what’s really important to people and what’s not. And that sorting is important, because you end up with all these junk apps that were like one-off experiments, or someone just kicking the tires, or whatever, but you can’t tell those apart from the ones that are important to people. And so it makes just the running and the maintenance of the platform a lot harder.

And then, you throw in the whole like spam and abuse side of things, which we always knew in the beginning would be a challenge… But of course, this is long before there was such a thing as cryptocurrency mining. So in today’s internet - I mean, I don’t know what the trust and safety team or whoever it is there that needs to deal with this, but I can only just can’t even begin to fathom how much work it is to kind of filter and manage just this totally free, open-ended runtime.

So I wish there had been a different solution; I’m sure they’ve thought about it and came up with what made the most sense, because I can see something there being a big problem for the business, and that problem impacting other users and customers, right? Badly-behaved apps in some ways sucking up all the time and attention of the team that’s running the thing, and then they have less time to support the people who are really getting value from the platform. So I see why the free apps would be a problem. But at the same time, it was a core part of the vision, which is that it’s completely frictionless to get started, and this takes that away.

Yeah, especially somebody like yourself, who is so much about zero to one; that’s what that free allows people to do, is get to one, and then pay from there. And so yeah, I was with you. I was definitely kind of like “Hm… That’s sad, but I get it. I understand.” I just saw an article yesterday, I think, that GitHub Actions is suffering the same fate… Because you get a certain amount of hours every month, or something, and the crypto miners are the spammers, or I don’t know what they’re doing, but they’re, of course, abusing that platform.

[01:26:17.15] Yeah. One of the bets we made with Heroku, that did turn out to be wrong, was we assumed that sort of basic compute infrastructure, storage, runtime etc. would be – essentially, the price on that would keep going down, so essentially approaching zero, and that the value would be elsewhere. And we kind of built the system assuming for that, that the value wouldn’t be in these kind of infrastructure costs. And maybe that was a little driven by, I don’t know - think of this as also around the days when Gmail was in its heyday, and they’d come along with, I don’t know, 100x as much storage as any other service, and kind of implicitly saying, “Look, storage isn’t as valuable as it used to be. Hard drives have gotten cheap”, and so on.

So that was something we always kind of designed around, was just assume that the compute is just not the expensive part of this. And there’s some ways that became true, but there’s some ways that it didn’t really go as far on that as we thought, and part of that is this kind of abuse problem that we just talked about, but part of it is, I think, just stuff didn’t get cheaper as fast, maybe as we thought it would… And the reality is runtime costs you money. And yeah, the first time I saw GitHub in early beta, the GitHub Codespaces, my first question was, “How do you pay for the runtime on this?” Because no matter how many resources a company has, at some point those resources will run dry, and won’t be worth the lead value of the free compute. So I think that’s something that all these platforms have to grapple with, and unfortunately, is very against the concept of just abstracting away the infrastructure. But if you have to worry about what your compute costs, you’re very much thinking about the infrastructure, and then you’re thinking about how to optimize things, and then that pretty quickly is leading you to more of a systems mindset, of how much memory do I need, and how do I do memory management, and how much compute do I need, and how do I do parallelization, when we always just wanted you to be thinking – think about your app; just think about the business logic, think about the data modeling, think about how to solve your customers’ problem and the user experience, and don’t get hung up on exactly how many cycles this operation takes.

So as you look around today at the new batch of platforms out there - and here we are, end of ’22, beginning of ‘23 as people are listening - what impresses you, what excites you? What’s interesting? You have what Vercel is up to, what Netlify is up to, we have Fly.io, we’ve got of course AWS still just adding more services, Lambda, functions on the edge, a lot of edge compute talk… Is any of this compelling to you, interesting, getting you perhaps to switch your business off of Heroku, onto somebody else? Or what does the landscape look like for you today as just an observer?

Yeah, I’m gonna have a disappointing answer to this question, as I would anything having to do with kind of modern development trends or tools… Which is I am pretty disconnected from that world. I have become more of just a user of these services, and not as hooked into what’s hot new… And that includes frameworks, and databases and… I don’t know, is NoSQL still a thing? I’m not sure…

[laughs] That’s awesome.

Yeah, exactly. So my knowledge is pretty out of date. And that reflects both that I was so deep in this kind of DevTools world of things for a while, and then maybe needed to refresh myself from that. I’ve since moved into other - let’s say an adjacent industry, which is productivity software. And then I’m not even the one doing the software development for myf current businesses. I basically have found myself more in product design, and some of the other aspects of the business.

[01:30:08.12] So my knowledge of technology and how software is built and so forth is still very relevant to the work that I do, but I’m just not deep in it. And on top of that, my current business is built on Apple platforms, and Swift, so I actually know way more about that stuff nowadays, probably, than I do a lot of the web world of things.

But to briefly answer your question, I would say that Vercel obviously seems like they’re doing something pretty impressive. I’m glad to see that they’re successors to the Heroku concept. Folks trying to pick up where they left off, new independent businesses that can take new directions, you have Fly and Render both in that category, I think… And then one I have to give huge props to as kind of a user/customer is Netlify, who I got the chance to meet them and invest a little bit of money pretty early on, and right away I saw that to me, they really kind of capture and embody a lot of the same values that we started Heroku with, but doing it in this different slice of the stack… And this whole concept of static apps, and static site builders. I’ve seen so many of this type of app, or what should be a static site deployed on – I’ve done this myself, because it’s easy to deploy there. But then a dynamic runtime is a huge hassle to maintain for what’s just basically a bunch of static HTML and images that can be served out of S3.

So I think Netlify, to me, is one of the best examples of what - to me it comes back to this impact question with what you do, which is… I think they took at least some inspiration from what we did at Heroku, and what I want to do is see not just my particular product or business be successful, or used a lot of whatever, but the ideas that I think are worth sharing, that others adopt them, or they spread within this little industry that we’re in. So Netlify to me is one of my favorite examples of this. I use it for a bunch of stuff, including my business website and my personal website, and I just think they’ve executed really well, again, on this specific slice of static sites.

Well, that question started off like a dud, but it ended very well… I’m happy to hear that. You did mention what you’re up to nowadays - Muse, different space altogether. We want to talk to him about Muse, don’t we, Adam? But we’re not going to talk about it right now.

We do. Yeah.

We’re gonna talk to you about Muse soon.

Well, let’s tee up that conversation… And I think the way to do it is - so Adam, you eventually exited from Heroku… You took some time off, you moved to Germany… So that’s your sort of like – you successfully exited from a startup, and then what next? So at least give us that journey, and we’ll tee up the initial things you started to do. You’ve got Ink & Switch, the research lab you started, some of the things with your other co-founders that are sort of lifelong partners of yours, business partners of yours… At least tell that story, and then in part two, when we come back, I wanna go deeper into this switch to Muse, this switch to a different side of you which is focused on product development, and not deep into the code… You know, the Apple ecosystem, Swift, etc. which is way different than DevOps, way different than what you were doing at Heroku. So at least tell that story; get us from successful exit to time off to Germany, and then what that next for you.

Yeah, so let’s see, I think I was at Salesforce for three-ish years, following the acquisition; again, a good portion of that was following through with the Cedar, Twelve-factor kind of part of the vision, and then with that completed – I don’t know, lived life as a manager… Of course, the company had grown to 100+ people, and I kind of found myself in the throes of the managerial things you would expect from a larger team, and trying to adapt to those skills… There was also just a huge element of sort of uptime, and operations, and for quite a while we essentially had to freeze all product development, because the platform was successful enough that the main thing people cared about was it staying online, and we had to do a lot to bring more reliability and more professionalism to our managing of incidents, and just how everything was instrumented, and so on.

[01:34:25.18] So yeah, at the end, when I decided that I had done what I had come to do there, it was obviously a sad day, but I put in my resignation there, in 2013. And it was probably a good six months or so of just – I don’t know how to describe it exactly, but the 6+ years before of like nonstop adrenaline rush, and I just needed to like sit and–

Do nothing.

…recover. Yeah.

Watch The Wire, all six seasons of The Wire. Nine seasons of The Wire, or something. Consecutively. Right?

Totally, yeah. There was a lot of those things. Hobbies I’d forgotten about… Honestly, I spent quite a bit of the time just catching up with old friends, reconnecting with family members, traveling, just being in a very – and of course, naturally, when you come off of something that’s perceived as success like this, people are instantly asking you what’s next, and the answer is, “I don’t know, I need to have no next for a little while, and just be more a free spirit, to kind of refill the creative well…” Or maybe a Steve Jobs would say “You’ve got to be hungry and foolish”, and something about like being a manager for a large organization, and worrying about operational uptime and whatever, I found myself drifting away from that curious person that I used to be as part of that. So I needed to kind of reset myself.

But yeah, that led me to thinking that I wanted an experience to live abroad for a little bit… Not a long time, but six months or a year or something like that, and that I kind of wanted to dabble in some startups, but I didn’t want anything that was too serious from responsibility… And so I just had this idea, “Hey, I’ll go do some gigs, basically advising-type, consulting-type gigs for startups”, and kind of get to dip into the world a little bit that way, without having anything long-term. And I thought I would combine these two interests by basically going to another city that had startups, and at least at the time - I think we have more of a startup diaspora happening now; you can do this work in a lot of places in the world, which is really nice. But at the time, San Francisco was really the center of everything, by a long shot. There was a couple of other cities, maybe New York and London… But of those, Berlin seemed the most interesting, and so I thought “I’ll just go there for a while.” There were some exciting new startups happening then at the time - SoundCloud, and Wunderlist, and a few others… And I’ll just have a little adventure, kind of in another country, work with some companies, and… I don’t know; after that, I’ll see what’s next.

But you stayed. It wasn’t just a few months or a year or so, like you said. It was many years, if I understand correctly.

Yeah, it was unexpected. I guess my – James and Orion, the other two Heroku founders, we sort of had a… I’m not sure what the word is; a loose agreement that we would sort of reconvene at some point, when we’re recharged and refreshed, and ready to think about what’s next. And so I was sort of – not quite killing time till then, but I sort of like had this freedom that I wanted to take advantage of. And yeah, I ended up working with these companies, one of which I really enjoyed, and kind of wanted to do a longer stint with, and then I really fell in love with Berlin as a city… Less Germany, the country. Maybe, like any great city, it’s sort of like – New York is not like the rest of the United States; San Francisco is not like the rest of the United States. They each have their own character, and I think there’s something similar with a lot of these major metropolitan areas. But Berlin at least has a very interesting kind of vibe, let’s say, some of which stems from the fact that up until pretty recently it was relatively economically depressed compared to a lot of other capital cities… But yeah, it just has this huge population of artists, and musicians, and there’s just a very creative energy here that I’ve found really energized me, in addition to just a lot of greenery, and that European quality of life, and all that sort of thing. So it wasn’t something of like oh, I came for three months or six months, and then said, “Let me settle down here.” It was more like “Well, I was here for six months, and not quite ready to reconvene with my other partners yet, and there’s nothing really pulling me back to the States… In the meantime, there’s a company I want to work with here… And boy, I sure do like the city. Maybe I’ll stay a little longer.” So it kind of was like that. And then you can play out that it was kind of variations on that theme, that proceeded over the course of the last eight years that I’ve been here now. And of course, the other huge thing is just remote work has made it so that – I think that was right at the time when I feel like that was just starting to become a viable way to do things… And indeed, when we started the research lab, we opted to go all-remote from the start. That was 2015, I think.

So I guess we’ll let that be the somewhat ending to this part one. We’ll come back for part two. We’ll talk about Muse, we’ll talk about this shift for you, this continued direction there in Berlin… Ink & Switch, which is the research lab you mentioned with your two co-founders of Heroku, James and Orion… We’ll talk about what you’re doing with your podcast, we’ll talk about what you’re doing with designing products, and building teams, and the fun things you’re doing there, to sort of taper off the next journey for you, Adam, and where you’re going. How’s that sound? Does that sound good?

It sounds great. I’m looking forward to it.

Alright, we’ll leave it there.