FounderQuest
FounderQuest
How To Unlock The Gold Standard of Webhooks
Show Notes:
Links:
Stripe
Hey
Bye
Full Transcript:
Josh:
I'm the co-pilot today, right?
Ben:
Co-pilot. Yeah, yeah. So today we're flying without Star. Star is not feeling well, so today is just the two of us.
Josh:
And I have been on vacation. Well, I am on vacation.
Ben:
Yeah.
Josh:
Sticking my head up.
Ben:
We are so into FounderQuest that we even come in on vacation to record an episode.
Josh:
Yeah. I don't know. It's nice to keep the schedule. I don't know. I've been trying to take a lot of vacations, so if we didn't record every time one of us was on vacation, then I feel like we wouldn't have a very consistent schedule.
Ben:
That's true. Yeah. So how is your vacation treating you?
Josh:
Alright. It's really a staycation so far.
Ben:
Right. I think all vacations are staycations for a while.
Josh:
Yeah. I've looked at bookings, to go to places. I don't want to go anywhere. I don't want to deal with any of the stuff that's going on right now.
Ben:
Certainly.
Josh:
Or take the risk. Then if we did go somewhere, we still have two toddlers. We're better equipped here at least to manage two toddlers who are bored, and there's only so much hiking you can do with a two year old.
Ben:
Yeah. So no trip to Disneyland this summer?
Josh:
Not so far, unless my in-laws decide that they want to watch the kids for a few days or something then we can get away. But so far, that's not looking too likely at the moment.
Ben:
Well, I'll tell you what. All you got to do is wait 10 to 15 years, and it will be great.
Josh:
Only 10 to 15 years. Yeah, yeah.
Ben:
Yeah.
Josh:
So, I don't know. I've been eyeing a bass guitar for a while, and I'm trying to talk myself into finally buying it right now. But I don't know, I'm still debating.
Ben:
Yeah.
Josh:
There's a chance I'll pick one up.
Ben:
Yeah, yeah. The pandemic is a great time to learn new things, right?
Josh:
Yeah. I think that a lot of people are thinking that way, and driving different parts of the economy.
Ben:
Now, you already played a keyboard, right?
Josh:
Mm-hmm (affirmative). Yeah. I play piano and guitar, and I actually had a bass for a while. It was borrowed, but I liked it. I liked having it around just to funk around on it.
Ben:
Yeah.
Josh:
Yeah. But now I want to get a big stack from a garage because I don't have enough cool stuff in there already.
Ben:
You need to take out some extra insurance on the stuff that's in your garage now.
Josh:
I know. If that garage burns down, I'm done for.
Ben:
Yeah. You got to declare that stuff, man. Those insurance companies, they don't mess around.
Josh:
Yeah. Speaking of that how's your bathroom situation?
Ben:
Yeah. My bathroom is still not great. So it's amazing how unresponsive contractors can be. I really don't get it. I sent out a bunch of requests to people like, "Hey, here's my situation, and I want to hire someone to help me fix it." And I would say 70% of the people just didn't even respond. I don't know what their sales process is like or if they're super busy right now or what the deal is, but how do you stay afloat in the business-
Josh:
Really?
Ben:
... when you're not responding to leads? I don't know.
Josh:
Yeah. That's a good question.
Ben:
Yeah. So, I still haven't selected a contractor, so the chances of me of actually just doing it myself are increasing as the days go by. I've been watching the YouTube videos to learn how to-
Josh:
Really?
Ben:
... install a new tub, things like that. So my confidence is growing slowly, so I just might actually do it. We'll see.
Josh:
I've had the same thoughts a few times. I should really learn how to do stuff around my house if I'm going to be a homeowner, and then I've also had the thought that maybe I shouldn't own a house, and I should be renting in the first place. There's that whole camp that I don't think ... They're not wrong.
Ben:
So the whole economic theory of you should maximize your ... I don't know what the exact phrase is. I can't remember what the term is, but basically you should focus on what you're good it and pay people to focus on what they're good at, right?
Josh:
Mm-hmm (affirmative).
Ben:
So the economist in me is arguing for me not to do my bathroom myself because that doesn't make any sense, right?
Josh:
Yeah.
Ben:
Pay someone to do it. They can do a better job than I can.
Josh:
It's like comparative advantage or it's the whole specialization thing, and yeah. Same.
Ben:
But on the flip side, there's the whole ... It would be kind of cool like, "Hey, I did that." Right?
Josh:
Yeah.
Ben:
I put that in there, and there may be a mistake here and there, but that's my sweat and tears, and probably blood.
Josh:
It's also knowing how to at least do some of the smaller things would be useful because at some point, finding good contractors, and then managing them, and getting the work actually done, that's a whole job in itself.
Ben:
Wait, are we talking about bathrooms or are we talking about software development?
Josh:
Yeah. That applies everywhere. Yeah. The whole management aspect of any kind of contractor project.
Ben:
Yeah.
Josh:
At some point, it really does feel like it would be more efficient just for me to do it if I learned how or something.
Ben:
Yeah. Pro tip for all those freelancers out there is A) Be responsive to leads. B) Maintain good communication so that you don't have to put a lot of load on the person that's hiring you.
Josh:
Yeah. That whole management overhead thing is huge, and I run across it very infrequently in contractors I work with in both industries. But yeah. That's like a super power, having that skill of managing yourself, and actually driving the communication with the client, and making sure their needs are met, and all of that.
Ben:
Yeah. We've had projects from time to time, that I know that you've discussed that you think, "Well, it would be nice to do this, but I don't have a lot of time. I could hire it out, but then I have to have all the time to manage hiring it out." So it's a big deal for actually getting out that work to actually have someone that can actually just do it, and not to spend all your time managing them.
Josh:
It's also tough when you possess a lot of specialized knowledge that needs to be transferred to whoever does the work, at least if I have a specific way I want it to happen. Like I'm a perfectionist, and I want it to happen my way, but not do it. Personally, maybe that's a problem with me. Just like giving up and letting someone else solve the problem their own way. But there is knowledge transfer that you can take time depending on what the job actually is, which I think that's when argument for hiring someone who's going to stick around longer, and hopefully absorb, and be able to utilize that information for a longer period of time versus having to ... They have to learn all this special stuff about our business and problems, and then they move on in a couple of months, and you got to teach someone else how to do it.
Ben:
Yeah. I saw a Tweet this week that is related to that, and I thought it was interesting. I'll have to see if I can go and find it again for the show notes, but I'm going to roughly paraphrase it because I don't remember exactly what it said. But the thrust of the message was be satisfied with 80%, and the detail was, "So you get someone who can do the job 70% of the way, you teach them the knowledge that they need to get another 10%, to get them up to 80%, and then just accept that." You would do a 100% job, but someone else can do a 70% job. Then if you get them up to speed a bit, so that they can do some of what you do, then settle for that.
Josh:
Yeah. I like that. That's a good way to look at it. Yeah.
Ben:
So you can't always use that, but yeah. And I have the same issue. I'm a perfectionist, and delegation is an issue for me because if someone does something, I'm like, "Well, I would have done it this way." And I think one of the secrets is learning to have more acceptance of, "Okay, yeah." I think being married is helpful in that respect, especially having kids because you have to learn ... Well, hopefully, at some point you learn that there are different ways of doing things that doesn't have to be a right way. And just because I have a way I like to do it doesn't mean that's the only way to do it, right?
Josh:
Yeah.
Ben:
So, I guess it's kind of the same thing.
Josh:
I imagine that's going to come up a lot more frequently in the future as I start trying to get my kids. Right now, the level they're at is like they're starting to be able to pick up their toys if I stand over them and micro manage them for two hours. But yeah, that's-
Ben:
Yeah. Most recently, I thought about this for myself when I was loading up the dishwasher and getting it ready to run, and my sons, who are teenagers are ... They put dishes in the dishwasher in a way that I wouldn't, and sometimes I look at those things, I'm like, "How do you think this is going to get cleaned? It doesn't work this way."
Josh:
Good thing you brought a good dishwasher, I hope.
Ben:
So, I just have to relax a bit. It's like, "It's okay. It'll be fine."
Josh:
Yeah. The dishwasher has been built to handle all types of people or all types of person.
Ben:
Right.
Josh:
Yeah. The one that jumped into my mind was picking up the dog turds in the yard.
Ben:
Oh. Is there a right or wrong way?
Josh:
You don't know about that one? No. On that one, I don't care. As long as they aren't in the yard anymore, my kids ... Yeah. I'm looking forward to the day that I can delegate that task. They can take however long they want.
Ben:
Nice. So, I haven't been on vacation this week. I've been actually doing some work. And surprise, surprise, I actually haven't been doing a lot of compliance work, which has been a nice change of pace.
Josh:
I bet.
Ben:
I've been working on the side project that we've talked about a couple of times, and it's coming along nicely. It's almost ready to show, but I thought we could talk about it a little bit today and maybe invite some people to come and check it out if they want.
Josh:
Yeah. I'm excited.
Ben:
So, I don't want to reveal the domain name just yet because I'm not ready to be able to just sign up and bang it. I want to have more of a white glove experience for the first few. But I will say it is related to Webhooks, and sending post requests. So it doesn't have to be just a Webhooks capitalized. It could be like, I don't know. If you're posting something to JIRA because just about every system has a REST API where you send a post request. But basically-
Josh:
The current integration or something?
Ben:
Yeah, yeah. So we have a lot of those at Honeybadger where things like JIRA, and GitHub, and Trello where we're posting stuff all the time. We have a bunch of outbound requests like that. And one of the inspirations for this project was Honeybadger, and just dealing with sending Webhooks. And I don't know if most of our listeners played with like Stripe. In Stripe, they have an option where you can receive Webhooks, like when people update their subscription or change their payment information or whatever, and Stripe has a fantastic setup for their Webhooks.
Josh:
Really kind of the gold standard of Webhooks-
Ben:
Yeah. I think so.
Josh:
... in my opinion. Yeah.
Ben:
Yeah. If your server doesn't happen to respond properly, like with a successful okay kind of thing, then it will retry, it will back off and retry over a period of days. And I thought, "Wouldn't it be nice if we had that same kind of thing, but didn't have to build it?" If we built that for Honeybadger, but it's kind of a slog. It's not really fun work, and so I thought, "Man, developers need this, so that's why I built that as a side project." It started out a couple of months ago, I guess, and working on it here and there, and I love using it. It's to the point that I've been able to play with it, and we don't have it plugged into Honeybadger just yet. I think that's going to be next week.
Josh:
It's solving some of those pain points for you though?
Ben:
Yeah, yeah. So you don't have to worry about a queue because this isn't going to have a queue for you. It's going to do the retries for you, if that's necessary. Happy path is you send a request, and it just gets delivered, and no problems. But if it doesn't go that way, if there's a bad response, then it will retry, it will back off, it will retry for a period of days. But the one thing that I'm really looking forward to, to adding Honeybadger that we don't currently have that this does is it has every history of all the requests, and payloads that got sent, and the responses that came back. And that's just fantastic for debugging like if you're sending a Webhook.
Ben:
If you don't track what got sent, then you don't know. You can't report that back to your customer. And if you don't track the response, then you can't, "Well? Did it actually get there?" You're not really sure.
Josh:
Yeah. What about failures and retries? Is that in the history as well?
Ben:
It is, yeah.
Josh:
Okay.
Ben:
Basically, there's a list of responses. So if we got some 500 responses, we'll record the headers that came back and the response body that came back. So that all will be in history of each request.
Josh:
Yeah. I think I've ran into that issue before where it's frustrating, like if you're using a Webhook API or something, and if something doesn't happen or an event doesn't fire, and you're scratching your head, trying to figure out, "What went wrong? Was it on my end?" Maybe an exception occurred that I didn't track for some reason. Or maybe it was just a silent failure of some kind. Maybe I didn't check the right event name in the payload or something, and it fell through a case statement, being able to go, and I think Stripe and GitHub both have that feature, and I've used them on both. Like if they show the actual attempts, and retries, and failures, and stuff, then it's super useful.
Ben:
It is. Yeah. Really handy. Yeah.
Josh:
Yeah.
Ben:
So that was a big thing that I wanted to have in this, and I think developers will love having that and not having to build it.
Josh:
Yeah. Because it's kind of specialized. The way we've currently solved the whole ... We rely on Sidekiq's exponential, back off and retry on an exception case, and I think we just raise an exception if it's not a successful post or whatever. But this is actually specialized responding to the actual HTTP response that it's working off of, I would imagine, which is tailor made for these case of delivering Webhooks and all that.
Ben:
Right. And one of the things that we do at Honeybadger is, for example, if we're sending a Webhook to someone's server and it doesn't respond with a success after, I think it's three or four tries, we just stop. We don't keep on hammering that thing. And we disable that particular integration in Honeybadger, and we flag it for the user saying, "Hey, this thing is not responding, so we're not going to send anymore stuff to it."
Josh:
Yeah.
Ben:
And this new service has a callback where it actually will send you a Webhook letting you know if something fails.
Josh:
Okay. So this has some Webhooks. Right.
Ben:
Yeah. It's like a Webhook inception I guess.
Josh:
So are we using this on itself? Do we have another service that we're using to send these Webhooks?
Ben:
Well, actually yeah.
Josh:
Kind of like we have Honeybadger?
Ben:
Yeah. It does use itself to send those reports back.
Josh:
Really?
Ben:
Yeah, yeah.
Josh:
Nice. That's sweet. I love it.
Ben:
So even the reports back have retries.
Josh:
So we've already got two use cases for this thing.
Ben:
Yeah.
Josh:
Yeah.
Ben:
Yeah. And one of the things that I wanted to do, I wanted to build something that didn't require a whole lot of configuration up front. So what you can do is you can actually provision this like, I don't know, via Heroku maybe. You get back the API key, and you get the URL that you need to post your Webhooks to. Then you don't need to configure that. You can include in the headers the target URL. So basically this is like a proxy that records and retries for you, and you don't have to set it up ahead of time saying, "So you can use this for ..."
Josh:
Oh, that's cool.
Ben:
Yeah.
Josh:
Yeah.
Josh:
For one-offs.
Ben:
Right, right.
Josh:
Okay. Yeah. You don't want to have to go and set up what your event it's going to be beforehand. If you had to do that for every single thing that you re-layer, whatever. That would get a little tedious I imagine.
Ben:
Yeah. Exactly.
Josh:
I imagine we probably don't have a client library for this yet. I imagine it's probably in HTTP, API, but I could see a Ruby client library for instance, or Elixir, or PHP or whatever. There's a lot of opportunity in there. For example, because right now it's like sending an email. You're not going to want to do that in a process in most cases, like if someone signs up for your web app or something, you're not going to send that blocking the connection while it's sending an email or delivering a Webhook. But in the same way that we could potentially just use an in-process thread or something to perform some work, you could easily use that in this case to post the Webhook to this new third party service because the service has all of the retry logic.
Josh:
So as long as it actually gets the initial request, then it's going to take it from there. So you probably don't even need to have a true job system for sending the initial request event. I imagine that's probably something we can build into our future client library or SDK or whatever we're going to call it.
Ben:
Yeah. One of the goals for this was for it to be fast enough, so that you wouldn't have to queue on your end, right?
Josh:
Right.
Ben:
You can just go ahead and-
Josh:
Just send it.
Ben:
... just send it. So we're using Serverless, we're using AWS, Lambda, we're using DynamoDB. So you send the payload to us. It's, of course, infinitely scalable because of AWS, and then we persist that really quick. Just this morning I was thinking, "Okay. Now how do we deploy this for multi-regions, so that you can have-"
Josh:
Oh, yeah.
Ben:
"... so you can have an endpoint that's close to you or close to your app?" And I've got a plan for that. So, I think we might even launch with multi-region support, so you can choose which one you want to deploy to.
Josh:
Nice.
Ben:
Yeah.
Josh:
Very cool.
Ben:
It's pretty close. It's cool. So just this-
Josh:
Can our tagline be send it by the way?
Ben:
Send it?
Josh:
Send it?
Ben:
Just like ship it? Now it's send it?
Josh:
Yeah. Like ship it, but send it. Yeah.
Ben:
Yeah. I like that. Yeah. Plus one. Yes, let's do that. So this week, I've been playing with the Heroku provisioning, and got that to work. So what I could really use, if any of our listeners are interested in checking it out, I could really use at least 10 people who would like to try out the service via Heroku because to get an add on listed with Heroku, you have to have 10 testers try it before they'll put it in beta stage, where it can show up in their marketplace. So if you want to try out our new hook sending service, please email me, Ben@Honeybadger.io, and I will get you squared away. It should be ready by the time this episode drops.
Josh:
Nice.
Ben:
Yeah. We're already deployed, we have the production environment ready, it's just I want to, again, do that white glove service that I know things are working properly for the first few customers before I open the floodgates.
Josh:
Yeah. This has been all you, and I noticed Kevin has been jumping in a little bit for the past couple of weeks, which is awesome. But I wanted to make time to check it out and do some work on it. I have not even hardly. I looked at the read me or something. So, I am excited to hopefully be one of those testers.
Ben:
Nice.
Josh:
I have a couple of little Heroku apps that I might be able to play around with or something.
Ben:
Cool.
Josh:
So sign me up.
Ben:
All right. So you're tester number one.
Josh:
Yeah. When I get back though, I'm excited to work on the marketing, and start getting into this project a little bit. I really like the idea of basically if Stripe is the gold standard for Webhooks or even GitHub has pretty good Webhooks, this allows you to have ... You are now the gold standard as well.
Ben:
Right, right. Yeah.
Josh:
It allows you to give that Stripe because Stripe has been known for the developer experience. Everyone knows Stripe. They have an amazing developer experience. It's what their business is based on. So especially if you're a developer, if you have developers who are your customers or your users, that's one area that you can really ... You gain a lot with those little fine touches basically.
Ben:
Definitely. Yeah.
Josh:
Because we notice that, and we appreciate it, and it's not something you want to-
Ben:
Yeah. It's funny. I didn't really think about this until just now when you were saying that, but developers really, their job is to pay attention to details, right?
Josh:
Yeah.
Ben:
They have to make things work exactly. So we really appreciate when we have a service that has paid attention to details and providing those little niceties. Yeah. Totally.
Josh:
Yeah. Documentation, that's the other thing that always comes to mind, even with Stripe. Their document has always been fantastic, and I assume we will have great documentation for this service once it launches, but that's another angle that's crossed my mind. Like when you were telling me about in the past also helping people provide that documentation on their Webhooks, not that this will cover that necessarily, but that's something we can definitely work into the whole onboarding process. You set up your Webhooks, now you should teach your users how to actually make the most of them and use them to build things, because that's really what it's all about. What are you going to do once you receive these Webhooks?
Josh:
It's the same idea as documenting your API. Your Webhooks are a part of your API. Yeah. And there's always-
Ben:
Yeah. I'm looking forward to have you jump in on that because you've done a lot of work on that with Honeybadger.
Josh:
Yeah. I still have a lot of work to do, but it's-
Ben:
Yeah. We still have those areas where it's like, "Oh, I really wish you really designed a payload this way instead of that way."
Josh:
Right. But again, maybe that's why we're building some of this stuff a little bit to create a better abstraction for what we currently have. Now, if you can solve versioning for me-
Ben:
Yeah.
Josh:
Then yeah, take my monies.
Ben:
Yeah. I'll have to work on that.
Josh:
That's the biggest issue with our Webhooks currently. It's on a super old version of our API payload, and eventually we want to migrate to a newer event format.
Ben:
Yeah. It would pretty cool. I'm just going to spitball here, but it would be pretty cool. We're thinking about Stripe, we're thinking about Webhooks. Stripe's API versioning is the best. I haven't seen a better example of versioning for an API. So what if we could do something like that where you first receive a Webhook, you know what version you received, and if a new version comes along, then you get an option to upgrade at some point, just like with Stripe. You can choose-
Josh:
That would be awesome.
Ben:
... the same old version or not.
Josh:
Yeah.
Ben:
Yeah. I have to think about that some.
Josh:
Yeah. Write that one down. That would be really cool because the way we would approach it in our current app, I think, is just build a new Webhook integration that new people can opt into, but we probably wouldn't ... It would be a larger project for us to actually go and implement some sort of opt-in for current users. I think what we would do is lead people on whatever they're currently using and support it forever, and then move new people who set up with Webhook integration are going to get the new version. But yeah, it would be awesome if we could actually encourage people to migrate ... To gain whatever benefits we've added.
Ben:
Right. Yeah. I'll think about that some.
Josh:
So maybe V2.
Ben:
Yeah, yeah. I know that Stripe's Webhooks do change based on the version of the API that you're choosing because when we did our Stripe upgrade recently, those payloads changed a bit that were coming into us. So this product won't have a request API like that, like Stripe does, but we could still a version thing where you choose a new version, then you start getting new payloads.
Josh:
Well, my favorite Webhooks to use are always the ones that mirror whatever the REST API is. So in the documentation, if you have your API objects documented, so for say like a user, you're going to fetch your users from your web app, you hit the API V1 users endpoint or something, and you get back a list of users. If there's a user involved in a Webhook event and that user is going to be communicated through that Webhook, send the same documented payload of whatever that object is because really, you're just communicating in objects. Yeah. They should always match the version on either side. Hopefully, your API and your Webhook objects are the same or working from the same spec basically.
Ben:
Yeah. I totally agree. And this new product does that with one exception. So we do store all the responses that come back when that Webhook gets delivered, and those responses can be kind of large because you're talking about response headers and response bodies, which can be really big. So when I send the report of a Webhook delivery, I send the same object that you would get back from the API minus that responses array. So there's just no point in sending a huge ... It could be a huge chunk of data.
Josh:
Yeah. We've run into similar issues with our Honeybadger API in Webhook formats. You're right. I guess even in APIs themselves that's, I think, one of the use cases for GraphQL or one of the selling points is that you can actually ... The client can describe the form of the data that is needed, and then you only send that data specifically. It's not that you're sending a different type of object or format, it's just that the user can tell you what it needs out of that object, so that you're not sending data that's just going to get thrown away anyway or never read. So you're able to send a partial ... Basically a partial representation of that object.
Josh:
And as long as a user knows that those other keys aren't going to exist or they're not looking for them, then I guess it's okay. But yeah. Something along the lines of that, I think we've explored a little bit. What's the JSON query thing that we-
Ben:
JMESPath.
Josh:
Yeah.
Ben:
Yeah.
Josh:
That's some pretty cool stuff.
Ben:
That is some pretty cool stuff. Yeah. So we use that internally, like for our PagerDuty integration. They recently they changed their API, so that they don't want payloads that are very large, and our payloads can be very large. So what we did is we added JMESPath filtering to the payload that we send, so we just filter out stuff that you just don't care about for PagerDuty. And maybe we could use that and combine that with a versioning thing. So you could post whatever you want to the Webhook endpoint, but then it gets filtered for an older API version maybe.
Josh:
Yeah. It could be cool. It seems like the same. It's solving a similar problem though. You want the same object, but you don't want all of it necessarily.
Ben:
Yeah. And it can do more than that. It can transform. Basically it's a transformation language, so it's not just pulling the stuff out. But yeah, we can do that.
Josh:
Cool.
Ben:
Yeah. A lot of fun stuff.
Josh:
It's nice to already have a V2 list. When you can't stop thinking of new things to add to it, you're probably onto something.
Ben:
Yeah. Exactly. And it gives you, I guess, a little more interest in it rather than just like, "Okay, we're done." It's like, "Oh, we can do this, and then we can do that." Yeah. Totally.
Josh:
Cool. Well, I'm excited to try it out for the first time when I return. I'm trying to stay away from the computer. It took me a couple of days, as usual, to get into that vacation mindset, and pull myself off of Twitter. Gosh, I won't start. I won't go on a Twitter rant. But it's nice to be off the computer and have that head space back to think about other things.
Ben:
Totally. Well, speaking of Twitter though, I hate to draw you in, but can you just-
Josh:
What's the latest? Give me the dirt.
Ben:
Can we just revisit for a moment the Hey thing from our episode last week, where we were talking about-
Josh:
Oh, yeah.
Ben:
And you've seen the-
Josh:
I saw our title today as we go out for our podcast. It's total click bait. I bet everyone will listen to it. It's great.
Ben:
So, I did not actually expect Basecamp turnaround that quickly. I didn't expect them to work over the weekend to do that.
Josh:
Yeah because you called it. You called that move, which was basically like, "Well, we're going to roll out the business version," which was part of it. That wasn't all of it.
Ben:
Right. But the other part was the free part, which I didn't ... It came out of left field for me and I thought, "That was really cool." So props to them for coming up with a clever way around that to come up with a-
Josh:
Yeah. It's a unique solution. Yeah.
Ben:
Yeah. So for anybody who wasn't paying attention, it was if you get the app and you don't have an account, they'll create a throwaway email address for you that you can try for 14 days. So you can actually download the app, you can use it, so it solves the problem that Apple had about ... It's a non-functioning about basically if you don't have an account. So, I thought that was a really clever approach to the problem, and of course, they're also doing the corporate thing, which will also help. But yeah, I thought that was cool. So props to them.
Josh:
It was cool. Did you see, what was it? Bye?
Ben:
Yeah.
Josh:
I don't remember the domain. It was one of the-
Ben:
Yeah. I can't remember either. But yeah.
Josh:
... see all these.
Ben:
You don't want to talk to anybody.
Josh:
It's true.
Ben:
That's an email service for contractors.
Josh:
Right. Yeah.
Ben:
They don't really want to talk to anybody.
Josh:
Yeah. Totally. Yeah, they should rebrand themselves for the service industry instruction.
Ben:
Exactly. They could send out the service pro.
Josh:
Yeah. Well, they could integrate with Yelp.
Ben:
Yeah.
Josh:
My favorite thing on that was the little squiggly design arrow things because Basecamp's are all handcrafted, just beautiful drawings, and then they took the arrow part of it, but then they just scribbled down the page.
Ben:
Yeah. That was beautiful.
Josh:
Obviously someone put a lot of work into that landing page, and then the sign up button was actually a donation to, I think, Black Girls Code-
Ben:
Oh, that's cool.
Josh:
... or one of those things, and I thought that was really cool. So if you've signed up for it, then yeah. The sign up is just to donate, which I think they're making a little bit of a statement there during the whole drama that was happening. There are larger issues to think about.
Ben:
Right.
Josh:
I like that they capitalized oh and that a little bit, and helped to redirect the conversation a little bit.
Ben:
Yeah. That's really cool.
Josh:
Yeah. I got to get my Bye address.
Ben:
Well, any exciting plans for your next week of vacation or are you just going to do more bumming around?
Josh:
Yeah. I think more of the same probably. We might, I don't know, maybe we'll go for a hike or something, or try to get out and do a little bit around here at least. But I'm hoping that the sun stays out, and honestly it's nice. I like a two week vacation for that reason because the first week is usually trying to learn how to exist off of the internet, and then the second week is then actual vacation because by that point, you're used to just a slower pace, and not being constantly bombarded by information from all directions.
Ben:
Yeah.
Josh:
And you start to be able to read a book again. Yeah.
Ben:
Well, cool. I guess we can wrap it.
Josh:
Are you going to wrap it this time since you did the intro or whatever? What are we-
Ben:
Well, if I do the intro, does that mean you have to wrap?
Josh:
I can wrap. So this has been FounderQuest, and you can rate us on ... What is it? Apple Podcast is what we call it.
Ben:
Yeah.
Josh:
Yeah. We would much appreciate your five star reviews and/or ratings, and I don't know what else to say.
Ben:
And do get in touch if you want to try our new product.
Josh:
The most important thing is to email Ben@Honeybadger.io to try out ... Well, I guess to gain the gold standard of Webhooks-
Ben:
Exactly.
Josh:
... for your web apps.
Ben:
Be as cool as Stripe.
Josh:
Yeah.
Ben:
Yeah.
Josh:
Cool.
Ben:
Awesome. Great job, Josh.
Josh:
That's a wrap.
