52. Building and Scaling a Heroku Add-on

Adam: Yeah. So like you said, Rails Autoscale is a Heroku add-on, and it's an add-on for auto-scaling. So to back up a bit and talk about what auto-scaling is, on Heroku, you run containers called dynos, and auto-scaling is just a matter of automatically determining how many dynos to run. So it scales you up when capacity needs it, and it scales you down when you have excess capacity to save you money. Rails Autoscale is an auto-scaling add-on focused on Rails developers and Rails applications.

Corey: So if I'm a developer, why would I use this add-on instead of just manually scaling my application or maybe overprovisioning it, et cetera?

Adam: Yeah. So if you're running more than a single dyno, chances are it's a lot of guesswork involved for how many dynos you need to run, so it's a lot easier to let software make that decision for you. In addition to just not having to manually do the guesswork, most applications' traffic and capacity fluctuates throughout the day, throughout the week, so automatically scaling up and down is going to save you a lot of money, and it's also going to give you some peace of mind that you can handle any increase in traffic that comes your way.

Corey: Makes sense. So the application essentially is responding to real-time traffic changes and it's ready for it?

Adam: Exactly.

Corey: So how did you first develop the idea for Rails Autoscale?

Adam: Yeah, so that was in 2016, and the company that I was working for at the time, as a full-time Rails developer, we had just moved our apps from Engine Yard to Heroku, which was awesome. It saved us a lot of money and saved us a lot of ops headache, but we were finding that our internal application, that had many users during the day and no users at night and on the weekends, we had to have it scaled up to eight or so dynos during the day, and then it was just wasted money during the nights and weekends.

Adam: So we knew we wanted to auto-scale this app, and we tried a couple of the existing solutions at the time, but what we found was it was just unreliable. We couldn't get consistent scaling behavior because most auto-scaling solutions are going to base auto-scaling using total response time, and so as total response time goes up, it would scale you up. But our application, it had been around a while, and it had some really slow end points, so total response time was not a very reliable metric to indicate a scaling issue. It was more just an app performance issue.

Adam: So that was sort of my inspiration to build a solution that took a different approach, and so what Rails Autoscale does is it measures request queuing time, the time that requests are sitting, waiting to be processed by your Rails application because your Rails application is busy doing other things. So requests queue time is a bit more indicative of an actual capacity issue than total response time.

Adam: So I initially built it as just sort of an experimental side project for the company I was working for with the idea in the back of my mind that like if it worked out, maybe it could be a little side business. But initially, it was just kind of an experiment. And yea, it worked out great for us. We used it and it was auto-scaling us reliably for months. Then, yeah, I decided to package it into a Heroku add-on. That was late 2016, early 2017 that I was working on that.

Corey: So where did you start just in terms of building this thing? You decided, "I'm going to make this more general purpose. I'm going to offer it to other developers." How did you start to craft it for that more general use case?

Adam: Yeah. I mean, the initial application was totally hacked together with duct tape and bubblegum. It was a quick experiment that we used internally only. So once I decided, "Yeah, this thing is useful. I want to turn it into a sellable product," it took a lot of refactoring and cleaning things up. But that was also when I started reading the Heroku docs on how to build an add-on, which was actually really easy.

Adam: The process of turning any application into a Heroku add-on is a matter of wiring up a few web hook endpoints to handle provisioning new resources, and changing plans, and de-provisioning them. And handling single sign-on when somebody launches your Heroku add-on. The process of turning what was initially just an experiment into a real sellable application, it took time, especially since this was a nights and weekends thing for me, but ultimately, not complicated. Yeah, the Heroku docs were fantastic, and the whole process was really pretty seamless.

Corey: So you mentioned this was a nights and weekend thing for you. How did you balance this rather major project? I mean, developers would be relying on this for their applications. It's a big deal. How did you balance that with the rest of your life, your day job, your family, et cetera?

Adam: I'm not expert on that. That part wasn't easy and never gets easier, but what made it palatable for me was that I just loved working on it. It was a super fun project that I knew would be useful to a lot of people. And I also took my time on it. Knowing that it was a nights and weekends thing, I didn't expect to have it making money the first month or even ready to put in the Heroku marketplace in the first month. So I really kind of allowed myself to take my time on it. I enjoyed working on it. Another huge thing was that I had my first customer from the beginning because it was the place I was working at the time.

Corey: Oh, wow. Of course.

Adam: We were already using it, and I knew as soon as I got it in the Heroku marketplace, they would be my first customer. And they were, in fact, already using it even outside the marketplace. So I think that was a huge part of it really is knowing that all the work that I was doing already had somebody benefiting from it and that somebody was myself and the other folks that I was working with at the time.

Corey: Did you talk with anyone else as you were in the process of building the wider add-on about the problems they experienced in their companies and with their products?

Adam: No, I probably should have. That's sort of one of the cardinal rules for bootstrapping a business is don't build it in a vacuum, and go out and talk to people, and understand their pain points. But the reality is the approach that I took on this was totally ... I was just building it for myself as I wanted it to exist and just hoping that the problems that I was solving for myself were going to solve problems for other people as well. Not necessarily an approach that I would recommend, but an approach that I got lucky with this time.

Corey: You were confident in it though because you had seen it solve your own problems.

Adam: I did feel that confidence. I think that's why I didn't feel the need to go out and talk to a bunch of other folks. Also, I had no experience doing customer interviews and that kind of thing. Naturally, I just gravitated toward writing the software instead of going out and doing a bunch of customer interviews. But as you say, yeah, I knew that it was already solving a pain point that we had felt really confident that we were not the only ones with that pain point.

Corey: Right. So bring us to the moment where you got your first bit of feedback from a customer that wasn't yourself.

Adam: When I did finally get some folks using Rails Autoscale that I didn't know, it was actually frustrating at first because it's really hard to get people to respond to you, and maybe especially so because my customers are developers. Developers just kind of want you to leave them alone and let them do their thing, which I can relate to. But yeah, so as folks started to signing up for Rails Autoscale and using it, initially, I was reaching out to all of them individually. There was no automation in place. It was, I would see somebody sign up for it, I would write them an email, and very, very few people responded, and that was hard. That was and is one of the harder parts of running this is I want to hear more from my customers, but I don't hear a lot from my customers.

Adam: On one hand, that's a good thing. I don't have a lot of support load. Even today with over 200 paying customers like I hear from maybe two or three a week, and early on, obviously, with only a handful of customers, it was much less than that. So that's been a struggle. When I do hear from folks, it's a highlight of my day, even when somebody is asking a question that I got to dig into. I love interacting with my customers, and I've gotten a lot of positive feedback, so that customer interaction is one of the parts of running this thing that I love.

Corey: Have you made changes to the product directly due to what you hear from a customer?

Adam: Most of the changes that I make these days are directly coming from a customer feedback. The latest major addition to Rails Autoscale earlier this year is auto-scaling worker dynos. So initially, it was just web dynos. Now, it can auto-scale like Sidekiq processes, and that's something that a lot of customers were asking for. It's also something that I needed myself, so it was kind of a combination. Rails Autoscale itself uses Sidekiq, and I wanted the ability to auto-scale my worker dynos. I think a lot of the features that I've added are like that. It's a combination of pain points that I've experienced and customer feedback.

Corey: Let's talk a bit about that new feature for scaling worker dynos. What's the use case there? Why would a company want to do that?

Adam: Yeah. So similar to web dynos, you can choose how many processes you're running essentially. So in the case of Sidekiq, starting out, you're probably just going to have a single dyno running Sidekiq, and it's processing your background jobs as quickly as you can and queue them. But as you grow, just like your web process, you're going to hit capacity on your worker dynos. You're going to start putting too many jobs in your Sidekiq queues, and they're going to get backed up, and that's no good, so you need to increase your worker capacity. So you're going to add worker dynos.

Adam: Just like web dynos, that volume is almost never consistent. It fluctuates, and if you just sort of cranked up your dynos manually anytime you ran into a bit of a pain point, you're going to be overscaled almost all the time. So just like web dynos, it makes a lot of sense to automate that based on capacity measurements instead of just making it guesswork, and cranking it up, and forgetting about it.

Corey: So it sounds like Rails Autoscale has two sides. One is scaling an application, a web-facing application in response to user traffic or amount of request queuing as you said where you need to scale up that user-facing end point. The other side is your background jobs that aren't necessarily user-facing, but they have their own ebbs and flows as well.

Adam: Yeah, and ultimately, for any of these things, speed is what matters. For your web front-end, you want your web front-end to be as fast as possible for your users. You don't want that to slow down. On the background jobs, even though users aren't directly waiting on background jobs to complete, you still need those background jobs to be completed in a timely fashion whatever that is, whatever you define for your app and your particular background queues. So ultimately, the auto-scaling is all about making sure your web requests and your background jobs are completing as fast as possible within whatever thresholds you define.

Corey: So I want to talk a little bit more about growth. When you started this product, you mentioned you had reached out to your first customers and asked how it was going. You didn't necessarily hear back. How did those first customers find you?

Adam: The first customers ... So I'm going to talk a little bit about the process of introducing an add-on into the Heroku marketplace because there's multiple phases. You start out as an alpha add-on, and anybody can build an alpha add-on. I don't think you even need Heroku's approval to do so. In the alpha stage, you're not listed in the add-on marketplace. But if you explicitly invite someone through their email, then they can install your add-on manually through the command line interface.

Adam: Obviously, at that point, you can't charge anybody either. You need to get 10 customers in that alpha stage before you go to the beta stage. The beta stage is when you're in the add-on marketplace, but you've got a little beta flag on your add-on and you still can't charge anybody yet. So people can find you. They can install your add-on, but you can't charge for it yet, so it's free for them. Then, once you get through the beta phase and you get approval, you go to general availability, and then you're in there for real, and you can charge folks.

Adam: So early on, when I was alpha, I was basically reaching out to friends and people I knew saying, "Please install this because I need 10 customers to be able to even get into the marketplace." Really, the folks who I reached out to, I tried to find people I knew that would actually use it and get benefit from it, but a lot of the folks that I ended up reaching out to, either they didn't have a Rails app on Heroku at that time or it was just a tiny Rails app that didn't need multiple dynos or whatever. So most of those folks, they installed the add-on for me so that I could get my first 10 customers, but they weren't really using it, so I wasn't really getting any valuable feedback from them.

Adam: Once I got into beta though and I got in the marketplace, then people just naturally found me through the marketplace, and this is when folks were installing it that I've never met before and they've never met me. They just found me in the marketplace and decided to give it a shot. That was incredibly exciting when people just... people I've never known in my life just found my add-on and installed it, and then I could see... Even if I couldn't necessarily get them to email me back, I could see that they've enabled auto-scaling and that it was scaling up and down, that they were getting value from it, which was awesome.

Corey: Wow.

Adam: But yeah, ultimately, like I wasn't doing any marketing or anything. It was just being listed in the marketplace. They found me there.

Corey: These original customers, are some of them still with you to this day?

Adam: Yeah, yeah. Absolutely. Naturally, some of those folks who tried it early on, maybe they don't have a Heroku app or anything anymore, some of them certainly dropped off, but a lot of them are still with me to this day. One of the great things about this type of product where it's an add-on and it's something that remains useful over time is that there's very little churn. Most of my customers who signed up for it, they end up using it for a long, long time until they no longer have an app on Heroku for whatever reason.

Corey: Speaking of platform and growth, so you mentioned that many customers found you in the marketplace when you were getting started, and this really helped you initially grow, For a developer who's thinking about building a side project and wondering, "Do I build on top of a platform like Heroku?" I'd love your thoughts on the experience of doing that, the considerations that a developer might think about when they're considering building on top of a platform, and how the experience has been for you.

Adam: Yeah. I am a huge proponent of building, especially a side project, in a marketplace like this. So there's a lot of things that I just got for free. One was the exposure. Being in that marketplace, the reality is if you're not in a marketplace like that, it doesn't matter how good your product is if no one sees it. I have no marketing experience. I'm not great at marketing, so I really wanted from the beginning to have at least a place where people could come and find my app without being completely dependent upon marketing efforts to get the word out.

Adam: Another huge benefit to me running it as a solo side project is that I don't have to worry about billing at all. Customers are billed directly through Heroku, and then it's just a single transfer each month into my business bank account, so I don't need to worry about chargebacks, or expirations, or any of the headaches that folks who make their own billing have to worry about.

Corey: Yeah, that makes sense. I mean, I've built a few side projects myself, and sometimes you spend a whole month on that stuff, just the billing basics, the signup, all this stuff that it sounds like you get for free building on top of Heroku.

Adam: Yeah. Of course, it does come with with trade-offs. Anything comes with trade-offs. Obviously, when you're building in a marketplace where billing is handled for you, there's a revenue share model, so a portion of the revenue goes to Heroku and a portion comes to me. Well, that trade-off is easily worth it, in my opinion. I talked a bit about the alpha and beta stage before I went to general availability in the marketplace, and the reality is like that took me, from the time that I started in the beta phase, so I was available in the marketplace, to the time that I went to general availability, close to a year I think.

Corey: Oh, wow.

Adam: Yeah, I think between nine months and a year. That would have gone a lot faster had I actually marketed the thing and been better about getting the word out, but I was wholly dependent upon people just finding me in the add-on store. So that was tough because I was paying to run the service for all that time while I wasn't making any money. Now, of course, I didn't have a lot of users, so it was very cheap to run. I wasn't paying a lot out of pocket, but obviously, I was putting my time into it, and I wanted to be able to charge my customers.

Adam: So that's a trade-off, but the flip side of that trade-off is that Heroku puts those restrictions in place to make sure that everything that's in the add-on marketplace is vetted and really high-quality. It's not just something that somebody threw together in a weekend and decided to put into the marketplace, and that's one of the things I love about the Heroku marketplace is you can kind of trust that the stuff that's in there is real.

Corey: Absolutely. Let's talk a bit about marketing. So you mentioned that you've found a lot of users simply by being listed in the Heroku Elements Marketplace. Aside from that, have you experimented with other marketing approaches?

Adam: A little bit. I have a Rails Autoscale blog that I've done a little bit of writing on but I'm not consistent with it. I started a Heroku newsletter that I completely kind of fell off of and haven't sent anything to that in a long time. The thing that I tried that did work a little bit was I have put some ads in a newsletter called Ruby Weekly, and it's really hard to tell the impact of these sorts of things because my sample size is so low. I get five-ish new customers signing up in a week, but it fluctuates. Some weeks, I'll have zero or one, and then a week, I'll have 10 to 15. It fluctuates so much that when I do something like, "Oh, I'm going to throw an ad in this newsletter," I might seem like I get a little bit of bump when that newsletter goes out, but it could just be a natural fluctuation.

Adam: So it's been really hard for me to tell the impact of sort of any of these efforts that I've done, and that's sort of compounded a bit by ... since the installation of my add-on goes through Heroku, it's really difficult to attribute those installations to how people found me. So when I'm running this ad in Ruby weekly, I can know how many people clicked that ad because Ruby Weekly tells me that and I can see the hits on my landing page, but I have no way of knowing of the installations that I got that week or whatever, how many of them just stumbled on the marketplace and how many came from the ad. So that's been a challenge. I think that's another one of those challenges. When you're building in a marketplace, you've got constraints like that. Yeah, trade-offs, trade-offs all around.

Corey: Sure. Would you say your primary user source right now is your listing in the marketplace?

Adam: Absolutely. Yeah. Of the other users that I've talked to, all of them have found me through the marketplace. I did do... When I was working, when I was building the worker auto-scaling, I did reach out to a bunch of my customers and got several of them to hop on a call with me, and that's when I was kind of able to ask them, "How did you find Rails Autoscale?" Pretty much, all of them was... It was either, "Oh, I can't remember," or "Yeah, I just found it in the marketplace."

Corey: I want to talk a bit about the technical bits of Rails Autoscale itself. Sort of meta, right, because Rails Autoscale itself is hosted on Heroku?

Adam: Rails Autoscale itself is hosted on Heroku, and Rails Autoscale is auto-scaled by Rails Autoscale.

Corey: Whoa, my brain just melted a little. So how has that experience been? I mean, especially as it scaled up itself as it's served this scaling of more and more customer apps? How has Rails Autoscale itself auto-scaled?

Adam: Yeah. I mean, so initially, for the first year, maybe the first two years, it didn't need auto-scaling because it was all just running on a single web dyno and a single worker dyno, and that was fine. As it's grown and I needed multiple dynos, that's when I basically hooked Rails Autoscale up to itself, and that's been fantastic. So I tend to not really think about ops too much and that's... I think especially as a solo developer running a side project, I'm a huge proponent of using hosted services that abstract away a lot of the operational stuff and managing servers yourself because as a solo developer, you need to be focused on building. You can't be spending your time doing ops stuff like setting up servers, and upgrading, and all that kind of stuff.

Corey: It seems like your add-on has really grown and succeeded. I'm curious, what success metrics are most important to you and what are you comfortable sharing with our listeners about the success of Rails Autoscale?

Adam: My definition of success for Rails Autoscale has changed over time. Initially, when I started building it, I had dreams of it taking off, and it was going to be my full-time thing within a year, and that just hasn't happened. It's grown every month since I've launched it in terms of revenue and in terms of customers, and as I said, I'm over 200 customers right now, and that's probably the most important metric to me is that I want more customers each month than the previous month. But the reality that I've had to accept is that until I really want to buckle down and pour some fuel on the marketing side of things, the growth is slow.

Adam: I guess that would sort of be a recommendation that I would make to a developer who's launching a project on the side, especially a SaaS project, is that it's going to grow a lot more slowly than you think it will, so have some patience. Be in it for the long haul, and don't burn yourself out. That's kind of the approach that I have taken is I want to enjoy working on this thing, and I do enjoy working on this thing. The fact that it grows each month and brings in some extra income for me and my family, that's excellent as well.

Corey: You mentioned advice for other developers. If I'm thinking of building a product that other developers would use, what should I be thinking about as I start to devote the time and figure out who my first customers are going to be, figure out what problems I'm solving? If you were to go back and you were at the start of building Rails Autoscale, what do you think is most important to think about?

Adam: I don't want to act like I'm an expert on this because as I've said, this thing hasn't grown into a full-time gig for me, and I know a lot of folks have been able to do that, but I can say what's worked for me and what's been important for me. Building it and solving a real problem, knowing that I had that first customer right away was crucial for me. I've started lots of side projects in the past with the idea of building them into little side businesses, but the reality is I wasn't building them for anyone. I didn't have anybody who was going to use them from day one, and that was key for this is from day one, I started building this, and as soon as I had something working even a little bit, I had somebody who was using it for real in a production environment, and that has kept me motivated from the beginning.

Adam: The other advice that I would have is just to make sure that you're focused on building and don't get distracted by all the other little things, playing with the newest technology, and all that kind of stuff. Use the tools that you know. Use tools that are going to reduce the work that you have to do.

Corey: When you've needed advice or mentorship or you're feeling a little lost on a project, where do you go for that?

Adam: Initially, I didn't have anywhere to go for that and that was kind of tough early on. I have gotten more involved in sort of the bootstrapper community. Last year, I went to MicroConf, which is a conference for independent software businesses. Met a lot of great people there. I'm part of a couple of different slack communities of people doing this kind of thing, and that's really great. It's having communities of other folks who are doing similar things I can bounce ideas off of, and talk about successes, and frustrations, and all that kind of thing. Twitter is a great place for that too. Twitter is the only social network I'm active on, and there's a lot of this bootstrapper community, they’re very active on Twitter, and there's a lot of good folks on there to follow and to get ideas from, and inspiration, and all that.

Corey: Great. Well, I've learned a lot about your journey and about building a Heroku add-on from scratch in your spare time and a successful one at that. So listeners, you can find Rails Autoscale at railsautoscale.com and of course, in the Heroku Elements Marketplace. So thank you so much for joining Code[ish], Adam. This has been a great conversation.

Adam: Thanks a lot, Corey. This has been a lot of fun. I appreciate you inviting me to be on here.