Show Notes
This week on FounderQuest, the guys talk about their decision to offer a free plan alongside the paid plans for Honeybadger and how it impacted the overall business. Josh is also back shares the hottest of takes from his recent trip to Nashville to attend RubyConf.
As usual, the show goes off the rails and talks about flying, Ben’s Eye of Sauron approach to fiscal management and an acquisition strategy based around companies named after honey badgers.
Full Transcript:
Josh: Oh yeah, I got first-class back from RubyConf. I forget what it cost, but it was like too cheap to pass up, so I splurged a little bit.
Ben: Yeah, I love me first-class, especially on the way back.
Josh: It was nice. Yeah.
Ben: Yeah. You're wiped out. You're tired. You just need to crash.
Josh: Yeah. I was hungry and they had food. It wasn't a lot of food granted, but it was better than no food.
Ben: So I've read on travel blogs that the guideline is, if it's less than a dollar per minute of flight time, then it's worth it to spend the extra. So you get a deal like that.
Starr: That's interesting.
Ben: Go for it.
Josh: Yeah. I need to start making that calculation more and make sure I'm getting the most out of my Honeybadger expense card for real.
Starr: Whoa.
Josh: That the handbook-
Ben: Yes.
Josh: ...grants me.
Starr: Wait, what's this? I must have glossed over that part of our new company handbook that Ben wrote?
Ben: Yeah, our handbook says that every employee in the US gets a company issued credit card and you can use it at your discretion.
Starr: Oh my goodness. Cha ching.
Ben: Yeah, totally.
Starr: That's what that is. I wondered what that thing in my wallet was.
Ben: Of course-
Josh: Well, it doesn't have to be burning a hole anymore.
Ben: Of course, you also have to deal with the part of our code of conduct policy that talks about how we do financial reviews of all of our credit card statements, or in other words, Ben, looks at every line item of every credit card statement like, "Hey, did you really need to spend it?"
Josh: I already know that Ben is like, I already assumed that Ben is watching, like, actively watching the credit card statement in real time. Don't you get notifications or something Ben?
Ben: I have, yes, I have Amex configured to alert me whenever a purchase happens that's over $500.
Starr: Oh my goodness. You know who you are, Ben?
Ben: What?
Starr: You're probably not going to like this. I've been reading the Lord of the Rings for the first time, finally. It's like the Eye of Sauron, right. But for credit card, for financial-
Josh: The eye of Amex.
Ben: Do you think Sauron was a micro manager or did he delegate?
Starr: He was definitely a micro manager. He was directly controlling everybody in the army.
Josh: Right, yeah.
Starr: As soon as he died or whatever, like his armies just dissipated.
Ben: Right.
Starr: So yeah, I also have got the first-class upgrades a couple of times. I'm sorry Ben. I hope I didn't hurt your feelings. I don't really think you're like Sauron. I just thought it was too funny to not say.
Ben: I don't know. Being compared to Sauron, that's actually kind of cool.
Josh: Bad ass.
Starr: I mean he's very, very capable manager that person.
Ben: That's true. He didn't do a lot of management.
Josh: Yeah, very successful right up until the end.
Ben: Up until the end yeah.
Starr: Yeah. He just took on too much VC cash.
Starr: So how was the actual conference, Josh? You went to RubyConf. You decided to go old school and you took a bunch of tee shirts with you, I think, right?
Josh: Yeah, it was good. I took a duffle bag of tee shirts this time. Not something I had to check. It was carry on. It was kind of fun. We'd moved to just like taking virtual, you know, we take our business cards that have little links to get tee shirts on them most of the time, but it's fun to have the actual swag at the conference and hand them out and stuff. Yeah, it felt like old times.
Starr: How'd you feel like the conference was in terms of attendance and the talks and all that?
Josh: It was great. It was, obviously it was sold out. Lots of people there. The talks that I saw were good. Honestly, I did mostly the hallway track while I was there. I think I probably only attended six talks or so, maybe five or six, but I got to catch up-
Ben: How was the game night?
Josh: Game night was great. I forget how many people actually showed up, but it was a full room. I think they had like eight to 10 tables or something and they were all filled at one point. So yeah, full house. We had a little swag table, so I got to put my shirts out with the other sponsors. Ruby Together and BackerKit were both sponsors.
Starr: Oh, so we sponsored the game night?
Josh: And Sidekiq yeah, we did.
Starr: Was that an official conference thing or is that a side thing?
Josh: It was official this time. Normally it's, I think we did it at RailsConf I think earlier this year.
Ben: Yup.
Josh: But it was unofficial. It's usually been unofficial, but this year Mike, with Contributed Systems who does Sidekiq, put together a official game night package and we got a couple of other sponsors to co-sponsor. I think that it made a big difference having it be an official event because the attendance seemed to really tick up with it being on the official docket.
Ben: Yeah. That's cool. And Nashville had some good food, right?
Josh: Oh yeah. Yeah. My favorite was the hot chicken and it was very hot. I'm glad I didn't get the a, they had one that was like a ghost pepper sauce, which we got a side of, and I'm glad I didn't get that on my chicken because it turned out to not just be ghost pepper sauce, it was ghost pepper oil basically.
Starr: Oh no.
Josh: The oil changes things. I was like, "I eat ghost pepper. It can't be that bad. You only get so hot, right?" No. I discounted the fact that oil exists.
Ben: Yeah. That changes things.
Josh: Yeah. Oil changes everything. So I'm glad I didn't dive into that.
Ben: Glad you had a good time.
Starr: All right, so I think the actual topic for today is going to be our free plan. Yeah. So I was talking with Jonathan from New Zealand, who is actually going to be writing an article for us pretty soon, and he is a listener and was like, "Hey, you should talk about your free plan because I noticed you have a free plan. But I've heard everywhere that when you have a free plan it contributes the most to support. You end up doing way more support for free users than for anybody else, and also just ends up draining a lot of resources and costing a lot of money."
Starr: So he wanted to know, first of all, what was the process by which we came up with the free plan, why did we decide to do it? And then he also wanted to know how has it affected our support costs and everything like that. And little did Jonathan know that this is a issue that has been, this is like a long standing, not really an argument or anything, there's no sides, but it's something that's come up and then been dropped a lot over the entire life of the company.
Starr: So maybe we should start a little bit by talking about our current free plan and what it's like and what we offer and whether or not it's working for us in support and all that. Could you maybe talk a little bit about that Ben?
Ben: Yeah, so our current plan.
Ben: Yeah, so our current plan, you started talking about support and I was thinking, how has that been? I'm thinking back over the past few months that we've had the free plan in place, and really as far as I can remember, it hasn't been much of an impact on support actually. I can't think of particular support requests, or volume of support requests, that have come in that have made me think, oh this is terrible. So I guess a win in that column, right?
Ben: So that's been nice. That's been a pleasant surprise. I don't think I was really expecting support volumes to change all that much, but it is nice to have that bear out that it hasn't killed us. But our current plan we decided to offer, because we saw that there was a certain group of people that would like to use us, specifically solo developers, but who just felt that our small plan was just too much. At $60 a month, they couldn't swing that.
Ben: And so they would go to our competitors who would offer a free plan. And so we thought, why are we turning away people? Why don't we build a free plan that allowed those kind of individuals. And, it is individuals. I was about to say, and small teams, but really it's not small teams because we decided that our free plan be limited to one user. And we decided that because we didn't want to run the risk of cannibalizing our existing business with having teams of 10 or 20 or more people and say, hey, we can get away with the free plan.
Ben: So yes, we decided that, for individual developers who just couldn't swing the 60 bucks a month, that we should offer them something because we didn't want to push them away to somebody else. We wanted them to be able to grow into a paid Honeybadger account. And if that ever happens for them, maybe they will bring us to their workplace. Maybe right now they're between jobs, and they'll get a job, and introduce us to their new coworkers. Hopefully, these free users will end up leading to paid users at some point through some life circumstance change.
Josh: Or maybe their side project will take off. And that would be the best.
Ben: Even better, yeah!
Josh: For us and them.
Ben: That'd be awesome for everybody.
Josh: That's always awesome to see.
Ben: Yeah.
Starr: I wonder if the fact that we have it limited to single user has resulted in us not having a huge support volume. Because if you're a single developer working on a project, you're not going to spend all of your time doing super detailed error instrumentation, you're not going to be spending all your time doing these really sort of weird edge cases, like you're not going to have firewalls that need to be configured, probably. And so, yeah. So maybe they just use the simplest case scenario. They plop in our gem, or our library, and they just let it do its thing.
Ben: Yeah, that's a good point.
Ben: Yeah, and to go along with that idea, we don't have, like it's a developer who presumably knows what they're doing, right? We don't typically have an unsophisticated user base. We have pretty advanced people using our system. And so the, the one place where that sometimes isn't the case, where there's a big team where they've got people who are not developers who are collaborating on a particular project. So that could introduce those more support problems that might bury someone who's offering a free plan for their service, that has users that can't help themselves basically.
Starr: Yeah, actually, I don't even know if this is the result of the free plan, but one thing that occasionally happens that is always a little bit amusing, not that I would make fun of people but sometimes we get people who sign up for our app, who contact support and it's pretty clear they really don't have any idea like what our app is for. They really have no idea what it is so it's like, why did you sign up for this? But you know, we try and sort of gently show them the exit and maybe point them to whatever.
Josh: Point them to the Honeybadger Bitcoin, or the hoodie? I forgot what the other one is that we get sometimes.
Ben: The nutritional supplements.
Josh: Or the nutritional stuff, yeah. It's either Bitcoin or nutritional supplements, so you've got to pick one or the other.
Starr: Out of all the companies online with some name having to do with honey badgers, we provide the most open and best support. And so we get support requests for all companies named Honeybadger.
Josh: Right, yeah.
Ben: So what we should do is we should totally acquire those companies, and then when those people contact us we'd be like, oh yes, we can help you with that. Here, check out our line of health-enhancing products.
Josh: That's an interesting acquisition strategy. You know, namesake.
Starr: It would be truly selfless because it's like we acquired this company because we want to be able to provide support for the people who are contacting us about these nutritional supplements.
Ben: And of course we want to make mad money by being a Bitcoin exchange. I mean, who doesn't?
Josh: Oh yeah. I've always wanted a Honeybadger coin that was our own.
Starr: If you really want to be abused though, go read patio11's tweets about Bitcoin. It's always amusing.
Ben: He is. Yeah. He's amazing. So yeah, no, we're never going to touch Bitcoin. That's never going to happen at Honeybadger.
Josh: Yeah. Patrick's got just a little bit of financial knowledge I gather. Right?
Starr: Yeah.
Ben: But on support, that wasn't our primary concern. Would it overwhelm us with support? Actually, our primary concern, and the reason why we didn't do free for a long time, was we were concerned about the costs of supporting those users. Like, if we got a free user who signed up and then sent us like a gazillion error reports, well that would swamp us, right? And we'd be doing all that for free. We were pretty allergic to that idea, and for many years when people would ask us if we had a free pen, our stock response was, nope, we can't afford to get the level of service that we provide to someone that's not paying us. Sorry, it just doesn't make sense, economically.
Starr: Oh, I was just going to say that unlike a lot of SaaS companies out there, it's possible actually for a customer to cost us more money to service than they pay us. If they have a high error volume, and they result in a lot of emails being sent or a lot of, I don't know, SMS messages being sent or whatever, we pay for each one of those. So, yeah.
Josh: I'd say, one of the big reasons that the free plan was tough in the past was when we [inaudible] having actually any kind of limiting of anything on our service, which we talked about before. But if you're allowing people to send basically unlimited traffic through your system, then the free plan could get pretty expensive in that regard I would imagine.
Ben: Definitely.
Starr: Yeah. So the current free plan is sort of a direct outgrowth of us implementing rate-based pricing, right?
Ben: Yeah, once we had the ability to limit, then we can say, okay, yeah, we can give you a plan that has a pretty low limit. And that was pretty straightforward.
Starr: Yeah. And it's a nice upgrade path too because if somebody sends us over their amount of errors, they get this automatic prompt to upgrade to get a higher limit. And if you are a free plan user and you start using more than is on your plan, then that's a nice upgrade path.
Ben: Yeah, I don't think we've seen that much. I think so far, again, we haven't had this live for a long time. It's just been a few months, if I remember correctly. We haven't really seen people doing that, starting out free and then upgrading. What we actually have seen more of is people who were on our small plan downgrading to our free plan because they had signed up before we had the free and then they realized, oh, my traffic is so low and I'm just me, I can use Honeybadger for free and stay within limits. And that's totally fine. We have no problems with that.
Ben: But yeah, the idea being that, you know, the person who's at work and using Honeybadger, he wants to have a side project and also use Honeybadger. We get that a lot. And to me, that's gratifying. I love being able to actually support someone who's doing that. I like side projects, and I like being able to have someone be able to use our tool who is really, there's no justification for actually paying monthly for it.
Starr: Yeah. So one side effect of having a free plan that I noticed when we did our stats, or when I did my deep dive into stats a couple months ago, is that if you implement a free plan, make note of the date that you launch it because you're going to see a super large drop in your conversion ratio. If you're not like, oh yeah, the free plan, then that might give you a little heart attack and I wouldn't want that to happen.
Ben: Yeah, it's good to mark turning points when you do those pricing experiments. Every pricing experiment that we have done has been over time. We don't AB test pricing, but we put new pricing out there and we see what happens after a few months. So yeah, you've got to be able to track like, oh, why did this chart all of a sudden change? Oh yeah, we launched new pricing that month.
Josh: Yeah. It's interesting. There's a little bit of a complexity overhead. It seems like when we introduce new concepts of a paid versus a free user into the system, or something. I've been working on redoing our onboarding emails and it seems the more different types of users we have, the more complicated that setup is too. And I have to have these conditionals. I don't want to send an email asking someone to pay us if they're on a free plan. But how do you know they're on the free plan versus a paid one. So it just adds a little bit of extra complexity.
Ben: Yes. It's totally bogus when there's a site that offers you a free trial, or a free plan, and they ask you for a credit card. It's like, but you're not going to charge me, right? So sending them an email like, hey, you've been using for two weeks, time to pay us. It's like, oh, but wait, I'm not paying you.
Josh: Wasn't there some discussion about that today. I think the rework podcast talked about that or something.
Ben: Yeah, that's today's episode of the rework podcast is all about how they decided to do your free plan again. They had one back in the day, and then recently decided to launch it again and yeah, Aaron responded to DHH complaining about the people that ask for a credit card for a free plan just doesn't make sense.
Josh: Yeah. Aaron Patterson, right?
Ben: Yep.
Josh: Yeah. So I think I totally agree on if you're signing up for an actual free, like the free version of something, it doesn't make sense at all to ask for a credit card because it's never going to get charged. It shouldn't ever get charged. There is debate between asking for payment upfront on a trial, which I think is probably more valid because if you're signing up for a trial, that's one of the steps. It's really important to continue if you decide to keep the trial or not.
Ben: Yeah, we've always decided to do it not through that, not have the credit card up front. Because a developer on a team often doesn't have the company card handy, right?
Josh: Right.
Starr: Not always. We started with a credit card up front, but then we quickly sort of-
Josh: Well, I think that's why too. Or it was part of the reason was that it wasn't working as well for us. And I think Ben's right though, it does have a lot to do with the customer that is signing up. For instance, the company or the thing we're switching to for our onboarding emails is user list. And I was a little bit surprised when they asked me for a credit card up front because it hasn't been as common. Like I don't see that.
Josh: Maybe it's because I'm a developer and other companies have come to the same conclusion we have, but I think it works in their case. Their customer is, like, they currently serve SaaS operators. And a lot of them are founders or someone relatively high up the chain. So they know they have a credit card, and the ability to pay. So I have personally, I had no problem putting my credit card in there. I was already pretty sold on it when I signed up.
Starr: So this isn't our first attempt at a free plan. How many other ones have we had?
Ben: I'm thinking one other attempt if I remember correctly.
Starr: Oh really?
Starr: I thought we did two. I thought we did one brief one a long time ago.
Ben: Oh, maybe. I have a bad memory. I can't remember stuff more than six months ago, right?
Starr: That's my shtick. And the last one, Josh was the person who was sort of the lead in developing that. Is that right?
Josh: On the free plan?
Starr: Yeah. I just remember that you were just pulling out of your hair over all the code that had to be written to handle the case where somebody was over the resource limits for the free plan, but then got automatically assigned to the free plan, and you don't want to just delete their resources.
Josh: That's starting to vaguely come back to me now, and I'm having bad feelings, Starr, so.
Starr: Oh, I'm sorry. I'm sorry.
Josh: Yeah, I think you're triggering me a little bit right now. No. Yeah, I remember that I took a fairly convoluted approach to that I think, which turned out to be maybe a bad idea. But yeah, we basically had a downgrade mechanism where you could sign up for the trial, but if you didn't pay at the end you got converted, and you weren't using any paid features, you automatically got a free plan.
Josh: So basically I think the idea was good. Let people sign up and see what Honeybadger could do in all of its power, and then at the end of the trial, so everyone goes through a trial, and then if you still just aren't, you know.
Josh: And then if you still just aren't using that stuff, then it would automatically convert you and you get your free plan. But it turns out that's a lot of extra logic and there's a lot that can go wrong there and it was a nightmare.
Ben: Yeah, and part of it, as I recall, there was some confusion because of the way that we do accounts and how we do collaborators. If you signed up because someone invited you to collaborate on their account, if you were then on a free plan, you could create your own project and we're like, well, is this my collaborative's project? Is it my project? And doing the checks on that. Yeah. That got kind of hairy.
Josh: Our whole account system, I think that's part of the problem is our user account system was not designed for that level of ... I don't know. It's not a good abstraction for those types of things. And I mean, that's been a problem elsewhere as well, and that's one reason I think you're working on that right now, aren't you, Ben, to get some sort of new account abstraction, which will be a better model.
Ben: Yep. Yeah.
Josh: Yeah.
Starr: So, I'm thinking about the question, what is it about our plan system that makes it hard to sort of switch between, to downgrade somebody from a paid plan to a free plan? And it seems like it's the fact that when you have the paid plan or the higher plan, you can create more of these resources, projects or whatever, and then I guess you could in the past. It's not how it works now, but in the past you could.
Josh: Yeah.
Starr: And those stick around and we actually perform work for those projects. We take inbound errors, we do processing on things, and that work goes on whether or not you're logged in or whatever. And so then, it's like this question. It's like, well, what do we do with those resources? Which ones do we shut down? We have to pause it and we can't just delete them entirely. So, it seems like if you're going to develop a plan system that was the most optimized for being able to switch somebody between a free plan and a paid plan. It would all be like ... The resources and stuff, there's no difference between free and paid. It's just the sort of features that the user themselves can use against the resources, and it's like everything else would need to stay the same.
Josh: Yeah.
Starr: Yeah.
Josh: I think having all those different, that whole ... We've had a fairly complex feature matrix for our plans in the past where it's like ... Especially when we weren't doing resource-based billing or usage-based, I mean. So, before we were doing usage, charging for the number of errors you can send or whatever. We tiered on a lot more granular things within the app itself. And if you're in a trial and you can just use anything, it's easy to get yourself into a paid state and then it's like, how do you get them back into a free state if they want to do that? I don't know.
Ben: Yeah. Yeah. And this one's more clear up front, what you're getting into. If you sign up for a solo plan, which is our free plan, you know what you're getting into, you know that there's some limits. There's no surprises 15 days down the road.
Josh: Yeah. I think that's the key for me, is just have different signup, just different paths for each type of user. If you've got a free plan, you sign up for the free plan from the beginning. If you've got an open source plan and having a specific page for it that lets people go through a different process to get into that. And that's something we're learning I think.
Starr: Why don't we to take that one step farther and we'll just have different apps for each plan. Completely separate applications on different servers and everything.
Josh: Yeah, that would really reduce the conditional logic in our app.
Starr: Yeah, it'd be great.
Josh: That'd be great. We just set just a handful of environment variables for each app and we're done.
Starr: Yeah. And you know what, the best thing of all is that it's Webscale.
Josh: It is. Yeah, I like that idea.
Ben: Like so many things in that we've experienced in running Honeybadger, the time, where you are as a business makes a difference. When we started out, we didn't have a free plan. We knew that we couldn't afford it in terms of support and in terms of operating the servers and handling the traffic and that sort of thing. And we gave up that opportunity for the growth that can come because people are being exposed to your service without having to pay for it. It's a marketing cost, but over time we dumped the system. We added the metering, we got to a scaling point where we could handle that kind of cost and offer that.
Ben: And so, if you're just starting out, like when we were just starting out, it's definitely a struggle. You're thinking, can I afford that? Can I run a business that way? And maybe you can. Maybe you can get lucky and structure it in such a way that the cost won't kill you. Or you're VC backed and you don't have to care. You can just give it all away free. That's not the situation that we found ourselves in, but if you have that, go for it.
Josh: Yeah. Early on, I think that not having the free free plan was a really good form of validation for us that we were actually onto something with the product because people who signed up we knew were signing up because they valued the product because you had to pay for it. And it's easy. I've seen people that have launched new things with basically a very strong freemium model, and they might end up with 10,000 users or something, but then no one is paying them. And so yeah.
Starr: And the feedback you get from paying users is also going to be way more useful than the feedback you get from free users, because a lot of free users are going to be like, well if you add this one thing then I'll pay for it or whatever. But that's usually bullshit, but the paid users, they're already paying, so you kind of know that they're already contributing something, so maybe it's worth optimizing the app for them and not the people who are not paying.
Josh: Yeah.
Ben: Totally.
Josh: That's true. Yeah. I've been really surprised though. It's been really great since we launched the current solo plan, which is what we call our free plan, that I've been loving seeing the signup. We do that onboarding introduction where they can introduce themselves. It's a freeform text field where we just say, hey, why are you signing up for Honeybadger? And we've had a ton of the GitHub student pack people signing up because we're-
Starr: Oh nice.
Josh: Yeah and it's been really cool though. It's like all these student bootcamp developers that are signing up for Honeybadger, and it's cool to read some of the things they say about why they want to ... They've never been exposed to monitoring before, a lot of them, so it's cool to see the next wave of developers being exposed to Honeybadger and to just monitoring in general.
Starr: Yeah, it's kind of neat with doing my interviews with the writers who are going to be working with us. We've got a lot of people who came through boot camps a couple of years ago and have been developing professionally and I don't know, this is kind of neat to see the next ... I mean, it's not really a generation because anybody can go to a boot camp, but a lot of these are sort of younger people. And so, it's kind of neat to see the next generation sort of coming through and how sort of different they are from my generation. I think that's kind of awesome.
Josh: Yeah.
Ben: One thing we haven't talked about yet is, we've always had a free plan for open source projects.
Starr: Oh yeah.
Ben: Yeah. We don't advertise that much. It's on our site somewhere, but whenever anybody asks, we're happy to give them a free account so that they can monitor their open source projects, and we have several people using us for that, and I love being able to give back in that way. I mean, we've benefited of course so much from open source in our business. Everything that we run on is an open source stack and it's nice to be able to support people who are contributing in that way to the community.
Starr: Yeah.
Josh: One of the things that's on my to do list is to make an official ... I'd like to get an official Honeybadger for open source page up and advertise it a little bit more.
Starr: One wrinkle with that that I run into with replying to support tickets and stuff, and this isn't really a big deal, but it's just something to be aware of that the listeners might want to be aware of too, is that people have a wide variety of definitions of open source, and so the open source plan isn't for necessarily anybody for any web app who's source code is open source. Because we got somebody whose like, yeah, I'm going to make this ... It was some sort of Twitch clone or something, and it's like, yeah, it's open source, but we're going to run it and it's going to be a business. It's like, no, we're not going to pay for your thousands of users business who releases an open source projects monitoring. That doesn't do us any good. Open source is about sort of giving back to the community that creates the type of open source projects that we all use and benefit from.
Josh: Yeah. Yeah. And there's probably a few, well admittedly fewer of those for a monitoring service because to use our open source plan it implies that you have a production service that you're monitoring, and there's fewer open source projects or organizations that run some kind of production service. RubyGems.org is one. So, that's an example. They use Honeybadger, and they're on our open source plan, and they are literally an open source foundation. It's being run by a foundation to benefit the Ruby community and they run RubyGems.org, which serves all the gems to everyone. So, that's an example of someone who would use our open source service as opposed to if we were a CI platform or something like that, then everyone would use us for their project because basically every open source project on GitHub needs CI. So, there's more of a market for open source people there.
Starr: So, could you say Josh, that every time somebody types in bundle install, that Honeybadger plays a tiny part in delivering those libraries and those gems to their computer?
Josh: That's true. Yeah.
Starr: That's amazing. We do amazing work, gentlemen.
Josh: Yeah, we were talking about Ruby Together a lot at RubyConf, and we support Ruby Together, and I think some of the work they do is really, really cool too because that's kind of their purpose is to build the tools that we as Rubyists use to build our businesses and projects and things. So, I definitely, on a serious note, it's great to support the Ruby community.
Starr: Do you have anything else to say about free plans?
Ben: Everybody loves free.
Josh: Yeah, give me more of that.
Starr: That's true.
Starr: Yeah. So, I guess we're going to wrap things up. Thank you dear listeners for listening to another episode of FounderQuest, all about free stuff. Everybody loves free stuff. If you like the show, please review us on your podcast app of choice. If you want to write for us and our blog, we're always sort of accepting applications and looking for people. So check us out. In the past, I've advertised this and said to go look at the blog top nav and you'll find a link, right for us, and it wasn't there because I forgot to merge that branch. So, I've since merged the branch. It's up there. Go look for it. Any other announcements? No, they're shaking their heads silently.
Josh: We're good. Yeah.
Ben: Founder Quest, always free.
Starr: Oh, that's a good one.
Josh: This is our gift to you.
Starr: Yeah. Stay tuned for our Patreon.