Will Working Together Ruin Our Anarchist Workflow?

This week The Founders talk about the possibility of working more closely together and if it'll ruin the company's current approach to project management, anarchy. If that's not enough, Ben talks about streamlining SOC 2 auditing, Josh talks about updating Hook Relay's marketing, and Starr reviews Twist, our potential Basecamp replacement.

Show notes:
Links:
Twist
Full transcript:
Starr:
So Ben is joining us today from his car. It's bringing back fun memories. I recorded, I think the voiceover for our very first demo video in my car.

Ben:
Oh yeah? Nice. So as you may recall, I have a two story building that I lease one of the rooms, and the downstairs is a wine tasting room. Well with the pandemic, the company that had the wine tasting room, they closed shop. They stopped leasing, because who's going to go to a wine tasting room during a pandemic, right? Well they're leasing the space to a new tenant that's going to take that space. Apparently hey, we're getting back, things are reopening, let's taste wine again, but the new tenant wants to have a new door put in. So I got to the office today and they're like, "Yeah, we're putting in a new door." And then I'm like, "Cool." Didn't even think much of it. But then a few minutes later, there's all this drilling going on. I'm like, "Oh, I think probably the car is a better place to record today."

Josh:
Well at least you'll have some new friends soon.

Ben:
True, true.

Starr:
Yeah. Well I'm glad you made it, at least. And so what's up? I missed a week of the podcast and you guys invested our entire Honeybadger savings account into Bitcoin.

Josh:
Yeah.

Starr:
And I'm not sure that was the most prudent investment decision, y'all. I just wanted to say that.

Ben:
Yeah, the timing could have been better.

Josh:
Yeah, we really pulled a Roam Research on that one.

Starr:
Oh yeah. What do you mean by that?

Josh:
They invest in Bitcoin, apparently.

Starr:
Oh, they do? Okay.

Ben:
Of course they do.

Starr:
Of course. It's just a dip. You're supposed to buy the dips, Josh. It's just what, like a 30% dip? 40% dip?

Josh:
I wasn't watching it, but I read that it had recovered pretty quickly too.

Starr:
Oh. I have no idea. I didn't even follow it.

Josh:
As it does.

Starr:
I don't even follow it.

Josh:
Yeah. I just read random people's opinions.

Starr:
There you go.

Josh:
I forget where we left it last week, but I just wanted to state for record that I think I mentioned I made some accidental money in Bitcoin back when I was learning about block chain technology, but I have not bought any Bitcoin since, nor do I intend to, and I do not really view it as an investment asset.

Starr:
This is not investment advice.

Josh:
I just need to state my opinions for the future so I can look back on them with regret. If I don't say what I actually think, I'm never going to have anything to regret.

Starr:
There you go.

Josh:
I'm just going to commit.

Starr:
So you've decided to die on this no intrinsic value hill.

Josh:
Right. I'll let you know if I change my mind.

Starr:
Okay, that's fine. That's fine. Yeah, I don't really check. Last week y'all did the interview with Mike, right?

Josh:
Mm-hmm (affirmative).

Josh:
Yeah, it was a good conversation.

Starr:
Yeah. I don't really pay attention to it, except occasionally I'll look at the chart. It's the same with GameStop. Occasionally I'll look at the GameStop chart and then just see what wild stuff people are saying about it. Yeah.

Ben:
Yeah, GameStop was hovering at about 150 for a while, but now it's up to like 170-ish, 180. Something like that. Yeah. I peek at it every now... it's on my watch list when I log into my brokerage account, so I just see it. I'm like, "Oh, okay. Cool." And then I move on and check out my real actual stock portfolio.

Starr:
Oh yeah, yeah. I'm not going to buy it. It's like a TV show for me.

Ben:
Yeah, totally.

Josh:
Yeah. To be fair, I really don't have much of an opinion either way. I still don't understand it, so I don't know. I just feel like I probably shouldn't be buying it.

Starr:
That's really good advice. I don't understand anything though, so what am I supposed to do, Josh? Huh? Huh?

Josh:
Yeah.

Ben:
Just buy the index fund.

Starr:
Yeah. I don't even understand that.

Josh:
I don't understand that either though, if you really think about it.

Ben:
That's actually, there was a good thread or so on Twitter. I don't know if it was this week or last week, but basically the idea was if you feel really confident in your own ability, in your own business, given that, you're probably spending most of your time in that business, right? We spend most of our creative time in Honeybadger because that's where we feel the most potential is. So you're investing basically all of your personal capital in this one business. How do you diversify that risk? Or do you diversify the risk? Do you double down? Maybe do you take investment to diversify, and so you buy out? Let someone do a secondary and so you take some cash off the table? If you did that, then where would you put the money? Do you just go, "Okay, I'm going to go buy Bitcoin. I'm going to go buy an index fund," or whatever. And if you do that, is that a better use of your money than having just kept the equity and just plowing more time into your business? Right?

Josh:
Yeah.

Ben:
It's an interesting thought exercise. It's like, "Hm." The whole investment mindset of your business is interesting to me.

Josh:
Yeah. Yeah, that was interesting. I think I saw that conversation, or maybe I saw a similar conversation where they were talking about even just 401Ks and for founders who are already fairly... have at least made it in whatever sense that means. Is it the best financial move to keep maxing out your 401K versus investing in your ability to generate revenue in your business?

Starr:
So a little bit of real talk here. If you are a founder who's made it, maxing out your 401K isn't really a blip on your financial radar.

Josh:
It's not a big... yeah. That was kind of the same thought I had. It's not like you're putting 50% of your income into it.

Starr:
Yeah. What is it, like 20 grand? Something like that?

Josh:
Yeah.

Starr:
It's a good chunk of change, but still. It's not like...

Josh:
Yeah. I don't know.

Starr:
Yeah, that's interesting. I think I'm just going to go all in on Pogs. I think they're due for a comeback. I think that's going to be how I diversify.

Josh:
But I think it's probably a good move to invest in yourself if you have the ability to build businesses. That definitely seems like a good investment, in any case. Probably still have a 401K. I tend to do everything, except Bitcoin.

Ben:
A 401K is a nice backstop. Just keep stocking money away, and later it will be there, hopefully. But in the meantime, really, really spend your time and your energy on making your business even more profitable. Speaking of making your business more profitable, so this past week or two weeks, I've been working on our SOC 2 type two audit, so I'm doing the evidence collection.

Starr:
Oh yeah?

Ben:
So that in this case means I take a bunch of screenshots of settings, like the AWS console and G-suite console to show yeah, we have users, and yes, we have login restrictions, et cetera. All the 150 different things that you're supposed to check off the list when you do the audit. And as I've been going through this process taking all these screenshots, honestly it's getting a bit tedious, and it's surprisingly time consuming. And so I'm like, "You know, there are services for this sort of thing. Let me check them out." And so in the past three days, I've had conversations with Vanta, Secureframe, and Drata. These are three providers that what they do is they provide almost SOC 2 in a box. Basically they help you connect all of your systems and get the evidence that you need for an auditor in a more automated fashion. So for example, they'll plug into your AWS account and they'll pull out information about your security groups, your application firewall, your AIM, all the access permissions, all that kind of stuff, and pack that up into a nice little format that the auditor can then look at and like, "Yeah, they're good on all these different requirements." So you don't have to take screenshots of security groups.

Ben:
And I hadn't really looked at them before because I was like, "I don't know if I just want to spend that kind of money," but actually sitting back and looking at it, looking at the time that I'm spending on this and the amount of time I'm paying our auditors to audit all these screenshots that I'm taking, actually I think it would be cheaper to go with one of these services, because your audit is a bit more streamlined because the auditor knows how that data is going to come in and it's an easy format to digest, et cetera. But the thing is that after having gone through some of the sales pitches from these vendors, I'm thinking I really wish I would have started with these back the first time, because I think it would have been much easier just from the get go. So I think I've been doing the SOC compliance on hard mode, unfortunately, but lessons learned.

Starr:
With my experience, that just seems to be how projects are. You do it one time and you don't really know what you're doing, and you just push your way through it, and then eventually you figure out how to do it better and easier and all that. Because when something is new to you, you don't know what you can safely ignore. You know?

Josh:
Mm-hmm (affirmative). Yeah. Well plus you're pumping up the value of FounderQuest.

Starr:
Oh, that's true. We got a lot of content out of that.

Ben:
That's true.

Starr:
At least $100 worth.

Josh:
That's useful knowledge. Yeah.

Ben:
Yeah, so I think the short version is if you are interested in doing SOC2 compliance and you have no idea what you're doing, talk to these vendors first and maybe just start with them. They will help you, because they have customer success people like SaaS does. They have people on staff who are there to help you have success with their product. And if you don't get compliant, then you're going to stop using their product, so they're going to help you try and get there. And it's still pricey. It's still going to be five figures a year, but it will definitely save you some time and maybe even save you some money.

Josh:
Nice.

Ben:
Yeah. So next year, our audit should just be smooth as silk.

Starr:
Just butter.

Josh:
Love it.

Starr:
So if we-

Josh:
What are you going to do with all that extra free time?

Ben:
I made an executive decision.

Starr:
Oh really? What's that?

Ben:
Yes. The executive decision is we're going to have more teamwork at Honeybadger.

Starr:
That's ironic.

Josh:
Instead of what? What we have now, which is anarchy?

Ben:
We pretty much do have anarchy, I think. We are coordinated, we do make our plans, and we do have things we want to get done, but yeah, we are very independent at Honeybadger. We work independently. You might even say we're kind of siloed. We go off in the corner and do our own thing for most of the time. And I was chatting with Kevin about this, and I think we're going to try an experiment. So I think we're going to try to actually work together.

Starr:
Kevin is our developer.

Starr:
Yeah, so you all are going to be developing features together. Are you going to pair program? Are you going to use Tuple?

Ben:
Whoa, whoa, whoa, whoa. Slow down there.

Starr:
Are you going to mob program?

Ben:
Pair programming, that's maybe too advanced for us, I think. Maybe actually we'll chat in Slack a little bit here and there and maybe have a Zoom call.

Josh:
Yeah, so you're talking about you're both going to work on the same project at the same time.

Ben:
Right. Right.

Josh:
Mostly independently, but coordinating.

Ben:
Right. Yeah.

Josh:
Yeah. Yeah, I don't know. I think that still can fit into our anarchy model.

Starr:
Yeah. It still seems a little bit independent.

Josh:
It's more like mutual aid or something.

Starr:
There you go. We should make a conference talk about mutual aid development.

Josh:
Right.

Starr:
That would go over well.

Ben:
Using NATO as a model for your development process. Yeah, so we'll see how it goes. I'm looking forward to it. I think I've been feeling a little lonely. I don't know if it's the right word, but maybe just off doing my own thing. I was like, "Oh, I think it will be nice to have some collaboration, some coordination." Maybe we'll even get to a level of synergies.

Starr:
Synergies.

Starr:
That's a blast from the past.

Josh:
Yeah, I think it's a good idea.

Ben:
Yeah, so more to come on that. We'll keep you posted. It's a bigger project. May not have results for a couple months. Don't really want to spill the beans on what it is right now. Competitive information. Don't want to leak it to all of our competitors.

Starr:
I like that. I like that. It's going to keep people on the hook for the next episodes.

Josh:
Totally.

Ben:
But yeah. That was my week.

Josh:
Yeah. Well my week, I took some time off, had some family stuff going on, so I was not very productive this week, but what I did work on was I've been working on this little guide for Hook Relay. I'd love to get the marketing machine, the fly wheel going on that at least, so we can be moving that along with everything else. And so yeah, working on some content and such.

Starr:
What is Hook Relay?

Josh:
Well you tell us what Hook Relay is, Ben. It's your baby.

Ben:
It's my baby. Yeah. So Hook Relay is a tool for managing web hooks. So you can record web hooks as they go out. In our case, to Honeybadger, we send a lot of web hooks, and so we built Hook Relay to help track all that web hook action. So we logged as pay loads that can go and diagnose issues that are happening, or maybe replay them as necessary, and of course it also handles inbound web hooks. So if you were handling, let's say, a post pay load request from GitHub about some activity that happens in your GitHub account, you handle that web hook and we can give you a place to store that, and then you can replay that, send it, forward it onto somewhere if you want, or just store it.

Josh:
Yeah. I think one of my favorite things about Hook Relay is just the visibility that it gives us into what's happening with the hooks, because otherwise we never had a dashboard. I guess we could have built one internally to see what the activity was and what's failing, what's actually... what requests are... because you're connecting to thousands of different people's random domain URLs, basically. It's really nice even for debugging and things like troubleshooting to be able to see what's going on, in addition to all the other cool things that it gives you out of the box.

Starr:
So you might say it's even like turnkey reliability and visibility for web hooks. For all your web hook needs.

Ben:
Yeah. Yeah, we modeled it on Stripes web hooks because we loved-

Starr:
I'm holding up a box up. I'm holding the TurboLinks box up and gesturing at it with my hand.

Ben:
Vanna White style.

Josh:
We should do our own channel, do our own infomercials.

Ben:
Yeah, I really wanted experience of Stripe. If you set up web hooks in Stripe, you can go and you can see all the web hooks they've sent you. You can see the pay loads, you can see whether they were successfully delivered or not, and I wanted that experience for our own web hooks, and also I thought it would be cool if developers could just have that without having to build the infrastructure. And so if you're building an app that send a bunch of web hooks on behalf of your customers, well now you can give your customers visibility into that web hook activity without having to build that tracking yourself.

Josh:
Yeah. That's pretty cool. So basically this content guide I'm working on is how to build web hooks into your application, including all the reliability and stuff that Hook Relay gives you for free. And the idea is that if that's what you're doing and you just want to save some time, Hook Relay will be a large chunk of that. You've just got to sign up. So I think it will be useful to everyone, even if they don't become a customer. If you're going to build your own back end and handle all the retries, build dashboards, and all that. But if you want it all turnkey, then Hook Relay is a big chunk of that work just done of you.

Starr:
So is this live? So can people go and sign up now?

Ben:
Yeah.

Josh:
Hook Relay, yes. It is.

Josh:
Hookrelay.dev.

Ben:
Yeah. In fact, we have enough customers now that it's actually paying for itself.

Starr:
What?

Ben:
Yes. So sweet.

Josh:
It's wild. That's wild.

Starr:
That's amazing.

Ben:
So Josh, is your guide going to have... are you going to dive deep into the architecture of here's how you build a whole web hook system, and so we're going to show you all the stuff behind the curtain so you can build your own? And then, "Oh, by the way, if you want it just done for you, here it is." Or are you going to just keep it more high level?

Josh:
I'm starting more high level. Yeah, I was planning on it being more high level. More like a high level architecture thing, or specification. Like these are the parts that you'll need to build, but you're going to have to solve some things, because it's not going to be specific to one system. It's not going to be like, "This is how you build web hooks for Ruby and Sidekick, or if you're going serverless." It will have suggestions on stacks or technologies to use for the back end, for instance, but yeah. I was thinking of leaving that to the user to figure out, but just showing the things you need to think about that a lot of people don't think about until they encounter the problems that might arise, like retrying and all the error handling that you add later, and validation for security reasons and things.

Ben:
Yeah. Yeah.

Starr:
This is giving me flashbacks to a whole two or three year process after we first launched.

Josh:
Yeah.

Starr:
It was just like, "Oh, crap. There's an edge case here that we didn't think of because we're not used to doing web hooks at this scale." And that just went on for like three years.

Josh:
Yeah. And it's nice having the two products because Hook Relay came out of Honeybadger and it's basically part of our web hook system. This is basically just documenting Honeybadger's web hook system for other people who might want to replicate that or whatever.

Ben:
Totally. I think that will be cool. A great piece of content, a great piece of SEO juice. And if you did decide to go deep into the technical side, like if you explain the entire infrastructure that we're building, that would actually be kind of cool too because you could maintain your technical documentation for the system internally and use it as a piece of content for marketing.

Josh:
That could be cool. Yeah. That's not a bad idea. Yeah, I was thinking just because I want to get something out there. I'm thinking it will help with both, having a resource for people who are already on the site to see this is basically how you will implement this. It's kind of like an implementation guide, really. But then also SEO. It should help get us in more search results.

Ben:
Yeah.

Josh:
And I also want to credit Ben Orenstein and and Tuple. They have a great pair programming guide which was an inspiration for this idea. I just really liked the format that they used, and I just think it's a great idea if you have a product that's highly targeted or focused on one specific thing and doing it really well. I think it's maybe even a great alternative to a blog, for instance. You can get some of the same benefits of having a blog, but without actually having to create a blog with a lot of different variety of topics and things.

Ben:
Speaking of the blog, I was talking to Harris, our sales guru, about our blog strategy, and I said, "Yeah, it's basically like a flypaper strategy. We want it to attract developers that come and see the content and they love it and they're like, 'Oh, let me check out this Honeybadger thing.'" Not particularly novel, but I like the flypaper idea.

Starr:
That's a good metaphor. And also for a long time, I poo-pooed SEO because in my mind, SEO was very scammy. I don't know. I learned about SEO in the days of link farming and all that, and I just didn't want to be involved in that. So I'm just like, "We're just going to put out good content and that will be enough." And it is, yes, but also I've looked at some metrics since then that make it clear that the majority of good things that happen because of our blog actually are people entering through search queries. That really outweighs people sharing articles and doing stuff like that, which I guess is obvious that it would be that way, but my own bias against search just made me not see that for a while. So maybe trying to pick some possible low hanging fruit. We've tried to make our site search engine friendly, but we having really done any explicit SEO type activities.

Josh:
Yeah. I went through recently through our documentation and just tweaked just small things on a bunch of pages, like headlines and some of the meta tags and stuff, but mostly headlines and content on page was what I was focusing on. And I wasn't using any particular tool to measure before and after results, but it does seem like it bumped us up in some of the results for people searching for more general terms like Ruby error tracking, for example, which are typically pretty competitive terms. But I think we rank pretty well for some of those terms these days. I think we've been around enough and we're one of the options that come up. So it does seem like if you already target the terms, it actually does what they say it does, which is good to know. You've just got to pay attention to it.

Ben:
So the moral of story is there is some value in SEO.

Starr:
I guess so.

Josh:
Yeah. Well and I think documentation sites. Your documentation, I think it's a great place to optimize SEO because a lot of times, especially for those... maybe not for the long tail searches. A blog is great for that, like what you were talking about with the flypaper, Ben. But for people who are actually searching for what you do, I think a lot of times documentation pops up first in a lot of cases when I'm searching for things, so don't overlook it like we did.

Starr:
Yeah. Well this week, I guess the main thing I did was I got our authors lined up for the next quarter of intelligence briefings. So if you haven't been playing along at home, we're having some intelligence briefings created. Basically everything that's going on in a certain language community for the quarter, and this grew out of Josh's need because he's basically in charge of our client libraries. And we have libraries in a variety of languages, so keeping up with those languages and what's going on is a real pain in the ass, so we were going to make these guides originally for him, but then also we were like, "This would be really great content to publish."

Starr:
And I've already got this system with authors who want to write about programming languages, and so let's see if we can make some authors make these summaries. And so far, yeah, I'm pretty happy. We had four or five of them created, and we're not publishing them because they were for a previous quarter, and this is just a trial run to see if the results are okay, and I think they were. I think the results were pretty good. We go some feedback from you two, and I updated my process and updated the template that all the authors are using, and so we should be getting round two done. I'm setting the deadline a week after the end of the quarter. My hope is if they get them to me then, then I'll have a week to get them up on our blog or wherever, and then they won't be too out of date by the time people see them.

Josh:
Yeah. That's cool. I'm excited to see the next batch. My favorite thing from the reports were the ones where they wrote some original content summarizing things or sections or whatever. That was super useful because there's a little bit of a story element to it that's specific to the quarter or whatever that you don't really get from just... if you just aggregate everything, all the weekly newsletters and what happened on Reddit and what happened on Twitter. If you just dump that all in a document, it's a bit of overload, so it's nice to have the summary the story of what the community was interested in.

Starr:
Oh yeah. Definitely.

Josh:
Here are some articles that they talked about.

Starr:
That's the whole idea, is to have somebody who knows the community explain to you what's going on, as opposed to... if I wanted a bunch of links, I could just write a little script to scrape links from places.

Josh:
Yeah.

Starr:
And it wouldn't be very useful. What's useful is having people who know the environment being like, "Hey, this is what's going on. This is why it's important." And yeah, so that's going to be something I guess I need to look for explicitly when I get this round of things of reports back.

Josh:
Start calling them secret agents or something instead of authors.

Starr:
Oh yeah.

Josh:
Or detectives.

Starr:
Operatives. Yeah. Assets.

Josh:
As our detective service investigators.

Ben:
I think having that analysis of why this news is important or why these things are important that they've collected is really handy, because the links are great. Like you said, I could just write a script to collect them, but having someone with that context in the community saying, "Okay, and it's important because, and this is why you should pay attention," I think that's really helpful to someone who's maybe not as deep into that every day.

Starr:
Oh yeah.

Josh:
Yeah. And also knowing what to surface, because there was one report that it really seemed to just dump every single link or article that was discussed or was in a newsletter or whatever, and I think it's more helpful if it's on a quarterly level, if you know what is actually the important things that you really want to know about.

Starr:
Yeah, that's true. I just made a note for myself to go back and explicitly just mention that to people, because I realized I didn't put it in the instructions anywhere. I put like, "Here's where a description of the content goes," but I didn't really put what I want inside that description, I realized.

Josh:
Yeah.

Starr:
So I'm going to do that.

Ben:
We're iterating in real time here.

Starr:
Oh yeah, yeah. This is where the work gets done.

Josh:
Yeah. Well and pretty soon, we'll have hopefully some good examples that we can show future authors, or detectives, or whatever we're calling them.

Starr:
Oh, definitely. Definitely. I'm going to call them authors because they're already in the blog system as authors and it just seems like-

Josh:
Agents?

Starr:
I don't know. I've got to be able to talk to these people with a straight face.

Ben:
You could call them research specialists, but then you might have to pay them more.

Starr:
There you go.

Josh:
Research. Yeah. Yeah.

Starr:
I don't know. I think I'm paying pretty well. Honestly, I think I'm paying pretty well for looking at... I don't know. How many weeks is a quarter? 12? 12 weeks of newsletters and just telling me what's going on. I think I'm paying pretty well.

Josh:
Yeah. You don't need to talk to them with a straight face though. You need to talk to them with sunglasses on, smoking a cigarette in a diner.

Starr:
Oh that's right. Yeah.

Josh:
Or a dive bar somewhere.

Starr:
Those people aren't smiling. Those people aren't smiling. Oh, that's right. I can do that. I just realized that it's two weeks since my second vaccine, so I'm ready to go out and recruit secret agents.

Josh:
Ready to party.

Starr:
Yeah. I'm very anxious talking with people in public now, but that's not a topic for this conversation.

Josh:
Yeah. We'll ease back into it.

Starr:
Oh yeah. Yeah, we're going to have dinner with my sister in law on Saturday, and I'm just like, "Okay Starr, you can do this. You can do this."

Josh:
Cool.

Starr:
Yeah, and I guess the other thing that we did this week is we are doing a trial run of Twist as a replacement for Basecamp messages, the message board on Basecamp. And yeah, so basically the long and short of it is the whole Basecamp BS just left a bad taste in my mouth in particular. I think you all's a little bit, or maybe you're neutral. I don't care. That sounded really harsh.

Ben:
You can be honest with us. We can take it.

Starr:
No, I didn't mean to sound that harsh. I just mean I'm not trying to put my opinions onto you, is what I'm saying. I just felt gross using Basecamp. Also if I'm being honest, I never really enjoyed Basecamp as a product. It's got a couple things that just really rubbed me the wrong way.

Josh:
We were having some vague conversations in the past. We have posed do we really want to keep this part of what we're using Basecamp for? And we were already using a subset of it, so yeah. It wasn't totally out of the blue.

Starr:
Yeah. And we were using maybe 20% of Basecamp, just the message boards feature.

Josh:
And the check ins, which apparently we all disliked.

Starr:
And the check ins, which nobody liked but we all kept using for some reason. Ben is like, "Can I turn off the check ins?" And I'm like, "I thought you were the only reason we were doing the check ins, it's because I thought you liked them."

Ben:
I think I was the only reason we were doing the check ins.

Josh:
It's because... yeah.

Ben:
Yeah, because I remember when I started it I was like, "Yeah, I really don't know what's going on," because back to that siloed, independent, off in the corner thing, I was like, "It would be nice to know what people are doing." But yeah, lately I've been like, "This is just a drag." So I'm like, "Would anybody be upset if this went away?" And everyone is like, "Please take it away."

Josh:
Everyone is just passively aggressively answering them.

Ben:
Everyone hated it.

Josh:
It wasn't that bad, but-

Ben:
I get it.

Josh:
Kevin used them too, but yeah.

Ben:
So I finally gave everyone permission to tell me that it was not okay, and now we no longer do it.

Starr:
There you go. And we're just like, "While we're at it, just ditch Basecamp." So yeah, so we've been trying a new system called Twist. Twist is, essential it's... I don't know, it's like threaded discussions. I figured this out on my own. I'm very proud of myself. So you have lots of threads, and you twist them together to make yarn or something or some sort of textile, so I bet you that's why it's called Twist.

Josh:
Beautiful sweater.

Starr:
Yeah. A beautiful sweater. The tapestry that is Honeybadger. And so far, I've really been enjoying it. I find the UI to be a lot better. There was one bug that we found that I reported, so hopefully that will get fixed. It doesn't really bother me that much. Yeah, it's amazing sometimes how the UI of an application can just be like, "Oh, ah. I'm having to parse less information just to do my task."

Josh:
It's much nicer.

Starr:
Yeah.

Ben:
It does feel like a lot less friction for our use case.

Josh:
Yeah. Well we talked about that, just the structure. The way that you structure conversation and organization things in a management tool like that makes a big difference. In Basecamp, we would create Basecamps for whatever. They call them Basecamps, right? They're the projects.

Starr:
They're like projects. I don't know.

Josh:
We'd create different ones, different projects for each project, but then there's five of us, so we'd basically just add everyone to every single project that is in there. But all the conversation is siloed off in each project, and with Twist, it's just much more of a fluid... it uses what, like channels? But yeah, it just seems like it's all together. It's kind of like a combination of Slack and a threaded message board or something, to me.

Starr:
Yeah, or like Slack and email or something.

Josh:
Slack and email. Yeah. It's a nice combo.

Starr:
Yeah. It has inbox, which I like, where it shows you any unread messages, and so you can just easily just go and scan through them, and it's all in the same page. It's a single page application, so you don't have to click out to a completely new page and then come back to the inbox and do all that. Basecamp had a similar feature, but it's like a timeline and it had a line down the middle of the screen and then branches coming off of either side of it. And for some reason, I started using the inbox in Twist and it was just like, "Oh, this is so much better." For some reason I think having things on different sides of the screen just doubled the amount of background processing my brain had to do to put it all together. And yeah, so I don't know. I do like it. Also, it's got mark down. It's got mark down.

Josh:
The mark down editor is so nice. It reminds me a lot of just using GitHub, the editor on GitHub, with the mark down mode and preview. And you can drag and drop images into the... I don't know if you knew that, into the mark down editor, like you can on GitHub, and it automatically inserts the image tag and uploads it for you.

Starr:
Yeah, it's all really slick. So I don't know. I imagine in maybe another... I've got vacation next week, so maybe after that we'll get together and compare notes. But I don't know, it seems like people like it so far.

Josh:
Yeah.

Ben:
Yeah, it's been good. It's interesting-

Josh:
If I had to decide today, it's a keeper for me.

Ben:
Yeah, I would go ahead and switch.

Starr:
Oh yeah, me too.

Ben:
It's interesting to me, you alluded to this, Starr, as you were talking about comparing it to your products and how they approach... it's interesting to me the UI, even if it's the same kind of functionality, how much different takes on the user experience can make a different experience for the user. How it just feels different. Like, "Oh yeah, it's basically doing the same thing, but it just feels better for whatever. My mentality or our business." Fill in the blank there, but I thought about that many times. Honeybadger versus competitors. It's like, "Yeah, they're doing basically the same thing, but we do have differences in how we approach the UI and different use patterns that we think are more emphasized by our UI versus the others." And sometimes it's just a matter of personal preference. It's like, "Oh, this just feels better to me." One night I tried Python before I tried Ruby, and Python is like, "Oh, that's interesting," but then Ruby really clicked my brain. It's like, "Oh, it just feels better." And I'm sure other people have the opposite experience, but I don't know. It's weird to me and fun to think about the human part of these products. 

Josh:
Yeah. And it's surprising, the strong opinions that people pick up just based on those experience things when they're basically the same, if they're doing the same thing. Some people, they either love it or hate it based on that.

Starr:
Yeah, that's true. Maybe it all goes back to whatever business apps you used in childhood. It's just whatever your mom made you for lunch, you're always going to love that.

Josh:
Yeah. It's like a nurture thing, nature versus nurture. You were exposed to these apps when you were young, and so it's just what you're drawn to.

Starr:
Yeah. I remember putting my little friend's contact details into Lotus Notes.

Josh:
Right. I had to program Lotus Notes.

Ben:
I got my first dev job because I knew Lotus Notes.

Starr:
Oh, nice.

Josh:
Lotus Notes was an important precedent at the time, I think.

Starr:
Yeah.

Ben:
Yeah. Yeah. It was the bomb. You could do some pretty serious stuff.

Starr:
Yeah. I kept having these jobs that weren't technically dev jobs, but ended up being dev jobs just because I knew how to write V basic macros for Excel. I'm sure a lot of people had that experience.

Josh:
The thing I remember doing in Lotus Notes was setting it up to ingest email from the outside world into whatever, the system. And thinking about it now, that project I've done over and over and over since then.

Starr:
It's Basecamp.

Josh:
And I'm still doing that project.

Starr:
It's Basecamp all over again. Oh no.

Ben:
If only there was a service that took in emails for you, and then you could just bring them into your app data.

Josh:
Yeah. I bet in 20 years, we'll be writing programs to accept email.

Ben:
Process emails, yeah.

Josh:
Yeah.

Starr:
Yeah. When is this stuff going away? Technology changes all the time. When is email going away? They've been killing it for years. It's like fricking Rasputin. When is it going away?

Ben:
It's the cockroach of protocols.

Starr:
There you go.

Josh:
After the singularity, they'll still have to have a way to import it directly into your consciousness, and yeah, I don't know.

Starr:
Yeah. I hope the spam filtering is really good then.

Starr:
All right, well it was great talking with y'all.

Ben:
Likewise.

Starr:
Yeah. So this has been FounderQuest. Go to the Apple podcast and review us if you want. If you're interested in writing for us, we are always looking for fresh, new talent. Young authors looking to make their mark on the world of technical blog posts for SAS companies. And yeah, just go to our blog and look for the write for us page. I don't currently have any openings, but who knows? People flake out. So if you're interested in writing these reports for us too, get in touch. These quarterly intelligence briefings, if you want to be an agent for our intelligence service. All right, so I'll see y'all later.



Copyright 2021 Honeybadger Industries LLC