The Changelog: Software Development, Open Source - The story of Heroku (Interview)

Episode Date: November 4, 2022

This week on The Changelog we're joined by Adam Wiggins, co-founder and former CTO of Heroku, for an exclusive trip down Heroku memory lane. Adam and Jerod are both tremendous fans of Heroku and believe (to this day) they represent the apex in developer experience for delivering code to production. We talk through the beginnings of Heroku, the v1 most people have forgotten about, the era of web hosting back in 2008-2010, the serendipity of Silicon Vally in those days, pitching to Y Combinator, the makings of git push heroku, the Heroku style and name, the sale of Heroku to Salesforce, potential regrets — and we tee up part 2 coming next week with Adam going beyond Heroku and the story of Muse.

This week on The Change Law, we're joined by Adam Wiggins, co-founder and former CTO of Heroku, for an exclusive trip down Heroku memory lane. Jared and I are both tremendous fans of Heroku, and we believe to this day they represent the apex in developer experience for delivering code to production. We talked through the beginnings of Heroku, the V1 most people have forgotten about, the early era of web hosting, the serendipity of Silicon Valley, pitching to Y Combinator, the makings of Get Push Heroku,

the Heroku style and name, the sale of Heroku to Salesforce, potential regrets, and we tee up part two coming next week with Adam, going beyond Heroku and the story of Muse. A big, big thank you to our friends and partners at Fastly and Fly. Our pods are fast

to download globally because Fastly is fast globally. Check them out at Fastly.com and our friends at Fly let you put your app and your database closer to users all over the world. No ops required. Learn more at fly.io. This episode is brought to you by Sentry. Build better software faster.

Diagnose, fix, and optimize the performance of your code. More than a million developers in 68,000 organizations already use Sentry, and that includes us. Here's the easiest way to try Sentry. Head to Sentry.io slash demo slash sandbox.

That is a fully functional version of Sentry that you can poke at. And best of all, our listeners get the team plan for free for three months. Head to Sentry.io and use the code changelog when you sign up. Again, Sentry.io and use the code changelog when you sign up. Again, Sentry.io and use the code changelog. 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 the podcast, so it's quite an honor to be here.

You don't do too many podcasts. You do your own shows, right? 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 to Mike,

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. My own instigation and my own concept. But I think there's a lot that can come out in someone else's venue as well. So looking forward to what you guys managed to get out of me. Well, I was thankful when I got the email back to say, yes, we'd come on your show.

But you agreed to do a two-parter because you want to talk about Muse, what you're working on now, but then also this big history, this big question mark of like where things began with Heroku, the journey, et cetera, your journey, how that all entertains, all that good stuff. history this big question mark of like where things begin with heroku the journey etc your

journey how that all entertains 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 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 count 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. 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 this kind of the biggest success of my career might be the

most successful thing I ever do, which I'd be totally fine with that. It naturally, it's the thing that comes up a lot or 12 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 I did evolve my career into Ink and Switch and Muse, which we'll get to in, 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 of this we thought like 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 where 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 the thing out there. And I think that's why we approach this with such reverence because like, it's your story,

but it's, it's Heroku. It's, it's the, it's the thing is 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 built a business on top of Heroku, both on, you know, websites I create for myself, as well as my customers. I'm a longtime software contractor. So like I 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.

Thank you so much for all those kind words. I and my colleagues were building something that was in our hearts but also just reflected something we wanted 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 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. 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 get push Heroku master. It was like like run your write your ruby code inside of the browser and you guys had this snazzy ide this is 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 ruby, 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 going to 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. 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.

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 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 scaling out 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 maths 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 developers 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 are nowhere near what they are today, but they had started to, 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 like 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 REPLL thing in a third pane and then maybe the application output in another pane and kind of got all that working.

It seemed like a really potentially useful and impressive piece of technology. We went from there to thinking, hey, maybe this could be a business. Maybe we want to spin this out as a product or do something differently here. 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. 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've 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 like 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 to just be to that. Yeah, well, I think from the debugger, we pretty quickly in 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 seemed like a pretty novel, 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 kind of 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. 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 are you doing it so far? You have this huge warehouse. And it turns out one person who is a total non-programmer just used 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 the 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 and 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 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 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, you know, the equivalent of Rails New, 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 a web page. We thought of it as a one-time operation. Maybe sometimes someone's already started an app. We thought of it as not something people would use a lot, but maybe it's good to have. 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 Web Editor at all. They were using this import page over and over again. So essentially, we sometimes call this a folk practice in the product design world, which is the idea of someone's using something in a way that's not really quite how it was intended or what it was designed for, but they're pointing the way towards their true problem.

So someone who exactly, as you were just 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. 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, I can recall deploying... 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.

So it was a different world with deploying back then. Even today it's still challenging, but back then it was super challenging. There was nothing. 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.

Basically the idea of making a mod.ruby that worked as well as mod.php so that you can just FTP your Ruby files. That was the state-of-the-art thinking, but that was the big dream. And at the time, you know, we were working on this and when I see folks talking about this online, and 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 kind of shared host.

They said, this is Rails-specific hosting. 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, signed up and became a customer and whatever, and they direct you to the, here's how you get started with the Rails app. And it's like eight pages of, okay, install Apache, now set up your SSH keys, now 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 Zmentovich, 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 like a lot of people vying for being the the home of Rails put your Rails app here essentially do you recall that Eric can you talk about you know that time frame since that was essentially the same time frame of Heroku being born yeah absolutely I think the 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 just wasn't good for anything other than a really tiny hobby app. And then you had VPSs were a bit of an emerging thing.

Slice host was another inspiration for us. I had been using Slice host for about one. 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 spent a lot of my time during that consultancy and actually for the rest of my career,

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 put it in the trunk of my car and take it to a co-location facility. This was the state of the art, but that was the standard thing to do. And at least a VPS was a step up. It was a little bit more on demand, even though you still had to wait, I don't know what, 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 could 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 posting as far as i was concerned and then you had ec2 as the new big player and that also was a piece of kind of the origin story of heroku we had been playing with it as part of um trying out 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 that it kind of, you know, you triangulate that and slice host, 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 in-house.

They were more like Red Hat probably would be the closer thing, but ultimately I think the thing they offered you was, apologies to any Engine Yard people that might be listening if I'm getting this wrong, but I think it was basically managed hosting, but it 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 engineer at office was down the road from us, and we hung out with them quite a lot, and we're 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 kind of keeping it in production,

which is sort of still the problem with ShipIt. The podcast you run, ShipIt, 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 database issues.

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 one thing was deploying, 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 application production, keeping it production, keeping it running, it was newer. So newer people were getting into application development and deploying application production,

keeping it production, keeping it running. It's 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, term cloud didn't exist.

This was a different time, right? Just thinking about that time frame, you brought me back mentioning EC2, well, Slicehost 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 BPS services of their own through that acquisition.

But I'm just thinking about all of the things that were burgeoning at the time that Heroku, that you guys started to execute. You had Git and GitHub around the same time frame. You really had the birth of AWS, specifically the EC2 offering. I believe it was at the end of the 20-ohs. What do you call them? Oths?

I don't know. Like 2008-ish was EC2. S3 was a couple 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 and was becoming so successful that your potential customer base was kind of exploding. And then the pain of deployment for Rails being kind of a sore thumb of what is otherwise an excellent building experience. There were so many things lining up for you, not trying to take anything away from your execution, but we talk about the ways,

the 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 the 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 ourself. 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, you know, the likelihood that you might find that 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. I think it's the same thing for any kind of creator, whether you're a software builder, 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 a thing we believed should exist in the world.

And then we happened to get very lucky with all those things coming together at that time. Yeah, I was thinking 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. If all things align, I can 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 we had been working on this open source project kind of 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, joining 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.

And it was, so all of this happened between, I don't know, Rails Confluence 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. And coincidentally, or not coincidentally, around that time was when we had started to experiment with what an API would look like. And I ended up doing this essentially as 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. 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 was 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 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 this. What is the point of integrating to a thing that no one uses? I 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 like 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 Wenstrop and some of the other GitHub founders. And they had basically just started on this project. And they said, we think it's really exciting. We want to make a painless way to host it. I ended up getting to try out their early product. Actually, I think we were in Engine's Yard's office in South Park.

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? I was explaining what we were doing. Again, very, very serendipitous, but in no way did it seem strategic in the sense of like, here's what developers are using.

We're just drawn to this different way of doing things. That's exactly how Chris describes he and Tom's initiation of GitHub was, they were in a bar. It was serendipity. It was like, yeah, I've got this, you know, this Git web interface thing I'm working on and I've got this thing over here and they kind of combine the things to create github essentially which you probably know this but it that's funny how both of these stories

which are like you know pivotal to so many so many folks ability to one collaborate on code and open source code and find and create community and and you know now with you know the commercialization of open source projects becoming products and companies you know building companies but then also able to host their applications with heroku and ship and stuff like that it's just crazy how both of your stories is like essentially steeped in serendipity and i think san francisco at that time also helped create that serendipity i can 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't Has Ruby

that 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 kind of 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 Hey friends, this episode is brought to you by my friends and potentially your friends too at Fire Hydrant. And I'm here with Robert Ross, founder and CEO of Fire Hydrant.

And Robert, there are several options out there for incident management, but what is it that makes Fire Hydrant different? The reason that we think that Fire Hydrant is on to something is because we're meeting companies really where they are. We face the same problems that every company in the industry that is building and releasing software is also facing. So where you want people to be able to sign up for Fire Hydrant and immediately be able to kick off an incident using the best practices that we've built and we've experienced and have gathered through the other amazing customers that use our tool. It really is a very quick time to value. And we want people to have a long jump from where they are to where they want to be in incident management. I love it. Thank you, Robert. Small teams up to 10 people can get started for free with

all Fire Hydrant features included. There's no credit card required to sign up. They are making it too easy to get started. So check them out at fire hydrant.com again fire hydrant.com 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 was some of the indicators that was the IDE. And then through the process of Y Combinator, you found out that that was the wrong direction. What was some of the indicators that was the wrong direction? Was it feedback from the newfound support and Paul Graham and others that come along with Y Combinator? Was it feedback from customers or would-be customers? How did you get to, like, this is the wrong direction. The thing you were putting 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 we got out of the program was more around access to and information about kind of 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, 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, yeah,

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, Series A was a lot less money than it probably is today, before the program was ever over. So we didn't even demonstrate, or we didn't even do the demo day experience,

which was 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. And this is a place where I think having money in the bank could sometimes prevent 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 kind of penetrated

our collective consciousness, and we heard Presta say exactly how. That on one hand, you had the way the people that were using the deployment part of the product, whether it was through this import form, whether it was through the command line and the Git kind of 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 would be more willing to pay, and that that represented a better direction for us than the citizen-developer direction. That side of things would be very good for people, for example, learning to program. 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 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 led to this pivot, which I think finally we did kind of 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 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 that'd be a fun exercise two very good questions i would only imagine that they are somewhere in the... Because we ourselves switched from Subversion to Git, I remember, around the same time that I was doing the integration. So the very 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 code bases have been cycled out in exchange for newer 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 system-type integrations, like shelling out to do system things that were way outside the realm of just the normal application. It was Rails app itself, of course, and that

stuff was way outside the realm of, yeah, we broke all the rules of the system. I'm guessing it would be a big project to bring that one back i mean awesome like phd thesis or something like if somebody had access to the source code or like archaeologists and then like bringing it back would be like a really cool yeah it makes me think of these uh the digital preservationists that work at archive.org and and other places to uh 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-based web things or Repplet, Glitch. There are 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 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 7, 2008. So that's got a little, actually, decent quality screenshot there of the web editor. So git push Heroku.

This started off as a side project in the CLI, 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, if the innovation was done, maybe you didn't know it yet. But like that, I think, accomplishing that from my perspective is like why I want to use Heroku all the time. Once I did that once, I was like, why would I go back to DPSs ever if I can just do this?

I think that's probably what most people thought that became your regular customer. I think the innovation was done, but 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 were taking away a lot of your effort because y'all invented a bunch of tech. I remember there was this routing mesh. There was a lot of blog posts coming out. There were various programming languages that you were using. I think maybe Erlang and Go was something you guys talked about a lot. So like

you guys are very much pushing the edges of the Ruby community into these new and weird and interesting places to accomplish Git-based push deployments. Soive 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. 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. 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. In particular, I had done, me and one of my colleagues had done quite a lot with Unix. I'm a big, lifelong lover 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 like, I don't know, something like INetD to spawn off little processes and I'd done a lot of socket programming back in my college days when I ran a MUD. 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 kind of 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 processes, we were able to use a lot of the default

Unix kind of 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, I don't know what, write a kernel patch or something like that. So we had this kind of user-facing interface that could be a Rails app or even the API, once there was a command line that would call that. That 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 the, call it the load balancer. It's probably a strong word for it. But when traffic comes into the,

and back then all of the apps were just on something.heroku.com. So when traffic comes into star.heroku.com, we would figure out how to route that. And the way we did that was to rewrite hdb.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 yourself and it was very very good about finishing all the current connections before it brought up new connections so things wouldn wouldn't get interrupted in a weird way. Now I think this kind of dynamically writing the config file and doing the SIGHUB thing, that worked up until a 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 engine x that would basically do 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 rails conf talk in 2008 i believe was writing a 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, I don't know, the edges of the, how far off the defend we had gone, which in the end did turn out to be a good exploration. 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 Miserani, was the inventor of Sinatra. He had come to work at Heroku and he kind of came to the same conclusion I think I did, where we sort of simultaneously realized the same thing, which is we really just need to write our own load balancer.

I think we'd maybe started to experiment with HAProxy, but even that wasn't going to do the trick. 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 front end. And actually this was such a radical idea

that we actually had someone quit on our team where they basically, it was basically someone that was more from the operations background, but 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. Wow. Which was fair. And again, 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 to call 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 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 you know replicated that but for little while, that was probably a pretty unique invention that we had in our arsenal. Dinos. That makes me think about the Heroku style. So Adam, you can probably speak to this. Adam Stachowiak, Namespace Conflict. In addition to all these things that we're talking about,

there's 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 like haiku names poetic yeah and there was just something that it had taste and style maybe sure yeah there was a style to it that just made it like 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. 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 bristled 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. My colleague James basically said, no, I want to draw a clear delineation in the same way that an iPhone is not a computer, Heroku is not hosting. I said, yeah, but you run your app there. So this was the compromise we arrived at, was we positioned it as 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 like, this is how we should build our business. It was more 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 a thing companies do. But it wasn't a thing companies do that we're building hosting or developer tools or anything like that. And so I think that ended up in a way being a 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 say user experience, design, a sense of visual flair, a brand that's not just completely practical, that's worth doing. And my basic thinking on that 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 gets Slice Host 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, know most hosts of the time you know dream host and slice host and rack space just these very pragmatic just kind of like so you know does what it says

or says what it does kind of thing yeah so the japanese influence is 100 percent um from ruby's japanese origins and i'm happy to say that you that there is a way that could have gone badly, that borrowing from a culture that you don't, you know, 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, you know, 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 um yushiro matsumoto and you know basically was able to like put the question to him directly like

actually he asked me first he was like heroku it it sounds japanese but it it doesn't 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 um so so and we did put some effort into you know talking to japanese speakers and making sure that it would be a name that made sense um but actually the 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 the haiku, again, reflected Ruby's Japanese origins,

the fact that it was very succinct language, very elegant, or from our perspective, elegant, beautiful language in the sense of how it looks on the page, so to speak. And then the heroic side, this has often been misinterpreted. There were 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. If you do that well, you're a hero. You feel like a hero. You are a hero for that business. We wanted to make something that would be a tool to help you be heroic, especially in combined with that early end user programming citizen developer vision that we only partially fulfilled, I'd say.

Yeah, well, congratulations on matching those two together so well. Because, I mean, it seems Japanese. And thanks to Matt for clarifying whether it is or it isn't. And at least giving you the credibility of having the creator, Ruby, on your team. What more significance could you have besides Matz and your team? It's been a while since we've talked to Matz. We talked to Matz for Ruby's 10-year anniversary.

Wasn't it your 10 years, 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. I think it was some off number. It was 12 years of Ruby.

No, it had to be 23 years of Ruby. I don't't know what it was yeah yeah he's been there for a while huh yeah it was a while back very well done though very well done yeah so i guess there's a a juxtaposition then that just kind of strikes me which is all that you just described of the name heroku plus the style that we've been talking about the 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 Slicehost. It's like, well, we're going to provide your Salesforce with a 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 Tunk Crutch article. Then you have the pivot from there. And then you have 2010, according to Wikipedia, Salesforce. Tell us the story of Salesforce and the sale to Salesforce. Yeah, sure. So yeah, briefly the timeline there was 2007, let's say RailsConf was kind of inception. 2008 was Y Combinator, and then later that year was kind of the pivot into the platform. And then we had the kind of various stacks, 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 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? You spent a few years, you innovated, great timing, great style. An amazing multiple on the dollars in, right? 13 million million that's nothing in today's dollars yeah and of course so the acquisition officially 212 million in cash and that's 2010 dollars that's not 20 uh 22 dollars so nowadays we're like huh figma 20 billion you know 212 million is for pikers but

adam's like i should have waited 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 do you how did you back then reckon with you know selling this thing you've 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 brought in as kind of hired as an outside CEO and great guy, now Cam's 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 right 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 but indeed people would lump us as one of the kind of seminal sort of cloud 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 coined it, but we 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. 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've 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 desk, so to speak. And we, 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 and a half years in,

and 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 liked their brand, even though they are more of that much more pragmatic infrastructure software. But I saw it as, 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. I said, this isn't really what I got in it for and we need to build this expertise on our team. Indeed, we were doing that, hiring people

and just trying to learn 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 current cutting-edge application development practices like decentralized revision control and so forth. It seemed like a really good fit.

Oh, by the way, everyone involved would get rich out of this. And not just, of course, you think about yourself, but also like these, all of our employees, many of whom were, you know, 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. 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.

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. We were pretty far in that discussion. 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.

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, this is $70 million. I couldn't even fathom that number. I don't know. Maybe again, maybe Silicon Valley these days is just full of 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 got to 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 continue independently. And 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. And indeed, the number they put on the table got our attention to at least open the conversation, right? What's up, friends? This episode is brought to you by Sourcegraph. With the release of Sourcegraph 4.0 and the Starship event just a few weeks behind us, it is super clear that Sourcegraph is becoming not just code search, but a full-on code intelligence platform. And I'm here with Joel Kortler, product manager of Code Insights for Sourcegraph. Joel, this move from code search to code intelligence is a really big deal.

How would you explain this feature, Code Insights, if you're just talking to folks in the hallway track of your favorite conference? I would really start with the technical because before I was product manager, I used to be an engineer as well. And it's really cool and exciting just to be able to say, we're going to turn your code base into a database. And the structured language that you need to interact is just the ability to write a code search, you know, literal search, that's totally fine, regular expression, you know, that'll give you a few more advanced options, even a structural search. But

the number of long tail possibilities that unlocks truly the journey of building this product was just saying, well, we've just unlocked, you know, an infinite number of possibilities, we got to figure out some immediate use cases, so can start to invest in this product, build it and sell it. But we're only getting started in terms of the number of uses that we're uncovering for it. The story I told you about discovering version tracking turned out to be a really important use case that wasn't even on our roadmap six months prior to discovering that as we were

already planning to launch this product until we talked to enough folks, realized this was a problem and then found, well, oh, that's like a simple regular expression capture group that you can just plug right in because we really built this system to not limit the power of what we built. We don't want to give you like three out of the box templates and you can only change like one character or something. It's truly like the templates are there to hold your hand and get you started. But if you can come up with anything you want to track in your code base, you can do that with Code Insights. I love it. Thank you, Joel. So right now there is a treasure trove of insights just waiting for you. Living inside your code base.

Your code base is now a queryable database thanks to Sourcegraph. This opens up a world of possibilities for your code and the intelligence you can gain from it. A good next step is to go to about.sourcegraph.com slash code dash insights. The link will be in the show notes. See how the teams are using this awesome feature again, about.sourcegraph.com slash code dash insights. Again, this link is in the show notes. I've never been in that position, obviously, because I have not built a Roku and I did not have it acquired by $212 million in cash by Salesforce in 2010. But considering what you've done in your career, I just wonder, obviously you're rich and you made some good money, and so 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's 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 specific you know co-founder of this thing, CTO of your baby.

That's Jared's question was kind of 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, you know, like in hindsight, today's dollars, that's not a lot of money in comparison. Let's say Figma, for example, is a comp. You know, 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 always think about the road not taken,

but I do think it's important to kind of compare to what were the other possible outcomes right so put aside acquisition let's say that um let's say we went to ipo or something like that you know my piece in this was i guess i'm a zero to one guy and so like i'm always interested in those those earliest days and in particular i guess i think of like building companies as sort of my 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, added the workers and the logging and all the things that to me were what kind of completed the vision for the platform. And was also when I published the 12-factor app, which was kind of the companion piece that sort of explained the philosophy of the platform. And I knew that 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, and wanting to paint my painting thing is 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, in particular 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 was actually a real boon to us. 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 knocking on the door, trying to close deals for a while.

That suddenly greased a lot of wheels. At least in the kind of 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 to 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

you know build something a little more able to weather that you know 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 a lot of companies manage to do that so you know that could have pointed something else but yeah is the heroku as a public company i'm not there either way what would that have looked like it would it have been better or worse than how you're comparing 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 how you're comparing or 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. 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. And it does exactly what I needed 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 longterm. Stability. Yeah. They want a stable platform,

a stable product. I asked you that because we have to ask you that, right? Because like, it seems like Jared's question, it seemed from the outside. And by no means am I saying this is the case. It seemed premature in terms of a,

an acquisition. It seemed early in its career. In retrospect. Right. In retrospect, because you were so early in the game you're only a few years in like was that good timing and you know we don't know and that's truly a true question is like only you can speak to that year year and a half as you

said like if you weren't able to deliver cedar if you weren't able to deliver 12 factor app and those details like that would 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 of 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 Roku and some of your journey there.

But after that, you went to Germany. You're still in Germany now. 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 independent, 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 you know are either run or are high up the chain in public companies and i know that that comes with all kinds of weighty you know business building stuff that is i think important for you know if you want to build a large and enduring company. But for me, again, I'm not a 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.

If you're an era of GitHub, GitHub was roughly the same time of inception. Obviously, you know the number, like $7.5 billion from Microsoft. I just wonder if 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 financial outcomes here, and again, you have a fiduciary duty to do this. 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 take an investor money, your job is to maximize returns for them. And again, early employees have that same element. They've taken stock options, lower salaries, and 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 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 have survived that long, right? So you have all these infrastructure costs. 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,

that is quite different from a 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, do you let it ride or you cash in your chips now? But in this case, that was part of the calculation was saying like, look, when we 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 know, if you figure there's a 30% chance of an N billion dollar acquisition four years from now, okay, who actually are the acquirers 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 are 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. 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. Salesforce was basically the original cloud company. They didn't believe in on-premise software.

They believed you should move everything to the cloud. Similarly, they invented the term platform as a service, which we eventually adopted as the name for the category we were in. There was a lot of reasons to think they would be a good home for us. That combined with these much more pragmatic calculations of 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 again, if I do have any regret, I think it is, what were those roads not traveled? For me, it's not about like, oh, 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 better which i have only touched in a little bit but i think you from what i've read of it so far a lot of what you're saying here right now is kind of embodied and 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 leafed through most of them because I'm preparing for our call and all that good stuff. So, you know, I like the way you think about it. I appreciate you letting us ask you these hard questions too on like, you know, 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 kind of stuff? Like these are hard decisions, you know, acquire earlier, 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 10 years and ask you about them. Yeah, the process of thinking through that is, I mean, there were so many things that was 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 the how to think about the existential question of an acquisition opportunity like this, including from these companies, and 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, 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 mean, 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. Because you kind of have to do this for publicly traded companies and blah, blah, blah, trying to get a 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. Even getting advice or input because the number of people in the world 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 to ask about this or to like get input on yeah the emotional side the existential side how's it going to change my life how's it going to change everyone

else's life 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 the 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 paused and been distracted, then obviously c would have been delayed and 12 factor may not have been as thorough or as polished as it was you know those kind of things yeah um i think we could have done better with that um definitely there was a lot of i don't know i think we 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 taking the Salesforce offer because once we kind of went through the due diligence and then talking pony show related to the announcement and so forth on the once we were on the other side of it then we're just going to build and we don't need to think about funding rounds and we don't need to think about 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 that 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, you can't, 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, as 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 it have taken it further by now? Like, of course, we would 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, right? Like 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 enterprisey kind of counterculture to what heroku began as which which was like the hackers platform, like the indies and the 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 dino and we don't have it anymore. Or be like, this is kind of like the changing tide of something that we once loved and it's going to start heading in a different direction. 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? Because your kids 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 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, I don't know, 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 kind of even use the software. So if you have an idea for a project late at night, you're not just going to spin it up out of nowhere. There's this whole ritual that is involved. Now there's the money of course but the and then that leads you into okay is this project really important enough to spend the money and like needing to to make kind of front load that decision and 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, 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.

I actually give a shout out to my colleague, Peter Van Hardenberg, who's now running the Incan 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 that kind of like if you're like, OK, 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 and in the sense of like paying for the you know 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 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 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, open-ended runtime. I wish there had been a different solution. I'm sure they 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. 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 the 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, hmm, 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. You get a certain amount of hours every month or something, and the crypto miners or the spammers, or I don't know what they're doing,

but they're, of course, abusing that platform. One of the bets we made with Heroku that did turn out to be wrong was we assumed that basic compute infrastructure, storage, runtime, et cetera, would be essentially the price on that would keep going down to essentially approaching zero and that the value would be elsewhere.

We kind of built the system assuming for that that the value wouldn't be in these 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 was in its heyday and you know they'd come along with i don't know 100x as much storage as any other as any other service and kind of implicitly saying look storage isn't as valuable as it used to be hard 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 um and yeah the first time i saw good github an early beta the github code spaces my first question was how do you pay for the runtime on this because you know that's going to be 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.

I think that's something that all these platforms have to grapple with, and unfortunately, it 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 think about your app, just think about the business logic, think about the data modeling, think about the data modeling, think about how to solve your customer's 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, you know, what Vercel's 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 you perhaps to switch your business off of heroku onto somebody else or what is 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've become more of just a user of these services and not as hooked into what's hot and new. And that includes, I don't know, frameworks and databases. And I don't know, is NoSQL still a thing? I'm not sure. That's awesome.

Exactly. My knowledge is pretty out of date, and that reflects both that I was so deep in this dev tools 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 my current businesses. I basically have found myself more in product design and some of the other aspects of the business. 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 kind of 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, pretty impressive. I'm glad to see that there are successors to the kind of the Heroku concept, folks trying to pick up where that left off, you know, new independent businesses that can take it in new directions. Fly and Render both fit in that category, I think. And then one I have to give huge props to as 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 capture and embody a lot of the same values that I and 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 Heroku. 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 could be served out of s3 so i think netlify to me is one of the best examples of what to me comes back to this impact question with what you do which is you, you know, I think they, they took at least some, 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 or whatever, but the ideas that I

think are worth sharing in that, that, that others adopt them or they, they, they spread within, you know, within this little industry that we're in. And 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 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 him right now. We do, yeah. We're going to 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, you know, the initial things you started to do. You've got Ink and Switch, the research lab you started. Some other 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, we're going to kind of 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, the Apple ecosystem, Swift, et cetera, 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's that next for you? Yeah, so let's see. I think it was at Salesforce for three-ish years following the acquisition. Again, a good portion of that was following through

with the Cedar 12-factor part of the vision. And then with that completed, I don completed, I lived life as a manager. Of course, the company had grown to 100-plus people. I 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 the 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 so yeah at the end you know when I decided that I kind of had had done what I had come to do there it was obviously a sad day but um you know kind of put in my put in my resignation there in 2013 and yeah it's probably a good six months or so of just I don't know how to describe it exactly, but the six plus years before of nonstop adrenaline rush.

Right. And I just needed to sit and, I don't know what. Do nothing. Recover. Yeah. Watch The Wire, all six seasons of The Wire, nine seasons of The Wire, something like that. Consecutively, right?

Totally, yeah. There was a lot of those things. Hobbies I'd forgotten about. But 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 kind of more free spirit to kind of refill the creative well. Or maybe as Steve Jobs, you know, would say,

you 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 kind of an experience to live abroad for a little bit, not a long time, but you know, 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 and 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 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 Ryan, the other two Roku co-founders, you know, 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 were recharged and refreshed and ready to kind of 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, I think. 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, of 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 found really energized me, in addition to just a lot of greenery and that European quality of life and all that sort of thing. And so it wasn't some thing 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. And 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 and switch which

is the research lab you mentioned with your two co-founders of heroku james and orion and we'll talk about what you're doing with your podcast 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?

Sounds great. Looking forward to it. All right, we'll leave it there. I got to say, I love a changelog exclusive. And thank you, Adam, for coming on here, sharing the story of Heroku. What a blast to go through all those details to ask and push back on the hypotheticals. That absolutely was a blast. And hey, we want to hear from you.

So get into the comments and share your thoughts. The link is in the show notes. Of course, come back next week. We're back with Adam again for part two, going beyond Heroku and cover what he's working on right now with Muse. Once again, a big thank you to our friends and our partners at Fastly and Fly. And also to Breakmaster Cylinder. Those beats are banging. And of course, to you, our listener, thank you so much. We love you.

We appreciate you. But that's it. This show's done. We will see you on Monday. Thank you. Game on.