Subscribe
Share
Share
Embed
Developers building a software business on our own terms.
Ben: Yeah. Talking about pitches for our dev cycle, yeah. We were talking about that in our shape up cycle that we're following, and I'm really liking the six week thing where we work on stuff for six weeks and then we cool down for a couple of weeks. I really like how that puts us in a good shipping pattern.
I think our shipping cadence we've seen lately, like, we're just getting stuff out there and that's nice. We've modified it a little bit for our process cause we're not, you know, Basecamp is a relatively—or 37Signals is a relatively small company, but we are teeny tiny.
And so the one thing about the Shape Up process that I'm currently feeling uncomfortable with is the whole “design the pitch” bit, because, like, you and I are pretty much deciding what we're going to be doing and then we do it, you know? So it's like, “Well, what is the pitch really like when it's a company of just five people”, you know? It's like, “Well, we all know what we want to do”, so do we really need to pitch it?
Josh: But do we know what we want to do? I think that's the struggle for me is, like, we do, we sometimes we get into the cycle and we spin our wheels a little bit trying to figure out like, “Okay, where does this feature go?” And I think the idea of the pitch is that it's not, like, a top down design but it's also not just, like, this is the whatever user story or what we're trying to solve.
But it's like somewhere in between—it’s a little bit like a wireframe, or, like, sketching out the limitations of the feature and thinking through the general UI concerns of where the feature is going to fit in the app and those sorts of things, so that you're not, like, spending a week or two in a discovery phase of trying to figure out, “Okay what does the UI look like? How much can we actually fit into this feature in the next six weeks?” I think that's the really useful part of the pitching process—thinking through the UI, having some wireframes to go off of.
Ben: Yeah, I'm definitely a big fan of doing a little bit of design. not a big design upfront—I guess I'm just a little—to me, a pitch feels like I have to sell the rest of the team on “We're going to do this idea, right?” And I think if I know where the product needs to go, then do I really need to pitch the team on that? Do I need—I don't know, do I need to get consensus, or do I just—am I just the benevolent dictator?
Josh: Right. Well, maybe we need a different word for it because I think we are using it less as like there’s—we don't really have a competition problem, for the most part, because it's mostly you and I that are coming up with these and sometimes Kevin—
Ben: Right.
Josh: And the three of us are usually on the same page, and we're all talking about these things anyways, so I think we're already convinced in the sense that, like, these are all things that we would like to do.
And if there's any decision to be made it’s, “What do we want to do first?” In that sense, I think also it's useful to have some—have each, whatever, potential cycle fleshed out a little bit.
So we can see, like, “Does this fit? Is this a good fit for now?” Like, it's important to think through—especially if you’re, like, limiting yourself to six weeks, I think there's value in thinking through how much you can accomplish upfront.
Ben: Yeah, for sure. We're still, I think, biting off a little bit more than we can chew for individual cycles. And so we get, you know, like right now we're halfway through our current cycle and it's like, “Well, are we going to get this done in three weeks? Does it really feel like it's going to happen?” You know.
Josh: Right. And also, like, thinking through the UI specifically has benefits I think. And sometimes it changes how the feature—like how we build the feature or what we choose to do—and sometimes thinking through that upfront a little bit sparks a new idea that we might not have had before if we had just, like, sat down and started coding, because I think that's the struggle for us. Like, as developers who built a lot of this product and—we’re used to just having an idea and jumping straight into the code and we figure out the UI as we go along.
But I think our UI has evolved—the product has evolved to the point where there’s, like, so much going on that if we don't start thinking through some of these things from a product vantage point, then we risk having this jumbled UI. It's not intuitive and simple like what we want to give to users.
But yeah, we're very good at having an idea and, like, building like a technical feature that fits well into the product. But I think, like, thinking through the actual user experience and, like, how—yeah, the other aspects of it is where we're a little bit weaker.
And I think that like Shape Up helps—can help with that potentially. It's just developing that muscle to sit down and talk through those things. And I mean, I don’t—I definitely don't like doing, you know, I don't want to plan everything out upfront either. I prefer an Agile style, but I think Shape Up strikes a nice balance between like Waterfall and Agile design.
Ben: Yeah. I guess maybe we just need to have a regularly scheduled meeting that is the planning for the next cycle kind of thing, because, like, we're not doing that as much today. So yeah, that'd probably be helpful
Josh: Yeah. And it's not even wireframes. It's more—it’s really like sketches. Like, I think they talk about that in the book. It's like, this isn't set in stone and it's definitely not even, like, the design could change, but it’s—yeah, it helps us give a general idea of where we're going and hopefully eliminate some of the roadblocks that we get into if we're like—where we get stuck on talking about the design. And then a week later, we maybe we resolved that, but now we're a week off of our—out of our cycle or whatever.
Ben: Right. Well, you and Kevin are gonna try something different for Honeybadger in general. You're gonna get together and actually work together in person for a day.
Josh: Yeah. Yeah. Kevin and I, this will be our second, well, actually our third hangout. Recently, we were actually just like, hung out three days last week at Monitorama in Portland here at the open source monitoring conference, one of our favorites. So, we saw a lot of each other last week, but we've been trying to get together and do some coworking lately this year.
I figure like, why not? We're like relatively close to each other. If we both meet in the middle in Portland, it's like, 15, 20 minute drive for each of us, I think. So, that's been cool, and it's useful for things like this. On Thursday, we're going to talk through a design thing. See if we can come up with some ideas. So I think that'll be useful.
Ben: We're 12 years into this remote working thing and while there have been many benefits to that approach, I do increasingly lately miss being in person with the team and, you know, just hanging out and making stuff happen on the whiteboard and stuff like that.
Josh: You feeling a little jealous up there?
Ben: Yes, yes, I am actually.
Josh: I wish—I wish you could be down here too. You gotta move to Vancouver. Like even you've talked about—
Ben: Yeah, totally going to get my wife on board with that plan. But I could just head down there. I could fly down for the day, or—the Seattle to Portland flight is pretty easy.
Josh: Yeah. We should do that sometime.
Ben: I am looking forward to getting together in September when we're all together for Rails World and hopefully we can get some time in there, but when you were—when you and I were at RailsConf, that was a lot of fun to be able to design some stuff and think about some things. So yeah, in person, good, even if remote is also good.
Josh: Yeah. Yeah. I really enjoy the in-person times. We get to hang out and work together.
Ben: So you've been really hot on getting some changes to our internal setup that will help us in our product design. You want to talk about your motivations for what I've been doing lately?
Josh: Should I introduce what your project, what your little project has been?
Ben: Yes, yes, you should.
Josh: You’ve wanted to do this for a while, but I've been really pushing you for my own reasons. I think my reasons have been different, but okay. So, Ben is working on some infrastructure for an EU—European Union region for Honeybadger, which will give us, like, our European customers will like that because they have like their own, whatever, regulatory and data siloing, you know, requirements.
And that's just like a great thing for us to have. But for me, this will solve an issue that I've noticed that we have not really been using parts of Honeybadger, especially some of the more recent things, in our own internal workflow or monitoring. And that is because we've had for a long time—we’ve had our own instance of Honeybadger, like our internal instance.
But as these things do, it's a little bit like a staging server or maybe even not a staging server, but it's like an environment that you don’t—it's not part of your production stack per se. And I think there's an issue with that sort of environment where, if it's not a production thing, it tends to get ignored a little bit.
And it's easy to be like, “Oh, that just doesn't work over there because we haven't gone and done the infrastructure thing that it needs”. Like, for Insights, for example, we launched the new logging thing, but we didn't get around to adding Clickhouse and setting up the infrastructure on our private internal Honeybadger instance.
And , we've used Honeybadger for error tracking for years, but it's always been, like, over here on this rando-like environment and so the problem is we’re, like, behind on the features we've launched and we don't maintain it as well or as often as we should.
And I realize that's probably been a problem for us because if we're not using our product, we're not experiencing the annoyance of various things. I think we're very annoyance driven developers—that’s why we started Honeybadger. And I think it's really important for us to be experiencing any pain that our customers are experiencing using our product so that we can fix that and make it better.
And it just, you know, it gives you a good vision for the product if you're using it daily, you know, as much as possible. I think having this EU region will give us the ability to—to use Honeybadger more ourselves because we can monitor—the reason we can’t, like, use just main—our main, like, current production stack is we don't want circular dependencies, right?
Ben: Right.
Josh: And if Honeybadger goes down and we need to troubleshoot it, we can't be like, “Well, our monitoring is now down because it's monitoring itself." So, we need a separate isolated environment. And the benefit of this EU region is that it will be a production environment that we will eventually have customers on.
And we will be motivated to maintain just like our main production environment. And these two things can monitor each other. And we can finally have a true production environment for ourselves, for our own monitoring needs. And sorry, I like just rambled for like five minutes, but this is something I'm really excited about.
Ben: Yeah.
Josh: I think it'll be a big deal, yeah.
Ben: You know, the secondary system—the staging environment that we've been using for the longest time, has been helpful. We've used it for Honeybadger itself, like, tracking errors that we trigger, we—we depend on this environment and it's been fine until we launched Insights.
Because like you said, we didn't end up doing all that infrastructure work over in that staging environment as well. And so, it's a few months behind now and yeah, we're not using Insights on a daily basis, like we are the rest of the Honeybadger functionality that we've had over the years. And we're playing with Insights where we use it a little bit on some of our stuff, but it's not a production kind of use case like Honeybadger, like the error tracking.
And we've wanted to have an EU stack for a very, very, very long time. It's something that we’ve—I mean, years and years we've been thinking about doing, but it's just been, you know, it's one of those things like, “Oh yeah, that'd be nice”. But it's so much work, it's a heavy lift. And every time I thought about it, it'd be like, “Well, there's this problem and that problem and this other thing.”
And I just don't want to solve those kinds of problems right now. But with the launch of Insights, it really became clear that having this environment, that’s needs to be kept up to date, basically like a production environment—well, okay, why don't we just make another production environment?
And while we're going through that process, why don't we just put it over in the EU and then we'd solve two problems at once right? And the—I think it was a couple months ago, well, I guess about the beginning of the year or so as Insights was getting ready to launch, I was like, “Yeah, I should do this.”
And I started making some efforts towards cleaning some things up and making some of the deployment more automated because we were heavy users of Terraform. And, you know, even with that, there are some things that are still manual set up and this configuration needs to be tweaked in that way.
And stuff that was very specific to our current production environment things accumulate, cruft accumulates. And so, like, I started going through, “Okay, I can automate this part. I can bring this into Terraform”, but it was just like a nights and weekends kind of project.
And then, a couple of months ago, you're like, “No, we really need this because we're just—we’re not feeling the pain”. Like you said, our customers—because we're not using this as much as we should be. And so I'm like, “All right, boom, I'm doing it”. So I'm locked in and good—the good news is, like, it's taken less time than I thought it would and it's gone more smoothly and we're pretty close to having—well, I mean, it's running now. We're actually kind of get baby steps where it's there, but it's not ready for production use yet.
Josh: It sounds like you've also—it’s—you like, you have better infrastructure code and other things now than the way that you're managing this system. I think we're hopefully going to be able to port some of this back to, like, our main production infrastructure at some point. So it's sort of, like, make everything a little bit more standardized and easier to maintain hopefully in the future.
And maybe even deploy into other people's AWS accounts in the future. If we had wanted to have an on prem story, sounds like you're making some strides there.
Ben: Yeah. I think we're definitely getting close to being able to do that. I've been keeping a read-me with this work that I'm doing. So, basically, I'm making—have a new Terraform path, and I just started copying in a bunch of the configuration from our production Terraform stuff and tweaking it from here and there as necessary. And as I was doing that, I noticed, well, here's the thing that like we still have to manually do, like setting up the database, right? You can use Terraform to create your database cluster, but it's kind of awkward to have Terraform, like, actually create the logical database and create the users and the tables and so on, the kind of things you do in migrations.
So I started when I realized I was hitting some of these issues, “Oh, I'm creating Kafka topics”. For example, once the cluster is in place, I started keeping track of these things and read-me. Okay, every time I'm having to type something or use a UI, what am I doing and how can I document that?
And the good news is like that read-me is very short. like most of the read-me is, “Okay, look at this file for this kind of stuff”, and there's probably like, I don't know, three or four steps now that are still manual. Like the database set up, the topic set up. so yeah, going to a customer now and saying, "Okay, just run this Terraform config and then we'll help you with these three or four things”.
Yeah, we’re super close to being able to do that. So, I would be delighted to have someone now asking me, “Hey, can I have this?” We've had that question before and always the answer has been, “Yes, we can do that for you, but it'll take a bit of work”, right? Because I knew there's all these little hidden things and now all those hidden things are cleaned up. So, I’m feeling pretty good about that.
Josh: Cool. This little project has had all kinds of network effects, or side benefits. That's cool. But yeah, I'm really excited. I’m, like, about all of this, but especially that we will be able to finally have a more production, like, experience ourselves with Honeybadger.
I think what it really boils down to is, if we are telling people that Honeybadger is all you need to monitor your web applications or your SAS business or whatever it is, and we're not using Honeybadger exclusively to do that, I think that's a problem and I think we really should—we should be using every part of Honeybadger as much as possible. And maybe that maybe it turns out that pitch is not quite—or that promise we're making the users in our marketing material or whatever, it’s not quite there yet. And we have a little work to do to get to the point where it really is the all in one.
I think we’re, like, really close, if not there, but I think us using the product more, and actually like relying on it for everything we do, in terms of, like, running Honeybadger and production will really help us, like, make that true. And also it might—it might help us further develop that ethos around monitoring. I think we should be able to tell people how they should be using Honeybadger to achieve these results—be able to do all this more, like, observability style monitoring, even with a small team of, like, whatever, four or five people even, or a solo developer.
We've had this cycle with Honeybadger where we use it, but then our needs outgrow it a little bit and we go find something like whatever PaperTrail or CloudWatch logs or whatever AWS is thing is, because we're whatever cloud native or whatever you call it.
But then we like want to use Honeybadger for that. So then we like build—now we have logging and observability in Honeybadger. But , now we have a gap of like, “Well, we use CloudWatch for, like, auto scaling. Is Honeybadger going to do auto scaling?” And the answer is maybe, so that's maybe someday.
But those sorts of things, it forces us to think through that stuff. And I think that's important because our customers have the same—they have the same problems that they have—they’re thinking the same thing. Like, okay, well, I love honey—the simplicity of—of insights in Honeybadger. But what about, we use AWS. So, how do we actually connect those events or whatever, to our auto scaling rules or whatever.
Ben: Yeah, yeah. And, you know, like you said, we're heavy users of AWS stuff like CloudWatch and their insights things. And you can see the influence of that in Insights that we've delivered. And like, because we love those kind of—that power that comes from those kinds of tools, we want to bring those same kind of tools to people who are not tied to AWS, right?
If you're running a Digital Ocean droplet, right, why shouldn't you have the same kind of cool tools and, not having to go through all the hoops that are required to level up your AWS expertise, right? Because, like, we've spent many, many years becoming very, very familiar with how AWS works.
And most people just don't really want to do that. Like a developer typically just wants to add water, deploy the thing and be off, right? And not having to learn all the intricacies. And so, that's really what we're hoping to do with Insights. And yeah, as you say, as we meet our own needs more with it, then we can honestly go out to people and say, Hey, this is really all you need.
Josh: I love the way you frame that. Like, If you invest a ton of time and you go and whatever, get—become a certified architect—cloud architect or whatever they call it, and you have all this monitoring set up, like CloudWatch is really cool. And like Amazon's monitoring, all of their tooling is really great.
But it is such a project to learn how to set it up. And it's a lot of work, and what if you could just have that all done for you in a simpler tool that doesn't, you know, require that, whatever, you don't have to go get a certification to—and understand and set it up in the, and maintain it. Yeah, I think that's our goal with Honeybadger.
Ben: Yeah. Sounds like you have some more marketing copy you can add to the website there.
Josh: So much marketing copy to write. Yeah, that's one of the things I've been working on is, continuing to refine our marketing copy and update pages. And that's a—it’s a constant ongoing process, but it's been fun. I enjoy that. I think the writing and copy part of it is one of my favorite things to do.
Ben: So how are you approaching that with the curse of knowledge, right? We have so much background in our head and so much context in our head. How do you get out of that headspace to write it so that it's interesting to someone who's just coming in cold, right?
Josh: Good question, yeah. I’m a huge note taker and researcher and I've become more so over the years, but I try to keep notes on things like that. So, I really—that’s one of the reasons I really like going to conferences and talking to people and especially like conference talks, discussing a production issue they had at their company or something—I guess what I used to do when—I guess when I was like an actual software developer, my notes were actually about the technical details of like, “How can we use this how can we bring this back to Honeybadger and use it in our infrastructure”, or whatever.
These days, I find myself furiously taking notes about, like, what the problems are that they're experiencing and what is the language they're using to describe this problem? so that I can then come back and then use that in my copy or whatever. So, I think that's like really the core of it. And just like talking to customers. When we’re on support—because we all still rotate on support and we do developers on support and founders on support, so you and I are constantly in the rotation for handling actual support requests.
That's a great place to find what's the actual experience with the product that people are having. Like, what are they trying to do? And then translate that into marketing copy. Basically, talking to people and listening to what other people are saying is the best way that I've found to, like, figure that out because you're right.
Like, we have so much context in our heads that it can become difficult to remember what it's like to be a fresh user or someone who doesn't have Honeybadger, or maybe doesn't have experience with monitoring at all, like we do. That's a real challenge.
Ben: I found that, lately, I've been talking more to customers—been having opportunities to get in touch with them more. And that's been fantastic for me to see where there are gaps in the UI or where there are some things that, maybe there's not a gap there, but maybe there's just too much friction in how we accomplish the thing.
And they'll say, “Oh, well, I'm having a problem with this”. And I'm like, “Oh, well, I just do, A, B, and C.” And it's like, yeah, but I sit back and I think, "Well, I mean, it wouldn't be immediately apparent to someone who's not me that you got to do A, B, and C”. Right. So we need to find a way to make that more clear or just eliminate those A and B steps and get them straight to C.
And, it also helped me realize recently I was talking to a customer, and he said, “Well, we got this problem with workflow, and I got to look at this over here, then that over there. And I thought, “Well, this is solved by Insights”. And I'm like, “Well, have you looked at Insights?” And they're like, “Uh, no, I haven't. I don't even know this thing.”
So it made me remember, like, a few episodes ago, when we're talking about, like, the seven times you gotta mention it—someone, you know, for someone, it's their first time. And for this customer, it was the first time, even though, like, we put it in the UI, even though we sent emails—for this customer, he’s like, “Oh, yeah, I haven't looked at that yet.”
Right? I'm like, “Oh, let's, let's look at that”, and right. And so, it only took, you know, two or three minutes. And it's like, let me show you this thing. And immediately they got it and they're like, “Oh, this is exciting. This is really cool." So I think, that helps me come back to say, “Okay, maybe I need to make a video about this thing”. Or, like, the screenshot on the marketing page can be about this, right, to help communicate the value of the tool.
Josh: Yeah. And just repeating that—put that all on repeat too, because I think there's probably levels of how checked in people are, and we're fortunate to have this core of Honeybadger users who are really excited about Honeybadger.
And they're following us on social media and they're opening our emails and they're in our new discord, that I—we can talk about later, but just, like, TLDR is we have a new secret, semi secret Honeybadger discord, that’s just, like, a fun community thing that we've wanted to do for a long time, basically chat with our friends and users of Honeybadger. So if you want an invite to that, reach out to us, but anyway, yeah, where was I going with that thought?
Ben: We have friends and, customers who are really engaged and excited and watching.
Josh: Yeah, but then there's a level of users where they're just—they like Honeybadger and they're here, they’re using it, but they're just trying to get their work done and it's not like a thing—they’re not necessarily fans—or maybe they are, but it's more of a passive thing. And so, maybe they see our emails, but they don't open them all the time or whatever.
They just skim or whatever. And then there's people that are just, like, either not using the product regularly, or they're just—maybe they just have email overload and they don't like social media and they're very focused on just getting their jobs done, which is totally fine.
But to reach the customers and users of Honeybadger and let them know that things are happening, like, it takes a lot of repetition and putting these things in all the places, like, we have the in-app callouts and the product changes, announcements.
And we do emails, and we do social media posts, and all these other things, but like, that's what you have to do to reach everyone. And even then sometimes they're like, “Oh, I didn't know that existed.” So, you reaching out and talking to people periodically is a great way to not only get feedback on the product, but also let people know how they could be using Honeybadger. It's like a customer success type thing.
Ben: Yep. For sure. Yes. That's the way I've been thinking about it. And we haven't done that much. And to my regret now, because I'm really enjoying it. And I'm like, “Why haven't I been doing this all along?” but I think one reason why I haven't been is because we subscribe to things.
Of course, we have a bunch of SAS subscriptions that we have for running our business. And I really get annoyed when I have an email in my box and it's like, oh, you have a new account manager from such and such SAS, and let's get in touch and talk about how you're using our product and see how you can have more success in it.
And then when I get that email, I'm thinking, oh, you want to sell me on how to use your product more or upgrade to whatever thing, and I just don't care. I'm happy or I'm unhappy either way. And I just don't want to spend more money on you. And I know that's what you're trying to do. You're trying to get me to spend more money on your product.
And so I think that was probably like the main thing that kept me away from doing this outreach, because I don't want to be that guy, right? I'm not interested in just selling cause I'm not a salesperson. Of course I'd like people to spend more money on us. I'm not turning away money.
I'm a capitalist after all, but that's not my goal, like, in reaching out to someone, I really do care. Just like Honeybadger really does care, right? I care about that. Someone's having a good experience with the product. I care that they're not frustrated and that's like my pitch has been to reach out to customers.
It's like, “Hey, you know, we haven't connected. I'd be happy to hear about whatever is on your mind. Like if you have any frustrations or any questions or any comments, suggestions”. And that's been fantastic. I've gotten bug reports that we wouldn't have gotten otherwise because people just had like, “Oh yeah, while I'm talking to you, this thing has been bugging me.”
And it's like, “Oh yeah, we should fix that”. And so, you know, two days later it's fixed and I can go back and tell the customer, “Hey, it's done”. And that's a great feeling. And that's what I love about having these conversations. And then of course, if it, if Insights comes up, I like—if it's could be solved by them, like, “Oh yeah, you should check out Insights.”
And you know, by the way, it'll make us more money if you actually subscribe to insights. That's great. Of course that's in there, right? But I go back to what Seth Godin has said about, if you have something that you believe offers value to the world, then you should share it with the world, right? You should talk about it. You should bring it to people because I mean, why? Why are you doing this thing anyway? if you don't think it has any value to the world.
And if it does, then you should tell people about it. It helps them. So, I don't know, maybe that's a soapbox thing. But anyway, I've really enjoyed doing that lately. And hopefully I will get better at doing that and, more regularly doing that with people.
Josh: I think that's great reasons to be doing this, which is maybe the thing that's held us back, like you said, in the past is we don't want to be like whatever cheesy sales people. But, like lately, I’ve had a similar outlook about it, and I'll just look at us like consultants, but now—we were consultants or whatever in the past.
Like we were paid to sit down and talk to people about software and then help them build it in a lot of cases, but we can take that mindset and we can be consultants to our Honeybadger users. And that's a benefit of using Honeybadger too, is the founders are very engaged and want to help you—genuinely like help you level up and solve your problems.
And as we've learned a little bit more about sales and at least if, you know, people who are good at sales—I think that's a good sales technique too is you're not just trying to sell someone on some solution that you may or may not care about, but you're going into these conversations, just genuinely curious, like what their problems are and how can you help them solve these problems, even if the solution is not to use Honeybadger.
Maybe they're not a good fit for honey badger and you can help them get there faster and you probably have enough experience to point them in the right direction or suggest a solution, from your experience. And I think that's something I get a lot of satisfaction out of that. I don't know about you, but I just like helping people And that's a little—a bonus to us that we get to do this, like, at a larger scale than when we were just freelancers or whatever.
Ben: Mm hmm.
Josh: So , it's a way to, it widens your impact potentially, since now we have like, you know, thousands of customers instead of like a few clients or whatever. And hopefully we can help more people maybe they will give us more money as a result.
Ben: It's a win win, right?
Josh: Yeah.
Ben: Yeah. I love this business 12 years in and I'm still loving it. Still love showing up every day and doing what we're doing.
Josh: I think we’ve—I've been learning a lot this year. So I think that's, I think that's one of the key—like, I want to always be—I want to feel like I'm learning and becoming better at what I do. So I think this year that's really—I’ve been feeling that. I think some of the things I've seen us like overcoming some of the challenges we've had in the past around talking to people or sales or marketing or whatever.
Ben: So back to this Discord thing. Uh, I got it—I got to say I was pretty amused because, like you said, we have talked about this for years and one of the hesitations that we had was, well, if we have this Discord thing, or I don't know, I think we've talked about doing Slack in the past or whatever.
It's like, well, we've got to have someone in there and because customers are going to be asking for support in there and do we really want to be on the hook for being available 24 seven in the chat room and so that we've always said, “Well, no, we don't want to be on the hook for that.”
So we're not going to do that. And then you went to the—you went to Blue Ridge and you came back and you're like, “Well, I created this Discord”, and I'm like, “Okay, I guess we have a Discord now.”
Josh: It was like after Blue Ridge, but I've been wanting to try this and it got to the point where I was just like, I've thought about this enough and I'm just going to ship it. I’d spent a lot—I’d probably spent too much time thinking about, “kay, well, should we use Slack or should we use Discord or should we have some discourse forum or something?”
Finally, I just—like, Discord seems like the—it’s the obvious, like community, like, if you're trying to have a community that is easy for people to join and is like chat based, Discord seems like the platform that—that has, like, stuck the most. And I know like discord overload is a real thing. People are in like, you know, 50, or I think I know people are like in a hundred or more discord servers. I guess actually making the community useful. And one of the ones that people actually check regularly will be an ongoing project.
And I also think I've signed myself up to be that person in the chat, you know, the community manager or whatever, which is also important, I think when running these things is like, you need to have someone that is building the community and all that. Coming back from Blue Ridge, I met a few people and one of them, Josh, he's a junior, like newer developer.
And we had talked about working on some things together with Thomas Cannon, who's kind of mentoring him and he's working on this game. Just like for, you know, a learning project, but I was like, it would be fun to have a place where we could chat about this and whatever, continue to keep the conversation going.
So, that was the opportunity I used to do this and they were the first two users beside myself. But then once I had that, I was like, you know, I should invite more people to this. So, I just posted on Twitter and LinkedIn and stuff and Mastodon, like, I have this super secret server, do you want to join?
And then I spent like the next week sending people invites because it turns out, like, if you actually have an exclusive offer or something you get a lot of takers. So I—we have like over, I don't know, a hundred to 200 people in there now, I think it's probably like a hundred, 120 or something, but haven't checked recently.
So, and that's just from direct invites and word of mouth. So, that was a lot of replies to sift through, but it's fun to do that. It shows you like who's listening or who’s paying attention. So maybe, we’ll open it up to more users.
Ben: I'm glad you did it. I think it's fun. I jumped in there and I'm not in there all the time, but I dip in, I think, at least daily. You know, check it out. And I think it's cool just to have a place for people who are Honeybadger fans can hang out and help each other or just chat about whatever. I think it's fun.
Josh: Yeah. So like, the focus of this is it's not a Honeybadger support channel. That's definitely something we provide support via email, if you're paying us enough, you can get a Slack integration with us. This is more, “Let's talk about monitoring and observability. Let's like make ourselves available as those consultants to people to help solve problems and share our experience.”
And then also there’s—part of my pitch for this, that like people started joining was, “Let's talk about in the SAS business and let's talk about marketing and developers building software and businesses”. Which sounds a lot like what we talk about on FounderQuest, which is not a coincidence.
I think this is also the FounderQuest community. So if you're listening, you should definitely get in touch with me or actually maybe what I'll do is, I'll put a invite link in the show notes and you should definitely come hang out with us in discord. And we can talk about episodes and stuff too. So that's a little bit of a extra incentive.
Ben: Yeah, that'd be totally cool.
Josh: This is basically like the Honeybadger, whatever the Honeybadger universe, community.
Ben: So, we're going to have our EU stack that we've been talking about for years. And now we've got our community server that we've been talking about for years. So I guess that means we got to do the other thing that we've been talking about for years, which is running a community conference.
Josh: Oh no. Well, one thing at a time, but yeah, so that—that would be fun. I don't know about that one. What I've been trying to do is talk other people into organizing a conference in the Pacific Northwest that I could then be fairly involved in
Ben: Right. That, sounds like the Honeybadger way where we, yeah.
Josh: I just want to, yeah, I just want to be like the idea person and, you know, let other people do the work.
Ben: No, I would be happy to join in on someone running a conference in the Pacific Northwest and spend a lot of time doing whatever, mopping the floors or setting up tables. I don't care, but yeah, it would be totally fun to have a community conferences, people that love this kind of stuff hanging out.
And I think Monitorama is like that. I think there's other conferences that are like that, you know, that aren't necessarily tied to one vendor or something. And I think that's of one hesitation of, frankly, aside from the complexity and cost of doing conference has been we don't want it really want it to feel like a Salesforce conference, or some sort of like vendor pitch, for two days kind of thing. We just want to hang out with peeps. Right.
Josh: Yeah. Yeah. I was thinking of—we’ve talked about doing like an indie, whatever, like an indie business type thing, which would be fun. Also, like, just, there's not Pacific Northwest Ruby conference currently. And that's something that I would love to see happen. If you're listening, Nate—I’m trying to get Nate Vic to—to organize this, I think it'd just be great at it.
But like, yeah, I would totally—I’d love to volunteer or help even help co organize like these sorts of things. Would be, I think, in our wheelhouse. It's just like with everything else, it seems like a lot to spearhead this, so maybe we'll get there.
But I do think it would be cool to, yeah, if we had some infrastructure, especially like if we could find a good, like, event planner to help us, like Xavier from—who used to organize micro comp, for example.
Ben: Yep. Yep.
Josh: We need a Xavier.
Ben: Yeah. Well, you know, if you are listening to this and you are a budding events planner, event organizer kind of person, and you wanna just go wild on a brand new thing, feel free to get in touch. We'll see what we can do.
Josh: Yeah, we'll see about that.
Ben: Anything else?
Josh: I don't think so. I think that's a wrap.
Ben: Yeah, that's a good one.
Josh: Cool. Well, this has been FounderQuest. Go check us out at FounderQuest podcast-dot-com. Go to the show notes for this episode and find your Honeybadger slash FounderQuest discord invite, join us on discord. We’ll catch you next time.