FounderQuest
FounderQuest
Should You Comply With Compliance?
Links: KolideSoc 2GDPRElasticsearchRedisSlackBitDefenderSaul GoodmanArthur AndersenHoneybadger - Write For Us
Full Transcript:
Starr: Did y'all go trick or treating?
Josh: Yeah, we did. We went to a neighborhood with some friends of ours and it was a good suburban trick or treating neighborhood. Most of the houses were all participating. The kids had a blast.
Starr: Oh, great.
Josh: We were a family of bats.
Starr: Oh, cool.
Josh: Yeah, I wasn't the Batman. I was just ...
Starr: You were just a bat.
Josh: Just a bat.
Starr: That's okay. There's nothing wrong with just a bat.
Josh: Yeah.
Starr: Yeah, we did the neighborhood thing too. This was Ida's first year of really understanding what was going on and not being just terrified of strangers. So she was just all over this. She was like, "We're going to go get more candy. Mom and dad, you stay right here. You leave me alone and let me do this myself. I'm going to go knock on their door and say trick or treat. She's not even four yet, so it was super cute.
Josh: Nice.
Starr: Yeah. I can't even imagine when she gets to be like 13, she's just going to be like, "You stand over here dad, you park a mile away from school and I'll walk."
Josh: Yeah, she's going to be choosing colleges across the country or something or ...
Starr: Yeah, she likes us nearby, but she just wanted to do it herself. She's very big on that.
Josh: It makes sense. Yeah, Tatum was doing ... she was going up to doors by herself too. I'm pretty sure I saw her hit houses multiple times. Like I should go up, come back to the street and then I think I saw her go back up at the same house.
Starr: That's so funny.
Josh: Yeah.
Starr: Yeah. I ate so much candy last night that this morning I literally feel like hung over or something. My brain isn't working, I'm just exhausted. That's how you know you're getting old, I guess.
Josh: Yeah, we did the same thing.
Starr: Yeah. Today, we're going to be discussing ... what are we going to be discussing? We're going to be compliance GDPR, SOC 2, all those big things.
Ben: Yeah. All that fun stuff.
Starr: Where should we get started on? Is anybody want to give us sort of an intro? This isn't really my forte.
Ben: In talking about compliance, we're a small company, and I think a lot of times people in our position, entrepreneurs in our position ignore the whole compliance issue because they're just too small to handle that, and like, "Oh, I don't have a compliance department because it's just me." I think we spent most of our existence in the same boat, like, we'll just ignore that and we'll just whistle and move along our way, but really came to a head with GDPR because we had customers who are international and who themselves had to deal with it. So, we had to deal with it because they had to deal with it. So I think that's the reason why we really felt like we had to get up to speed on what all this compliance stuff means and couldn't just ignore it, put our head in the sand.
Starr: What do we mean when we say compliance? What are we talking about?
Ben: Yeah, really, all the compliance regimes are about, generally speaking, like security. A good security practice is making sure that you are operating your business in a way that protects the data, which you're entrusted. GDPR was very much about personal data and making sure that companies treat that responsibly, that is not going out to everybody and their brother, that you're not doing things with it, that your customers wouldn't agree with you doing. For them, it was about, you want to be sure that you're not sharing this information willingly and unwillingly. Either through marketing partnerships or through breaches, that would be basically a breach of trust with your customer, or your employee, like they have a special case for HR data.
Ben: If you're employed by a company, they have your social security number and they might have other information about you and your address, your, maybe some health insurance information, whatever. You don't necessarily want that information going out to everybody and their brother. Basically, GDPR came about, and compliance, more generally, is all about doing what you're supposed to do, being ethical with the data that you have in your possession.
Starr: A lot of the companies are sort of ... If you're a company in the European Union or you're selling to people in the EU, you are sort of legally required to follow a GDPR, this sort of list of rules. Right?
Ben: Right. If you're a company in the EU and you have to comply with this regulation, you also need to make sure that your suppliers comply with this regulation. That's where it involves us because we're not in the EU, but we have customers there.
Starr: Yeah. The other sort of compliance regimes, what is it? SOC 2. I don't know, there's, I think HIPAA is sort of in that same boat. All these are, either there's a law somewhere that says that certain people have to follow these or big companies have in their policy that they only do business with people who follow these. They're like viral, right? A lot of these, because if a big company only does business with a company that follows, say SOC 2, that means like they have to get certifications from all the vendors they use. Then, those vendors have to get certifications for all the vendors they use, saying that they are compliant to some degree or whatever. Is that right?
Ben: Yeah. This avoids the scenario where you can be ignorant of what's happening with the data once it leaves your control. If I'm processing data for my customers and I hand that data off to an email vendor or whatever, I can't just say, "Oh well, I don't know what they're doing with it, but I'm fine." You have to be able to say, "Oh no, my email vendor is also behaving responsibly with this data that I'm giving them." Yeah.
Josh: Nice.
Ben: Yeah, so that's how we got introduced to it.
Josh: You're saying as a developer then, I can't use a public S3 bucket as my database? Would that be a bad idea?
Ben: I'd recommend against doing that.
Josh: Okay.
Starr: Well, you can, but you have to disclose it.
Josh: Oh, all right. Okay. That's where the compliance comes in.
Ben: Yeah, and more recently, I think they've done a pretty good job of locking down the S3 thing. AWS has added more controls around making it harder to actually accidentally expose your S3 Bucket, but lately in the past few months, the new thing has been open Elasticsearch instances where they're just hanging out on the internet, no restrictions, no password required. Just hop on in there and query all the data you want.
Starr: It's interesting.
Ben: There've been some relatively big breaches on that.
Starr: Oh really?
Josh: Is that from an older version or is it newer versions? Really?
Ben: Yeah. It's just because people stand up in such instances and ...
Josh: You'd think they would have learned and learned something from Redis. Way back when Redis had the same problem, basically just like unprotected Redis instances.
Ben: Yup. Yeah. That's why I love how Amazon does the VPC thing. And they have this option for Elasticsearch, specifically their service that allows you to restrict access to it, to your VPC. It's a private network. No one's getting into there. There is no public IP address that is listening to you. That makes it a lot easier to handle these kinds of security issues. After GDPR, we dealt with that and it wasn't too painful, actually. I think for a long time. We were like, "Oh, it's going to be so horrible."
Starr: That was mostly me saying that I think.
Ben: Well, it really helped to get some good third party help. We had some consultants help us. We had a good legal team help us. There's a company here in Seattle that specializes in compliance issues and they gave us some great advice and walked us through the process. Basically, what it came down to is like, we were already doing good practices for security, but we had to formalize it a bit. We had to make sure that our terms of service had the right verbiage in there and that we were disclosing who our vendors were. Of course, we had to go through that whole chain of trust thing too, where you had to go to our vendors and get their GDPR attestations. We had to come up with an information security policy, which that legal team helped us write, which gives us basically a framework for how we run things.
Ben: Things like, well, we have our hard drives encrypted or we have SSH access to our servers rather than ... it's wide open, things like that. But that information security policy like documents, then it says, yes, these are the things that we do and we certify that basically.
Starr: It sounds like there's sort of two aspects to this, right? There was the technical requirements and then there are these sort of a documentation and paperwork requirements. Is that fair?
Ben: Yeah.
Starr: I know we're already doing a lot of those sort of technical stuff, but if you were doing a new app, what would be the main technical requirements that you be worried about or not worried about? You would be sort of paying attention to when it comes to making sure that your app is GDPR compliant?
Ben: Yeah. There's the basic security stuff like not having that public S3 Bucket or not having that public Elasticsearch server. Making sure your data is under control and making sure there's access controls around that, like SSH keys and things like that. Not everyone's using the same root login, for example. In the, in the specific case of GDPR, there's also data retention rules that you want to pay attention to. You need to specify like how long we hang onto data and what data we hang onto. If you're building an app and you know you're going to be tracking social security numbers for example, well, you know there's going to be some extra scrutiny around that, like I need to encrypt that data somehow as opposed to just storing it plain text.
Ben: Whereas, I could just order name, maybe plain text. And then also like deleted data. How long do we hang onto that? And then, in the case of GDPR, we can have request for data, right? Someone can say, give me all the data that you have on me. So you have to be able to track that data that you have. Basically, when you're building your app, you need to say, well, what data am I taking in? What types of data is it? And then how do I know what I have and for how long I have it?
Starr: One interesting thing about GDPR, it also has this sort of aspect of consent to it where you have to get people's consent in order to track certain data about them. That poses front end challenges too because you have to figure out a way to get people to opt in. How do we go about doing that? I think I remember you doing a lot of stuff on that, Josh.
Josh: Yeah. Do Not Track was something, I guess, I don't know if it plays into the like GDPR specifically, but it's a internet standard that basically it's a browser feature that sets a header if you enable this, like it says. It's basically like if you go on your browser settings and say, "I don't want people to track me," what that does is it sends a header to each website that you visit. If that website happens to comply with Do Not Track, then they will disable any Google analytics or tracking code that they use. At least they're supposed to.
Starr: Okay. But with the GDPR, how do we inform people of this? Did we just like change our terms of service or?
Ben: We did change our terms of service to include information about more details about what we collected. Fortunately, we're not like a marketing company. We don't track a bunch of personal info and then send it out to a bunch of people, but we basically had to write in a text that we, "Yes, we do not do that sort of thing." Then, we're not collecting, at least as a first party, we're not collecting from our customers very sensitive data, like HR data or social security numbers and stuff like that. So we made that clear. We didn't really have a lot to do in that regard because we're not redistributing data for marketing purposes or really much at all, besides our limited list of vendors that handle things like email and data storage, things like that.
Starr: Yeah.
Josh: Yeah, and I think we've been trying to go the other direction of intentionally not using services that would require us to get extra permission or extra do extra disclosure. Even if you have the option when you're building an app in the first place, I think it's better to opt for using more ... I guess in the way that you store, if you're handling user data, just like if you can build your app to just handle as little user data as possible, opt for the minimum amount that you need, that seems to be like a good way to set yourself up for being more compliant, maybe.
Starr: Yeah, for sure. Yeah. It seems like this really kind of encourages vendor lock in a bit because once you get permission to send data to one vendor, it's like, Oh, I would change, but now we've got to get everybody to opt in to this other vendor.
Ben: Yeah. There are two ways that I've seen people handling that because you do, as part of the GDPR, you can provide this data processing addendum to your terms of service, a DPA, that specifies exactly what kind of data you handle and what do you do with it and who do you send it to. In there, we list out people that we sent it to like Intercom, AWS, for example, Google analytics. Every time you add a vendor, you've got to go and update that agreement, right? And you have people, this is a signed agreement and so you've got, however many customers who have signed it. Now you have to go back to those customers and say, "Oh, here's a new vendor that we've added, so we're sending data to.
Ben: I've seen two ways that people have handled that. Our vendors have handled that sort of thing for us. They either will send an updated list like, "Oh, we are amending the addendum and here's our new list of vendors to whom we're sending data." Or, I think MailChimp does it this way. They send out an email saying, "We've updated our list, please come back to our website to check out the new list." Like we used to do in the olden days with our terms of service have been updated, and a lot of companies still do that, and you never click on the link. But yeah, you do have to have some way of tracking who has signed the agreement so that you can then send them the updates when the list of vendors changes. Yeah, it's kind of annoying, but ...
Starr: Yeah.
Josh: Weren't the terms of service, emails a compliant, due to some regulation to ... I just remember I didn't used to get any of them, and then all of a sudden, I started getting everyone I ever used in the world started sending me, like "we updated our terms of service." I assumed it must have been some legislation that was passed.
Ben: Yeah, I vaguely remember that, but I can't remember details, but I had that same experience.
Josh: I want to say it was part of GDPR, but it might have been further back.
Ben: Yeah. That's been put to bed pretty much. We're just doing the usual stuff that we have to do. We expire data as we agreed to, and we keep that vendor list updated and stuff like that. But what's come up a little more recently for us is SOC 2. We've had more and more customers contacting us asking for our SOC 2 report and I really didn't know what that was about, so I had to do a lot of research into what that means. It's been an interesting experience. I think we're about to embark on an endeavor to come into compliance with that as well.
Starr: What does it mean? What is a SOC 2 report?
Ben: A SOC 2 report is basically an attestation that you follow certain best practices in handling ... there's five different areas that you can cover. There's security, availability, privacy, confidentiality and processing integrity. Each of these five areas have criteria that say, are you following best practices in this area? For example, like in a security, there might be a requirement for you need to know when there are attacks on your servers, you need intrusion detection. You need to know if any files have been changed, or you might require your employees to use two factor authentication whenever handling customer data. Is like a laundry list of things that you need to be pay attention to you in each of these areas.
Ben: A SOC 2 report is a report that says, "Yep, we're doing X, Y, and Z to cover these particular concerns." And then, an external auditor comes in and looks at the systems that you've implemented to counteract these risks and says, "Yep this company is doing those things." That's what that report is. There's actually two types. There's a type one report and a type two report. A type one is just like the initial. The accountant comes in or the auditing firm comes in and says, "Yeah, these are the things that they say they're doing and I can see they're doing them and we feel that these things that they're doing are sufficient to control the risks." Then, a type two report is actually over time.
Ben: They'll come back in a year or six months or whatever and say, "Having evaluated this company and these controls, these controls are in place and they've been monitoring them for this amount of time and we feel that this monitoring assures that they are following what they said they were going to follow." It's like, there's your attestation. It's an involved process, not just because of the things you have to have in place, but also because then you have to monitor and show that you're monitoring, and then have this audit where you have these third parties coming in and checking your work basically.
Josh: Right. If I just run my app in, say a data center that is SOC 2 compliant ... They have a certification, I can basically just ... that means I'm SOC two compliant. Right? I can just ...
Ben: Maybe, partially. Yeah, I think some people might say, "Oh look, I'm SOC 2 compliant. because I use Google Cloud. And they are so I am."
Josh: I can just put that on my security page.
Ben: Yeah.
Starr: It sounds like y'all are bitter about something.
Ben: Yeah. Let's put that on our security page. Let's say that we're compliant because AWS is compliant. Yes. You can say we do use AWS and yes, they are obviously SOC 2 compliant. Our data center is covered. That part of the compliance, boom, you're done. Right? You could use AWS in a very insecure way, right? You could have that Elasticsearch instance running in AWS that's wide open to the public. And so, that's obviously insecure. Yeah, it's not just add water kind of thing.
Josh: Well, I know, but we can say we are compliant asterisk right there. That'll solve the problem, right?
Ben: Boom, problem solved. Yeah, you saved me months of work. Thanks. I'll go add that to our website right now. We are compliant, asterisk.
Josh: Nice. It's what I do.
Josh: Yeah. We've learned in researching this that some people do ... that is like their version of compliance. It's interesting because the whole compliance thing seems to be very hand-wavy to like no one really knows exactly what it is, especially at the smaller level. Maybe the large companies who have to be like ... they have government oversight ensuring that they are compliant and they have lots and lots of money to pay compliance departments and outside auditors to come in and make sure that they're checking all these boxes for everyone else. You might check some of the boxes and then just hope for the best.
Starr: Wait, so are we doing things in the hand-wavy way or are we doing things in the correct ethical way?
Josh: I think we're trying to do things in the ethical way, but we're realizing why everyone else seems to not.
Ben: Yeah. What we've done so far, we have had requests for a SOC 2 report, and we don't have one because we haven't gone through that full process yet. But the way that I've responded to that kind of request has been to say, we're following the principles, security best practices and these are the things that we do and here's our information security policy and here's the things that we've implemented. I think that's the most upfront and straightforward way that we can be, to say, "No, we don't have that report, but these are the things that we're doing that goes along with the desire that you would have to have someone had this report."
Ben: I think that's fair. I think it's fair to say, yeah, we follow the principles outlined in such and such security framework, but we don't have an auditor to check that off yet.
Starr: That's reasonable.
Ben: That's the approach that we take so far.
Starr: That's not like thing, we're SOC 2 compliant asterisk though.
Josh: Yeah, right. Yeah. The difference is that you're not advertising it as a core part of your benefits, yeah, your platform.
Starr: Yeah. A lot of the marketers in startup land, feel like they can say anything and it doesn't matter.
Ben: Yeah. I think you got to be careful when it comes to this kind of stuff because that can get you in some pretty hot water. There's also like there's third path, which we haven't talked about yet, which is, and we've had this happen to us at Honeybadger, where one of our customers comes to us, and instead of asking for a SOC 2 report or instead of just like, "Oh, tell us what you do," they come at us with a third party vendor and they have this like security questionnaire. You might think, oh, a questionnaire, no big deal. But it's like 40 pages of questions, and each of those pages has like 40 questions on them. So, you're talking about like days worth of work to fill this out. But basically, it's ...
Starr: For like a $40 a month account.
Ben: Exactly. Basically, these questionnaires are like, they have all of these same security and privacy criteria as these compliance frameworks have, and then they just ask you specifically, yes, no, are you doing this? And if not, why not? Right? There's like a gazillion questions to go through. That's one option. You could also say, "Well, we're not compliant, but we'll fill out this survey for you or this questionnaire." That's one of the benefits I think from going through the whole compliance work is that you can say, oh, here's our report. Yeah, and you just save yourself three days of work of filling out this questionnaire, right? It's this commonly agreed to like, oh, if you have a support then I know you're doing all these things that I care about from a security perspective.
Josh: Makes sense.
Starr: I really wonder what would happen if you took that questionnaire and just filled it out in the most negative way possible. It's like, no, we don't do that security thing. Yes, we give your data to everybody. We don't have passwords, and then just see what happens. Do they just want to report somewhere?
Ben: That is the interesting part about the whole compliance ...
Josh: Does anyone read it is what you're asking?
Ben: Yeah. It really is about, here are these risks that we care about like data loss or data breach or whatever. And then what are the controls that you have in place to handle those things. You can say, "We don't do anything. We have all of our stuff out there, it's wide open, blah, blah, blah." As long as you sign your name to what you actually do, you're done. Right now, a customer might say, well that's not good enough for me. I'm going to go someplace else. But yeah, you can totally answer those questionnaires with like all "No" if that's the case for you.
Starr: Well, it might be worth a shot. I'm just saying if you're going to fill it out anyway.
Josh: Yeah, it's cheaper because you can easily outsource answering those questions because ...
Starr: Yeah.
Ben: We did have one example of a customer who came to us and wanted a custom agreement, and they're paying us enough money to make us consider that. They came to us with this list of requirements and basically, it was the SOC 2 kind of stuff. And I said, "Okay, well, so we don't do all the things yet that you might ask for in these five different areas of SOC 2, and what we're working on that." So, I couldn't agree to all the things they had listed. They had this appendix to the agreement, is multiple pages long, and here's all the things that you need to do. And I couldn't say yes to some of those things right off the bat.
Ben: Some things take some time to actually implement. So I said, well, we don't have those things in place. This is what we do have in place. I said, so we can't agree to all these things in this appendix. So they came back and said, "Oh, all right, well, strike that and we'll come up with other ways to control for those risks." On their end, they had to make some control statements on their own saying, "Well, we have this vendor who doesn't certify that they do X, Y, and Z, but we have these other controls in place to handle that, to mitigate that risk.
Starr: That's really interesting because a lot of times I always assumed that things are non-negotiable, and it's just like, well, that's it. Sorry, see you later. The world usually isn't like that, especially if you're to the level where people are emailing you forms to fill out personally, and they're going to have lawyers look over them like. There's often room for a little back and forth.
Ben: Sure.
Josh: Yeah, I didn't think of that either. It sounds like this is a lot of this is really just about shifting risk around.
Ben: It really is. Yeah.
Josh: By default, you want to give as much risk as you can to your vendors. If maybe some of them push back, they catch the risk and toss it back over the wall in some cases if they're smart.
Ben: Yeah.
Josh: Yeah.
Ben: But it's been good. It's been a good experience for us to start to go through this process. I've been researching this for a while now and I've started doing some things. For example, and part of the compliance stuff is that you have to monitor. It's fine for you to say, "Yes, we're secure," but okay, how can you assure that you're secure? One of the ways that is baked into these frameworks is monitoring. They might say, "Okay, you need to encrypt your data." Okay, so that's a requirement. Now, you say that you're encrypting your data. How do we know you're encrypting your data? What are the monitoring tools that you have in place that say you're encrypting your data? I started looking at those monitoring tools and we started using them some in the past few months.
Ben: One for example that I really think is really cool is Kolide. K-O-L-I-D-E.
Starr: I like it too.
Ben: Yeah, it's really slick because it's built into Slack. What you do is you sign up with Kolide and you install this agent on your Mac or on the Linux box, your Windows box, and it reports back to them a variety of security checks. One of them being, is your hard drive encrypted? Because they can look at the OS level settings and they can see where that's the case. So, it sends that back to Kolide, and if not, if that's a problem in your particular environment with one of your machines, it then sends a message to Slack saying, "Oh, Ben's computer doesn't have this hard drive encryption turned on. You need to fix that." That's one of the tools that we're using to help with this monitoring aspect.
Ben: The thing I love about that is it's actually useful. Sometimes you can say, "Oh, this compliance stuff is just a bunch of lawyers and account and stuff. But that's actually helpful, to say, "Oh, I didn't know I had one of my teammates using an unencrypted hard drive. We should fix that." I think that's a good thing.
Josh: A lot of the checks that it does are pretty granular. The hard drive is obviously like a big one. But there's a lot of smaller OS settings and best practices related to your specific operating system that you might not know all of them and they will tell you.
Ben: Yeah. Another thing that we started using recently, it was a BitDefender, it's antivirus. I've always been of the opinion, like I run a Mac. Give me a break. I don't run into viruses on my Mac, but it's one of these things like you have to have if you want to check that box on the compliance things. So, we started using that. That's really cool because again, it has the same ... it's monitoring a whole team's worth of stuff, and it's like, "Oh, Josh's virus definitions are out of date." It's like, oh, Josh, can you go update that? It's just a confidence builder.
Josh: Yeah, and before you had to email me to remind me to update my virus definitions.
Ben: Well, more likely, like I didn't even think about it and so nothing happened.
Josh: Yeah.
Ben: Yeah, so having those tools in place, that makes it a lot easier. I appreciate that.
Josh: Pretty soon we'll be having weekly meetings with printouts of our a BitDefender and Kolide results for the week. We can get together and share results.
Starr: Can we have some TPS reports?
Josh: Ooh, yeah. To cut down on the meetings, we can probably like create some forms to fill out just so we can fill out the forms and pass them into to Ben, central management.
Starr: There we go. We'll get Ben one of those like giant rubber stamps that says like "denied" on it, so send it back.
Ben: Yeah.
Starr: Well, that was a whirlwind tour. Is there anything else you'd like to add about compliance before we head out into the sunset?
Ben: Well, one thing we haven't talked about yet is cost and I'm sure a lot of people would be interested in hearing about that.
Starr: Yeah, let's do that.
Ben: It can be costly. Like our GDPR compliance cost us a couple thousand dollars. Legal was most of that cost. SOC 2 is going to be at least as much, probably not as much in legal but in time, because there are a lot of systems you have to put in place. All that monitoring, it takes time to set that up and to keep on top of it, like you have to ... For a SOC 2 type two report, you have to be able to show evidence that hey, yes, we've been monitoring and these are the systems we have in place to show that we're monitoring.
Josh: Yeah. Even with GDPR too, like time was a big factor. I remember you spent a lot of time on GDPR. So, if we factored that in, it was probably a lot more than that even.
Ben: Yeah. Now, the good news for small startups like us is that SOC 2 is only will only take you a few months versus a year or more with a larger organization. But it's still like a couple of months really. Then there's the whole question of the actual audit. Because SOC 2 is, is done ... it's a financial based compliance regime so it's done by CPA firms, accounting firms. The audits can actually only be performed by licensed CPAs. You're paying these accounting firms to do that audit for you. Tens of thousands of dollars is not an unreasonable amount based on my research to expect to pay for one of these audits.
Starr: Yeah. Every year.
Ben: Yeah. That's kind of hard to swallow for a small startup.
Josh: Every year is a big one.
Ben: Yeah. I'm still researching that and hoping maybe I'll find the fly by night and bargain basement CPA that will do it for cheaper. But yeah, I'll keep you posted on that.
Josh: Do we want a bargain basement CPA though? I don't know. It's like we need the Saul Goodman of CPAs.
Starr: I hear a lot of people from Arthur Andersen are still looking for work.
Ben: Finally, I think one thing to mention is that there are a lot of consultants out there who are happy to help you for really obscene amounts of money. I've talked with a number of them and I've found a local person actually here in Seattle who is not going to charge us an obscene amount of money, but will help us get started and do a gap analysis to find out, what are we doing today versus what we need to get to before we could do an audit. You had to, maybe look under some rocks to find those people that can help you for reasonable amounts of money, but they're out there.
Josh: Ben, you just missed the golden our opportunity to bootstrap your SOC 2 consulting business.
Ben: Yeah. Ask me again in a year, maybe-
Josh: There are consultants who will charge obscene amounts of money. By the way, I'm one of them.
Starr: Ben's consultants only charge a slightly obscene amount of money.
Josh: Right.
Ben: It's risqué.
Josh: Yeah.
Ben: That's it. Well, you have to check back with me in a few months to see how we're doing, but ...
Starr: We can do a followup episode, that'll be great. All your hair will be gray. You'll just have a 10,000 foot stare in your eyes.
Ben: My pockets will be empty.
Josh: Yeah.
Starr: All right. Well, before we get going, I wanted to mention that we are still looking for writers for Honeybadger blog. We've had a good response to our initial call, but we're like continually bringing in writers. So, go check out our posting on that at honeybadger.io/blog. I don't remember the URL. Just go to the blog and there's a link in the header. Yeah, I don't know why I was tell you the URL.
Ben: That's the first test. Can you actually find our post?
Starr: Yeah, that's a good first test. There's instruction there for how to email me, and I'm super nice. Yeah, and if you liked this podcast, go to wherever you review things and review it please. And thanks. Oh man, I'm only like 10 credit hours away from my certificate and professional broadcasting.
Ben: Another hour down, boom.
Starr: All right. There we go. Well, I'll see you all next week, guys.
