Ben: I'm like, alright, you know what? We deserve better than that. And other developers deserve better than that. We can build this product and we can do it better, and we can give better customer service than that.
Like, it felt like a low bar, really.
[00:00:16] Intro
Andrew: Hello, welcome to Dev Tools fm. This is a podcast about developer tools and the people who make 'em. I'm Andrew and this my co-host Justin.
Justin: Hey everyone, uh, we're really excited to have Ben Curtis on with us today. Uh, so Ben, you are one of the co-founder, co-founders of Honey Badger. Um, and you've launched Rails Kit, and you've just. Done a lot of stuff. Uh, and we're excited to chat about all you've been working on. Um, but before we dive into it, uh, why don't you give us a little bit more background on yourself.
Ben: Sure. Yeah. Thanks for having me. It's, uh, it's a pleasure to be here. Uh, yeah, I, I do a lot of stuff. I don't, I don't need a whole lot of sleep apparently. That's one of my. Gifts or curses, depending on how you look at it. Uh, so I love to, I love to play with tech ever since I was, I dunno, about eight years old or so, got my hands on a TRS 80, you know, and, and copied the programs outta the little magazines that we got.
Um, yeah, been been doing that ever since then. Grew up with the, the BBS scene and, uh, turbo Pascal and, you know, all that stuff. And I've just, I just always loved playing with computers and making them do things. So that's, those are the kind of projects that I'd love to do.
Andrew: Yeah, you've, you've been here since the start. You've seen the full spectrum of what web is, at least the worldwide web. Uh, so, uh, like what got you into web since you were a kid, you kind of had like, the world was your oyster and you chose web, and then how did that lead to Ruby?
Ben: Yeah, so, so pre-web, I was actually pretty interested in, uh, muds and Mo. I don't know if you ever did that back in the day, but, uh, yeah. So, you know, um, back when there was IRC and Usenet and the dinosaurs run the earth. There was also this little thing called a mud or a moo, or a mush depending on your flavor.
And uh, you could tell net into a machine and you could have a chat with people and there would be some that were just about chats and there'd be different rooms. And there were some that are actually about games, like think picture ork, right? But, uh, multiplayer basically over tell net, uh, where you go from room to room and you might build things and there was some crazy stuff happening.
Anyway, I wanted to build one of those. And, uh, so I got in to see and the Unix world. And, uh, that was, that was really how I got started on like collaborative spaces and interactivity and that sort of thing. That's about the time that like Gopher was the, the highlight of how you would get data on the, on the internet, right?
It was all still kind of a bunch of research guys, universities doing stuff and ways, the wide area information system, I think is what it was. Uh, those were high tech and super happening, uh, before the, the whole worldwide web launched. Um, and I remember vividly like the day I walked into the computer lab and I saw.
The cello web browser running on Windows 3.1, and I saw a website that had an image in it for the first time and I was like, oh man, there goes all the right bandwidth, right? Like, because I was used to like all text and you know, blah, blah, blah. Um, so yeah, it's, so going back to that is I just, I've just got addicted, I guess, to being online.
Like a lot of us have, uh, just maybe just a little bit earlier than, than some, uh, and just haven't gotten away since then.
Justin: That's awesome.
[00:03:19] Finding Rails Magic
Justin: So yeah, let, let's talk a little bit more about your, your involvement, uh, with Rails. So I know like. Especially for a lot of folks who were doing, uh, well development around, you know, nine, nine, 2000, like in, in some of the early days and like moving on. It's like when res hit the scene it was like huge.
It was like a, a, a big deal because, I mean, frameworks before it were. You know, not as, not as nice. Not as ergonomic to work with necessarily. Not always. Uh, there were some good ones, but, um, yeah. So, so tell us about that. How did you get involved with Rails? How'd you discover it? What did, what did that, uh, what was that experience like?
Ben: Yeah. Yeah. Like you said, 99, 2000. The web scene was really heating up. There was, you know, businesses launching on the web for the first time and uh, uh, you know, back in those days I was doing Pearl and PHP. And, uh, Pearl had some, some interesting web stuff, but it felt like it didn't really fit all that great.
And so when PHP came out, especially version two, I was all over that. It's like, oh yeah, a, a language purpose built for the web. This makes total sense to me. And I just dove in. And then, you know, like he said, yeah, there, there were some frameworks and there were some patterns that were starting to develop over that, around that time.
But it was pretty rough and a lot of times, like you built your own stuff, right? I like, uh, by the time I was done writing PHP, I had my own database abstraction layer. I had my own view template layer and had to come up with my own patterns. And that was like the thing that really appealed to me about Rails when I first saw it.
It's like, oh, like. All the patterns that we've learned over the past several years, uh, are just baked in to the framework. And I guess it's, you know, no accident that DHH was also a PHB developer had the same kind of background happening, and, uh, so they just kind of clicked in my brain. It's like, yes, we've got routes, we've got database.
Well, I mean, the first launch of Rails, we didn't have routes, but, you know, that's, that's pre wind. Oh, no one remembers that anymore. Um, but. But you know, like, yeah, these things like how we learned how to do in the PHP community became just baked in. And so it was actually particularly funny like later on when Laravel popped up, like taking a lot of inspiration from Rails, it kind of came full circle, right?
Bringing all that stuff back to the PHP community. So that's great. But yeah, like 2005 I think is when I first learned about Rails on slash dot and saw that 15 minute, uh, video that DHH put out. Started diving into it and, um, little known fact, I'm actually one of the recipients of, of Dave's, like early on incendiary posts, like where he was always, you know, 'cause his marketing strategy was basically like attack.
Anyone that attacks me, you know, that doesn't love rails. And, you know, me being a PhD P guy, I was like, well, rails looks cool, but it's got these things and I'm not sure. And it's kind of early on and, and I got, you know, both barrels from Dave. But that was, it was awesome. It was fun. So I went and chatted with him at a conference later.
I'm like, Hey, remember me? He's like, he did remember me, of course. But, uh, it was, uh, it was great. It was good fun. And you know, it didn't take me long to really become convinced, converted, or whatever you wanna, whatever word you wanna use. I remember I was at a job where I was doing a lot of PHP and Pearl.
And, uh, I knew that the job wasn't gonna change. Like we had a big platform. It, you know, we weren't gonna just bring in something brand new. And so I'm like, well, time to find a new job. You know, so, so I did, uh, so I could derails.
Andrew: And a lot of rails. You did. Uh, so one of the first things I wanna talk about is you kind of got into the selling software business quite early, uh, with your Rails kit, which is like a, uh, purchasable purchasable starter code for, uh, for Rails. What did that experience kind of like teach you about, uh, selling software?
Ben: Well, it taught me a couple things. A lot of people had a lot of negative issues with the idea of selling software. Um, and, you know, I guess to be expected this rails was open source. Uh, Linux was open source. Uh, Apache, all the things that we were building on was all open source, right? And so the idea that you would have to actually pay for some software was pretty.
Very repugnant to some. Um, but at the same time, I also learned that, you know what, there are a surprising number of people who understand the value of software and the time savings that it can be in your life and how that's worth actual cash. And they're willing to pay. Like, so I, many times I'd be at a conference and I'd be talking to somebody and they'd be like, oh, I can't, I can't imagine you have any success with that and blah, blah blah.
Like, no one's gonna pay for software. And I'm like, well actually, if you looked at my revenue, you would see that there are plenty of people paying for software. Uh, so yeah, it was kind of an early indication, really like, hey, like don't always believe what the zeitgeist is or whatever. You know, everyone knows to be gospel, you know, it's like, uh, if you think you can do something, go give it a shot, and who knows?
You might actually find that, that this is different.
Justin: Yeah, makes total sense. I mean, I think, uh, even like the, I mean, larva community tailwind, like a bunch of these, there've been a long tell of community. That are like, you know, if you can take some expertise and taste and skill and pre-packaged together like tools and frameworks in a way that folks don't have to just mess with 'em and they can just get to the thing that they want to do, people will pay for it.
Um, well, at least historically, uh, the, the new age is, is interesting and maybe we can talk about that a little later
on.
Ben: definitely talk about that. Yeah.
Justin: Uh, before we get that far, uh, uh, one interesting thing while we're doing research on you is, uh, so you had actually written the original like rails, plugin directory before gyms were like a thing.
Uh, how did, how did that happen? How did that come about?
Ben: Yeah. So, uh. Got into rails and like plugins were the way that you distributed some ready-made package for Rails. Right? We didn't have gems as bundler to have that. Uh, so if you built something that you wanted to share, it was, it was gonna be a plugin. And the way that it was originally shared, like we didn't have GitHub then either.
Uh, so there was a, there was actually a wiki. So the Ruby on Rails site was basically a wiki and there was a page or pages for plugins. So if you had your access list plugin or you know, there's a few of 'em like that, uh, you would list it on the Wiki page and pretty soon it became apparent that it was just not scalable, right.
- Sure. But a hundred plugins now you can't find anything. Right. You couldn't really search for it. So I was like, well, this would be a great project to do. And uh, so I was still, you know, still early days Rails, still learning about rails. I'm like, I was always looking for projects to build and so this was a great one.
So yeah, I thought, hey, we could use a plugin directory. So that was, I was fun and uh, gave me a lot of exposure, I think, to the community. Like just meeting people. That was cool. Like I still have friends today that I met doing that. And uh, also. You know, speaking of rail kits basically gave me kind of a stepping stone to get there, right?
Having those interactions with people, being a part of the community, having given something to the community of value, then it was easy for me to go to people and say, Hey, now I've built this thing, uh, maybe you should check it out, right? And I was already, already a known quantity at that point for a lot of people.
And so they're like, oh, you know. It seems like something reasonable. So, um, it wasn't necessarily a strategy. I wasn't like planning this step by step. Oh, I'm gonna do this, I'm gonna do that. Uh, but it was, you know, I just, I really enjoyed being a part of the community and I really enjoyed the open source aspect of giving things back.
That's, and that's the reason why I built Faker, uh, like that was a. A Pearl Library that I had loved from the Pearl world and I was missing it, and the Ruby world, it didn't exist. And so I was like, okay, let's, lemme build this thing. And by this point we did have gyms and so that made a little easier. But you know, it was just giving back and doing something that I thought is cool and fun and then, and then sharing that~~ and.~~
Justin: Mute it.
Andrew: Le
[00:10:34] Honeybadger Bootstrapped Growth
Andrew: t's move on to talking about what you've spent the last 13 of years of your, well, 14 years now of your life on, uh, honey Badger. Can you tell us what Honey Badger is and what kind of was the genesis of the project?
Ben: Sure, sure. Honey Badger started out as an exception monitoring service. Uh, so back in the day that it launched, we had things like, um. Hop towed, which became air brake, which a lot of people use. There's also Air Bit and that's, I think is still around as an open source project. Um, and, and basically it was just a way for you to, you know, plug in, uh, a gem into your app.
And if an exception happened, then that would trigger a report to our API and we would tell you that it happened, give you notification on Slack or email, whatever, and help you manage that process. Over time Honey Badger's grown. Of course. Uh, 14 years you don't stay still. Right? So
we, we always wanted Honey Badger to be a place where a developer could have everything they needed to know what the health of their app was in production.
That was basically the goal. So Errors of course, is a big one. Uh, but also, uh, uptime monitoring, you know, is a site up. Uh, Cron monitoring, are things happening in the background that they, that should be like, is my billing system still billing every night? You know, and then, uh, most recently we've added insights, which is a structured logging platform.
So, you know, keeping track of the health of your systems or the, maybe the processes that are happening inside your app, all the things that you might wanna know, what's going on. Um, and that's, that continues to be our goal. Basically be a place where a web developer in particular can find out what's going on with their app, how healthy it is in production, and knowing if anything's wrong.
Um. You asked about our, about our genesis, how we got started, uh, and I already said that there were others doing this when we got started. Uh, in particular Air Break was, was a huge one in the Ruby community. I think, I think Century launched about the same time. Uh, Rollbar was also around. Um, but Air Break was the one that I was most familiar with because it had come from the thought bot guys who were big in the Ruby community as well.
And, um. It is just when we were happy with airb Break to a point, we were using it at Star and I, one of the co-founders for Honey Badger. We were using it and we just, we had this one problem where we, you know, our app had thrown an exception and we sent it, or, you know, sent the payload to Air Break and we went to go check it out, see what had happened.
And there was no data in the ui, like just wasn't there. And so I sent an email to customer support. I'm like, Hey, we reported this error and I see it in the ui, but there's just no detailed information. Can you tell me what happened there? And the response I got back was almost literally what I sent them.
It's like, yep, there's no dad in the ui. I'm like. Cool. Well that was immensely unhelpful. And uh, so I turned to star and I'm like, alright, you know what? We deserve better than that. And other developers deserve better than that. We can build this product and we can do it better, and we can give better customer service than that.
Like, it felt like a low bar, really. And uh, what what had happened was like over time Airbrake had been, had been sold from the original developers and now is being run by a private equity firm. Right. So they just didn't really care, like as long as the checks cashed. Right.
And I didn't know that at the time, but that's, that's what was going on and that's what I was seeing from the outside.
Uh, so anyway, like we felt like, hey, we, we should have a tool that's better for what, you know, a it should work, right? It should show me the detail when I wanna see it. Uh, but b, if there's a problem, like it doesn't work as expected, then at least you know I should be able to get some good help. And we figured as developers, we could provide an awesome product and an awesome service to other developers like us.
So that's, that's how we got started. And I think that resonated with people. And I think a lot of people were kind of frustrated with where Air Break was at the time. And so, and plus we'd had this history with the Ruby community, like it had been a few years at that point that I'd been doing, you know, the plugin directory and reels, kits and so on.
And so it was pretty easy like to send out email, say, Hey, I'm working on this thing now. Come check it out. You know? And so we had a bunch of friends and family signing up from day one. Um, but it was, it was great. And eventually, eventually I did learn why that ar detail page probably didn't show up. You know, having, having run the ops side of Honey Badger for as long as I have, I can see, oh yeah, it could have been this or could have been that.
'cause we've had this. Same experiences ourselves.
Justin: Yeah, I'm sure it's a really hard service to operate. Um. Uh, it's sort of interesting. So you, you launched around the same time that like Century and a bunch of other services in this space did.
Um, so not only did you launch at a time when like other companies were like taken into that market, but you were also bootstrapped,
um, and. You know, 2010s, uh, definitely there was a lot of VC money flowing around. Um, you know, maybe not quite as much as there is today in ai, but like there was, you know, it was pretty flush. And so you're competing with these folks who, uh, take on large amounts of VC and not like a relatively crowded market at the moment when, you know, the web and the industry is like really maturing and things like exceptional handling becoming more important than ever. Um, how did you. Navigate that. How did you stay competitive and, uh, yeah. How did you, uh, make the bootstrapping successful?
Ben: Yeah, that's, um, we could, we could talk for a long time about that one. Um, so Star and I, when we started Honey Badger, we, we wanted to start a business. Well, we've been talking for a long time about a business that we could start. We had plenty of ideas and just nothing that felt quite right. And so Honey Badger was.
One of the ideas and when we landed on it, we're like, yeah, we, we should do that. And it worked out. Um, but as we were going through all these ideas, what our goal was, was to have a business that would sustain us and our families and that we would enjoy running. Um, and just be fun to do. Right. Uh, and that we could do our way, like being in control was huge for us at the time.
And uh, so that's why we didn't even consider the idea of taking on any investment capital like before we launched. We didn't have any contacts in that kinda industry, wouldn't even know how to do it if we wanted to. Um, but we really wanted the ownership and the control that was big for us, I think. Um.
It might have been, um, Jason Cohen that has that old, old, old blog post about, do you wanna be rich or do you wanna be the king? Uh, we wanted to be the king, right? We wanted just to have this project that was a good, sustainable lifestyle business. That was the thing. Um, and so we launched it that way and we had a little bit of startup capital from our own savings accounts.
Um, Josh joined us shortly after we got started and did the same. So we pulled our resources and just, you know, made it happen. Duct tape and bailing wire, uh, and. Like, like you said, VC money was sloshing around at the time, especially I think 20 13, 20 14 after we had gotten started, had some, had some traction happening.
We definitely got plenty of calls. Um. I think our, our desire to really be in control was probably the main thing that kept us from going down that path. But also, um, again, we, we didn't have experience in that industry and so we felt a little nervous about the idea of diving into something we didn't understand.
And, uh, I honestly did not understand at the time how, uh, you could project that, well, this, you're gonna invest X amount of dollars because the business is, you know, allegedly worth. X times whatever amount of dollars. And I just, I couldn't wrap my head around that math and it, it just felt like a shell game to me.
Honestly. It felt like investor A shows up at a certain time so that they can sell off their stuff to investor B who then sells it off to investor C and then some magic happens and you get acquired and everybody's happy. And I was like, well, I don't, I don't understand how that works. Right? And, and every time I asked, I never got a straight answer, right?
And so I was like, okay, I'm just, I'm, I'm, I was just too scared, like to go down that path. I'm like, I know, I know how it works. To have a customer who pays you and you, you make more than you spend. I get that. Like, and so I just, that's the path I went down. Right. Um, so has that been the best choice? Well, it's, it's been a pretty good life.
I mean, 14 years we're doing, we're doing fine. We're happy. Uh, I get paid well to do what I love to do every day. So that's. So that's success, right? That's living the dream. Um, could it have been fun the other way? Sure. I guess, uh, maybe And you can't prove a negative, right? You can't prove the contra. But, um, I mean, there are times when we've regretted the decision because like, hey, uh, we've had times where we just didn't have the resources that we wanted to build the things that we wanted, but, you know, that, that comes with every decision, right?
There's always gonna be trade offs. There's gonna be opportunities lost, but opportunities gained as well. So I think it's worked out.
Andrew: Yeah, at one point you had to go back to consulting as well, right? It
wasn't just like a immediate, oh, we're working on this full time.
Ben: Yeah, totally. It wasn't a rocket ship and uh, it was definitely a slow growth kind of thing. And, uh, we were star, like I said, we were, we were working together at a job at the time. This was a honeybadger was a side project for us. This wasn't like a, Hey, we're gonna launch this and be rich. Um, and so for a while we just, we kept our jobs.
Doing Honey Badger on the side. And it was fine, but it got to a point where, um, it's an operationally heavy business. You know, there's a lot of data coming in, there's servers having to be, you know, babysat and all this kind of stuff. And it just eventually got to the point where we were doing enough work and interrupting us enough that we just couldn't honestly say, okay, we can work this day job and have honey badger happening on the side.
There's just too much of a distraction. We wanted to focus on Honeybadger more. Um, the one thing I told Star when we started. I said, I do not wanna go back to consulting. Whatever we do, I wanna make sure that we have enough revenue on the side before so we can just smoothly switch on over. And, uh, and star one requirement to me was I don't want to be in anyone's critical path.
I don't want it to be a high stress business. And neither one of those came to be. We had to go back to consulting and we had a high stress critical path business. Uh, so we weren't too great on that. But, um, yeah, that transition wasn't great. It wasn't ideal, but, um. It worked out like I think we spent, I wanna say, uh, 12 to 18 months.
Of post revenue, but pre enough revenue to pay ourselves a full-time salary. So 12 to 18 months of having to do some consulting to make up the difference. And that worked out fine. Definitely better than having a day job because, you know, when you're consulting, you can partition your time. You don't, you're not, uh, you know, a hundred percent committed to one employer, right.
They know it's a transactional kind of thing. So, uh, it, it worked out and, um, also gave us some great, uh, client projects to test honey baders some more. Right? So that was kinda a virtuous cycle too.
Justin: Maybe let's start digging in and talking a little bit more about some of the technical aspects of the product. Um, one of the things that I has, uh, found pretty fun and. I think is like, kind of interesting in the category of the space. 'cause I see like people taking like different stabs at it. So Honey Badger has its own, uh, like query language, like called Badger ql, uh, for insights.
Uh, so what sort of led you down the path of developing that query language versus doing, um, something else using, um, SDK or something else?
Ben: Sure. Yeah. Well, I have to admit that doing the query language was not my idea, and I was in fact pretty opposed to the idea. Uh, so doing, doing Bad, cruel was, uh, Kevin's idea. And, uh, insights is really his baby. Uh, he had experience with Splunk at a previous employer. Uh, Splunk is a logging tool that a lot of large enterprises use, and it has its own query language and he really liked it.
And so he is like, well, if we're gonna build this kind of thing, we should definitely have a language go with it. And, um, we went round and round for Mountain for a while. Um, but obviously Kevin won that argument, which was great. I think I love it now. Um, but the thing that's I think really beneficial is that you have, uh, you have it.
An ab abstract syntax tree, right? If you build your own language, now you can manipulate it, do all kinds of things, right? You can parse it, you can re-inject things into it, re-render it. You know, the alternative was to just go with sql, and that was like my argument. It's like, Hey, everybody knows sql. Like there's no learning curve, blah, blah, but now you're locked in.
Now you can only do what SQL does until you decide, oh, well we wanna have this extension or that extension, and now it's not SQL anymore. Right? So now there's a learning curve, right? So now you're kind of back to where you started. Um, so yeah, you can, you can see how like this, this argument developed over time internally at Honey Badger.
Um, and we eventually figured out like, Hey, it's actually most flexible for us if we do this and. I mean, to be honest, I, one of the things I love about it is that it's, it's, it's filtered. It's like a pipe, right? So it's like a functional thing. So if you've ever written any elixir, like you're very comfortable with this idea of like, you have these fields and you filter them through these functions.
And, uh, that just kind of clicked with my, my dev brain. And so I, yeah, I became quite, quite fond of it. And, and now I love it. Like, I, I get it. And, but still, still, we deal, like I do demos with people and they're like, why, why bad? Why not just sequel? And so I have to like. You know, explain, uh, periodically, like why we went this path.
And every, every time I start to get the nods and people start to understand and, and yeah, but it's, um, it, it's a choice, right? And not everyone's gonna love that choice. Uh, but it's, it's been fun.
Andrew: So there are a lot of different things that you could build for error tracking. There's many different, uh. Many different frameworks, many different languages. Uh, how did you guys choose to prioritize stuff? And like, is there anything like left on the board where you're like, ah, I wish we had that and that would make our our service that much better.
Ben: Man, if you could see our, our issue backlog in GitHub, it's just, it's amazing how much there's, we want to build and haven't had a chance to build yet. Um, we from, from the earliest starting of the project, it was what do we want in this kind of tool? And after that, what do we think other developers like us will want in this kind of.
That has guided our product development, has guided our, our what, what we now call a product-led growth, uh, strategy. Right. Um, it's, it's really about like, do we, do we think this feature or idea or whatever is gonna be valuable to a web developer who is in their project deep in their editor every day writing code, trying to support their product in production?
Like we did not want Honey Badger to be a place that you have, or a tab that you have open. All day, every day, and you're in there doing analytics and reports and blah, blah, blah, blah. No, we, we wanted to support a workflow where you're a developer, you're writing code, and you get this alert and slack that says, Hey, something broke.
And you go find out from that link, you go straight to Honeybadger and you say, Hey, what broke and how can I fix it? You find where it happened. You see the code, you go right to your editor, go fix it, and then you're on with your day. You don't look at Honey Badger again until something else breaks, right?
That was like our ideal, and that's the way we designed it. And I, that's also one answer to the question of, well, how do you differentiate from some of the other products? Like some of the other products are about having the analytics and being in the tool and that sort of thing. Um, and that's, that's fine.
It clicks with some people and just, it's just not what we wanted. So I think over, for us, the overarching question always is. Is most valuable to that web developer who is supporting their app in production. So we don't target like the team of developers that has the team of ops people where they just throw it over the wall and they never worry about it ever again.
You know, we are really all about like that small team or that really invested team that's, uh, that's. Monitoring their app that is concerned about how their customers are experiencing their app. And so, you know, little, little things like we provide a link to your own user admin interface if you include a user ID in your error report context, right?
That's. Great, because now you know exactly who had the, had the issue and you can respond to them quickly and let 'em know it's fixed. Uh, two bigger things, like the insights where it's like, where we realize, you know what, you're losing a lot of information if you don't have these logs or these other events along with the errors that are happening application, right?
So we should probably provide that, right? So that's, that's really our North star. Like what, what would help a developer in their day to day, uh, building their apps to better support their customers?
Andrew: Uh, has AI like changed that product thinking at all? Or like how you view, uh, what the product can and should do?
Ben: Definitely, definitely like, uh, we haven't settled on any solution to that yet. Uh, like there's no ai. Sparkles icon in the, in the product yet? Uh, I don't know if there ever will be, uh, but we have tried to do things that will help developers. Like I'm a big fan of Claude. Uh, I use Claude Code like all the time, every day.
And, you know, having, uh. Markdown export of an error, for example, so that it has the back trace and it has the context. Like that's why we have a button in our UI to give you that to your clipboard. Right? So you can just paste it right into Claude. Uh, so definitely it has impacted like some of the design decisions we've made and some of the workflows that we're thinking about, and it has definitely impacted our wishlist for way we wanna do in the future.
Like I would just, this morning, I was thinking like, what's the ideal experience with AI and Honey Badger? Is it something like.
[00:27:18] LLM Debugging in IDE
Ben: I, I log in and I'm like, Hey, what's going wrong with my app today? And then that's the question that I type into a box, right? Do, do we wanna have like a chat interface and then, then it goes through and crawls my data and surfaces like the most frequent or the most user impacting or you know, these are kind of big hairy questions and this is why we don't have that sparkles button yet.
'cause we haven't quite figured it out. But we figure if we can at least give you the data that we have. All that context, uh, in a, in an easy consumable way for your LLM to help you, whether it be copilot or, or Codex or Claude. And so we built an MCP server, right, that you can plug into your IDE and you can say, Hey, give me the info on error number, blah, blah, blah, or give me the last five errors that happened in Project X.
Right? You can have that kind of conversation in your IDE where I think it makes a whole lot of sense. Um, and then we're still trying to figure out what does, what does that look like, look like in the application itself? If, if we ever do that, yeah.
Justin: Yeah, I think a, a lot of applications are trying to figure that out. I
also wonder from the other side though, like so. You know, this is, you're building a product around observability and air handling, uh, you know, giving developers more insights to their applications. But there's this big change in how we're building applications where more and more people are using AI tools to like write them.
And I'm,
Ben: mm-hmm.
Justin: I kind of am curious if like, there's like. Something there, like getting earlier in the pipeline and the development process is like hooking into some of the, you know, writing cloud code hooks to like, give you analytics about like AI usage or to, I dunno, track prompts or something. I don't know. There, it feels like there's something there that's like very, um, it's very nascent, but like, seems like there's something interesting there.
Ben: Right, totally. And, and there are, uh, I'm not very con uh, familiar with them, but there are, you know, AI observability. Solutions out there now, right? There's specifics towards monitoring your AI usage in your app. And since we don't have AI in our app, I haven't looked at them very closely, but yeah, it does feel like there is, there's some room there.
Like I don't know if it's a, if it's a, a blue ocean. Uh, I dunno if you're familiar, the Blue Ocean Bed Ocean Strategy, um, book. I don't dunno if it's a blue ocean, like this is huge, wide opportunity there. Or if it's gonna become this very niche. Kind of observability, I think it gets rolled into other platforms.
'cause as we've seen over the past 14 years, a lot of the standalone tools get rolled up into bigger platforms to become like this mega platform, uh, which has, you know, it's good points and it's bad points. So, um, I dunno, it's a long way of saying like, yeah, I think there's something there, but I too don't know what that's something is yet.
[00:29:50] Breakwater Docker Licensing
Justin: I kinda wanna move on a little bit and talk about, uh, one of your, the new projects that you're working on. Um, and it's so funny 'cause I feel like we just had a conversation on the podcast and a recent epic. So it's about like somebody wanting something like this, but so you're working on a project called Brick Quarter. Um, and if I'm understanding correctly, it's like, uh, it's like a docker image hub where people can like, basically like sell the images. So you pay when you pull. Um, maybe you can contextualize and
Ben: Yeah,
yeah, yeah. So the, the motivation came, uh, again, scratching my own itch, just like honey badger. Where here, here I am at Honey Badger and I have customers who want to have Honey Badger running on-prem. In their own data centers or in their own AWS accounts. And, uh, so we need to deliver to them a bunch of our Docker containers, right?
The app and the search engine. And we have, I don't know, 6, 7, 8, whatever, docker, different images that, that make up our service. And, uh, how, how do I deliver them to my customer? In a way that, uh, my customer has, maybe has a license for a year, let's say. Like he, he purchases Honey Badger, you know, self-hosted license, and now he gets access to these docker containers.
How does that happen? Because right now my, all of my images are sitting in Amazon, ECR, right? And I not necessarily gonna give my customer access to my ECR. That doesn't feel quite right. And so now I was thinking about this, uh, over the past few months. And I was like, looking at what was out there. And there are solutions like, um, key and uh, and some others that are like, or Jfr, that's, they're very enterprise-y focused and don't feel all that fun really.
Um, and then there's, um, you could host your own Docker registry. Okay, well now I gotta supply like authentication and how do I manage that? And hand out credentials. And then there's like Harbor, which is probably the closest, which is a Docker registry that has an authentication layer on top. But it's not really meant to be like a, a, a salesy kind of thing.
It's more of a, like you have, you know, your internal customers or you have known entities, right? And you're handing out robot accounts is what they call 'em. So anyway, all this was floating around in my head and I was thinking, well, I could just install Harbor, like, just deploy that and that works. I, it just felt like a project, you know?
I was like, ah, I don't really wanna do that. It's boring. Um. And so then I thought, well if this is an annoyance for me, uh, and obviously there's somebody else having this problem too, right? And so if I built a product that did that, then, you know, that could be interesting, right? And it gave me an excuse really to, to use Claude a bit more too.
I really wanted a pro, a Greenfield project where I could play with Claude code. 'cause it was, this was over the Christmas holiday and they had done that thing where you get extra credit 'cause they had, you know, whatever reasons. Um, and so I'm like diving into Claude Cove for reels for the first time, uh, like all day kind of programming sessions.
So anyway, I'm like, okay, let me let just build this project, uh, into a product or a weekend. And basically the idea is. If you're a vendor that has docker containers that you want to, you know, images that you wanna sell, uh, you create a license, rec, you create a product and, you know, upload, push your things to, to this private registry.
Uh, you create a customer record, you give them a license, and then they can, it'll distribute the credentials to them and they can do a pool. You know, they can auth, authenticate to your, your doctor, just like you might authenticate to GitHub's registry or to ECR, whatever. Um, and then you can define what those licenses look like.
Maybe it's a, a, a perpetual license. Maybe it's one that has just limited to a certain tag, like you just get the V one tag, you know, or V two tag or whatever. Um, basically just make it easier for companies like us to distribute those docker images to customers, um, and not have to set up their own harbor or do that, you know, just things that just feel like kind of annoying.
Right. So it's not like a huge change the world kind of project, but it was something that I really wanted to exist in the world. And so I'm like, and you know, Claude, I just wanna play with it. So, uh, so yeah, that's, that's how it came to be.
Justin: Andrew, you wanna take the next one?
Andrew: Uh, sure I'll do, I'll do a follow up to that one. Uh, yeah, this, this seems like a pretty interesting idea. Like selling software is a, is a weird thing to do. Like you, either it's this one huge hosted service or it's these little things that aren't a service service at all. I could really see something like this kind of coming into its own and like the age of personal apps where
it's like we can just generate our own things and then like.
I could definitely see a world where people wanna sell those things
and that opens up a whole can of worms that they're not at all prepared for. So like
a where you could just like push those things and then have people install them really easily. Seems pretty powerful.
Ben: Yeah, that's, that's, um, what I'm thinking and it's, it's an interesting time, you know, with, with Claude, with how easy it is to build software. Like I think it's gonna, 2026 is gonna be pretty wild when it comes to SaaS in particular. And, you know, we've had things like, uh, the, the base camp guys did the once.
Thing, you know where the, you get, you buy a Rails app for a couple hundred bucks and you get to install it and deploy it. And there are other smaller, uh, vendors out there doing similar things where you can buy the app and just pay once or buy the Docker access. And I think, uh. There's gotta, it'd be helpful to have a product like breakwater out there.
Like, I mean, think about Gun Road, right? Makes it so easy to write up a, a book and self-publish it and then you can sell it. Well, why not make it easy to self-publish your Docker containers? Because Yeah, you, you build your personal app and with Claude and you're like, Hey, this is actually. Kind of cool, maybe other people like this.
How can I monetize this? Uh, and today there's no answer for that, right? That's easy. Um, so hopefully, uh, hopefully breakwater make that more easy and, and we'll see,
Andrew: Yeah, especially if you're like, like I've been building a personal app lately and like AI is in the mix a lot, and for me to make this a service for people, I have to start thinking about, okay, I have AI in there that's gonna cost me money.
Now I have to think about charging them money. But if I could just sell like the program and then it's like, okay, all the costs of running this are on you, but you still
pay me a little bit of money.
I, I love that idea.
Ben: Yeah. Yeah. Totally.
Justin: Yeah, I do think that like we are gonna have to start being e even more creative. About how we sell software because I mean, it is always been a thing. Um, and I think there's always been this weirdness when you're selling software to other software engineers. You know, that's, that's
kind of a, a strange world where especially in more in the age of open source, people expect a lot for free. Um, but yeah, it's interesting to sort of think about selling packages and services and. Um, other distribution models. So excited to, uh, see what happens there.
[00:36:15] Bootstrapping Advice
Justin: Um, I kind of wanna talk, I I actually want to continue on this topic a little bit. So we talked a little bit about how you had bootstrapped Honey Badger.
Um, we've talked about, you know, how you've sold Rails, kit, how you're thinking of breakwater. You, you've had all these moments, uh, throughout your career where you've engaged with products in a way that I think a lot of engineers find traditionally. Challenging. Uh, it's like, how do we, how do we sell these, uh, how do we, you know, manage this world when it seems like so many people are just like going down the VC track? Um, yeah. And I just like, I'm curious, like Af I've. Through all of these experience, all these different experiences, do you have like advice for people who are like, kind of wanting to go down the same track? Maybe they wanna bootstrap or they're like, want to sell software, or they wanna, you know, take a non-traditional, like vc, like they don't wanna take a a VC route, they don't wanna just like get a job, they want to do some sort of like software entrepreneurship.
Like what is, what is your sort of like learning and advice around the, the stuff you've done?
Ben: I, I think my, my biggest piece of advice would be to, to be patient, uh, realize that it's probably gonna take longer than you might think. Uh, you know, it takes a while for these things to really get traction at Honeybadger took, I don't know, um. 18 to 24 months to be making significant money. And that was, that's part of the bootstrapping thing.
Like if we had done VC right, we could have accelerated that. And that's, that's kinda the bargain of what you get, one of the trade offs that you get there. So I think for, for Indie Hackers, a lot of times we, we think, oh, I'm gonna write this thing and it's going to be amazing. And other people are immediately gonna see that it's amazing and it's just gonna take off.
Chances are it's not right. I mean, it happens like, uh, you know, there are some notable stories of things that just went crazy. Um, I think, uh, like, uh, Claude bot, Mt bot, or whatever it's called today, open claw, uh, is one of those stories, right? Um, but more often than not, it's gonna be a slog. And so I think, like for me, and I don't know if this is global advice, but for me, like picking something that I'm interested in personally, like a personal problem that I, I think this thing just has to exist in the world.
And if I make zero sales, that's okay. 'cause at least this thing now exists, right? For me, that keeps it healthy. Like I'm not tending my retirement on breakwater, right? Um, it's just not a moonshot for me. It's like, oh, this is a cool project. Um. But other people approach it differently, right? Some people are like, well, if it's not gonna be a moonshot project, I'm not interested.
Like, I don't wanna spend my time on it. I got so many days on this planet and I'm not gonna waste it on things that don't matter. You know? I'm like, okay, cool. That's, that's fine. Um, but I think for a lot of indie hackers, it's uh, we sometimes get wrapped up in this idea that, Hey, I'm gonna do this and magic's gonna happen, and then the, the dollars roll in or whatever.
Whatever the success metric is. And uh, I think we often underestimate just how much work is involved on the non-product part. Like there's a whole lot to getting a product in front of people, right? Uh, the marketing, the distribution stuff like don't, don't sleep on that stuff, right? Um. So just be patient like it takes, it takes some time and it takes some effort.
Um, but other than that, I think my advice is just have fun, right? Because I, I just do this as a hobby. This, and my, my, my wife thinks it's kind of weird that my job is my hobby as well. But, but for me it is. And, uh, I just enjoy it, right? So if you can find something that you love doing, you know, keep doing it.
Even if the dollars don't roll in right.
Andrew: Yeah, I was talking about hobbies with my wife yesterday too, and she's like, I, I need some hobbies. I'm like, yeah, I just, I just love building things. She's like, you don't do any of that? I'm like, code. She's like, oh, yeah. Yeah. I guess that that's.
Ben: Right.
Justin: Uh, we, we need more active hobbies.
Andrew: Um, uh, so one interesting thing I found while researching you is that you do a 30 hour work week, or at least you did at one point in time. Is that still true? How does that, how do you manage that across the company and how has it worked out?
Ben: That's, that's still true ish. Uh, that's, I like to say that's our ideal. We don't always hit that. Like sometimes it's a 40 hour week. Um, but more often than not, we're getting pretty close to 30 hours, uh, which is, which I think is healthy. Like the, the motivating thing behind that, um, as I worked in my career.
Mostly at startups. Uh, very rarely have I been at large companies and, and by, and like, even the largest, I think was, was less than, uh, 10,000 people, right? So not, not a large company by, by most standards, but most of the companies I work for are tiny, you know, uh, 10 people, a hundred people, 200 people, and, um.
What I found is, like, as a developer, as an engineering manager, you know, having an expectation that I show up and have eight hours of solid brain work every day just doesn't, doesn't happen. It just doesn't like you. Yeah. Your, your, your butt can be in the C freight hours, but you're really getting four, six, I don't know, somewhere in there hours of really actual productive work.
Most of the time is meetings or taking a break or, you know, your brain just can't do a. Five, you know, eight by five every week. It just doesn't work for me. Uh, maybe there are other people that have more stamina than I have, but I, I just can't do that. And so I, I found that my sweet spot was six by five.
Like I can do six hours of focused work five days a week, and I'm feeling pretty good. And, you know, that gives me time in the evenings to do my hobby projects where I'm building things like breakwater, right? Um, or, you know, going to the gym or whatever. It's, um. I, I just found like that that's the focus, that's the sweet spot for my focus.
And so that's why I said let's have 30 hour weeks. 'cause I don't think we can really expect more productive time out of employees than, than that. And you know, obviously there are weeks that are higher, there are weeks that are lower. Um, but I think. That's generally what we shoot for and, and generally works pretty well.
Um, that's, and that's kinda been of a strategy for us as far as, you know, competing as well with, uh, like on the employment front, like we're, we're a small boot shop company. We don't, you know, we don't make the mega bucks and we don't pay them mega bucks. And so like we have to have other incentives, right?
And so one of 'em is, hey, you've got a four day work week, or however you wanna divide your time because we're a hundred percent remote. So, you know, if you wanna work six days a week and you know, whatever the math, how that works, we don't care. Right. As long as the work gets done. Um, but the, the four hour work week is a, is a, is a easy way to catch someone's attention.
It's like, oh, I get a three day weekend every week. Sign me up. Right. Uh, and it's great. It works, it works out great. So I'm, I'm delighted. Yeah. We start doing it and I love that we're doing it and I recommend everybody do it 'cause it's fantastic. Um, but yeah, it's been great.
[00:42:46] Reliability and AI Future
Justin: I, I wanted to sort of like build on that. So there's this other thing is, you know, we started this by talking about like you were using a product. It had bad customer support. You're like, we can build a better product and we can offer better service. Um, and there's this challenge with infrastructural products or observability products is like, you know, mentioning not wanting to be on a critical path, critical path.
You, you really are, you're
like really necessary, right? And so if something goes wrong. Your platform's, the thing that's like spawning the alerts and somebody else is like, oh, you know, crap, we gotta like deal with this fire.
Um, so obviously like if your platform goes down or you have like, um, any infrastructure issues, that's, that's a really big deal too. And I, I'm curious like how you balance both the customer support issues because in some ways it applies that you need like a. Bigger team or like you need someone dedicated to it or you need something there. And you know, you're talking about like, well we don't work, uh, these like long 40 hour weeks or whatever, but like on call for an observability product, I'm sure there's like something there.
So yeah. I'm curious about
those two different aspects of it.
Ben: Yeah, that's, that's, that's true. There are, there are some, uh, some trade offs and some given give and take there. Um, so yeah, not wanting to be in a critical path. We ended up in the critical path. Like, I, I like to say that, you know, we are here for you when your, your app is having a bad day. Right. And given the number of customers we have, at least one of our customers is having a bad day every day.
Right? And so we're always dealing with someone. Their database failing or whatever bad is happening. And so we can't really, can't go down. Uh, 'cause people are relying on us to be available when, when they're not. Right. So they can fix it. So they can be available again. And like when US East one goes down, like we have a pretty fun time over here.
Right. Dealing with that. 'cause they have, the internet is sending us errors. Right. Um, so early on, um, in the first couple years. It was really, really tough. And that, and that and that. I, I mentioned this, like, it was just too hard to keep the day job and honey bad at the same time. And this was the problem, like, 'cause we would have a server all of a sudden get buried with a new customer that showed up and like, I would have to like, excuse myself from my day job and go get out my personal laptop, you know, and get to work.
Right. Um, and it just got to the point where I couldn't, couldn't do both. Uh, so the first couple years were rough. Really rough. And as we were learning, like not every team is like us and other teams have, you know, different kind of quality standards and that sort of thing, and different volumes. And like I said, I've worked at small businesses and there are some really large businesses on our platform.
Anyway, what I learned in those early days, great tip from a friend who had worked at Google and he said, if you have a, a, a critical problem, something breaks, uh, that you're having to deal with your, your hair's on fire, fix the problem. And then fix it so they don't have that problem ever again. And, uh, I sat with that and I thought, yeah, that's, that is what we need to do.
And so just made hardcore about any time there was any kind of issue that caused us some sort of downtime or whatever, it's like, okay, we fix it. And now how are we never gonna have that problem again? What are we gonna put in place that doesn't happen again? And that has led to a whole bunch of automation and auto scaling configuration.
Like there's a reason why we're hosted at AWS. Because like we were at a colo platform, a dedicated platform, and they just. Couldn't give us the automation that we needed to be able to have things happen automatically to self-heal. Right. And so, hey, where's the place, place to go in 20 2007? Whenever that was.
Uh, 20. I guess I don't on that. But anyway, what's the best place? AWS is the best place. Let's do that. And we spent a whole lot of time writing automation scripts dealing with, you know, plugging all the Lego bricks that AWS gives you. And today, like if something bad happens, like. We get alerts, but all we have to do is like keep an eye on it, right?
And it'll fix itself. And if it doesn't fix itself, if a human has to get involved, then that's a problem that we need to fix with some additional automation or some additional monitoring. And so every one of our postmortems is, okay, what happened? What kind of monitoring or automation are we gonna put in place to make sure that it never happens again?
And after doing that for about 14 years, you get to a point where it's like, well just, it just doesn't break right? It is broken every possible way that it can break. And unless you introduce new stuff into the system, like insights, uh, it won't break in novel ways. 'cause you fix all the ways that it can break.
Right. Uh, so now we tend to be pretty conservative too. When we introduce new stuff into our stack, it's like, okay, it's gotta be, it's gotta be battle ready, right? Uh, and so that does limit our flexibility. It does actually decrease our velocity, right? Because now we can't just throw stuff out there and be like, oh, let's see if it works.
It's like, no, we have to know that it's going to work and not ruin our lives. Um, so we still provide excellent customer service. I. I'm basically the customer service representative, um, so that the other team members can focus on what they wanna focus on. Uh, I guess I, I drew, I drew the short straw. Uh, but I love it.
I love, I love chatting with our customers and, uh, they can all email me every day and I'll, I'll love it. Um, but also like we, we've never been, um. Uh, fake about who we are or how big we are, and we never like projected this big oh, 24 7. It's like, no, we're, we're a small business. There are just, you know, three or four of us, uh, give us a break.
Right. You know, we're gonna be asleep sometimes. And, uh, so as long as we get paged and we, we do have a pager rotation, so each, each one of us is on call for a week at a time. And we just rotate that among us so that, you know, we use PagerDuty to wake us up if anything bad happens that it hasn't happened in years at this point.
Um, but, uh, but yeah, I mean, so we're obviously we're available 24 7. At least one of us is to handle any kind of breakage. But typically most of our customers problems are. You know, a nine to five kind of problem. Right. And if they have to, if they're in Sweden and they submit something when it's 2:00 AM for us, they're okay waiting until 6:00 AM you know, again, back to my, I don't get a whole lot of sleep.
I, I actually can cover a lot of hours just myself, uh, you know, handling emails. But, um, but yeah, it's, you gotta find the balance, right? You can, you can go too far either direction. But, uh, it's been, it's been pretty manageable for us and. We on the regular get, you know, good feedback from our customers.
Like, I can't believe you just did that and, you know, turn that around in an hour. I got a, I got a thing the other day. Alright, I ha have to say this 'cause it was so awesome. So I got this customer request came in, um, I don't know, about three hours before I woke up. I saw it when I woke up and I was like, yes, we should have that.
And I totally got Nerd Sniped. I'm like, okay, I'm gonna build that right now. I woke up my laptop and I'm like, okay. And so for the next, I don't know, two or three hours, I was just building it, got it through review, got it, shipped that afternoon, emailed back the customer, like, yep, that was a great idea, and we shipped it.
And uh, and he wrote back and he is like, this is the best customer service I've ever had. And I'm like, that just, that made my day right. Uh, that's, that's why I do what I do. I love it. I, I love doing stuff like that, so, you know, it's an endorphin rush and all that. Um, but yeah, I just, I love, uh, our customers.
I love giving them great service and, um, uh, I, I just love what I do so much. I think that, that it shows and it comes out in, in the product that we built.
Justin: Yeah, absolutely. Absolutely. As we're getting close to wrapping up, um, we always like to ask our guests a future-facing question. And, you know, for you, I think you've been in the sort of observability monitoring, air handling space for a long time now. Um, you've, you've seen the tangent of a lot of, uh, different application developer processes, different frameworks coming and going. Um, different trends in development, um, and now we're in a new trend, in a new like era. Um, and I, I'm curious how you think about how the challenges that your business is gonna have to solve may change going forward. It's like, is this age of like AI driven development going to really change how we think about observability and about like, tooling around the space?
Or is it, you think that's gonna be mostly a. Steady a steady state. Um, yeah, just curious about that.
Ben: Yeah, so I've, I've been in this business for, uh, you know, 26 or so years now. I've seen a few things come down the pike and, uh, when, when I'm looking at something new. I think, okay. Is this, is this like a blip? Or is this a wave? Um, is this an interesting thing or is this a, a life-changing thing? Um, so like when Rails came out, I'm like, this is a wave, this is a life-changing thing, this I need to be a part of.
And so I, I jettisoned what I was doing and went to do the new thing. And then I saw the rise of like, you know, no JS and the JavaScript frameworks. I'm like, okay, is this a wave or is this a split? I was like, well, I actually feel like it's pretty big, but I don't really wanna be a part of that, that because I.
I'm a big fan of Ruby. I love Ruby, and I just didn't want to get into the JavaScript world. And fortunately that wave didn't bury us, even though we didn't focus on, you know, switch everything to JavaScript. Right. Um, thi this ai, this rise of AI in, in the past year especially, is this a blip or a wave? Uh, I think it's a tsunami.
Like, uh, it, it feels to me like going from, um, assembly to sea. Like going from c to a higher level language, it like going from, you know, your single server to the cloud. This feels to me like a big, a big transition. Um, and maybe I'm wrong. But it really feels big to me. And so the way, the way I'm looking at it is, uh, is it, is it gonna change the observability world such that honey badger is obsolete like that?
That's what I wake up thinking about, or go to bed thinking about, uh, the verdict's out, right? 'cause we don't, I mean, you could, you couldn't have predicted two years ago that we'd be sitting here today doing the things we can do today. Like, I couldn't have predicted that. I, I never would've imagined that.
Right? So I can't say in two years from now that we won't be obsolete. But are people still gonna be running things and still wanting to know if they're up or down and if they're healthy or not? Yes. Okay. So like, you know, Jeff Bezos said, always do the things that don't change, right? People always want faster, cheaper, right?
Um. So can I build my business around things that don't change? People that still want to have some sort of visibility into their stuff? Yes. It may look a lot different than it does today. I mean, 'cause frankly, the Honey Badger is very similar to what it was 14 years ago, right? We still plug into your app.
We still process exceptions with back traces and, and for as long as there's gonna be Ruby Apps, there's gonna be a need for something like Honey Badger, right? Um, so is this, is this new AI world gonna change? Are we going to be writing. Code air quotes, that is more just English and we don't even worry about the code anymore because like the AI has figured out a more efficient way.
Just like we went from assembly to C, like, and now we don't have to worry about assembly anymore because we've got the C. Is AI gonna be under new compiler? It could happen is that whatever it generates still need being monitored. Yeah. We'll still need some monitoring for that, right? So, uh, yeah, it could be huge change, but I think, uh, we can ride the wave and I think we can, we can still, uh, get some good mileage outta Honey Badger yet.
Uh, hopefully I'm right on that. But, um, I think developers are always gonna want, want to build stuff. People are always gonna wanna have stuff be reliable and so that means you gotta watch it, right? And you gotta be aware when things aren't so healthy and we'll, we'll be there for that.
Andrew: Sweet. Well, that wraps it up for our questions this week. Thanks for coming on Ben, and taking us through your journey and through Honey Badger and all the other things you're building. So thanks for coming on.
Ben: Wow. Thanks for having me. It's great.
Justin: Yeah. Thanks Ben.