In this week’s episode, Rob sits down with Derrick Reimer to answer listener questions. They discuss whether they have any regrets about selling Drip, protecting against web scraping, making the leap from side project to full-time, and making decisions as a development team.
The topics we cover
[2:10] How development teams think about decisions together
[13:42] Do you ever regret selling Drip to Leadpages?
[21:00] Preventing against web scraping
[27:16] Jumping ship from a full-time job
[37:20] Advice on starting a mastermind group in 2021
Links from the show
- The Mom Test
- The Personal MBA
- The Ultimate Sales Letter
- Traction
- The Entrepreneur’s Guide to Keeping Your Sh*t Together
- Start Small Stay Small
- The Art of Product
If you enjoyed this episode, let us know by clicking the link and sharing what you learned.
Click here to share your number one takeaway from the episode.
If you have questions about starting or scaling a software business that you’d like for us to cover, please submit your question for an upcoming episode. We’d love to hear from you!
Subscribe & Review: iTunes | Spotify | Stitcher
It’s great to sit down once a week to think about this, to hear from other founders that are going through it, and to just feel like we’re not alone in this journey. This week I sat down with Derrick Reimer. You may know him from The Art of Product podcast, and he’s the founder of SavvyCal, which is a competitor to tools like Calendly and YouCanBook.me.
Derrick and I take on a bunch of listener questions this week including how to make good decisions on a dev team, whether we have regrets about selling Drip, the effects of web scraping on your business and how you can potentially block web scraping, how much of your journey and success can you share with family and friends, and more.
Derrick and I have known each other for almost a decade at this point. It’s always a pleasure to have him on the show. I think we have great chemistry, and it’s just really comfortable when we sit down on the mic together. I hope you enjoy our conversation.
Derrick Reimer, thanks so much for joining me today.
Derrick: Yeah. Thanks for having me back on the show. Always a pleasure.
Rob: I know, man, you’ve been on several times. For folks who don’t recall, you are the co-founder of Drip that you and I built together and exited in 2016. You had founded a little side project called Codetree that you built up to (if I recall) about $4000 MRR. We talked on this podcast about how you sold if $128,000, right around the time we sold Drip as well. I think you sold a car, a house when you moved here.
Derrick: It was a mass liquidation event, yeah.
Rob: Now, you are working on SavvyCal at savvycal.com, which is online scheduling. If people used Calendly or YouCanBook.me, it’s a similar tool, and you’re getting some good traction with that. If folks want to hear your journey, they can head over to artofproductpodcast.com. Excited to dive into some questions today?
Derrick: Yeah, let’s do it.
Rob: Yeah, I’m stoked. The first question comes from colin@thepodcasthost.com. Take it away.
Colin: Hey, Rob. It’s Colin here from the podcasthost.com and our SaaS product, which is alitu.com—podcast maker. My questions around the SaaS we’re building is the team that we have now, which is growing—we have five developers now on the team. I’m asking about decisions.
We’re starting to struggle with decisions because we have more than just one or two people, we started to have—now and again—disagreements, and not in a bad way. We’re having good discussions around these, but one person will believe we should go one direction, one person believes we should go the other direction. We’re reaching an impasse more often than we used to.
I’m wondering how teams—development teams in particular—should think about decisions when it’s not a black and white decision, there’s no one right answer. This technology has these pros and cons, this technology has those pros and cons. How do you decide? How do you decide which direction to go? What decision to make? I’m curious how you do that on teams, especially […] ones. Thanks for all the content you do, and looking forward to your answer.
Rob: Interesting question. Since I know a little more about Colin’s business, I want to give some background. He and I have actually spoken. I’ve interviewed him for this very podcast. The interview just hasn’t come live yet. He runs a SaaS app in addition to educational stuff for podcasters. His team is relatively small, and he’s not a developer. Just as […] any of that is relevant. I think he said in the voicemail that four developers, five developers—still a relatively small team. What do you think about this topic of making decisions in a dev team?
Derrick: This is a really interesting question because it can get tricky when you have a number of developers on a team who each bring their own varied experience to the table and have their own preferences and certain libraries that they prefer to use. Obviously, we have to contend with this kind of thing at Drip. For the longest time, we were very, very small. It was just me and a couple of junior developers. I got to kind of just call the shots on the foundational pieces of technology that we’re going to use.
I guess, my first piece of advice is someone should be in the leadership position on what the core values are and what the types of technologies you want to use. It really helps to establish some guiding principles. An example being, are we willing to use libraries that are brand new, or are we looking for a certain amount of time that they’ve been around and battle-tested? Do we value a good amount of documentation? Is the library actively maintained? A lot of people on the team already know how to work with the underlying technology, or is it some language that only one person knows and they’ll be the bottleneck on maintaining it?
Considerations like that are practical things you can use to guide technology decisions. Another good exercise is to encourage folks to try to craft a thoughtful pitch for it. And in writing, it’s probably a good way to do it. Just organize your thoughts. If we’re at an impasse and we’re trying to figure out which library to use, state your case and roll through some of those guiding principles that the team has. Does it check those boxes, and use a little bit of persuasion to try to advocate for the piece of technology you want to use.
Rob: I agree with all those points. When I’m thinking about it, there has to be a hierarchy. This is why that exists. While it’s not a dictatorship in terms of I make all the decisions and everyone listens, it shouldn’t be like that. There should be helpful conversations. You can vote if you want. But ultimately, this comes back to who’s responsible for this. Who owns this area of the company?
When I think about having a dev lead, a tech lead, a development manager, or whatever title you want to imbue on them, they are ultimately responsible for the uptime of the app. If it goes down, they should get paged at 2:00 AM in the morning—they or whoever else is on call. That should be shared around. They are the arbiter of these decisions ultimately. I love and I loved healthy discussions we used to have at Drip—both pre-acquisition and post-acquisition. When it was just a handful of us, to when we had an engineering team of maybe 16 or so when we left.
There were spirited discussions, but ultimately, it would come down to a couple of options that made the most sense. And then sometimes, there was just a decision made by the manager or made by one of us, if it percolated up. In Colin’s case—as the CEO or founder, I don’t know (as a non-developer) if he wants to be the ultimate arbiter. But technically, he is the owner of all of it. He is the person who would make the decision if a tech lead didn’t know what to do or whatever.
But realistically, if it’s within the wheelhouse, it’s in the discipline that your developers are experts in, then I would have that senior person be making those decisions. Have its responsibility, its ownership, and it’s the freedom to make the decisions such that they are willing to own them later. If you use a cutting edge, brand new library, know that that has risk, per your comments. Maybe it gets abandoned, or maybe they do a 2.0 update where the entire API changes like a lot of the JavaScript and VC frameworks did back in the day.
There’s a balance here. If every decision is a bunch of conversation and even arguments, something is broken. That’s not how it should be. In general, there’s usually a pretty obvious choice or maybe two. And in general, if you have a team that wants to do the best thing and is keeping the mindset of building an app for the next decade. We need to build stable, maintained components—whether it’s an open-source or not—libraries, and this and that. Oftentimes, there are usually one or two obvious choices based on the language or the tech stack that you have. There’s a leader (so to speak) in the space.
Derrick: Yeah. Encouraging a mature mindset around technology. I’ve seen this among developers as they get deeper into their careers. The first couple of years you’re a developer, you really are in the experimentation phase. You like to pull brand new things off the shelf and play around with hot new technologies. I’ve seen many startups make this mistake where they’re like, we’re going to use RethinkDB for this thing because it’s a really hot, cool, new database. And then come to find out it’s a nightmare to DevOps to keep it up and reliable is a nightmare. It ends up being just an albatross.
I think the more mature developers, oftentimes, become inherently skeptical of shiny new things and tend to—all things being equal—go with the simplest architecture or the simplest technologies that are battle-tested. Even just laying that out is this is something that we, from a practical standpoint, want to do and then try to hold things to that lens as much as possible.
Sometimes you’re going to have to take some risks and choose something where you’re not totally certain that it’ll pan out. But hopefully, most of the time, when you’re making these decisions, it’s a pretty straightforward one.
Rob: And part of that is to use boring technologies. If I were to build a SaaS app again, God forbid that ever happens, I’m only joking. But I would need someone to convince me pretty hard to not use either Ruby on Rails over Postgres or Python Django. They just work, and I like HTML that just gets spit into the browser. I know that some people really like their spinny things like the MVC framework in your browser. It loads it, but that bugs that crap out of me. I’ve just seen too many issues with that over the years.
Yeah, it’s getting more mature, and of course, apps built-in that are doing great and there are pros and cons. But for me personally, there are some tried and true technologies that over time, of course, is Ruby on Rails 10 years from now the choice? Probably not. Technology just doesn’t tend to have that arc. It does get outdated. But I get a look at that maturity curve and pick the things that’ll work.
Derrick: Yeah. One more note on that too is if you’re looking at the Hacker News crowd and a lot of people who are working at really large companies like Google, Facebook, Fortune 500 companies, or whatever where there are large dev teams, you’ll see those types of organizations that are at high scale using a lot of microservices, being a polyglot organization where they just have 10 different programming languages in the mix, and you choose the best tool for the job.
That’s good for the stage that those companies you’re at. But if you’re a bootstrapper trying to just get your initial version of your product off the ground, you do not want to be mimicking what those teams are doing. Because they’re implementing things so that they can scale it up to a team of 500 engineers handling a crazy, high volume of scale. You’re going to be a long way off from that. Like looking to funded companies to see how to build your business, it’s also risky to look at funded companies and large organizations to see how to organize your tech stack too.
Rob: Yeah. On this note, Colin didn’t specifically call it out, but there’s obviously a difference between development and technical—technology choices and product choices. When I say product, I mean which features do we build, what do they look like, what’s the user interface, what’s the user experience of them, and how do we technically architect them? Maybe the technically architect part, that probably actually goes in the first bucket that Colin already raised.
Your product decisions, I think maybe a little different because oftentimes, technology decisions, as we’re saying, it’s like, there are one or two kinds of obvious choices based on your stack. With product decisions, there’s not. What should we build next? I don’t know. It’s anybody’s guess.
With a product, especially at an early age when you’re small and growing, I think you need one, maybe two product people, and they have the vision of where it should go. They take in all the feedback. Again, it’s either one person if you’re the product CEO, or it is two people like you and I did where we’re co-product leads.
As you expand, you get to 100-person company, 200-person company, you do need a specialist in different areas. Typically, you break it up by an area of the app or break it up to the API in the web app, and this and that. There are different product owners there. But at that early stage, I do think you need fairly opinionated people to not let the app just be whatever the customers request next you build.
I don’t think most developers have product skills. It’s a totally different skillset. Writing code, architecting, and building a feature is a skillset. Scaling and all that stuff is a skillset. Let’s say in 2008, I had learned that really well when I was a senior in all those things. I knew very, very little about actual product thinking. About what to build, what not to build, how to build things, user experience. I didn’t even realize that I didn’t know that skillset, I didn’t realize it was a separate skillset.
In your mind, as a leader, whether you’re the CEO, the founder, or you’re the product owner, product manager (so to speak), I would not leave it to a developer. Unless they have this experience or they’re really sharp and you think they can learn it. I would not leave it to a developer or a team of developers to decide what features to build next.
All right, thanks for that Colin. I hope our thoughts were helpful. The next question is from Will Johnson. He says, “You might have spoken about this and I missed it, but I was curious. Now that a few years have passed, do you ever regret selling Drip to Leadpages?” We sold it in July of 2016. It’s a little over four years now. I’m curious. You and I have talked about this, but not for quite some time. It was a few years ago. We were grabbing beers chatting about it, but I am curious to hear your thinking about it.
Derrick: Still, I think my answer back then was no, and I think my answer is still no. I haven’t woken up and said, oh man, we shouldn’t have done that. I’ve had time to reflect on it. Reflecting back on my experience, we obviously started this, and there were just two of us. Then we grew the team very slowly pre-acquisition, and we took on a lot of ambitious challenges in building Drip. It started out very simple and then it became this full marketing automation platform. It was a ride of a lifetime building it. It was a lot of fun. I loved working with the team that we had. I have a lot of fun memories from that time.
But I also realized that I was starting to get burned out pretty completely by the end because the journey morphed from let’s figure out how to build this really powerful product that is really in line with what people are requesting. There was a lot of energy behind that, and it started to slowly become overtaken by the scaling challenges that we had.
We built such a powerful product. I like to laugh about this that we get ribbed by the engineering managers who ended up taking over the engineering team from us at Leadpages. And they’re like, you guys built a product that’s way too powerful. We need to put more guardrails in place because allowing people to segment or whatever became a nightmare. I had to spend a lot of my time just figuring out how to re-architect things and keep the app from not falling over during that tale end time. We were in the thick of that around the time that we got acquired.
To me, it felt like the right point to entertain the strategic acquisition that we did. I don’t think I could have done that for many years longer. Something big would’ve had to change. We would’ve had to either raise some funding and hire some really experienced engineering leaders who had scaled something like Drip before. I was definitely bumping up against the edge of my capabilities. I didn’t have any experience doing it. I was just figuring out how to do it as we went along. It would’ve started to continue to burn me out if we had kept going at that pace.
Rob: Yeah, I’m in the same boat as you. I can’t think of a day when I’ve woken up and thought I wish I was still running Drip. The adventure was amazing, and the journey was incredible. It was growing fast. Could we have waited another year and sold it for more money? Yeah, almost certainly. But there are these certain windows that you get. You don’t get an acquisition offer that comes along where someone is serious about it willing to pay a strategic premium. That doesn’t come along every day.
To be able to accelerate earnings is really what it was. It was to take years and years of any potential net profit we could generate and just accelerate that to the point where it’s like, okay, now we’re able to move on to the next thing. I was in a similar boat as you in terms of I was struggling with burnout for different reasons—probably the same reasons. It was just running all and too many things. There was a lot of stress—a lot of stress on both of us. We totally could’ve done it.
If we didn’t have acquisition offers and we’re still running Drip, it would be wildly successful and it would be doing a lot of ARR, millions and millions. But when I see that path, it’s like that would’ve been cool, but we’ve also gone these other paths now. Those have been really fun.
What’s interesting is I didn’t think I was going to enjoy the post-acquisition time as much as I did. When we were still working at Drip/Leadpages, obviously, there were some things, it’s like we’re part of a big company now. There were things I didn’t like. But I really enjoyed our team, and I really enjoyed having the resources for the first time to hire super senior talent and to scale-up servers.
It wasn’t infinity money, but it felt like that. Given that Leadpages have raised $38 million in the venture, and we came from very cash-strapped—that it really felt like a different game we’re playing all of a sudden. I learned a tremendous amount about that type of business, about that side of things, and about hiring when you have more resources about what money can do. These days, again, if I were to start another SaaS app, I would either fund it well myself or I would raise around really early. Because I can absolutely now see how money changes things and where I would spend it to get there faster.
I think 10 years ago, I remember saying, I don’t know what more money would do for me. I hear people say that. That’s cool and that’s valid that you don’t, but there’s almost always a way that more money gets you there faster.
Derrick: I agree. That was a really fun time. I think that’s also another reason why I can’t say that I regret selling Drip to Leadpages. The question was like, in general, selling Drip and then also selling to the people that we did. Unfortunately, I hear a lot of acquisition stories where people hate their time at the company as they’re doing there or not or whatever the arrangement is. That was not my experience.
We retained basically the entire team for a while, got to grow it, and work in a cool office in downtown Minneapolis with a bunch of really smart, creative people. That was really fun too to get to play around with extending the vision for Drip while we were there in directions where we had more resources to actually throw behind it.
Rob: If there’s anything you could say you regret about anything, I remember when Drip—after you and I left—they have made different choices. They were redesigning the app towards the end. They changed the color palette, they changed the logo. After we left, they did a pricing upgrade or pricing change that made a lot of people mad. They’ve done other stuff. I don’t regret it in terms of I wish I still owned it so that we could undo that or whatever. But it was a little bit sad for me to see that happen at the time.
And to feel like oh man, that’s a bummer that they went and did that. But at the same time, look what we’re doing now. We’re doing fun stuff. I’m working at TinySeed, MicroConf, and this podcast. You’re doing Savvycal. I’m not the type of person to run the same app for decades. It just wouldn’t interest me.
The Drip ride, I was doing the math on it. From the time you broke ground a code until we sold it was three and a half years, and from the time we really finished the slow launch until we sold it was two and a half. It felt a lot longer than that, to be honest. It felt like at least twice that long. I think that’s the sign of a journey that the candle that burns so brightly burns half as long. It feels like that was a very intense journey, and I don’t know how long either of us would have wanted to be on that train.
Derrick: Totally.
Rob: Thank you for the question. I hope our musings were helpful, insightful, or informative. We haven’t talked about that in a few years. It’s kind of fun.
Our next question is from Dave Lara, and the subject is the effect of web scraping on my business. He says, “I’m a software developer who’s debating between native and web or a combination of the two.” When he says native, do you think he means a native mobile app or a native desktop app?
Derrick: A little bit further on his question I think he says mobile, actually.
Rob: Cool. “It sounds like it is virtually impossible to prevent web scraping without degrading the experience for legitimate users. So basically, if I want to create a collection of useful original data on the web for my real users to enjoy, am I just to accept that the data I spent time and money creating will be stolen? That I will have to invest in tools to mitigate this theft and potential for crashing my site from the stress, or do I look at a closed native mobile environment (there you go) where scraping would be more difficult and just avoid the web altogether?
The more I look into this, the more a native mobile app sounds easier than fighting with scrapers on the web despite the reduction in users this would cause. Am I looking at it the wrong way?” What do you think?
Derrick: This one I found a little bit tricky. I think he’s omitting some details for the sake of protecting his intellectual property probably. I don’t know exactly what the nature of the business is. To me, my assumption is that he’s aggregating some kind of data. He’s pulling together a data set that others would potentially want to just harvest, and instead, he’s selling access to it.
My first reaction was that putting it behind in a native mobile app is just another more aggressive tactic (you could say) for fighting scrapers. Ultimately, if a bad actor wants to steal data that you have explicitly said is not allowed to be used in this way, then it’s a losing battle. If there’s a will there’s a way is my first reaction. I think stopping ethical people who are entertaining violating your terms of service should be pretty achievable if you make it clear what the boundaries are for using the data in what ways.
If someone is an unethical actor and they want to get your data, whether it’s taking screenshots from a mobile app or sniffing network traffic to figure out what your network API endpoints are for getting that data into the mobile app or whatever. I think you may have a hard time still stopping them even if you went into a native environment.
My initial reaction would be that this (to me) doesn’t sound like something that should necessarily cause you to make a huge technical decision that would maybe harm your ability to grow the business just because some bad actors may want to try to steal data.
Rob: I kicked this email over to Chris Dokomajilar. He’s the founder of DealForma, which is a TinySeed batch 2 company. DealForma is, in essence, a business that has proprietary data that they sell to folks in the biotech and pharma space. I said, have you thought about this? Is this an issue for your business? Because his business is doing well, it’s growing. They sell to enterprise clients. If someone had his data, that is the real value of what he’s providing.
He said, “Here’s our approach, and here’s how I think about it. Number one, only paying customers can access their data. Number two, trial users are limited to only those that we let in, and that’s after a call where we’ve made some progress towards closing a sale. I know this won’t apply to everyone or at scale. Number three, we make it easy for paying customers to export data within reasonable limits so they can get work done, but not so much that they’re dumping out all the data. Trial users cannot export.
Number four, disabling text highlighting within the data limits the amateurs. Number five, seed the data with unique and obvious wrong data, which we can refer to if we really need to claim copyright infringement—as long as it doesn’t affect real usage. And number six, terms of service protect against it.”
He goes on to say, “Keeping the data up to date with new info and new updates on old events makes any one-time data output stale pretty quickly.” And then being selective about customers helps too. It gives them more value on the entire platform over just the data. There are no guarantees, as he’s saying, but that’s how he’s thinking about it. You can check out dealforma.com if you’re curious more, and I appreciate Chris weighing in on that.
I agree with you, if someone really wants to do it they can do it. I know that places like CrunchBase, which a lot of people try to scrape, are pretty hard to scrape. They use a lot of JavaScript frontend, and of course, it’s possible. But man, I think between using some best practices like anti-scraping best practices—it’s never going to be possible, but to make it difficult without going way outside spending hundreds of hours building something custom. There have to be libraries and GitHub that help you do this.
And number two, having rate limiting. I think that’s a big thing right. If your data is paged and most normal users are going to page through it at human speed. But you can often tell—just by the rate they’re hitting it—if they’re hitting it in an automated fashion. There’s rudimentary advice, but that’s the step one where I would think about.
My guess is it’s a problem you’ll have eventually, but it’s not the first thing I’d be worried about. I’d be worried about are customers willing to pay me for this? Can I build a business to $5000, $10,000, $15,000 a month—whatever your goals are. There are way more important things to be worried about. Personally, I would not make the decision to go mobile-only if this is the only reason. I don’t think this is enough of a reason to not build a web app.
Derrick: Yeah. Drip was obviously subject to a lot of potential abuse from spammers. We had to, over time, build up a moat of defenses against all the different ways that people tried to misuse the system. At this point, it sounds like you’re early on enough in your own business that it’s not totally clear what the attack vectors are potentially going to be for someone who wants to really try to do harm to your business or steal value.
I would try not to make too many upfront assumptions about that because it’s going to be really hard to know what are the ways that people are actually trying to do that if at all, or maybe this won’t even be an issue.
Rob: Thanks for the question, Dave. It’s an interesting one I don’t think we’ve had before—all the hundreds of Q&A episodes we’ve done. That was a fun one. Hopefully, that was helpful for you.
Our next question is from Evan G, and his subject line is huge growth in a year. Should I jump ship from my full-time job? He said, “Hey, Rob. I reached out a few months ago about a migration tool I built that was seeing about $3000 a month in one-time sales. I’ve since modified the product a bit and figured out how to also sell it as a monthly subscription tool.” I think Mike and I talked about this one. We were trying to figure out if a one-time migration tool could be sold as a subscription, but obviously, he hasn’t been able to do that.
He said, “Here, we are getting close to finishing out the year, and I just hit $100,000 in gross revenue with $1500 in MRR with 40 customers. If you remember from last time, which I’m guessing is unlikely, this product has massive platform risk. I built a feature of a product.” So in essence, it moves data from one product to a competitor (I believe). If that competitor basically built this, then he’s saying he would be out of business.
“My passion is entrepreneurship and I love this, but I also know what my revenue could literally end tomorrow if the product just released my feature. I stay in touch with the product manager over there as they currently appoint people my way. Nonetheless, the risk is there, but I feel like I’ve built an audience that I’m exploring and building new products for. If I’m going to make more money on this project than I do at my full-time job, is it time to quit and pursue this thing further?
I have a 5000-person email list of potential customers, some of which I’ve already started chatting with about a new product, but part of me is scared too. I have a wife and a kid I support, and frankly, I’ve gotten used to having two income streams. I’m going to make over $200,000 this year between my full-time job and side project. Maybe not life-changing, but still a lot of money in my opinion. Would love some advice on stuff you would be thinking through whether to make the jump or not.”
He also has a follow-up, but let’s dig into that. What do you think, sir?
Derrick: Well, that’s the classic decision point that a lot of us bootstrappers end up going through. I mean, it very much comes down to what is your own tolerance for risk. How much money do you have in the bank? If things were to go sideways, are you comfortable with that?
In my mind, I put myself in this category. I think I tend to be a little too risk-averse sometimes. I try to remember that with the skillset that I have—and I think you’re probably in a similar situation where you have a very marketable skillset—what’s really the biggest risk if you do make the jump? Will you be unable to get a job within a couple of months, or do you think you have a high likelihood of being able to put your skills to work on the job market if needed?
If the answer is, yeah, I think I could probably get a job given my network and my skills, then this might very well be the right time to double down on your own independent business. But I think it is a very personal decision.
Rob: Like you, I in the past have also been a bit more risk-averse than I should have been, and I wish that I’d taken some leaps that I hadn’t. You want to talk about regrets, it’s not selling Drip, it’s staying working a full-time job too long or it’s not doubling down on things and taking bigger bets with different amounts of money that I had at the time.
I think it does depend, Evan, on your comfort level with this. Risk tolerance is one thing. When I see this type of platform risk, it does concern me a bit. The way to get away from platform risk is to build this for a bunch of platforms, to have five platforms each generating $100,000. And then if any one of them shuts you out, you still have a good chunk of money.
I actually see this with a lot of Shopify apps. Between Shopify, BigCommerce, Magento, and WooCommerce—even those that do move out to each of those platforms—Shopify is just the 900-pound gorilla. You’ll see an app with 80% of its MRR coming from Shopify—a thing that could get killed by platform risk. That’s something that you got to figure out how much I believe is going to happen.
In addition, do you think if they want to build this that maybe they would just acquire you and you get a nice multiple on this? I think that’s something we talked about in the last episode. My take, I don’t want to give someone else advice because I think to Derrick’s point, we don’t know how much money you have in the bank. But if you’re able to save a good chunk of this and if you quit your job and everything went south tomorrow, you could live for months on your savings, then really it’s that question, what is the worst that can happen? The real worst.
Even if we went back into being in a recession, you’re a software developer with skills, what do you do? You get a job, you build this out. If the platform risk killed this overnight if they suddenly built it, I don’t think your revenue would go to zero instantly. It would go down, but you have traffic, you have leads coming in. Maybe there are things you do a little better than if they were to try to build it in-house. And then how long would it take you to expand it to other software packages to diversify?
There are a lot of ways. There’s often that thing, it’s that fear of oh my gosh if this happens then we’re done. I remember thinking with Drip, it’s like oh no, the Russian spammers sent all these phishing emails through Drip one Sunday night. We got blacklisted all of our IPs, and I remember wiping my hand saying, well, we’ve had a good run. But you know what, we were fine. It sucked for a couple of days, then we got de-blacklisted, and everything was fine.
These things that seem catastrophic—don’t get me wrong, there are some things that really are, but most of them are not. As savvy entrepreneurs, one of our biggest strengths is figuring out creative situations to things that just seem insurmountable at the moment. When I hear us talking, we both are probably trying not to give him direct advice, but it’s like we’re both leaning towards you should probably just do it. Is that what we’re saying?
Derrick: I think so. That’s probably what I would say.
Rob: Yeah. Making $100,000 from a one-time-use tool is pretty cool. He had a follow-up question as well, which I actually like and I don’t think we’ve ever talked about on the show. He said, “Do you share your successes with family and friends? I officially hit a $100,000 in gross this year and I feel like I have no one to share it with besides my wife, and yes, that’s a great person to share with. However, I have close friends and family, and to them, I don’t want to tell them I made all this money because I don’t want to sound like I’m bragging. I just want someone to be excited and pump for me. How do you share your accomplishments with others?”
I like this question because I know that I encountered that as I would build apps and I got HitTail to $20,000, $25,000 a month. It’s like I’d never seen that much money in my life, and I couldn’t tell that to a lot of my family and a lot of friends. And I actually remember telling it to a friend and a month later, he has to borrow money. I was like, oh man, that sucks because then I have to be like well, I don’t really loan money. I mean, it was just a […] situation. I’m curious what your experience has been, Derrick.
Derrick: Similarly, the way I think about this is most laypeople don’t really know how to interpret SaaS metrics. Most people don’t know what MRR is then you tell them. Well, it’s monthly recurring revenue. Especially if they’re not entrepreneurs, if you tell them—I’ve experienced this on both sides.
I’m celebrating 1000 a month. I just had that celebration recently with Savvycal, and to certain people who don’t know any better, they’re like sorry, is that a good thing or a bad thing? That’s a low number. And then on the flip side, if you reach these various milestones—$10,000, $50,000, or whatever—sometimes if people don’t know they can just think now you’re rich. Are you going to buy a private island?
Personally, I enjoy sharing it most with a mastermind group, advisors, or people who are in the same space playing the same game and know what these different milestones actually mean. And then with family and friends, I do still like to try to celebrate milestones. I think that’s really important for mental health and to give people a window into this crazy hard endeavor that you’re doing. But I usually try to abstract it a little bit.
Maybe I’ll say, now this business is paying my living expenses or something like that instead of an actual dollar amount. Because if people don’t understand the dynamics of a business and if you say a big number, it’s not all pure profit, or whatever, it just helps from muddying the waters a little bit. That’s how I approach it with friends and family.
Rob: I like your point about sharing with other entrepreneurs. I actually emailed back and forth with Evan a little bit, and that was the advice I gave him. You really should have a mastermind or a group of people that you talk to regularly who just get what these things are.
I remember telling a friend, Drip hit $40,000 of monthly revenue. The guy was like, that’s how much I make in my day job in a year. I was like, yeah, but it’s not all going into my bank account. Again, it’s that weird thing of, so your business has half a million dollars a year and there’s three or four of you working on it. Wow, that’s a profitable business. It can get weird. I didn’t share a lot of stuff along the journey with outside people who like yourself—you, Phil, and I were in a mastermind. I’m sure at times I said big numbers, but you guys at least knew what the context is there.
Evan, I think if you’re looking for other people to share it with, I like your way of obfuscating the exact thing. Hey, it’s paying my living expenses. Your next thing is it’s buying me a private yacht, it’s buying me the second private jet, and an island in Hawaii. So then you’re obfuscating, they don’t really know how much it is. I think that’s cool. I think that’s a nice way to do it if you’re wanting to share with other people.
And then obviously getting together with entrepreneurs. It’s the MicroConf community. If you went into MicroConf Connect and you said I hit $100,000 and posted the screenshot—$100,000 in a year—people would be like bravo, man. Way to go. No one would be like wow, you’re rich or can I borrow money? It’s a great milestone to hit. Thanks for sharing that with us, Evan. I appreciate it.
All right. I think we’re going to do our last question here. This is from Mike Needle, and he says, “First off, thanks for all you do with the bootstrap startup community. I’ve been listening to you for several years now, and your consistency helps push me forward. I’m currently building uption.io.” The name is cool when it’s written out, but saying it on a podcast, it’s like how is that spelled? It’s not upshon. It is uption, and H1 on that is joining a mastermind group focused on reading personal development books.
So Mike describes it as a platform to join temporary book clubs/masterminds centered on a specific book with the focus being on personal development and business topics.
“I went back and listened to episode 167 of Startups for the Rest of Us from January of 2014 on starting a mastermind, and I’m curious what you think has changed in the past almost seven years? What advice do you have on how to curate masterminds for others? And finally, what book titles would you have loved to read and discuss with others?” Several questions in there, sir. Do you want to just pick one and go?
Derrick: Sure. I think you can probably speak better to what has changed from your previous episode about it, but I guess I’ll just speak generally about a couple of things that I’ve noticed out of my mastermind groups in the last few years that have been really positive.
A couple of qualities that I look for or try to cultivate are varying degrees of experience. When there are a couple of different people at different levels in their business, but not too far away from each other, but close enough where if someone’s further along, they can still remember when the people who are not quite as far along were in that phase and can still offer advice that they can draw from their own experience.
I think it’d be hard for me to be in a mastermind group with Jason Fried because he’s been running this multi-million dollar business now for many, many years. The problems he deals with are far different than the problems that I’m dealing with. I think being close enough but having someone there to pull you up. It’s nice to be the person in the middle position too if there’s someone who’s not quite as far along as you. It can help you to solidify your own thinking and way of strategy around business if you’re helping strategize with someone who’s not quite as far along as you.
Masterminds where you can have complete transparency, a high degree of trust. Usually, the ones that have lasted the longest for me are ones where we’re actually friends too, it’s not just business. We have a strong personal rapport with each other. We would get along outside of the context of just talking about business and really trust each other a lot.
And then finally, my favorite element of a mastermind is when they function as an extension of my founding team. Because I’m doing the solo founder thing, and it’s really nice to have a co-founder. If you don’t, if you can lean on your mastermind group in the same way—in a lot of the same ways that you would as a co-founder, at least to talk through hard problems that you’re dealing with. That’s a major win.
Rob: When I think back to what’s changed, it’s not much. When we launched MicroConf Masterminds, which you can check out microconfmasterminds.com, which is a matching service we do to get folks together and linked up. There were two episodes about masterminds, pulled out a lot of that content, and turned it into a guide—maybe it’s two guides. I forget if it’s one or two, but it’s how to start and run a mastermind. It’s an eight- or ten-page ebook that you can download for free at the MicroConf website.
When we looked through it, it was pretty much timeless stuff. It was how to arrange it. There are a couple of different formats you can choose from. A lot of what you just said was communicated in there. I don’t think I have any big takeaway of like oh man, we’ve innovated so much on this model and it’s so different. No, personally I like three-person masterminds. I think four is starting to get big. I think two is fine, but it’s not enough people. There are nuances and personal preferences, but I don’t think a ton has changed.
His second question was what advice do you have on how to curate masterminds for others? I think it’s providing that introductory guide or ebook of this is what a mastermind is. This is our opinion about what they are and this is how. Perhaps you pick a format. You can get opinionated or you can say these are the two or three your group can choose from, in terms of always doing hot seats or just doing round-robin every time. That’s a nice thing when you do have three people is you do an hour, everybody gets 20 minutes. That tends to be plenty of time.
Or when it was you, me, and Phil drinking in my kitchen, it was three of us. Each person gets 45 minutes and two are so tired at 11:00 PM trying to pry ourselves out of there. Those are some of the fun ones. I have good memories.
Derrick: Those were the days.
Rob: I think curating masterminds for others is just about trying to pick people who, like you said, are near each other in the journey. Although with a book mastermind, I mean it’s more of a book club. I don’t know that you necessarily need to be as close in the stage of the journey as you are if you’re going to meet week in week out or month in month out and really talk about your companies.
Derrick: Oh, no. I guess I was going to say that just came to mind when you were saying that book masterminds. I suppose curating those probably involves—if you’re doing a deep dive on something very specific. If it’s general business advice, then that may be generally applicable. But if it’s very specific, then trying to pull the other people who are struggling with that specific thing. If you’re doing a deep dive on the paid acquisition or something than if you’re diving into something about, and obviously trying to pull together people who are actively working on that problem and not just theoretically. It’s probably more of a chance for success.
Rob: Yeah, I’m curious. This is an interesting experiment. I don’t know that I’ve heard of someone doing this before. I’m curious to see how it turns out. His last question is what book titles would you have loved to read and discuss with others? I assume he means back in the early days maybe. I don’t know that I have any off the top of my head. Start Small, Stay Small, of course.
Derrick: Of course.
Rob: I remember reading and really liking The Personal MBA back in the day, but that is a lot of generalized knowledge and less applicable to actually getting off the ground. I’m having trouble thinking of others. There was one that was a copywriting book. It was like the ultimate sales letter and the ultimate sales machine. There were some really tactical ones, but I don’t know that those are as interesting because they’re just a little dry and it’s a lot of tactics. Do you have any? Do you have any thoughts? Do you have any books you would wish you could have read through with a book club?
Derrick: Yeah, probably a couple. I think if it’s a group that’s earlier on in their journey, but even this is applicable to people who are further along and still doing customer interviews. I think The Mom Test is a book that I talk about all the time, and it’s just a framework for how to talk to customers in a way that will actually be useful and not give you biased data. I see that mistake being made over and over again because it’s just so hard to do. That book is really tight, really actionable, and it crystallizes my head the first time I read it. I felt like, man, this should be on the reading list for any founder who’s trying to validate a market and get a product out there.
I also really like The Traction Book too. It’s one that I return to all the time.
Rob: That’s a good one by Gabriel Weinberg and Justin Mares. That’s a good one. Did I ever tell you the story? I sketched out this idea in—I don’t even remember what year it was, but I wrote it all out and I asked Ruben Gomez about it. I said I want to write a book. There’s no book I know out there about SaaS or startup marketing, and I want each chapter to be a marketing approach. I want to give an active, like a real case study of me doing it or someone else doing it and it’ll just be a big buffet. Just a big list of marketing approaches so people could go to it and pick from it. He’s like that’s a great book. You should write that.
I don’t know what happened. I either bought HitTail, we started Drip or something, and it’s like who has time for that? When they came out with it I was like, yes. It was not, oh no. It was, I’m so glad someone wrote this. Whether it was me or not, it’s just such a good book. It’s such a good idea, and they implemented it well. They went to experts who knew each of the areas, interviewed them, and then gave ideas and stuff on how to get it accomplished.
Derrick: Yeah, really good. They’ve got a framework you can follow if you want to run through an exercise to try to distill down some to test first, different traction channels. And then it also, for me, just serves as a reference. If I’m needing to brainstorm, I want to come to spark some inspiration for how to grow the business, I will just often return to it and thumb through it and usually spark some inspiration.
Rob: That’s a good one, and I’m glad you thought of it because I was trying to think. There were books that were impactful on me like the 4-hour Workweek back in the late 2000s. Maybe back in the day, I would have liked to talk about that. I was really, really early in the journey. I think it was 2007 when I bought it, I’m maybe misremembering. But I think the only app I owned was a .net invoice at the time, and so I was applying some of the hiring a VA overseas and learning some of that outsourcing stuff. That would have been fun back in the day, but I definitely wouldn’t want to do that today. It wouldn’t really apply.
Derrick: Yeah. I also got to give a shout out to Dr. Sherry Walling’s book, Entrepreneur’s Guide to Keeping Your Sh*t Together. That’s probably a good one to do a book club on, honestly, because it’s probably a lot like exploring your own psychology that you can dig into a little bit with other founders. It might be a bit therapeutic.
Rob: That’s a good point actually. That would be a really good one. I already jokingly plugged my own book, but I agree because I think a lot of founders go through tough experiences. I mean, you and I on this podcast have just been like yeah, we were kind of burning out. Yet, you and I never sat down and talked about that. I should have probably gotten a therapist yet at the time just to vent and think of how to make things better. It blindsides you. It catches you off guard, and maybe you don’t even realize it at the time. I think having that book knowledge in your head and being able to discuss it would be good.
Well, sir, it’s great having you on the show. If they want to hear from you every week talking about what you’re up to on Savvycal with your co-host Ben Orenstein—Art of Product in any podcatcher, and it’s the artofproductpodcast.com if they want to see your show notes as you say at the end of every episode.
Derrick: Exactly. It’s become a trope now.
Rob: Yeah, and you are @derrickreimer on Twitter. We’ll of course link that up in our show notes.
Derrick: Awesome.
Rob: Thanks again for coming on, man.
Derrick: Thanks for having me.
Rob: Thanks again to Derrick for coming on the show. If you have a question that you’d like to hear answered by myself or a future guest, send it to questions@startupsfortherestofus.com. I’ll be doing probably one Q&A episode a month, assuming there’s enough question volume, and so far there has been. If you send a voicemail, you can send it as a Dropbox link, a Google Drive link, or however else you want to get that to me. Those go to the top of the stack. Thanks again for joining me this week for episode 530, and I’ll talk to you again next Tuesday morning.