So it was like, okay, we've got no heat now. We're just going to have to slaughter the horses and crawl inside of them. You guys have horses in Seattle? The scariest thing. Slaughter the neighbor's horses. I thought all the horses were in Kirkland. It's like Steve Jobs and the dude had triplets and they built an app. This is FounderQuest. I got back the work from the Barney guy. The Barney guy is going to do our intros and it's all pretty great.
It is excruciatingly difficult for me to listen to it though. Let's just clarify. He doesn't actually sound like Barney. I assume like he's. It sounds like announcer voices, right? Yeah. It sounds like sort of cheesy announcer dude, but it's excruciating. I was, I was listening to these, uh,
these introductions that this guy recorded for us. And I'm like, I have to listen to this so I can spot errors and stuff, but I'm just clenching my fists. I'm kind of in a fetal position because it's so painful to listen to this professional man. who has been the voice of Barney amongst many other roles, reading out the really stupid shit I asked him to read.
So anyway, I'm sure I'm making you guys feel great about the future direction of this podcast. I'm sure it's going to be awesome. And I mean, by the time people are actually hearing this, they're going to have already heard the announcer. So I guess they'll know whether it's shit or not. Oh, yeah, that's right. Maybe. I mean, they can tell us, I guess. One thing that I get asked a lot, and I'm sure you guys get asked a lot too, is how do we do it, right?
The three of us have this pretty cool little software company. We build things we like. We do it on our own terms. How do we do it? Because a lot of people are interested in doing similar things. So I thought it would be fun to have a show where we talk a little bit about that. So what do you guys think about that? Yeah, sounds good. I mean, like, I think it's just like pure blind luck, obviously. I don't know how the hell I do. There may have been a little bit of work involved.
I guess I should start out and explain a little bit about what we have, right? So the three of us started Honey Badger about, like, how long ago was it? Yeah, we started in 2012. 2012. So it would be seven years old in the summer. Oh, man. What grade is that? Like second grade? Yep. I just don't, I don't want to see Honey Badger when it's a teenager. I don't know. I thought that's going to be pretty scary. Yeah. So seven years ago, we set out to build this, this.
app to monitor our web apps for errors. We were using an old service that did a similar thing called Hot Toad eventually turned into a thing called Airbrake. And it just wasn't doing it for us. It had a lot of problems. It had a lot of service degradations. And we eventually just kind of got fed up. and decided to build our own thing. And fortunately for us, a lot of other people were thinking the same thing. So we had a lot of early customers out the gate who were
airbrake customers originally and looking around for a more stable replacement that was being actively developed instead of just kind of milked like a cash cow. I think one of the things that we did, I mean... that kind of just came naturally is that we were solving our own problem, or I guess they say scratching your own itch, but it was something that we really wanted ourselves. And that was a big.
That was a big factor in doing it in the first place. It was, I mean, we did want to build a product and sell it, but we also really had this need that we, uh, that we wanted to solve for ourselves. And, and, uh, and we kind of did that. Like that was the, that was the initial motivation.
how we chose like what to actually build in the first place was we used ourselves kind of as guinea pigs. Yeah. Cause we were like freelancers for a long time and we, we weren't really in the same company, but we worked on, on similar projects and we all used air break.
Actually, at the time that we started on Honey Badger, Ben and I were working at another company as employees. And we used Airbrake then, too, and it was just not doing it for us. I think the thing about scratching our itch is, you know... You can have a lot of itches, right? And there are some that are more interesting than others and some that are more painful than others. And you've heard that phrase like, is your product a vitamin or is it an aspirin?
Is it solving a real pain or is it something that it's kind of nice to have? And I think one of the things that made a difference was like we felt that air break was a painful experience. Like we were really pissed off about how the service did. degraded and we decided that we had to fix that so we felt the pain keenly and it wasn't just oh it'd be nice to have this thing it was like we gotta have this thing oh yeah totally like i remember this and this
You might say that one of the things that set me off being interested in Honey Badger was kind of a mistake on my part. I was having trouble with airbreak. I was having an issue. And so I posted a... question on their customer service forum, which was literally the only way to get customer service. And maybe a day later, somebody responded. And it was kind of a flip, non-response answer.
And that just made me so angry that these people who I'm paying, or my boss is paying, I guess, are writing me off like this and not even... giving me a decent customer support answer. And it was only a couple months later when I went back and realized, oh man, that was just, that was like another customer. Like they're in the same boat as I was. That wasn't even airbrake support. But I guess if they would have really had support.
In the first place, that wouldn't have happened. So it's still their fault. Screw those guys. Yeah. And I mean, it's too bad because I mean, I think part of the reason why we were so like passionate about this thing in particular too, was because we were such big, we were such big fans. At least I don't know about you guys, but I was.
I was a big fan of Airbrake for a long time since Thoughtbot had originally started them and stuff, and they were acquired after that, which I think was the turning point. Um, but I was a huge fan of their, of their product and it was incredibly useful to me. Um, which made it really hurt when it stopped, when it started to like stop working and there were, you know.
you'd have errors coming in, but you're not getting notified or you're not getting the details that you need. And at the time I was still freelancing. So like I was having my clients like pissed at me and stuff when, when, you know, their apps would stop working. So, yeah, I felt pretty strongly about the fact that it wasn't working like it used to. So, yeah, we had a bunch of people in the same boat as us.
I just remember having this moment where I thought, okay, we have to build a competitor to this because it sucks. There's so many people who want it. We have to build it right now. So from then on, I think it was kind of like a mad dash. It was me and Ben at first who were going to do it because we were talking all the time. We're taking lunch breaks together and working together at this other company. And so we started working on it. And then Josh was in the campfire chat room that we use.
Because we just never left. Yeah, we never stopped hanging out in the same campfire chat room. Yeah, it was such a small... startup that Ben and I were at that there were no other developers to talk to, so we had to talk to somebody, right? So you had to talk to Josh. Yeah, we had to talk to Josh. Why else would we want to know?
I think your biggest mistake was actually talking about Honey Badger in the campfire chat room because if you hadn't, then I would have never forced you to let me build it with you. I don't know. I think it's been a net positive. I think, I think so. I think you've pulled your own weight. Yeah. I'm just, I'm just basking in the memories. Like, you know, I got a poor alpha campfire. I mean, uh, but, uh, I remember like when we got started and.
we just had too much to do right and so we said oh let's let's hire josh to do some stuff you know he's still freelancing we'll pay him and josh declined and we're like what you know like what's the deal and so Yeah, I was like, hell no. And so I turned to Star and I'm like, you know what, Star, he doesn't want me to pay. He wants to be a founder. He wants to join us. So let's just cut him in on it. And so, I mean...
That was an easy decision. So that was awesome. I think that has been great. Like having the three of us has definitely made it possible to do it. I realized that there are certain levels of problems that you just can't take on. To take on certain kinds of businesses, you have to have a certain number of people, right? You have to have a person who can do X, Y, and Z. And there are plenty of businesses that you can do by yourself.
And there are other levels of business that you can't. And I think had Star and I just done it by ourselves, I think we wouldn't have had the success because I think we needed those three opinions, those three voices, those three contributors to the project. And plus, man, like in addition to what you're saying, Ben, like, I love you, dude, but you and I would have just murdered each other at this point. Like, I think Josh has been.
a good influence. Yeah, I think that's not something we've talked about before and definitely having the three people. And the different personalities that we have definitely helped smooth over differences that we've had as we build the product. Yeah. It's nice having a tiebreaker. Yeah. And it's nice having someone as he's doing a job.
Well, I was going to say like, like, I, I feel like I do end up kind of being a tiebreaker, um, a lot or like a, you know, but like it, sometimes it like changes too. Like if, you know, it's nice to have, like always have like a person that. is kind of if two people have a disagreement, like the third person can jump in and kind of try to understand where both sides are coming from and, you know, try to kind of smooth that over or whatever. At least that's what that's.
kind of how I've tried to look at it over the years. And yeah, I think it's worked out pretty well. Yeah, I think so. Yeah. And having our, I've always been, I guess, amazed that we have an ownership structure of the company that's a third.
even right like all of us have a third of the company it's 33.33 and like you always hear stories of like someone has to be in control there has to be like a 51 49 kind of things and someone can make the decision And we've made it work like with that, even even Steven, because probably mostly because of Josh helping us get along.
Yeah, I think, I think the, like us all being equals has been a really big, like a really important factor in that. And I'm personally a strong believer in like equal, equal equity splits, at least in like, you know, like serious partners for that reason.
I just think it helps avoid a lot of jealousies and it helps you kind of, you know, at least even in your own minds, like be on equal footing as peers. Yeah. A question I've gotten several times is like with three founders who are all developers.
How does that work? How can you even have a business? And I think that one of the key advantages that we've had is that we can all contribute equally because we all are three developers. No one feels like, oh, he's not doing anything, or feels like I can't contribute.
right now in a way that's useful plus like we're all business-minded and i think that's what saved us like if we were just three developers who just like writing code all day long and that's all we like doing then we would have flopped because it would have never done that required you know marketing and stuff that you got to do to make a business work right but being freelancers beforehand we knew like you have to do some sales in order to get a business and we weren't allergic to that.
I'm still struggling with that one. Yeah, well, it's a learning process. But yeah, I agree, Ben. I mean, I don't know about you guys. The reason I was... freelancing in the first place. And I freelanced pretty much my entire career. I was freelancing over 10 years by the time we started Honey Badger. was the fact that I was interested in creating a business. And, you know, it took me a while to figure out how to actually do that. But that's all part of the process, too.
Yeah, if I was kind of just looking to just be a developer or just do development, I probably would have gone... been, you know, I probably would have had more jobs, but I kind of like, I think that kept me like, I always wanted to start a business and solving business problems has always been like really interesting to me.
I was going to say the short version is if you just want to be a heads down developer, don't start a business. Yeah. Yeah. Cause I mean like, yeah, best intentions, you just can't like, there's so many things that you have to do and it. It really helps if you like to do that stuff. So here is a fun idea, guys. How many, if Honey Badger is a home run, how many non-home runs have we had between the three of us? Sort of personal together, it doesn't matter.
Personally, I can think of three, maybe one of which was shared with Ben. Yeah, I probably got a couple under my belt at least. I guess my number would be like four or five, maybe six, depending on how you count. Yeah. Ben's been doing this a while. Between us, we've got at least 10 projects that were not as successful as Honey Badger before Honey Badger.
That's something. That's something to think about. That's experience. In some cases, you have to have that experience before you can really find the one that works. So we made a good decision. We already talked about by deciding to enter the market when we did. We focused on Rails. We focused on a group of people who are very unhappy with their current situation and were actively looking for something new.
So what other sort of turning points do you think there were? One of the things I think you mentioned briefly, but I just want to dive in a little bit on was, you know, you mentioned paying customers. uh product already in the market that people were paying for right so we weren't like just building something out of thin air and just hoping people would come to it right we already knew there's a demonstrated market for that particular product
And so we just took something that was existing and we improved upon it. Like we added better customer service and we added better functionality. So I think that's a key. Yeah. And like I started kind of alluded to it, but we did highly focus like on a niche market at the time. I think that was the first big thing we did.
And I don't know if we did that. I don't know if that was like our genius that led us to that or just the fact that we didn't have the resources to pursue the entire market. But I think like focusing on Rails and Rails developers, which we are.
we know very well. And I think it allowed us to like, even from a marketing perspective, like speak to those, that group of people a lot better than we could have if we were trying to like, just, you know, be an error tracker for, for web applications or something.
yeah and i remember that helped star keep the product really focused right because i remember he could make decisions that were just like perfect for a rails developer that may not have worked as well if we tried to sell to every developer on the planet but you know focusing on that
on that small market that small group of people was one of the lessons that i learned from one of those you know five or six not so successful side projects that i've done before you know i catch the best i built starting in 2007 and it's still running but it's not you know it's not making a whole lot of money it's just a little cash machine but the mistake one of the mistakes there was trying to go after a really big market
like small to mid-sized businesses who are hiring, right? So I learned from that, like focus, focus on a very small market and you can make a lot more noise in that small market. Yeah. I think the best decision that we made was Choosing a market that one existed and two, we could talk to in a way that was sort of cost effective for us and was welcomed and appreciated by the market.
Like with your catch, the best example, the market's really big. And so it's really difficult for you as a solo developer to go and talk to that market as a whole. Like how do you even start? to do that. That's the sort of thing that people have enterprise sales teams to do. But as Ruby developers, we knew how to talk to Ruby developers. And at the time, there were like 50 Ruby conferences in the United States. So we just went to all of them.
And at the time, it was like you would talk to people and you would say, oh, we're making an air brake replacement. And people just, their faces lit up like you were their savior. They were so happy to talk to you about this. Yeah. And if we had, say, pulled a product out of thin air for just a large market that we didn't know as well, we probably wouldn't have even known that they had that problem in the first place.
Understanding them that well gave us the specific knowledge of what they actually wanted and needed at the time, which helped that it was also what we wanted and needed. Yeah, that helped, I think, too, with deciding what was going to be in and what was going to be out of the product. Being able to scratch your own itch, being the developers that we wanted to serve, we could say, oh, this feels good. This feels like it should fit in the product, I think.
other developers are like this and then you know we added later on the bigger expansions like uptime monitoring and check-ins you know it's it's all came back to like as a developer what do i care about i care not just about my errors happening but i also care that my site is up right and i care that my current jobs are running so you know being customer driven is easier when you're your own customer. Yeah, but that also led us to one of our big canards, I think. You might call it a mistake.
I have the privilege of being the person who I think was most in favor of doing this. And then the person who suggested getting rid of it. I was, I don't know about, I was like, I may have been the most excited about actually ditching it. I just realized I haven't said what we're talking about. We're talking about metrics. I've said metrics. APM. Rest in peace, metrics.
A little bit of background information on this. So we started out with our product doing only exception monitoring, right? Your application throws an exception, we catch it, we let you know about it. works great that's still the majority of our business and then later on we started adding um other features and the first i think this was the first
extra big part of the app that we added was Metric, sort of like a New Relic thing. There's lots of apps that do this now and it's huge business. But we ran into some problems because... Well, there are whole companies devoted to this, right? And we're just three guys. We were like the dog who chased a car and we finally caught the car. It's like, what do we do with it?
It was one of those classic, it was a good idea at the time. We thought, you know, there are so many people who are buried in the complexity of New Relic, for example. And they just want a few things. They just want to know what the performance is, how many requests they're getting. And so we thought, well, if we could just build that 10% or that 20% solution, wouldn't that be cool? And it was until it wasn't. Well, it was just too much for us to handle at the time, I think.
And, you know, I think we've joked about even like bringing it back someday. And I'm never going to say I'm never saying never. on that. Like if we had the, you know, if we have the, um, the people to do it, that's fine. But I think like to do it even, um, up to our standards, um, even to cut, to address that 10% that you talked about, like, well.
We just didn't have the, yeah, we didn't have the time to be able to do it right. And I think that because we're kind of perfectionists in our own way, it kind of drove us crazy that this thing wasn't really fully up to our standards. And that's kind of what led me. That was like the big thing for me when I was thinking about just kind of pulling the plug on it.
Yeah, so we ended up with a metrics feature that works, but it was not a ton of people used it. I think we did some... analysis on that and we found that maybe fewer than 10 people actually used it but it ended up contributing what was it it was more than half of our uh of our server usage was just handling metrics. Well, and just development time too, because I mean, to collect that data, you have to.
be able to collect it on every single platform we support, which means modifying every client package that we have to be able to do application performance metrics, which is like diving deep into. framework code and stuff and pulling out numbers um which is a lot of work so um like new relic for instance has you know a multi-person team to do that just for ruby so
Us doing it with one of us dedicated that task was starting to become a problem, I think. Yeah, so eventually what happened was we decided to look into dropping it. did some research found out that only a handful of people were using it we emailed them they weren't too sad to have it go away so we dropped it because it was
It was ridiculous the amount of effort and money we're spending on this thing. I think in the end, there were a grand total of two people who were sad that that feature went away. Yeah, I know. All that work. All that work for two people. Like, why couldn't we? What could we have done different? With our main product, the exception tracking, we built that based on a need that we knew existed. But with the performance monitoring, we just kind of built it.
We didn't really get a ton of feedback from users. We didn't have people calling us saying, why don't you add this to your product? I just can't wait to get rid of New Relic. We just kind of assume that people would be interested in it. I was thinking earlier, kind of as we were getting into this, one of the big decisions that I think we made early on was to focus on our customers.
And I think that's something like, like a lot of the features that we added to Honey Badger, like, you know, like shortly after we launched kind of with an MVP. A lot of them were customer feature requests. And a lot of the things we've continued to add to the product have been pretty much entirely customer driven. And so I don't know, maybe this is one area where we kind of like dropped the ball on that. Maybe that's why we were seeing.
it didn't quite take off like we hoped it would. Yeah, I agree with what Josh is saying that I think this is one area that we weren't as customer driven as we had been with other features like this is something i thought would be cool and so let's let me build it uh and our customers just weren't that interested in it so yeah
yeah i mean to be fair we all thought it was cool right yeah i thought i was into it i mean like for the record yeah it is cool it's just yeah there's a lot of things that are cool though Well, you know, my philosophy about businesses, it's just one big experiment. Like nobody has it all figured out. Right. And every business is different and you just learn as you go. And that's part of part of what you do as a business.
So you're talking about experiments. Another experiment that we did recently, maybe a year ago, was that we switched to metered billing and that... worked out in a big way for us. Let's talk about that for a minute. Yeah. Well, that's almost two years ago because it was summer. Two years ago. Is it? Yeah. Wow.
Yeah, that was a great call. You know, we started initially with unlimited traffic. That was a big thing that Star wanted because one of the things that... really irked him about airbreak was how they limited you on number of errors per minute from a developer standpoint you're thinking you know
I'm having the worst day of the year when my app is falling over because of all the errors that it's getting. The last thing I want to worry about is like, I'm going to go over quota on my error tracker. So now I can't even see what's going on in my app. And so, you know, we resisted that. And that was a great decision, I think, for the initial part of a business. But then over time, it just got too much for us to take on. I think we saw too many customers who were...
making hardy use of that unlimited allotment. It's like economics. It's when you make something free, people who need that thing gravitate towards it. We ended up with a lot of customers who were really sending us tons of errors because we were the only company that wouldn't bill them thousands of dollars for receiving those errors.
We ended up with a lot of really big customers sending us a ton of errors and paying us, what, 20 bucks a month? We're such nice guys. I know, we're such nice guys. And oh my God, we rang our hands over this, didn't we? That was one of those rare disagreement things, right? Because we just did not
could not really agree on how to proceed. And so finally, we just said, well, let's just try it. That was the point, I think, in the business where we decided, you know what, let's just stop talking about stuff and let's just try something. And if it doesn't work out, we can just roll it back.
And I think that definitely involves some nail biting. But in the end, it's been awesome for the business. And I think it's... If you recall, it almost didn't... It's not that it almost didn't work out, but there was definitely a roller coaster ride there because...
The first thing that happened after we implemented metered billing, because we didn't make everybody upgrade to it, only the people who would be paying less money under metered billing upgraded to it. Only the people who were on our larger plans that let you set up lots of projects.
moved over to the meter billing because you had unlimited projects. Whereas the people who were paying $10 a month and sending us millions and millions of errors, they're not going to move over to meter billing so fast. So revenue started dropping. And it really freaked me out. Personally, it really freaked me out. No, it was scary. Yeah, that was one of the scary times in the business, I would say. Yeah, but then we had a meeting. And I think the thing that turned it from a scary...
downhill ride to an exciting uphill ride is that we decided that, hey, we just really need to... If we're billing people based on their usage, we really need to enforce that because we were... Again, we were being nice. We were saying to people, okay, you went over your errors, but we're still going to let you send us as many errors as you want. But we're all adults here. Please pay us.
to the amount of money that's appropriate to the amount of errors that you're sending us. And people just didn't do it. I mean, I'm not saying they're dishonest. They're probably just busy and didn't have the time to think about it. But yeah, nobody was doing that. So eventually we just had to say, okay, you know, you're sending us too much errors. We're going to give you lots of warnings. We're going to give you lots of information about it so you can plan better.
eventually we're going to have to cut you off, guys. Yeah. I think the way we've solved it and the way Ben has solved it really is... Still a lot nicer than a lot of the other options that are out there on the market too. We're pretty generous, I feel like, in how we do it. But it's enough so that it's equitable. We're not getting the short end. Yeah, and we managed to...
Develop a system that lets people send us sort of spikes of errors and stuff like that. That is fair to people in cases where they're just having a bad day, but that charges more to people who legitimately.
send us consistently more traffic. So I think we ended up with the best of both worlds. Talking about experiments, like one of the other experiments that was interesting, and I guess one of the... natures of our business is sometimes one of us gets very interested in something that the other two just don't care that much about.
And so that one person just goes off and does it. And the other two people are like, yeah, we'll support you, but good luck with that. And I think one of those things was GDPR.
I remember being very interested in GDPR when I started learning about it. I'm like, oh, we got to do this. And I remember Star was like, you know what? I just don't care. If you want to do that, go right ahead. Now, I may be remembering that incorrectly. You can correct me if I need to, Star. In the beginning, at least, I sort of lumped GDPR. into the whole corporate certified compliant thing. Like there's tons of these.
Certifications have long acronyms that basically you have to jump through all these hoops to prove that you're trustworthy to be used by some sort of enterprise company. And they just seemed all like so much BS to me. I guess we should say what GDPR is in case people don't know. GDPR is a, I don't know if it's the name of the law or.
or whatever. But essentially, the European Union is saying that companies have to provide certain guarantees to their users, to their customers, about the data they collect, about their online usage and stuff. companies to provide a log of whatever information they keep. And to delete that log, there's a whole right to be forgotten and stuff in it.
as a service that captures errors for people, sort of end up right in the middle of that, right? Because we're actually logging information about people's users. And those users might live in the European Union. And so they might... be able to contact our customers and say, Hey, I need to know all my information. And then those customers have to be able to get that from us if we have it. Also, we need to make sure that we're not doing things that are just kind of verboten.
which is just things like logging people's IP addresses and keeping them around forever for no real reason and stuff like that. So, you know, it's a good chunk of work and it was definitely a headache dealing with the legal side of it. But, you know, being able to choose what we want to work on, even if that thing isn't so much fun that day, I think it's a great.
a great way that we've enjoyed running our business. There's new regulations coming down the pipe from California, right? I forget the name of that. Do you guys remember? The CC something. Yeah, Ben. Yeah, it's got a bunch of Cs in it. That's all I can remember. But it's going to be essentially like the GDPR, but for California residents. And, you know, like with car emissions, probably what California does is what other states are going to end up doing, right?
Exactly. So privacy is a huge deal and it's going to become even more of a huge deal in these. frameworks, in these privacy frameworks, you really need to have complete control over the data that you're collecting for people. And you have to get people's permission to opt in if you're sending their data to a third-party service like Honey Badger.
So this kind of leads us... We've been talking a lot about open core. We've been talking a lot about self-hosted apps because we're wondering if maybe self-hosted apps are going to make kind of a little bit of a comeback. Everything's been moving to the cloud, to software as a service type models. But if you have to be super strict about where you send your users data, that's really something in favor of running your own infrastructure, isn't it? Yeah, it simplifies things quite a bit.
I think one of the things that we discovered in that GDPR process was that, you know, you have to have that chain of responsibility all the way down to all the other providers that you're using. So like in our case, we use Google Analytics, right? So we need to have that agreement.
in place with Google, which of course is just a very simple form that you fill in because they deal with so many. But you have to have that with every provider that's touching that data that you're handing down, whether it's your user data or your customer's user data. So, you know, being able to say, okay, this set of data we know is under our control. It's not going anywhere. It's definitely helpful, you know, for complying with those privacy regulations.
Exactly. And it's my understanding that, say, if you have a user who opts into tracking with Google Analytics or whatever, and then you want to switch to a different analytics provider that's run by some other company, you've got to get that user to re-opt in. essentially. Whereas if you switch to an analytics platform that you're running on your own hardware, that you're running yourself, you don't have to have the user do anything because that's just considered your company still.
Yeah, so that's really interesting. I think we've been interested in open core stuff. Recently, it's really fascinating to me to see how certain companies have been able to leverage this idea that the core of your software is open source. So people can install it, they can distribute it freely, they can do whatever they want with it. team like us that seems like a really attractive
model, if you can build something that people legitimately want. Because we just don't have the resources to go in and do marketing enough to own a market. It allows a lot more community involvement, I think.
Because the core, you know, because a large part of it is open source and people can kind of take it in and use it and then, you know, contribute to it as well. So. I think there are a lot more opportunities for things like community building or the entire construction of it becomes a little bit...
A little bit of a marketing type of thing, too, where you can engage with the audience as you build it. Yeah, it kind of takes on a life of its own, almost. Yeah, if you're building a product out in the open, you can talk to people about it the whole time. You can get people's feedback. You can get them to contribute. Whereas if you build something...
behind closed walls and then you get it done and you release it into the world and nobody's heard about it. Like that's a real uphill battle that a lot of, I mean, most companies face and it's really hard to get over that. So what are we talking about here? I think what we're saying, you know, we're interested in these directions.
I think we're kind of interested in building additional products within our company, I think is what we're getting at. And these are kind of models for thinking about what that might be. Is that kind of what we're saying here?
I was just going to say kind of like to tie it all together with kind of the open core model of distributing an application. We kind of think that, you know, that kind of ties in back into some of the privacy regulation, things that are coming down the pipeline, you know, where in the future it may be. it may make a lot more sense than it has in the past even to run these types, you know, certain types of applications on your own infrastructure. Open core is a good potentially way to do that.
So we're kind of exploring technologies that can be distributed along those lines. Yeah, that's why Erlang is so interesting to me personally. If you're going to distribute a Rails app... for people to host on their own hardware. Not only do they need to be able to run the Rails app, they have to run a database. They've got to probably run Sidekick. They've got to run Redis. Maybe they've got to run Memcache. If they want WebSockets, they've got to run a WebSocket server.
Right, yeah. Yeah, so in Elixir, you get all that stuff kind of baked into your application. So if you want to distribute a single executable that has... all this functionality baked into it, then that just seems pretty awesome to me. Yeah, also with the way that Elixir does packaging, or I guess the way that Erlang does packaging. you can distribute your app as a single self-contained package.
You don't have to do what you do with Ruby, which is you download Bundler. Then you have Bundler install a bunch of things. And hopefully they don't collide with any of the other things that you've had installed by other bundlers on your system. And all that kind of ties in. You get a lot of this...
from just features of the language, but all of this kind of revolves around the fact that it's in a virtual machine. You've kind of described it like you're basically like you have an entire ecosystem that you don't have to call out to other services. Yeah, like a lot of languages have their own VMs, but...
The Beam is a lot different because it's set up to run different bits of code as sort of standalone processes and they can interact in ways that is very similar to sort of servers interacting on a network. feels like you're programming and almost is like a serverless environment, like programming on AWS, where you just reach out and throw something in cache or throw something in a database. You can do that just inside Elixir or Erlang itself.
Anybody else want to add anything? Any final thoughts? Nope. I don't think so. All right. Well, I'll talk to you guys next week, I guess, then. Sounds good. ThunderQuest is a weekly podcast by the founders of HoneyBadger. Zero instrumentation, 360-degree coverage of errors, outages, and service degradations for your web apps. If you have a web app, you need it. Available at honeybadger.io.
Want more from the founders? Go to founderquestpodcast.com. That's one word. You can access our huge back catalog or sign up for our newsletter to get exclusive VIP content. Founder Quest is available on iTunes, Spotify, and other purveyors of fine podcasts. We'll see you next week.