Garrett Dimon: [00:02] We're here with Ben Curtis of Honeybadger. How are you doing today, Ben?

Ben Curtis: [00:08] I'm good.

Garrett: [00:09] We'll just dive right into this. Can you give a quick rundown of your career, your journey that led you to Honeybadger?

Ben: [00:17] I've been interested in technology, and development, and entrepreneurism since I was a kid. I started business selling stuff in middle school and started writing code when I was eight or something, I don't know.

[00:36] Going through college, I had side projects. I had my own consulting business. I just love business and tech. When I left college, the first thing I did was go to work for a startup. I've been working for a number of startups ever since then, I don't know, six or seven different places. Back in 2007, the startup I was working for folded, and everyone got laid off.

[01:02] I figured that's as good a time as any to strike out on my own, so I started freelancing then and launched a product about six months later. Then I launched RailsKits a year after that. Working at a startup for a while and then started Honeybadger. It's been a whole lot of side projects, and startups, and just a lot of fun.

Garrett: [01:26] RailsKits is something that's interesting to me, not just because Sifter used it for the billing code, but just in terms of how that fit into your path that led you to Honeybadger. For those that don't know, RailsKits was basically batches of very focused code for specific purposes. You could basically buy the library, so kind of a quick-start kit for certain things.

[01:52] Like I said, I used the billing one, heavily influenced Sifter. You start out with a product and were selling that. That wasn't your only thing. From a business standpoint, how did that translate? Was there dots that got connected, or how did it unfold?

Ben: [02:13] What was interesting about that is that RailsKits came along in 2008 or so. I'd been in the Ruby and Rails community since about 2005. That made a big difference in the success of that particular business.

[02:29] Being a part of the community, I had built the plugin directory back when Rails first got plugins, and before using Gems was a thing for that. There was a lot of awareness of who I was.

[02:42] I was blogging about Rails all the time. The community was smaller then, so that led to an in, I guess, there. I was a known quantity already. People were like, "Oh, OK, I can probably trust his stuff."

[02:55] The thing that was interesting about that is Honeybadger also we focused exclusively on the Rails and Ruby community when we first launched. A lot of those connections were still there. A lot of people already knew who I was.

[03:08] There was already that trust. That made a big difference in having paying customers from day one, for example, and also knowing what kind of customer I wanted to have and who I was targeting the product.

Garrett: [03:23] It's a long history that built up and set you up, at least, for a little bit of a jumpstart. I'm being a little presumptuous here, but something tells me that your reputation wasn't enough to launch the business to an immediate, comfortable salary full-time paying gig. Is that the case?

Ben: [03:47] [laughs] That would have been nice. No, that wasn't the case. In fact, when we first launched Honeybadger, I wasn't planning on it being a full-time thing. It was a side project. I was perfectly content with the idea of keeping my day job. I was a VP of Engineering at a startup, and running Honeybadger at the same time.

[04:07] I figured, two income streams are better than one, but it just didn't work out that way. Honeybadger was successful enough and required enough of my time that I couldn't keep my day job. Unfortunately, it was one of the situations where I couldn't just walk into the full salary with Honeybadger. There was a transition time.

[04:27] I went back. I had been doing freelancing and consulting before the startup I was working at, so I went back to doing that for about a year, year and a half when there was that gap between leaving my full-time salary as a VP of Engineering and then when Honeybadger could give me a full-time salary.

Garrett: [04:45] The reason I ask is so many people seem to believe that you were only successful because you already had a reputation. I hear that story a lot amongst a lot of people explaining away people's success. The thing is, yes, it generally does help you get a quicker jumpstart, but then it doesn't take you very far, right?

Ben: [05:09] Yeah.

Garrett: [05:09] It's like a spark, but it's not going to carry you enough to be a huge, sustainable business. A lot of people are almost fearful if they don't have that reputation, and they don't have that to help them jumpstart because they think that it counts for more than it does.

[05:29] To me, so much of it is you talk to the people who have had a reputation or had some exposure long before they launched and they launch. It was still a hard, grueling slog to grow the business to a point where it was actually a healthy, sustainable business.

[05:46] I have yet to find a point where that wasn't the case. It's one of those things that I feel it's good for people to remember and realize, "It's not that big of a deal. It would be a bonus, but it's not going to make or break my business."

Ben: [05:58] I definitely agree with that. It's definitely a foot in the door. It's definitely a good start, and I totally recommend it to anyone who asks me, "How should I get started?" A good way to get started is to be involved in a community.

[06:12] At the same time, you can do it without that. I have a friend who started a business selling to salons, that kind of business. He just went literally door-to-door selling it and bootstrapped it that way. He didn't have any in to the community. He wasn't a hairstylist or anything, but that's the target he wanted and that's what he did. He just worked it. He's doing well with that.

[06:38] Like you said, it's a great way to get a good start, but it's not critical. It's definitely not the end-all be-all. It's not going to get you overnight success, that's for sure.

Garrett: [06:51] How long have you been working on Honeybadger? What was the initial impetus that made you decide "I've got to do this," and you couldn't brush it out of your mind anymore?

Ben: [07:02] We started about five and a half years ago, so that's how long I've been running it. Starr and I were working for the same startup. We were building a Rails app. At the time there were two exception monitoring services. One was Airbrake. That's the one that we were using.

[07:22] What made us start Honeybadger was Airbrake. We had a terrible customer experience with them one day. I just felt, as a developer and as a human being, I deserved better service than I was getting from them. I turned to Starr and I'm like, "You know what? We have to build our own, and we have to do better than that."

[07:43] It turned out that a lot of people were having the same experience because as soon as we launched, people were like, "Thank goodness, now there's an alternative." This was back before there was as much competition in this space as there is today. That's what got it started.

[07:57] It was a frustration where I've had a bad experience with this product. I know I can build that same kind of product, and I can deliver an awesome experience to go along with it. That was really our impetus and still is our mission. Let's provide an awesome experience for a developer who is using our product.

[08:16] It's already a bad day when you're having a bunch of errors in your application. You don't need to have that compounded by having a crappy product when you're trying to deal with those errors or crappy service that goes along with that product. We felt like, "You know what? We deserve better, and all developers deserve better. We can deliver that better experience," so that's what we did.

Garrett: [08:36] You mentioned that now the market is much more competitive. I think for a lot of people you can look at that one of two ways. One is that means there's plenty of opportunity. Two, it means I'm going to struggle to stand out.

[08:52] On top of being competitive, it's a space with relatively low switching costs to move between providers. Beyond loyalty, there's not a lot to keep somebody from jumping ship to the next one that comes along as soon as something else pops up. Have you found that to be difficult? Are there tactics that y'all employed to help mitigate that? How have y'all worked within that environment?

Ben: [09:19] There definitely are challenges to that. Like you say, it's easy to switch from one to another, and we can't hang onto any particular piece of data to come out to try and keep people in the system.

[09:34] I think what our strategy has been...You mentioned loyalty. People might say, "Oh, that's froufrou," or whatever, but if you provide an awesome experience to people, both in the product you're delivering and in the service you're giving them, that does create loyalty.

[09:51] We connect human to human. It's not just business. It's about people. We believe strongly in that. We do have a lot of people who have been around, basically, as long as the product has been around. They stick because they like us. They like the product. Why leave?

[10:09] A lot of people vote with their wallet and they tell us, "I like you and I'm happy to support you." As long as they don't violate that trust or break that promise, I think we'll keep doing fine.

Garrett: [10:24] It's something that the answer is so simple, people don't want to believe it. If you take care of your customers and you provide good customer service, it will carry you a lot farther than you think.

[10:37] Now, that's a lot easier said than done. Providing great service takes a lot of effort and at times takes an emotional toll and it can be exhausting. The thing is, because it's hard and exhausting, so many people don't bother to do it.

[10:53] I feel more and more companies are coming around and doing it now, but I still find plenty that just don't care. It's obvious when a company cares and when they don't care. How long did it take you to transition fully to Honeybadger in terms of...?

[11:13] Well, I guess you had to transition instantly, it sounds like. How long did it take to transition over to where you're working on it full-time? Then how much longer after that to where you felt you were fairly compensated for a full-time effort?

Ben: [11:28] We spent about three months, I guess, in an alpha, somewhat beta stage. We launched in the fall of 2012. By the next summer, we had basically gotten to the point where we couldn't keep a day job anymore, had to focus on Honeybadger, not 100 percent full-time, but quite a bit of the time because it's an operationally heavy business.

[12:00] We get a bunch of load coming in. If things break, we can't go down, right? Because people will depend on us when their sites go down. We had to do a lot of work in the early days to keep things going.

[12:13] We onboard a new customer, and all of a sudden, we have to deal with a bunch more traffic and that sort of thing. That was summer, 2013. 2014, we actually set up payroll. That was in January 1. We'd have, "Hey, now we actually have a salary, and I get a paycheck."

[12:31] Then, I guess, it was probably another year. Somewhere in that year, we got to the point where we had market salaries. Then, it was January 1, 2015, we started actually buying our own health insurance with the company.

[12:45] That was awesome. Somewhere, I guess, around a year, a year and a half is about how long it took to go from zero to getting, "I'm being paid fairly for the work that I'm doing here.

Garrett: [13:00] I don't know how many other founders you've talked to about that. That's a pretty quick ramp up from zero to a market salary.

Ben: [13:11] We did pretty well, and we had three co-founders. All three of us...

Garrett: [13:15] had to get paid, which is even better because if that means all three people are getting paid, then that's definitely a nice ramp up. I can't even remember these days. I want to say, it took me about three-ish years with Sifter, three or four years to get to a full-time salary. I'm definitely envious of a year and a half.

[13:33] [laughter]

Ben: [13:37] I read that generally, typically, it's somewhere in that two to three-year time frame that you should not expect to be living off that income.

Garrett: [13:45] If you beat it, great, but it's best to not count on it and to plan for the long run and cut your living expenses, whatever it is, to help you extend that. Let's talk about support a little bit. How is support for you all?

[14:04] You've got, theoretically, a moderately, technically savvy audience. In some cases, that can mean high expectations, in other cases, it can mean complex questions, not simply, "Hey, help me reset my password," but really, really complex things.

[14:22] How does that play out? Do you end up spending what feels like more time and support to help troubleshoot some more complex issues? Tell us a little about that.

Ben: [14:35] It's been really interesting. Like you said, we have a customer audience who are developers. They know their stuff. They know what they're doing as well as we do, many times. Sometimes better. Sometimes, when we get bug reports, we also get the solutions that come with them, "Hey, I saw this problem on your site. By the way, here's how you fix it."

[14:54] That's pretty awesome. We have actually awesome customers. Since we have developers as our customers, they understand what we're coming from and so they get it. They're like, "Oh, yeah, I know. You might be having a problem with this or this other thing."

[15:06] On the one hand, there's sympathy and empathy. On the other hand, they are very demanding. Developers, in general, like things to work. I guess it's because we're so frustrated about how many things don't work. They're getting kind of demanding.

[15:20] I'm that way so I understand that. When we get a problem, it's usually not, like you said, the password reset, it's usually, "Hey, I sent this data in and it's not showing up where it should. Why is that?"

[15:33] That results in me going in, diving in logs, and looking at databases, checking, "Goodness, is everything broken? Are things still working?" A bug report can involve a 30-minute or a 3-hour research day for trying to figure out what's going on, but our customers are awesome. They're always understanding and we love the opportunities to be able to just deliver something awesome and someone's like, "Hey..."

[16:00] A few weeks ago, we had a customer who, they didn't see some data and one of our export functions that they wanted to see. At first, I was like, "I think you might be missing it," but then I went back and double-checked and realized, "Oops, we're not sending that."

[16:13] I just wrote some code to send that data out. Pushed it out and deployed it that same day and got back to that customer, "Sorry, here's the data you wanted." They were like, "That's so awesome." That's the way we love it.

Garrett: [16:27] That was always one of my favorite feelings, is when there's something that you can turn around quickly and help somebody get their job done, whatever it is. It definitely feels like a huge win, especially in days where, you've got those bad days. You're struggling through and then something like that comes along. It's just a huge, huge sigh of relief to be able to help somebody.

[16:47] I don't want to go too deep but with three founders, talk a little bit about has that been a pretty natural division of responsibility based on skill sets, or is there some overlap?

[17:01] I know as a solo founder, I always dreamed of the idea of having founders where I could go on vacation and not have to worry about it. How has that been for y'all? Or do y'all each have your own area? If one of y'all goes away and something goes wrong in that area, it's going to be a tough day?

Ben: [17:17] A little bit of everything. We do have some overlap amongst us because all three of us are Ruby developers. All three of us will get in there, we'll work on a Rails app. We'll work on back-end code or whatever.

[17:30] Starr does more front-end stuff. He has more talent there than I do. I typically leave that kind of stuff to him or Josh. They're both pretty good at that and I'm not so much. I'm the guy that's responsible for the all the ops stuff. As far as vacations goes, I'm probably the one that gets the least amount of vacation time.

[17:47] Over the five years, we've automated a lot of things. Now, even I can go on vacation and not have to worry too much. We tend to let go whenever we find something that interests us. Mike Starr is getting interested in the ops stuff more right now.

[18:04] He's researching that and getting up to speed on doing more of that. He'll ask us, "What's our process for developing new features and whatever." I'm like, "Whatever we find interesting, that's what we'll work on then."

[18:17] There's no, "I own this and you can't do that." There's no, "I'm never going to touch that." It's pretty much, we're all in anywhere in the business and just whatever strikes our fancy.

Garrett: [18:29] In a lot of cases, that's probably fairly unique because most founders tend to complement each other. You don't necessarily have the benefit of that kind of overlap and coverage. That's another thing I'm very envious of there.

Ben: [18:43] It's been good.

Garrett: [18:47] You mentioned automation. That's something that I did a little bit of in Sifter, but after going through the process of selling, I realized, I didn't do anywhere near enough. I could've gone so much farther and done so much more, and it would've made life so much better.

[19:01] How have y'all embraced automation? What kind of things have y'all found to be really helpful? And how has that changed the day-to-day work?

Ben: [19:12] Early on in the business, when we were doing a lot of scaling issues, life was not good for me. I was not in a happy place a lot of the time because my hair was on fire, and I was just dealing with stuff. I felt like I could never get above water, my head above water.

[19:28] I got some great advice from someone, talking about dealing with problems on what felt to me like a perpetual basis.

[19:37] He said, "Deal with the fire right now, but then automate it so you never have to deal with that fire again." I took that to heart. Every time I was working on something that was broken, or I had to get in there and, "Only Ben can fix it because only he knows what's going on in there."

[19:54] Then, I documented what I did and then I wrote code to do that for me, or something. I figured out a way to automate that or just not have to deal with that problem again. Over a period of time of doing that repeatedly, now we've gotten to a place where things are pretty smooth.

[20:14] Going down to the nuts and bolts, we have auto-scaling groups that automatically spend up workers, based on the queue latency. That's a simple thing to say. It's a complicated thing to implement. [laughs] We didn't do that from day one.

[20:28] We purposefully set one, day one, "This is a side project. We're going to just do it as we need to do it. We're not going to spend six months architecting the most awesome thing and then not have any customers."

[20:39] That, in some ways, put us behind the eight ball because the customers showed up, and then we didn't have all of that scaling stuff. We had to do it while we're going down the road.

[20:51] Looking back, I think that was still a great approach. It caused us some anxiety and stress at times, but having gone through that, we didn't do anything before we needed to do it. Now, we've gotten a lot of work, and it just runs smoothly. It's awesome.

Garrett: [21:07] Probably one of the most difficult things to recognize when you're in the thick of it is when to automate and when not to, because there's this fear of, "Is this going to be premature? Am I jumping the gun, wasting time automating this when I should be doing something else and I've got 10 other tasks I could be doing? How do I know this is the right task?"

[21:25] What you said, which was, when there's a fire, put it out. Then make sure that fire never happens again.

[21:33] Now, that's probably not the only rule of thumb, but that seems like a good rule of thumb to guide to that because so often, you finally get your head up after putting out a fire, and the next thought isn't, "How can I work on this some more?" It's, "What else do I need to get to?"

[21:49] It's hard because you're so busy looking at everything else on the horizon to stop and say, "I need to go ahead and fix this so it doesn't happen again." That's a good indicator to know when it's worth fixing something and taking the time to just stay on it until it's done and then move on and not have to worry about it.

Ben: [22:09] You phrased that really well. For us, it's not done once the fire's out. It's only after we get it to the point where it's not going to happen again. That's when it's done.

Garrett: [22:20] On the note of fires, what's the toughest day or event that y'all have encountered with the business thus far? It could be anything. It could be business related. It could be technical related. You name it.

Ben: [22:34] For me, since my primary responsibilities on the op side, the technical problems are my worst days. We're had more than one. The absolute worst that I can think of at the moment, the one that stands out the most was early on, we had a problem with our database. We use Postgres, which we love. It's awesome.

[23:01] But I wasn't aware of the transaction wrap-around issue. If you're into databases and stuff, you may have seen a couple of blog posts a couple of years ago about this. This was before those blog posts came out.

[23:14] Basically, this text book, we just ran out of transactions on the database. The way Postgres works, it just shuts everything down until it cleaned that up. Nothing, there's nothing you can do. Nothing that helps until that process is done, and it took hours. Hours for that database to get back to working again. That sucked. That really, really sucked.

[23:39] Fortunately, again, that was early on in the business. We didn't have a whole lot of customers at the time. The customers that we had, they knew we were a young company, and they were very understanding. We really appreciated that. Of course, we had a queue. We had this huge backlog, and we had to work it for hours and hours after the database can back online.

[23:57] Fortunately, we didn't have to drop a whole lot of data, and one of my favorite memories from that experience was after we had finally worked through the backlog.

[24:06] I guess this is probably at this point, 12 or 14 hours after the initial event started, had a customer write in, said how appreciative he was that we actually took the time and the effort to actually process all that data rather than drop it all.

[24:23] It was really cool. Again, awesome customer. They understand what we're going through. That was a horrible day for me, but it turned out well.

Garrett: [24:30] Of all the stories I've found, the only fairly consistent factor I've found that determines whether it ends well or poorly, almost always comes down to the company's honesty and transparency after the fact. So many companies try to cover it up or talk around problems, and especially with the developer audience.

[25:01] They know how to write code. They know if you're full of it. At least, in my experience, it seems the more honest and transparent they are, the better it goes for the business as a whole, and the less fallout you're dealing with and all of that.

[25:16] One of the things I've always told people is things are going to go wrong. Once they go wrong, just be a hundred percent honest and clear about it because anything you try to cover...

[25:25] It's always like, the cover up's worse than the original. That's just something that seems like is worth repeating for people to let that sink in. Be honest and transparent, and everything will be fine, or as fine as it possibly can be.

[25:47] What tactics or techniques have you used to grow it? Has it mainly been word of mouth? As you've grown, have you hit any plateaus where you had to adjust your tactics to break through? Or have you been lucky enough that growth has just been slow and steady and never been a thought, it's just been healthy?

Ben: [26:06] Early on, like I said, it was pretty easy to get growth. You just put it out on Twitter that we were launched and people were like, "Yes, that's awesome. We'll sign up." Since then, I think the primary driver has been word of mouth.

[26:20] People love us and take us with them. Freelancers move from project to project, and we get introduced to new people all the time that way. Developers, once they get a tool that they love and they get used to, they like to stick with it. They take it to the next job and so on.

[26:37] That's been a great way, primary for us to grow. Another that we really enjoy has just been get out and talking to people, going to conferences and giving presentations, or just hanging out at meet-ups. We love that. We are developers, and so we love hanging out with developers and just chatting with them and just one-on-one talking to people.

[26:59] We're not there to sell but, "Hey, we're Honeybadger, here we are." People are like, "Cool, I know those guys. I'll use their service."

[27:08] Those two things have been the primary ways that we've grown the business. We've been fortunate that we've had pretty steady, consistent growth over the life of the business. Of course, we'd love to bend that curve upward and figure that out, but I don't think there's any magic to that.

[27:27] I don't think there's any shortcut. It's just a matter of continuing to plug away at the things you know you should be doing and doing them.

Garrett: [27:34] A lot of that too is it's easy to get carried away with desiring growth and not necessarily being fully cognizant of why you want that growth other than you're supposed to want growth.

[27:47] Gail Goodman's "Slow SaaS Ramp of Death" talk and one of the things she talks about is, "I wish somebody had told me the fun was happening here, not later where you're a more vertical growth rate."

[28:03] By the time you start growing too fast, you've missed all the fun and it's too late. Now, your whole job is just making sure the company doesn't fall apart as it goes a thousand miles an hour.

[28:17] What are some reoccurring challenges, with automation maybe there aren't as many, that you haven't solved yet? What's made them difficult for you? This is more from a SaaS perspective. What operational things have y'all struggled with for whatever reason? Maybe it's technical, maybe it's just not as interesting of a problem.

[28:36] Is there anything for those problems you've tried that hasn't worked? Think about this from the context of somebody else starting a similar SaaS business. Problems, they're inevitably going to run into.

Ben: [28:52] We've had probably three or four inflection points, I would call them, that I can identify, where on an operations side, we hit the wall. We got to a point where what we were doing wasn't working anymore. It worked just fine, and now it's not working anymore. We had to rebuild.

[29:13] We've done some major overhauls of our stack several times. I think you can pull back from that very detailed view and say...

[29:25] When you're running a business, to me, my philosophy is everything is an experiment. No one knows exactly how to do it. If someone did, it'd be game over. We'd all say, "We'll just do that," and then boom, we wouldn't [inaudible] .

[29:37] You've got to give yourself some slack. Just try something, and if it works, keep doing it. If it doesn't work, you do something else. At some point, what's working won't work anymore. It just won't, for whatever reason. That's OK. It's not the end of the world. You just try something else.

[29:59] The thing that's awesome about a SaaS business is that that revenue is coming in every month, like with RailsKits, I sold something one month and then, boom, that's it. I had to start over, had to get new customers coming in the door.

[30:12] I loved having that recurring revenue. You can say, "We've got a pretty good foundation." Even if we plateau, let's talk about it, let's figure it out, let's spend some time. We've got that income coming in. We can say, "Hey, let's try something new or something different," or, "Let's tweak that."

[30:30] I guess the moral of the story is just trying something. If you have an idea, try it. If it works, keep at it. If it doesn't, try something else. Then almost guaranteed, what you're doing now, at some point, will stop working until you have to do that again anyway.

Garrett: [30:44] I've never thought about that, but as you're saying that, I'm thinking to myself SaaS gives you perpetual breathing room that you don't have in so many other businesses because you're afloat, or inventory, or whatever.

[30:59] With SaaS, that's not an issue. You can be pretty confident it's going to work, so you've got the breathing room to experiment and be a little more out there with some of your ideas and still be fairly safe. That's a really, really good point that I never, ever thought about.

Ben: [31:17] It's nice.

Garrett: [31:18] If you could go back to the beginning and give yourself a head's up, what would it be? Is there something you would be ready for, or something you'd say, "You know what? Don't even worry about that. It's not important." What would it be? What would that advice be?

Ben: [31:31] Funny aside on that. When Starr and I were at the startup and we were talking about side projects, he had one condition, and I had one condition. His condition was, "I never want to be in someone's critical path." My condition was, "I don't want to have to go back to freelancing before I switch over full-time to whatever we do." [laughs]

[31:52] Neither of our condition words came true. We're in the critical path. We had to always be up, and we didn't have enough money to support us from day one. If I were to go back to myself, I would get in my face and say, "Are you sure you really want to be in someone's critical path because it's a big deal? You're going to have some late nights and early mornings, and it's going to suck for a few years."

[32:21] I guess, the going-back-in-time lesson is it may not be peaches and cream the whole time. It may suck a lot of times, but the journey is still worth it. It's still awesome. I still love what I do. I love making our customers happy. I love being able to do what I want, when I want, and I get paid well for it.

[32:45] It's awesome. I am living the bootstrapper's dream. It's been painful at times. I've had times literally going to bed late and waking up early to deal with whatever blew up during the night. I've had long stretches of no vacation.

[33:02] I wouldn't repeat some of those experiences if I had the choice, but overall the whole journey's been just awesome. I love this. I love doing this. I love business. I love technology and so on. I love my life.

Garrett: [33:19] Telling yourself it's going to be a bumpy road, but the journey's worth it. Tough it out. Maybe, just do as much as possible to make the journey a little less miserable at times, wherever that's possible.

[33:32] It's easier said than done, of course. If you were starting a new business today, and it doesn't necessarily have to be SaaS, would it be Honeybadger, or would it be something completely outside of technology? The sky is the limit. With your skill set, what would you do?

Ben: [33:53] The grass is always greener, right?

Garrett: [33:54] That's why this is a fun question.

[33:57] [crosstalk]

Ben: [33:58] Gosh, if I were to start something brand new today, it might look a lot like Honeybadger. I don't know that it would be as heavy operationally because been there, done that, don't know that I want to do it again.

[34:13] Maybe, one lesson that I've learned through this process that I could use today would be if I could go back and change one thing...If I'm starting something new today I might do differently is I might postpone taking the money out of the business that I did, like paying myself a salary. I might hold off on that so that I could hire someone sooner.

[34:35] We made a conscious decision early on in the process that we didn't really want to grow our headcount. We wanted to maximize revenue per employee. That was our goal. We were very explicit about that and very upfront. The three of us signed onto that. That's why we're still three of us today.

[34:50] Not that we'll never hire. We've had plenty of contractors come and go. The one thing that might have made a difference and made this journey smoother would be to hire someone earlier on to take some of that load, so it wasn't just the three of us. I might do that differently.

[35:07] Other than that, I love the space I'm in. I love dealing with developers. I love technology. I love building software. I love recurring revenue. I love the Web. All the things I'm currently doing, I love those things, and I think I would probably look for something just like that, just maybe a little less intensive on the operation side. [laughs]

Garrett: [35:29] Fortunately, you're past all that now, so it's all downhill from here. Or uphill, I guess, hopefully, uphill in a good way. [laughs] That's all I've got.

[35:39] If there's anything else you can think of that you want to share just based on your experience, or words of wisdom you've heard from someone else, or that helped you through, now would be the time to share that. Otherwise, that's all I've got. Nothing?

Ben: [35:54] I'm good.

Garrett: [35:54] We're good. We covered it all. That's it. Thanks so much for being on.

Ben: [35:59] Thanks.