Code with Jason
Code with Jason
260 - Adam McCrea, Founder of Judoscale
In this episode I talk with Adam McCrea, founder of Judoscale, an autoscaler for Heroku and other platforms. Adam built Judoscale as a side project in 2016 and ran it part-time for five years before going full-time. We discuss developer marketing challenges, the difficulty of measuring marketing attribution, and building sustainable businesses. We also compare notes on our respective developer tools.
Hey, today I'm here with Adam McRae. Adam, welcome hey.
Speaker 2:Jason.
Speaker 1:How you doing, I'm good.
Speaker 2:How about yourself? I'm doing all right. Today is my last day before taking a week off, so just wrapping up loose ends and all that.
Speaker 1:Nice, yeah. As we record this, it's Friday, december 20th, so, getting close to the holidays, I don't have any more classes to teach for the next two weeks. I've been teaching a class for one of my clients and it's fun and everything, but it's nice to have a break from having an obligation, you know, having like a calendar item on the calendar every single day, definitely, yeah. So you have founded a startup if that's the word, I don't know how you like to label it A business called Judo Scale. Tell us about that.
Speaker 2:Sure, yeah. So Judo Scale is an autoscaler, initially an autoscaler for Heroku. It was a Heroku add-on for six, seven years before we last year kind of expanded outside of Heroku into Render, amazon, ecs. We're about to launch Railway and Fly integrations. So yeah, it's a third-party autoscaler for when the native autoscalers on platforms aren't quite cutting it for you which was the case with us on Heroku, which is what?
Speaker 2:well, actually, when we built, when we built Judo scale, which was originally called rails auto scale, the Heroku's native auto scaler didn't exist yet, but the things that existed there weren't cutting it for us. So I say us, it was me at the time. It wasn't working for me, and so I built rails auto scale as a better auto scaler and just been kind of rolling with it since.
Speaker 1:Rails Autoscale as a better autoscaler and just been kind of rolling with it since. Okay, and I'm personally interested in both the technical and the business aspects of your business. One thing that I'm always curious about and I had a different guest on the other day I asked the same thing when did this idea come from? And also, like, did you come into it saying I want to start a business but I don't know what? And then you found this idea and like that worked. Or did you have no intention of starting a business and it just kind of developed and next thing you knew you were in possession of a business, because I know it can happen both ways. How did it go for you?
Speaker 2:I very much wanted to start a business.
Speaker 2:I had that entrepreneurial itch for a while, basically the desire to be able to work for myself, decide what I worked on on any given day. I had that dream for a while and started a few little side projects, but nothing I ever got close to even launching to the world. I always, you know, chickened out or, you know, just got bored with it or whatever. But in 2016, the opportunity came about for this because the company I was working for at the time we were a super small company. I was on a dev team of three. We had just moved our hosting from Engine Yard to Heroku something that I kind of drove when I got there because we were just spending ridiculous amounts of money on Engine Yard and not getting a lot for what we were paying. And we saved a lot of money moving to Heroku, but we had the opportunity to save a lot more if we weren't fully scaled up to however many dinos on all hours of the day. So it seemed like a pretty easy thing to just scale it down, scale it up, based on traffic and that kind of thing. Tried a couple autoscalers that existed at the time and they just felt very clunky, very hard to set up, hard to make work the way we wanted to make it work, and so I thought, you know, I'd be like I could build a better version of this.
Speaker 2:At the time, I was also reading a lot of the stuff that Nate Berkapek was writing on Rails performance, and one thing that he talked a lot about was looking at request queue time to measure the capacity of your web servers, instead of looking at things like compute metrics or total response time or something like that. As a quick digression, request queue time that's how much time a request sits waiting to be picked up by your Rails process. Basically just because you don't have enough server capacity to handle all requests that are coming in at once. So it's a really good metric for server capacity. So I was like I want to try building an autoscaler based on this request queue time thing, and so, yeah, I just you, just, you know built it in my spare time.
Speaker 2:You know I asked my boss if, like, hey, if I build this thing would, would you be interested in using it? And you know I would own it and he's like, yeah, whatever, like we're a small company, like really informal um. So, yeah, I built it and you know we used it initially like it first version had no UI. It was just configured via Rails console. There was no way for other apps to sign up for it. It was literally just built for one app, just to see if it worked. And it worked great for us. So I spent a few months integrating it into the Heroku add-on marketplace and launched it in there in 2017.
Speaker 1:Interesting. So it sounds like this was conceived to be potentially a business just right from the very start, and that's also interesting to me that it started with no UI and no way for any other customers. It sounds like to get onboarded or anything like that. It was just this single use case to kind of maybe test the technical viability of the thing. Is that the idea?
Speaker 2:Yeah, absolutely yeah. I wanted to see if this idea for a better autoscaler actually resulted in a better autoscaler and I wanted to prove that out with the most minimal thing possible. And I knew if I built a UI, I'd get carried away with it, and if I built a way for other people to sign up for it, there were just so many things. When you're building an actual product, there's so many things that you need to do. For me, I knew eventually that's what I wanted to do, but I didn't want to go through all that If the thing I was solving, if I wasn't confident that I could solve it. You know.
Speaker 1:Yeah, yeah, I feel parallels between that and what I'm working on. Did you and me talk about the that and what I'm working on? Did you and me talk about the CI product that I'm working on? When we met at RubyCon?
Speaker 2:A little bit. Yeah, a little bit.
Speaker 1:So I'm really not satisfied with GitHub Actions and CircleCI. There are a lot of gripes I have with both those products, and so I decided to build a different CI product and it's not like a super straightforward CRUD app. Same with JudoScale there's kind of some technical unknowns to it, and so there was a little bit of a question of like is this even technically viable? Is this like going to be too big of a thing for me? Is there going to be some unforeseen obstacle that I don't know what to do with? So my first task was to just build like the simplest thing that I possibly could. That could give me as much of a yes or no answer to the most important parts that it could. I recently learned the term steel thread. Have you ever heard about this?
Speaker 2:idea.
Speaker 1:No, I don't know that. Yeah, I don't know why. It's a great metaphor. So the idea is like the idea is to build an entire like end to end I don't know proof of concept or prototype or whatever of whatever you're building and then expand outwardly from there. Like maybe you start with, metaphorically, a steel thread and then you add another few threads and eventually you have a very thick, strong cable, but you don't start with the first part of the thick strong cable, you just start with a thread that goes completely from one end to the other.
Speaker 1:And the idea with that to me, is that you're mitigating the risk, because the last thing you want to do is like start with I don't know, start with the CSS and make everything look really nice without even having anything under the hood that makes it work, and then, once you get to the technical part, you realize, oh wait, this is like a way different thing that I thought and all the work that I've done so far has to be thrown out because I have made some bad assumptions or whatever.
Speaker 1:Part of why I mentioned that is because a lot of the development style that I see, because I get a lot of chances to work with a lot of different developers in my consulting work. They very much don't develop in the steel thread style and it makes me very sad because there could be a lot less waste if people would develop in this way. Anyway, that was kind of what I wanted to do. Can I just have some kind of script that like spins up a virtual machine, runs one single test on it and then gives me the result in some way, and then I expanded from there. I imagine you must have taken a similar approach.
Speaker 2:Yeah, yeah. Well, I want to dig into what you're talking about a little bit because I feel like, if I remember the way you were talking about this idea of yours, part of a big part of what you were frustrated with in GitHub Actions and CircleCI was the experience of it and and the usability of it and all that.
Speaker 1:So I feel like.
Speaker 2:I feel like it's especially challenging for you to prove out your idea without building out at least a good chunk of that experience, right?
Speaker 1:Yeah, yeah, and you know it was, um, it was really interesting. It took me a lot. I don't know if I'd say it took me a lot less time than I expected, but it didn't take me a crazy amount of time to build like an actual CI test runner thing, like it was you know, it was janky as hell and like was missing a lot of essential stuff, or not missing a lot of essential stuff, but like the core stuff was there.
Speaker 1:But yeah, it didn't take a long time to get something that could spin up a virtual machine, run the tests and report the results. And from there on out it was like OK, now I just have to make it so that I don't have to manually refresh the page, but instead it uses a turbo stream to automatically update and stuff like that. So it was more just like grunt work rather than solving mysteries.
Speaker 1:Yeah, yeah, what's the status of it today? Good question it is ready for use and I'm onboarding my first couple customers. My expectation when I onboarded my first couple customers was that it would bring to the surface some deficiencies in the product, which it definitely did. The first thing I discovered is that there's no way to put in environment variables, and so I'm like way to do that stuff like that. And then, for example okay, so this product is a little bit different from a lot of others in the sense that, like it does need a certain level of polish from day one, because the whole proposition is the usability. So it's not like a totally novel product where, as long as it allows you to achieve the job that you need to achieve, it's good enough. Like it needs to actually be like nice to use.
Speaker 1:And so one of the more recent things I ran into was a performance issue. Like when you would go from build to build, there would be kind of a it was like a 700 millisecond delay which you could feel it, and that was like too much. It made it feel janky, um, and so I got that down to like less than a hundred milliseconds and now it's just like I I couldn't stop messing with it, like I was just sitting there like clicking from build to build because it's just like, wow, this is so nice, I'm so proud of what I did. Now it's like it feels instantaneous to use and I really need to get a little bit more disciplined and prioritize getting people on the product, because maybe the stuff that I'm working on at this point is not so absolutely essential.
Speaker 2:You're at the scary part now where you're going to have to start asking people to pay for it.
Speaker 1:Yeah, exactly, and yesterday I just scheduled a meeting with um, with a friend of mine, somebody who I both I think we both know um, and in a couple weeks we're gonna go through it together and I'm gonna try to get him onboarded onto the project just for free, to to vet it and see like will it even work for people? Um, and then you know my, my hope is that my hope and intention is that once somebody uses it for free, for a bit, they're like wow, this actually is really nice. I would never dream of using circle CI. After this, um, I need CI, so I think this is what I'll use for it.
Speaker 2:Yeah, we keep referring to it as the product. Does it have a name yet?
Speaker 1:Oh yeah, SaturnCI.
Speaker 2:Okay.
Speaker 1:Yes, and it is invite only because onboarding is painful and I would never expect anybody to do it on their own right now. Again, that's. That's not the priority um right I'd rather get people manually onto it and then, once it's like, build the plane and then get build the wings to the plane so it can fly, or something I don't know if that door so people can get into the plane.
Speaker 1:Yeah, anyway, back to Judo scale. So you had it working for one customer. Tell me about what happened between customer number one and customer number two.
Speaker 2:Yeah, so getting it working for one customer was really huge because it wasn't like I'm just playing with it locally and it works. It's actually in production, doing production things for a production app. So that gave me a lot of confidence that this thing worked and was valuable. So the process of integrating with the Heroku marketplace isn't that tough. You know you have some web hooks that you create and whatever. But, like I said, like the app had no UI at that point, so I had to build all the things you know. I had to give it a UI and evolve the data model to support tenants and all that kind of thing. Once I threw it into the Heroku marketplace, I didn't really do what you're doing, which is, like you know, practically reaching out to people like concierge, onboarding this stuff. I did the chicken shit developer thing, which is where I just like threw it out there and hope people just found it. Generally is a terrible idea. It happened to work for me because the Heroku marketplace is.
Speaker 1:Well, there's traffic flowing through it already.
Speaker 2:Yeah, developers on Heroku are used to looking in the marketplace for things. So if you put something into the Heroku marketplace, people are just going to find it. It's not going to happen immediately. And so, yeah, in Heroku when you throw something into the marketplace, it sits in what they call alpha state, which means it's not in the marketplace and it's invite only. So I did have to reach out to a few people at that point. Then, once I got to like 10 people, then I could get it into the marketplace, but it had a beta badge on it and I couldn't charge for it. But people could find it and install it on their own. Had to hit a hundred customers there before you can go to general availability and actually charge people for it.
Speaker 2:That took most of 2007,. Honestly, Because, like I said, I wasn't really marketing it. I was just like, oh, people will just find it. And eventually they did, but it took a while. Right, it took nine months to hit that number, but as customers were using it, I was talking to them and making sure it was useful for them. And, yeah, so for the end of 2007,. I think December 2007 was when we finally went general availability and I was able to start charging new signups and then, yeah, from there I continued along the same path of not really marketing it and just waiting for people to find it, which is why it was a side project for, you know, five years and I didn't go full time on it until 2021. So I wouldn't necessarily repeat that part, you know.
Speaker 2:I would do a little more marketing, I would talk about it a bit more than I did, but Wait, did you?
Speaker 1:mean to say 2007 or 2017 17 did I say seven yeah yeah, I'm like, oh wow, it started way earlier than I thought, um, but then I thought like, wait, heroku, like that timeline doesn't add up. Um, right, right, yeah, okay. Um, well, that's really interesting because, because there's always a question of how to get customers, that's the whole thing. If you can get customers, you're all set and you can figure out the other things. They're almost trivialities in comparison, and if you can't get customers, then nothing else. Um, and I think, like something I think about a lot is like finding out where people in your target market are already congregating and go to where they are.
Speaker 1:Um, I'll share an awful story real quick. Um, I was working on a product from 2011 to 2015. I made, uh, scheduling software for hair salons, and there's all sorts of reasons why that was not a good idea for me to do, but one of them was that it was hard to reach these people. They're not big computer people and so the ways to reach them are to like go, go, go to them in person, physically, or go to trade shows, which I guess is just another way of going to them in person, and so that was tough, like if I wanted to go to where they're. And you know, talking about where people congregate, like there's not a lot of congregation happening, they're just working at their salons.
Speaker 2:Right.
Speaker 1:Yeah, and so that wasn't great. And then, something that's different about Saturn CI is like the customer base. Like I know exactly where they are and how to reach them. I know exactly where they are and how to reach them, and Saturn CI only works for Rails and specifically only for RSpec, and so that really narrows it down. I'm in the Ruby community all the time, I'm very involved, and so it's very clear for me how to reach people and in the beginning this is like we kind of touched on it's.
Speaker 1:It's a bit different from how you went early on with judo scale. Um, it's very manual. Saturn ci doesn't even have a website yet and I'm gonna kind of lazy load that part where, like, I'm to like reach out and grab people by the lapels and say, hey, I'm going to you know. First of all, do you want to try this? Okay, great, now I'm going to drag you through the process every step of the way very manually and then maybe, once I get I don't know five people onboarded in that way, then I'll like get it a bit more automated. The reason for that part of the reason for that is because it's just it's easier in certain ways to like get on a call with somebody and just like kind of say, do this, do this, do this, rather than like giving them a signup page and say I hope that you carry through with all the steps and are successful and stuff like that.
Speaker 1:And the other reason is because, again, I expect to run into snags with this process, both technical and non-technical, like I suspect that I might find out that the people who I think are good candidates for the product are not or you know, I'll probably learn things that I didn't even know, that I didn't know through that process of onboarding the first five people or so. And so I feel like it's more in sequence to like get those things ironed out and then try to automate it, rather than trying to automate it before I get those things ironed out. There has to be a metaphor here, but I don't know what the metaphor is. Anyway, so when you put this on the Heroku marketplace, that was the where are the people in your target market congregating? Maybe congregating isn't the right word, but that's where they were, and so you could go there and reach them that way, and it sounds like it didn't take, like maybe you could have gone faster if you had done additional things too, but that was enough.
Speaker 2:It sounded like yeah, yeah, you know it. I ran it as a side project for five years, but it's not like I was working every night and weekend on it, like it was a very sustainable pace while I was, while I ran it as a side project, I was. I was maybe working most nights and weekends when I was initially building it. I mean that's when the excitement was high anyways, and I didn't mind it, like it, I was just, I was just excited to just plow forward on it and get this thing built as quickly as I could. But then, once it was just kind of in the marketplace and slowly growing, I was adding things to it, I was improving it, I was working on it and enjoying working on it and I was kind of content with it just being this side project that brought in some extra money. It was fun. But eventually I definitely I, you know, I definitely did have the itch to go full time on it. And that's when.
Speaker 2:That's when I started, you know, trying to think about marketing a bit more seriously, trying to start writing a bit more. You know you mentioned where, you know, where does your audience congregate. Well, our audience was the same. It was Rails developers. You know, we were initially just targeting Rails made the mistake of putting Rails in the name of the product, which I commend you on not doing. Going to Ruby conferences, reddit, there's all these places where there's Ruby Newsletters. You've got Ruby Weekly. There's all these sort of obvious places to ways to reach Ruby developers that I hadn't really tapped into initially.
Speaker 2:So, yeah, eventually I started taking that a bit more seriously and even then it's been a slow ramp for me to take marketing more and more seriously. And even then, like it's been a slow ramp for me to take marketing more and more seriously, even today, like it, I do have, you know, a full time developer on the team now, so I'm not solely responsible for development, but I still like doing development. So, like you know, I divide my time maybe half and half. Half and half is kind of my goal. I probably still do more dev than I should because the marketing is harder and less fun, but I'm not going to stop doing dev. I love doing the dev and I think a half and half split for me is sort of a good sweet spot where I'm able to do the things that I enjoy while doing the things that are moving the business forward in a way it needs to.
Speaker 1:Yeah, yeah, and there might be people from the outside who have opinions on what you should do. It's like you should be doing less coding and more work on the business side, but it's like it's your business. Like if, if that's what you want to do, then like that's a totally, totally valid choice, right? Like?
Speaker 2:it all depends on, like, the desired outcome. If my goal was to grow judo scale as quickly as I could and sell it well, then yeah, I should probably not be doing dev at all and focus all my energy on marketing. Um, that's not my goal, like I. I you know, maybe one day somebody wants to buy judo scale and the price is right and I can't say no. But like, I'm not building it to sell it, I'm building it as a sustainable, independent business that I am going to enjoy working on for the foreseeable future. So, yeah, with that goal, yeah, it makes perfect sense to balance my desire to keep doing dev and, you know, the marketing alongside it.
Speaker 1:Yeah, I'm curious about where you want to go from here on out and I want to talk more about that. But first, going back in time again, I'm curious what worked and what didn't work for your early marketing and that stuff? You know it's not always attributable. You can't always tell what worked and what didn't work for your early marketing and that stuff. You know it's not always attributable. You can't always tell what worked and didn't work. But yeah, tell me about, about that a little bit I still don't know what works and what doesn't work.
Speaker 2:um, and I've I've kind of given up trying like I don't, I don't really even track, I don't even attempt to track attribution or conversions or anything like that, probably to our detriment, but it just got so frustrating trying to answer those questions when there was no clear answers at all, because the reality is somebody signs up for Judo Scale today. Maybe they saw one of our blog posts today, but maybe six months ago they saw another one of our blog posts today, but maybe six months ago they saw another one of our blog posts and maybe three months before that somebody on their team had mentioned it to him. Like there's just there's so many touch points and it's um so hard to know what actions actually drive the results. Yeah, and maybe that's.
Speaker 1:Maybe that's a bit of laziness on my part, um, I don't think so getting exhausted from digging into it yeah, I'm I'm actually glad to hear you say that because, like, I feel like too many people um have the wrong idea about it. Like, as developers, we can often get away with just like trial and error and we do a thing and observe the result. And it's like we can do. We can take actions without much thought and observe the result and tell retrospectively whether it was good or bad, or it worked or it didn't or whatever.
Speaker 1:But with marketing you don't really have that ability because, one, the time scales are often too long. It's not like you can type something and press enter and see the result like you can with programming. It's like you might have to wait months or years before you would know the answer. So the feedback loop is too long and oftentimes the feedback loop is kind of non-existent, like you take actions and then things happen as a result, but you don't know which of the actions led to the result. And so, instead of operating by trial and error, which is like really popular business advice to like make hypotheses and test them and stuff like that, but what you really need is like an actual deep understanding of how the world works and what you need to do in order to get what results. And then do those things even though you know that you'll never be able to directly attribute cause and effect.
Speaker 2:Right, right, yeah, I think that that that's well said. Yeah, I think in my mind I have an idea of the things that I think are wise moves from a marketing point of view. From a marketing point of view, and if I do those things and Judo scale continues to grow each month, I'm just going to assume that what I'm doing is okay. I don't know what of all the five things I'm doing are most impactful, and I don't think there's any way to peel those apart, because I think, at the end of the day, it's a cumulative, it's the way all of those things compound on each other.
Speaker 1:Yeah, yeah, like for my consulting work, my marketing includes my email newsletter, my snail mail programming newsletter, this podcast, my YouTube videos speaking at conferences, just going to conferences, holding my own conference, doing networking calls and blogging, writing books and a few other things and like who knows exactly what effects those things each individually have. And it also doesn't even make sense to talk about individual effects because they mix with each other. Kind of like you said, somebody might see a blog post and then hear a podcast episode and buy my book and then we work together in a consulting capacity or something like that. It's really impossible to tell.
Speaker 1:Yeah, I think, at the end of the day, it's less of a science than we would like it to be, especially as developers where you know how do I, how do I tdd my marketing, not gonna happen yeah, well, I think maybe a lot of developers and you know people who like like the lean startup book and stuff like that I think they maybe misunderstand what science is, because science isn't just about like rapid formation of hypotheses and performing tests and stuff like that. Like I saw this comment once that really bothered me. You know that book, guns, germs and Steel. It was written by Jared Diamond, who's a biologist, and somebody was commenting on how we can't do science on the past because science is about experimentation and you can't perform experience on the past because the past already happened. And I thought it was such a misunderstanding of what science is because it's not about performing experiments.
Speaker 1:The only reason we perform experiments is to generate data, and performing new experiments isn't the only way to get data to analyze, because science is about developing explanations explanations for how things work and why they work, how they do, and stuff like that and you compare your explanations with the data to see how well your explanation fits with the data. And you can absolutely do that with historical things. You can say, okay, there's fossils in the ground. Is it likely that they're put here? Because there is a god and a devil and the devil put the dinosaur bones there to trick people? Or could it be that there were organisms that lived a long time ago and they died and their bones got replaced with minerals and that's what happened? Which explanation fits the facts better? Which explanation fits the facts better?
Speaker 1:So, coming all the way back around to the marketing stuff, um, I think you know, I, I think there's nothing that's untouchable by science, and so the marketing stuff is all about psychology and human behavior, and so that's the area to study. And again, it's like it doesn't work to like throw things at the wall and see what sticks. If that does work, it's only because of great luck. So what I've done is I've spent quite a lot of time and attention studying psychology and human behavior and stuff like that, to see what works, and if I do certain things, what can I expect, even if I can't immediately observe the results? So that's my monologue about that.
Speaker 2:Yeah, I think I agree with most of that. I think the metaphor of throwing things to the wall and seeing what sticks I think you've done some research and you've had some experience to give you a better idea of what to pick up and throw at the wall. But at the end of the day, I do still feel like we're just throwing stuff at the wall to see what sticks. I just think we can make mindful choices about what we pick up and throw at the wall to see what sticks. Um, I just, I just think, um, you know, we can make mindful choices about what we pick up and throw at the wall, and we'll get better at that with time. Just, you know, not even necessarily being scientific about it, but just noticing the patterns, noticing, um, what feels like it works, even if you don't have, you know, objective data to support it yeah, interesting.
Speaker 1:Um, yeah, that's definitely true that we can educate ourselves and come up with better things to try. Um, yeah, I don't know, uh, that's a that's a very deep topic that we could go really far into if we wanted to, I guess. Ok, yeah, and some of the specific things. Like you mentioned Ruby Weekly that piqued my interest, because I kind of forgot about that. Do I remember correctly that maybe I've seen ads for judo scale in Ruby Weekly? Have you advertised there?
Speaker 2:Yeah.
Speaker 1:Yeah, and that's probably a kind of measurable thing, right.
Speaker 2:I mean we can measure the clicks, but that's where it stops. Like I don't know of people who clicked an ad in Ruby Weekly who became customers. Now that is probably something that I could measure with the right cookies in place and the right tracking software or whatever. I just don't think it's worth it At the end of the day. I don't think One thing. The sample size just isn't big enough. I mean, maybe we get a couple customers from a Ruby Weekly ad, but it's not going to be a big enough sample size to be like oh yes, this is definitively working or definitively not working. It's like well, sometimes it might work well, sometimes it might not work well. At the end of the day, I just think it's a good idea, so I'm going to keep doing it.
Speaker 1:Yeah, yeah. Again, you just have to use logic and understanding rather than retroactively testing. Because, you're right, like Ruby Weekly, I think, has like 40,000 subscribers, and so for any ad, if 1% of people click on it, it's like 400 people, 400 people come, maybe four of those become a customer and it's like can you really like A-B test something or something like that to really like a b test something or something like that to tell what's a better ad, or something like that? Um, yeah, um, that's something that I might try for, uh, for saturn ci at some point is, uh, is putting some ads in rub Weekly?
Speaker 1:I remember something that Rob Walling said one time. He said, with email marketing and blog posts and stuff like that and the kind of personal brand marketing that can get people to buy e-books and stuff like that, but for a product it doesn't work so well. That's what I remember Rob Walling said, and he talked about other things like search advertising and stuff like that. Have you been able to get a sense of whether that kind of stuff, like blogging and stuff like that, works very well versus these other kinds of things, or is that kind of hard to tell too?
Speaker 2:It's hard to tell. I can tell you my hunch. My hunch is that, um, it's still depending on the kind of customer you want. It still helps to have a personality, like how many people have tried HoneyBadger because they've met Josh or Ben at a conference and they think they're cool guys, they're just really nice guys.
Speaker 2:It happens it feels good to know the people behind the thing that you're using, especially, I think, in a tight knit community like the Ruby community, if you're talking like enterprise-y software, whatever, that matters less. Especially, I think, in a tight-knit community like the Ruby community, I think, if you're talking enterprise-y software, whatever, that matters less. But the customers that we're focused on are the smaller companies, the companies of one to a hundred, maybe a few hundred, and when you're looking at teams like that, I think that's where, and especially, the people who sign up for our products whether like Honey Badger or Judo Scale or I think even Saturn CI it's developers. Maybe it's a CTO if it's a really small company, but it's more of a bottom up approach. You're not selling up approach, you're not selling the executives, you're selling the developers, and developers like to have that personal connection, I think.
Speaker 1:Yeah, I definitely think that's true and if nothing else, I think it can get the ball rolling. Like I'm not expecting that my like minor celebrity status in the Ruby community can like carry me all the way to where I'm trying to get to with Saturn CI, but I do think it can get things started. And, you know, maybe I can get a couple dozen customers just by like doing manual outreach to people, I know, just by doing manual outreach to people, I know. But that's probably a heck of a lot better than starting with nothing and just trying to go straight to ads or cold outreach or something like that. Yeah, so I think, even if it I guess this is just saying the same thing but even if it's not the only thing, like getting the juices flowing like that definitely, definitely is very helpful. I don't know how much it's going to help later or not, but probably certainly more than zero.
Speaker 2:Yeah, and again, I think it's also one of those things where, at the end of the day, I don't know which approach is more effective, but I know which approach feels more authentic to me and, and if I'm going to be doing this for a while, I want to feel good about it and it feels good to me to have a personality to the business. For you know, if you think of Judo scale, I do want you to think of me and my personal brand, because that feels genuine to me. I like thinking of the actual humans that are behind the things. Like I said, whether or not that's effective or the best business approach, I don't know I'm going to do it anyway.
Speaker 1:Yeah, yeah, a lot of the stuff. There's just like no way to know. But, like you said, I don't know. But I'm going to do it anyway. And, by the way, that seems to have worked well for Chris Oliver. You know, first there was Go Rails and it seems like he took kind of a stair-step approach where Go Rails was the first thing and then he built off of the success of that to do Hatchbox and Jumpstart. It seems like probably Hatchbox is like the bigger of those of those two.
Speaker 2:that's just kind of a guess, but anyway, like the personal brand thing seemed certainly to help yeah, and if and if chris wasn't such a likable guy, they probably would not have grown the way they have.
Speaker 1:Like I, that just or if, or if he just, like you know, hid behind a corporate brand and nobody knew who he was, I don't think they would have grown like they have right, like a lot more people are interested in listening to the remote ruby pro remote ruby podcast, which chris is on, than like something called the um the hatchbox podcast or something like that.
Speaker 2:Yeah, yeah.
Speaker 1:Yeah, okay, maybe let's talk more about the technical aspects a little bit. You mentioned that, you well okay. So what like stage or size is a customer going to be at when they're going to be? Is there some kind of distinct pain point or threshold or something they go over where this product starts to make sense?
Speaker 2:your hosting bill, or frustrated by getting alerts because your site has slowdowns or timeouts, that kind of thing. I think anybody with those frustrations is going to benefit from auto-scaling of some type, because if you're not auto-sc, you're almost certainly over scaled most of the time, paying a lot more than you should for your hosting, and some of the time you're probably under scaled because traffic is not consistent. And under scaled is even worse because that's when things time out, that's when the site goes down.
Speaker 1:So I think any production site needs to have auto scaling in place yeah, interesting, because I guess I wasn't thinking about the other side of it. I was thinking most about mostly about scaling up, but I wasn't thinking about scaling down during off hours and stuff like that, because this is total waste if you're not scaling down right, right, yeah, so different customers come to us from those different angles.
Speaker 2:I would say you know the smaller companies, maybe the companies of 10 people or less. They might be more interested in the cost savings aspect of it because they're running on slimmer margins. They're just a smaller company and that's the reality of that, whereas as companies grow beyond that they're less cost-sensitive. They're willing to pay many thousands of dollars a month for their hosting. That's just part of the game. But any sort of timeouts where there's customer impact or where developers are getting woken up in the middle of the night, like that's more the issue with them is like but they just want to make sure that their app is up and running reliably all the time okay, um, and how do you like?
Speaker 1:how does judo scale? Know when to scale stuff up and down?
Speaker 2:So there's two metrics that we track. On the web side, like I said, we track request queue time. That gives us an idea of how close to capacity the web servers are, the web dynos, services, whatever, whatever web containers you've got going on there. But then on the background job side, like for Sidekick, there we're tracking queue latency. So if you've got, you know, a Sidekick queue where you expect jobs to be picked up, you know within five seconds. You probably want that to scale up if your latency gets higher than five seconds. So we're able to auto scale based on queue latency. It really helps for you to like set up your infrastructure so that your scaling aligns with the expectations of your various job queues.
Speaker 1:Okay, this is making me think about my own scaling challenges. I might not have to cross this bridge for a while, or I might, I'm not sure yet. But with Saturn CI there's kind of a problem where if I don't have any like virtual machines at the ready, then when you run a test suite you have to wait for a new virtual machine to spin up, and that's kind of wasteful because you're waiting like one minute just while nothing is happening, no tests are being run. So so I could have virtual machines sitting there at the ready so you don't have to wait that time. But the question is, how many do I have just sitting there? Because if I have a whole bunch of them just sitting idle, then I'm paying for nothing. But if I don't have enough, then they'll run out and people will start to have to wait, and that's not good. Um, does that seem like basically the same problem, or at least a similar problem to to auto scaling when, when spikes happen?
Speaker 2:I would say similar, but I think what you're talking about is almost like pre-scaling, because you're trying to scale up ahead of the need, um, which unfortunately isn't something that we're able to do. I think, yeah, in your case you, almost you have this like, um, this buffer, this margin of extra capacity you want to have at any given time, um, that way you can, you, you can, you can tap into it instantly, but then you need to be provisioning more, so you maintain that buffer and then, as you don't need them, you bring it down. So I think at a high level it looks similar. This auto-scaling is going up and down, but, yeah, you're scaling ahead of the need. So I think at the end of the day, it would work similarly. You'd just be measuring different things. You'd be measuring the sort of extra capacity, the buffer that kind of maintains some consistent buffer there.
Speaker 1:Yeah, I can imagine a number of different ways of attacking it, like I could track historical usage and then predict future usage based on historical usage. You know going to want more capacity on weekdays than weekends, and stuff like that. That's going to be a bit imperfect and I was curious whether judo skill does something like that, where it's like predictive based on historical usage and stuff like that. But it sounds like the way it works is based on what's happening now. Is it like trending up and, if so, add more capacity? That kind of thing.
Speaker 2:Right, right, right right. I mean, when it comes to most web apps and job queues, there might be some consistent patterns on like a daily or weekly basis, where it's like oh, you know, this time of day, you know we're going to see an increase and then we'll see the ability to have like daily and weekly schedules for that reason. But beyond that, I just don't see a lot of predictable behavior. Things are just traffic is unpredictable.
Speaker 1:Yeah, yeah, that is true. Um, okay, well, probably got just a few minutes left. Is there anything that you wanted to cover that we haven't covered yet?
Speaker 2:I don't think so. Yeah, I just kind of wanted to catch up. I'm glad I got to hear a little bit more about Saturn CI. Yeah, I definitely wanted to chat about that and yeah, there was nothing specific that I wanted to cover, I guess.
Speaker 1:Yeah, well, one of my last questions for you is, now that you're at the stage you are now, what are you envisioning from here on out?
Speaker 2:Company size. Company wise, I don't have any visions to grow Like. We're a team of three right now and it's a great size and I'm having a lot of fun with it. So I want to stick with that for a while and I don't think we'll need to grow. We're a team of three right now and it's a great size and I'm having a lot of fun with it. I want to stick with that for a while and I don't think we'll need to grow.
Speaker 2:Honestly, we've kept the product simple and mostly it just runs itself at this point. So we are expanding platforms. Like I said, last year we expanded to render an Amazon ECS and we're about to expand to Railway and Fly. So we're just trying to. You know, we don't want to be completely tied to Heroku. Heroku is still the majority of our business and we still run on Heroku and we love Heroku. But we're hedging our bets there. We want to be able to be the auto-scaling solution, no matter which pass you're on. So we've got that about ready to roll out um got some other you know features. We have planned um beyond that. It's just kind of making small improvements here and there, trying to keep the product as simple as we can yeah, that sounds, uh, very much in line with my intentions for Saturn CI.
Speaker 1:in the event that it does work out, I want to keep it simple and I want the business to be not like a huge burden on myself. You know, just from my selfish perspective, I want to be able to have the freedom to like do stuff that I wouldn't be able to do if I just had a job, and stuff like that, which, by the way, it sounds like we talked a little bit about this when we talked in person. Maybe it was kind of like a lot of responsibility until you started hiring people and now you're able to have a little bit more freedom to like take a vacation and stuff like that yeah, I mean so I I brought on our first full-time developer, carlos antonio, who's who's also a rails core team member.
Speaker 2:Um brought him on earlier this year and it's it's been life-changing for me because I mean, for one thing, I mean Carlos is just an amazing developer and he's just a great person to work with, but now that somebody else is full-time, I've got somebody to rotate support with. So I'm not. You know, I've basically been on call from the day I put Rails Autoscale in production in 2016 until, you know, until earlier this year when Carlos and I started rotating support. So, yeah, it's been wonderful to be able to take vacations now and just have weeks off of support. I mean, support load for JudoSc scale is not that heavy. We get maybe I don't know roughly five support tickets a week and production incidents are extremely rare. So being on support isn't an intense role or anything like that, but when you're on call without a break for years on end it takes a toll, it never leaves your mind because something always can happen.
Speaker 2:Yes, it's that background thread that's just running in my brain and yeah, it takes a toll.
Speaker 1:Yeah, I was on call 24-7 for a number of years myself and it definitely took a toll. And when I finally got away from that and I wasn't on call anymore, it was just so different, even though nothing was actually different. It was very different because I didn't have that background thread running anymore yeah yeah, um, okay. Well, uh, if people want to find out more about judo scale Scale and maybe even try it out and stuff like that, where should they go?
Speaker 2:JudoScalecom is the place to go If you just want to hang out with me. I'm Adam Logic on Blue Sky. Same on LinkedIn. I'd love to see you there.
Speaker 1:Awesome. Well, Adam, thanks so much for coming on the show. Thanks, Jason.