Episode 575 | Shipping Code, Pivoting, and More Listener Questions with Derrick Reimer

Rob: You better believe it. It’s Startups for the Rest of Us episode 575, where Derrick Reimer joins me to give a quick update on SavvyCal and what he’s been up to lately. He’s actually thinking through a hiring decision, and then we dive into listener questions. We talk about shipping code as a bootstrapper versus a large team, talk about pivoting and a zoom-in pivot—talk about what that means—and we answer more listener questions. Hope you stick around and join us.

Before we dive in, MicroConf Remote 3.0 is happening November 30th, December 1st, and 2nd. This is our third MicroConf Remote which is a virtual event. It’s the No-Code guide for B2B SaaS founders. We’re going to take a look at the ever-evolving world of No-Code, its implication for SaaS founders, and the best ways you can incorporate No-Code across your stack from marketing, to sales, to SEO automation, and more.

Once again, we will be using a really cool community platform that simulates the hallway track. It’s not just people talking at you. We usually have 20 minute conversations or talks, followed by 10 minutes of Q&A. Then we roll into hallway track time. You can walk around in a virtual world and meet other folks to simulate that.

It’s not a replacement for an in-person event, but we found a lot of folks who attended the remote events were folks who had never attended a MicroConf before because the stakes are so much lower here. The tickets are really inexpensive. It’s a few hours of your time over a couple of days and so it’s a great way to dip your toe in the water if you have enjoyed the previous remotes or if you’ve never been to a MicroConf.

Head to microconfremote.com if you want to get notified when tickets go on sale. With that, let’s dive into my conversation with Derrick Reimer, where I get an update on SavvyCal, and then we dive into listener questions.

Derrick, the last episode you were on was 532. This is episode 575, it’s been 10 months. You were back in January of 2021 and here we are in November. You want to update folks on SavvyCal and what’s been happening? I know that folks probably heard about your product launch back in January and you actually did a talk about that at MicroConf Remote, but you’ve been public about an MRR milestone you hit.

Derrick: Yeah, we’ve just recently crossed $20,000.

Rob: Congratulations, man.

Derrick: Thank you.

Rob: How’s that feel?

Derrick: It feels kind of surreal, honestly, because it’s one of those milestone markers that you always kind of envision in your mind when you’re thinking about building a SaaS. I mean, the first one’s $10,000 and then the second one is naturally $20,000. To me, $10,000 is you can pay yourself a pretty good salary and as long as you keep things pretty tight on other expenses, you can be profitable.

Then $20,000 to me is like okay, I can pay myself probably closer to a full salary and still have revenue to cover growth expenses, it’s really starting to get interesting. It’s pretty surreal to be honest.

Rob: Yeah, and you have no employees so your costs are very low. I know your server costs are relatively low and you have a couple of contractors and stuff, but that’s a nice place to be in. TinySeed salary […] quarter a million. You can ratchet that up as much as you want.

Derrick: Yeah.

Rob: It does bring up an interesting point. For those keeping track at home, $20,833 is a quarter million a year. It’s a quarter million ARR. What’s funny is aside from a million, I’ve rarely thought about ARR multiples. For some reason to me, it was always the MRR, right? The $20,000, $25,000, $30,000, $35,000. Is that your mental model as well? Are you focused on MRR?

Derrick: Yeah, pretty much. Although I’m kind of obsessive about checking my profit graphs and seeing where we are at currently, what’s the projected based on the way churns operating, conversion rates, and everything, and that’s constantly surfacing ARR in front of me. I’m probably a little more aware of it just because my metrics dashboard has it on it, but yeah, I’m always thinking MRR.

Rob: A lot of sales multiples are based on ARR. If you were to exit—I know you’re not planning to do that—it’s good to keep that in mind. It’s a trip because you’ve made it this far with no employees. I referenced this already and you’ve done something, in fact, that if a founder came to me and said, I want to be a sole developer and I want to hire out my marketing strategy to a consultant, contractor, and I want to outsource support as well, I would say, not sure you should do that. These are kind of core competencies of a SaaS app, but you’ve pulled them off. You both have been successful. How did you do it?

Derrick: I was just tweeting about this earlier because admittedly my end is one here. I don’t know how repeatable this is or how generalized this advice is to say this works all the time. On the marketing front, it was sort of serendipity finding someone like Cory Haynes. He’s a unique type of person where he has a lot of experience on this front. He’s ambitious, he’s building his own stuff, but was in a phase of looking for consulting work to bridge the gap.

He’s able to operate at the owner-level thinking and operating, that I think is probably pretty rare to find in a part-time contract person. I’ve been able to benefit from that and I don’t know where you find those types of people.

I’ve been asked before, I want to find a Cory and it’s like I don’t know how to tell you where exactly other than hanging out in MicroConf Connect, in the circles, and spotting someone who’s working on their stuff and looking for something to bridge, I guess.

Rob: People call it a unicorn and not in terms of the billion dollar outcome, in terms of someone who is so unique. A developer who can also market, or product person who’s really good at UX, and also back end development like yourself who can go all the way from front to back, that’s it, unicorn.

There are only a handful of Cory Hayneses that I know, of people at that caliber who can do marketing strategy, which is that owner-level thinking you’re saying, because from my understanding is he came in and you’re like, cool. What should we do? He was like, well, I have all these ideas of things we could do, and you’re like, great. Can you go do them? Which is marketing tactics or marketing implementation.

Those are two different levels and they’re usually two different roles at a company, and to find one person like […] is another one who can do that. Back in the day, that was a role that I did. I wasn’t as nearly as good as the two people I just mentioned, but it was something that I felt like I had to do because I couldn’t find anyone to do it and didn’t have the money to hire two or three people to do it. That’s often why people raise funding. It’s to be able to hire these roles.

Derrick: Yeah. I like to think that I’ve been trying to build up my skills in this area. I have some generalist founder skills in the area of marketing, but still not as specialized as the type of stuff that Cory has been steeped in for so long.

We talked about the product launch and I was like, yeah, we should do that. It may or may not work, we’ll see. Then he proceeded to layout a doc and architect a strategy that’s multiple pages long of, we’ll time emails at this point, we’ll reach out to some people at this point, and send an email to the list like this, and we’ll make sure to focus on this part.

It was just very meticulous and well-planned. I think part of it is luck and part of it is execution on the results that we saw from product time. If I were just my many hats wearing founder person doing the product launch, I probably wouldn’t have put nearly the amount of time into it just because it spread so thin already and maybe wouldn’t have seen the same results. It’s been good to have someone like that on the team.

Rob: I think so. You hear me say it ad nauseum, hard work, luck, and skill. I think you finding Cory, there was some luck involved in that. Also, you put in the hard work of having a podcast and building a personal brand to the point where it’s probably pretty appealing for Cory to work with you and work on SavvyCal because he knows that you’re not a schlub, the products good, the odds of it succeeding are good if he brings his chops.

Derrick: Right, yup.

Rob: Very cool. Anything upcoming that is super interesting or happening right now that you want to mention?

Derrick: Things are feeling like they’re starting to kick in. To summarize the last year, it’s been a lot of investing in different things, podcast sponsorships, PayPerClick ads, affiliate programs, and SEO. We’re trying all the tactics and trying to invest in them appropriately, and it feels like things are starting to really kick in. We just had our best growth month in the month of October since February, since right after the product launch, so that’s been exciting.

I think coming up, I am always flirting with when is the right time to expand my direct team, the product and engineering side of things. I’m still basically doing all of that work. I’m actually having a couple of conversations that I’m pretty excited about with some potential first engineering hires, so that’s pretty exciting. It feels like a big step and one that I’ve been kind of tiptoeing towards because I know it changes things significantly, but hopefully for the better to bring someone in on that side.

Rob: Especially if you’re bringing the right person, right? Someone who really, really elevates it. I feel like a good piece of this is like you’ve already been through this with Drip. It was just you for a while and I know that I did a lot of the initial interviewing and stuff, but then we co-interviewed and kind of went like I don’t know, should we hide this person? Yes. You know what this feels like.

Derrick: Yeah, it’s been demystified a little bit.

Rob: Exactly. While we were still bootstrap before the acquisition, we went from one to what was it, three engineers? I think we were three, then got acquired, and then by the time you and I left, were we 16 engineers, 18 engineers? You’ve seen it grow.

I had joined some companies early, before all of this when I was still working a day job. I had joined maybe a four-person engineering team, I think was the smallest that was ever on, aside from consulting firms where oftentimes it was just two of us, but we’d gone from 4 to 24, and I knew that I didn’t like the larger teams, but I had never been a sole engineer and grown it like that like we did with drip. You kind of know some of the mistakes that we’ve probably made and you’ll do it differently this time, right?

Derrick: I think last time with Drip, we were sort of trying to be very scrappy, we’re kind of funded by HitTail. Like how can we get some help without it hurting the bank account balance too badly. Thankfully, with the help of TinySeed funding right now, we have the resources to go after a more senior level hire, which is going to be pretty exciting. Once we got to the post acquisition phase and we were kind of building the team with senior engineers, it was very nice to bring in someone who could really slot in quickly.

I’m all for hiring juniors and training them. I think there’s a lot of value in doing that, but I feel like at the stage I’m at right now, the company will really benefit from having a senior level person right now. Then we can work on training juniors when we’re a little bit more mature.

Rob: Yup, and why is your first hire an engineer versus any other role you could hire in a SaaS company?

Derrick: Part of it is I see myself holding back on certain opportunities to move the business forward as kind of the founder and business person because I’m so focused on product. I have a very long roadmap. There are lots to build. I can kind of peek into the future when I do some exercises of trying to just set a vision for where we can take things, and I just know there’s a ton to build.

If I’m focusing all my effort on that, then I’m probably missing out on other opportunities to kind of oversee the overall vision of the company. Getting some help on that front so that I can free up some mental headspace is going to be really important.

Rob: It’s interesting we’re on this topic, because our first listener question of the day is pretty much about how should a bootstrapper approach software development tasks differently compared to executing a project at a company.

Derrick: Great segue.

Rob: Yeah, it really is. I apologize to the question asker, Pramad. He sent this back in April, so it’s been a few months. I’m sorry, sir. Haven’t done as many listener question episodes, and also voicemails and video questions go to the top of the stack. If you have a question you want answered on the show, you can email it directly to questions@startupsfortherestofus.com, or head to the website, and you can click a button. There’s ask a question at the top and we use video ask, and you can just click and submit an audio snippet from your phone, or your laptop, or a video as well.

Pramad asks, “It seems to me that the early stages of developing a product as a bootstrapper need a different approach compared to executing a project at a large company. Practices like writing detailed design docs, unit testing, and code quality don’t help as much.” I’m cringing a little bit when I see code quality and unit testing, that matters much but I’m going to get through this, detailed design docs I agree with. “The ambiguity is a lot more and so are the constraints on how you can execute. Have you noticed such differences in how a bootstrapper approaches day-to-day software development compared to executing a project at a larger company?” What do you think, sir?

Derrick: I’ve thought many thoughts around this. It is a tricky balance to strike so I don’t know what stage our asker is at on his particular product. I think things shift a little bit, if you’re building an MVP versus building a product that you’re pretty set on continuing to build out.

I can kind of speak to both phases. The MVP phase is the hardest one to strike this balance, I think, because on the one hand, you risk over engineering things. You spent too much time on bulletproof code and then if you’re using truly as an MVP, and you’re testing in the market, and you determine it’s not actually viable, well, now you’ve wasted all this time building a really good version of something that’s never going to see the light of day.

The flip side is that you end up building something that’s really really brittle, really buggy, and maybe you validate it, and you start to get some traction. Then suddenly you have to grind to a halt because it’s time to rewrite and build the real product from the ground-up and then you miss out on all the momentum that comes from getting it into market.

I’ve seen startups do both. My instinct is to lean on building something like a code base that if the MVP proves to be viable, that you can continue on that code base and not have to stop and rewrite.

For me, I’ve kind of gone through different phases in my feeling very adamant about lots of tests. When I was a newer developer, I was sort of steeped in the Ruby on Rails culture of test, test, test, test everything and it’s definitely really important. I think there is sometimes a tendency to over test.

Sometimes you just write tests around things that don’t really need to be tested like little granular unit tests that don’t necessarily provide much value and even make it harder to build out and mutate your codebase over time.

You do some of those things for important little bits of logic that have to be right, but in general, I would focus more on kind of integration tests like testing the entire system, focusing on your really core functionality, and what tests help you do? Yes, it helps ensure correctness, but they also help you architect better code and that’s kind of the hidden secret about writing tests is your code quality comes out better by nature of running that process.

That’s what I think on testing. I wouldn’t want to skip the test. I’ve definitely probably written fewer tests for SavvyCal than I did for past products in the name of moving fast, but I’m definitely testing that core functionality heavily to make sure it’s correct.

I have other thoughts, too. I say err on the side of writing monolithic code bases. You see larger teams building microservices and separating their front-end from their back-end and building API layers in between. That stuff that teams do in order to kind of have independent teams have to take responsibility for different parts and that’s only going to slow you down and over complicate things when you’re building your product.

I’m a big fan of the monolith code base where everything kind of deploys together, lives together, and you can lean on tooling. Ruby on Rails has fantastic tooling for building server side views that spit out HTML, then you can layer on React if you need that, but I’ve kind of stuck with this sort of hybrid model of if a page can just be server side–rendered HTML, then just do it that way. If it needs something more complex, then you can pull in something like React for that page.

Rob: Yes, that’s my tactic as well. It’s a little old school, but it is just simple. I think Drip, which is quite a complicated app. Most apps people build, not putting as much data through. They don’t have the billions of rows. They don’t have the tens or hundreds of millions of queue jobs that are being processed every day. It was intense.

I think we were doing close to $10 million ARR and it was purely still a monolith. Eventually, they had to break out for performance and because once you get 16–18 engineers, having a monolith is a problem. To your point, you can make it to life-changing levels, especially if your app is even simpler, but you can make it further. This is kind of what I’m saying. Keep going. You’re on a roll there.

Derrick: Yeah, I think it goes without saying, go light on the process. I was thinking back when we were building the drip MVP, we had the spreadsheet. We just made a list of features and we put our estimates on them, which I think helped us to wrap our minds around how much time is this actually going to take? Do we need to cut scope if we want to come in at the time that we were hoping to meet? What’s that function called in Google Sheets? It’s like work days or work hours or something?

Rob: Work days, I think.

Derrick: Yeah. It was kind of a scrappy solution, but it was actually pretty interesting to track that and see are we falling behind on what we’re aiming to achieve? Or do we need to cut some things? Or can we afford to add in some things? I think the most important thing there is that it was very, very lightweight. We didn’t implement JIRA from day one and over process this thing. This is the approach I’ve taken, I’ve gradually layered on more processes.

One thing I have done, though, is I set up continuous integration early from the get go. Every time I push code to GitHub, it’s running through CI, running the test suite even though the test suite is tiny. You have those parts there in place that kind of reinforce your best practices.

I’ve been doing GitHub workflow from day one, even though I’m just one developer, I’m still pushing code on branches, cutting pull requests, I will kind of self-review code and just give it a sanity check before merging it. That’s a good muscle to build up to as opposed to just pushing everything on master all the time and sort of just build bad habits. I think there’s a lot of benefit to still pretending like you have a small team with you so that you’re kind of ready when you bring on your first hire.

Rob: Right, but also not writing a three page Word doc to describe a feature. In fact, if I was writing the code, I wouldn’t write anything about the feature unless I needed to think it out. If I had it in my head, I would build it.

If you need docs, you can write docs later. Nobody will go back and look at the design docs. They’re going to look at the code. The only thing that I would document is if you make a decision and you know this is either counter-intuitive, or it’s something I really want to remember why I decided to do this, then document that somewhere. Is it a gist you do it in GitHub?

Derrick: Yeah, that’s one place you can do it. It’s basically like a lightweight document that lives at a URL. That’s a good way to do it. I feel like that is honestly my guiding principle on when I put code comments in. Code should be pretty self-explanatory, but when there’s an odd decision that was made, or something that’s kind of unique, or special about that decision, that’s the place to drop a comment, in my opinion.

Rob: If you’re working solo, it’s one thing. If you had 20 developers, then you have all this process that Pramad is asking about. Let’s say you had one or two developers. There’s an in-between where you have to have some processes. At that point, Derrick, let’s say you’re running product, in essence, and also coding, then you have two developers. You’d be developer-heavy, but for the sake of argument that’s what you have. You would have to put something into it. It could be a Trello board, it could be Notion board, it could be GitHub issues.

To say build this fee, add this setting on this page, this is what it should do. If it hits this controller, does this thing in the database, you can use an existing field. I’m mixing product and technical design here, but that’s a luxury you have. You can do both. You don’t need two people, right?

Derrick: Yeah. I think it’s knowing you achieve a certain level of understanding and context by onboarding the new engineer. You probably should be spending time with them. Probably a two-ple or something like that, pair programming, and getting them up to speed on the code base. Then at a certain point, it’s like, all right, how much information do I actually have to spell out about this next feature?

Certain things are going to be obvious, and then there are certain non-obvious things. That’s what I always spend my time focusing on, pointing out the parts that are non-obvious and foregoing being complete and comprehensive at that stage, because it’s going to slow you down quite a bit and probably not provide much value if it’s just a couple of you.

Rob: Yup, as little process as possible because it allows you to move faster. Your biggest advantage at this stage is that you can move so fast compared to larger companies because they do have a need for so much more process.

Derrick: Indeed.

Rob: Thanks for the question, Pramad. Hope that helps.

Next question is from Victor, who was just from a month ago. How did that happen? Well, I’m glad we’re able to get to this so soon, Victor. He says, “Hi, Rob. I’m a longtime listener, a huge fan. After listening to the podcast for more than two years, I created my startup six months ago. Now, I’m considering a zoom-in pivot, but there is another startup offering the same service and they have been recently acquired. The market is far from overcrowded, but I wonder would you pivot and enter the market, if there was a startup offering the same service with potential access to a huge amount of money?”

For those following along, zoom-in pivot is where you build a product, then you either realize that there’s a specific vertical that you want to zoom in on, or I believe, you can zoom in on a specific feature. Like, we’re going to get rid of half the app. This one piece is what everyone loves. We’re just going to ditch the rest. I think that’s my interpretation of a zoom-in pivot. What are your thoughts on this, Derrick?

Derrick: I would say, just because there’s a well-funded competitor in the space doesn’t mean that it’s necessarily a bad idea to go in there. That’s what I’m doing myself. I’m entering in the scheduling space. There are 800-pound gorillas galore in that space, and I’ve managed to carve out a little slice that I’m working on building. It’s definitely doable.

I think I would be thinking about, do you have any particular unfair advantages in that space? I think it’s much harder to enter a space like that. If you don’t have a deep context about the market, know the pain points, maybe have connections or a network in that space that you can use to initially get your product launched in the market. Are you insanely skilled in an area where the big competitor is lacking? If customers value UX in that space and the large well-funded come in and just don’t have that in their DNA, that’s your opportunity to seize.

I’ve heard people say, like, well, they can just hire people and get better at UX. But that’s a lot easier said than done. Companies that don’t have something like that in their DNA, as an example, do have a very hard time getting really good at that. Something like that, that you can leverage to your advantage to make you stand apart. I think that the important thing is figuring out what your key differentiator is going to be, then honing in on that really strong. If you’re thinking about zooming in, that sounds like you might have a hypothesis about something that you have a unique take on or will really speak to a burning pain point that maybe a subset of the market has.

I think that’s the other piece. I’m competing with well-funded competitors. By nature, a lot of these competitors have positioned themselves very broadly. Calendly is easily scheduling ahead. That’s their H1. It’s not speaking to any specific pain around scheduling. It’s just like we make it easy, because they’re speaking to a really, really broad market segment. That gives me an opportunity to speak a little bit more narrowly to something more specific that people are experiencing.

Rob: I think that’s really good advice. I think the only thing I have to add is not only are they a well-funded competitor, but they’ve already been acquired. Once a company is acquired, the founders are usually not going to stick around 10 years to drive it like they have. There’s a clock ticking for them to leave. If they had just raised a huge funding round, then it’s like they’re trying to get to exit or that get to the next round.

I’m not saying every founder who sells checks out or anything like that, but some do. Also, the odds of these founders being around in two, three, or four years are small because they got their payday. That’s even more reason that I think that you could probably make up some ground on this startup. I wouldn’t be concerned by this very much at all.

All right. Our next question from Lorenzo is about whether to use a progressive web app—we’re going to abbreviate it as PWA—or a native app for a SaaS startup. He says, “Hey, Rob. This is Lorenzo from Italy. I’m working on a concept for a new SaaS startup and I’m thinking of bootstrapping. My next concern is how to keep costs under control, manage complexity at a reasonable level, and create a platform that is future proof.

Among my doubts, there’s one related to the technology to be chosen upfront to build such service. I would expect it would be used 70% from mobile and 30% from desktop, would you suggest I develop the platform as a progressive web app (PWA), or two native separate apps, one for iOS and other for Android?

I’m inclined to do a PWA but I have doubts, given that only Google seems heavily committed towards this format. It seems to me Apple still prefers native apps on which they can have a cut of the monetization within the app store. What do you think?”

Derrick: I think it’s extremely difficult to pull off implementing multiple platform versions of your same product. We’ve seen many examples of this from the history of startups. Facebook being a big one. Historically, they had native apps only and they pivoted over to being a web app. I think they’ve gone through different iterations.

They have React Native now, which could be an option of taking web code and compiling it down into a form of native code. There’s certainly one way to achieve this on desktop apps, like Slack for example. It’s still an Electron app, still a web app running in a shell.

We’ve also seen another example from the community. Twist (I think) is a Slack alternative. They were for the longest time committed to building native versions of their apps, trying to optimize for a very fast, snappy, and native feeling experience. I think they recently pivoted away from that as well, because the burden of doing that is just extremely high.

Every single feature you add into the one UI, you now have to go and write code to implement it over there. You end up with things naturally drifting apart, synchronizing engineering schedules, not to mention the cost of doing that is pretty immense. I would strongly recommend unifying it under one code base, and just opting for either using a web wrapper technology like Electron, or something like React Native that might let you reuse the same parts and compile it down into native.

Rob: Usually, I have a bunch of things to add on to these answers. But really, I was basically going to say, yeah, don’t do it. These big companies try it and it’s like Napoleon invading Russia. They run in, like it’s cold, it’s cold, and they run out. It’s like that over and over. It’s happening, right? Was that the 1800s? The joke was not a good one, was it? It’s actually a reference to an Eddie Izzard comedy sketch. Go check that out if you haven’t seen it.

Is white labeling an option for getting started? That’s our next question from Devin Tracy. He says, “I’m not technical, and I’ve never owned a SaaS. So when I started listening to your show, everything was just entertainment for me.” That’s funny. Entertainment, this show. “But now, I have white-labeled a SaaS that I’m starting to try and market and sell as my own. Suddenly everything you say has relevance beyond the entertainment.” That’s cool. That’s once you start doing things. That’s usually what happens.

“I’m curious about your thoughts on the white labeling approach I’m taking. I do hope to have my own SaaS one day, perhaps learn coding, more likely be a non-technical founder. I’m hoping this can be a good route to help me get my feet wet, maybe even build some revenue. I love all you do and appreciate the podcast. Much gratitude, Devin” What do you think of this?

Derrick: I was actually trying to understand how the model is working when he’s saying white labeling. It sounds like there’s a product that he has licensed to become a reseller of it sort of thing?

Rob: Pretty much. You can imagine, let’s say that there was an email service provider. Whether he’s paying them X amount per month as a flat fee or per year, or he’s paying 30% of his revenue that he generates to them, but then he has his own website, own domain, own logo. Usually, this is like a white label is to go into a vertical. There’s an ESP selling to everyone and then you want to build this ESP for realtors. You just pre-populate it with content for realtors, you market it to realtors, and you call it realtyesp.com or whatever. That’s a terrible name, don’t use that, but that’s the idea. He didn’t say that, but let’s assume that’s the example.

Derrick: In that case, it seems like this could be a good stair-step. I think especially if you’re looking to level up your chops on the non-technical side of things, on marketing and selling. If you’re looking to experiment with figuring out how to do SEO, do a content strategy, do pay per click or partnerships, sponsorships, all those things, I feel like you could practice those skills and deploy them with this off-the-shelf product that you’re bringing into a new market.

If you’re looking at another big part of operating your own SaaS, is developing the skills on how to interview customers, iterate on product-based on their feedback, set your roadmap, managing development cycles, all those things. It depends on what skills you’re trying to develop. I see no issue with using this. This sounds like his goals are to bring in some revenue, and to level some skills in a particular area that will apply to someday running his own SaaS. To me, it seems like this could fit that bill nicely.

Rob: I feel similarly to this, because the whole point of the stair-step approach is that it’s really hard to learn everything all at once. It’s like there’s product, there’s engineering, and there are all the things around marketing. When marketing itself has 20 different things, you have to learn to be any good at it. Then there’s sales, then there’s support, then there’s operations, on and on and on. Learning all those things at once is really tough. That’s why a step one business eliminates a bunch of that. Usually it’s in a marketplace or something. So you don’t have to learn all the marketing. Maybe you’re just doing the coding, some promotion or whatever, some ranking, but then it’s support.

This approach of white labeling is similar. As you said, he’s trying to limit the number of things he has to know, all at once. Then he can learn other things, the innovation, or the product management, taking in customer requests, and actually going and building stuff. You could learn that later. There are obviously risks here. You have platform risk that is crazy because you are beholden to someone who, I don’t know, can they revoke your license? Could they just shut the whole thing down and stop supporting it? There’s risk there.

For me, I wouldn’t be like, I’m going to build this $5–$10 million business and exit. I would be concerned about trying to do that. But I could see building a cool lifestyle business on this, that $10,000, $20,000, $30,000 a month with just you. You don’t need developers because you know that you’re paying this other company, essentially, to develop it or to maintain it or whatever. You just have to handle support and marketing. Really? I’m intrigued with that, especially as a non-developer founder. I’m curious. I mean, Devin, I hope you update us because I haven’t heard anyone do this before.

My initial take is similar to Derrick’s. I don’t see why not. If I wasn’t a developer and wanted to do a SaaS app, I think it’s an interesting approach. Aside from the platform risk where you just have to go into a vertical, because there’s no innovation happening here.You’re not able to make the decisions of what gets built.

If you go into a space where it’s a constant feature race, you’re going to get out-featured. If you were in the scheduling link field, or if you are an ESP that’s not niched down to a small vertical space, I think you’re going to get crushed because you’re just not going to have anything unique to offer the market. That’s probably a word of caution. I would look ahead into spaces where it’s not that feature race and the constant need for innovation.

Derrick: That’s good advice. Also, a big part of making progress towards having your own software product is making sure that you are tackling a worthwhile problem. I feel like this could be an interesting way to discover. I don’t know if this is a field you would want to continue staying in, but you could potentially build up something here as you build this business that would help you towards your next endeavor. You don’t feel like you’re going to have customers in this space, contacts, partners, whatever.

You may discover this product is not cutting it anymore, this white labeled one, but maybe you have an angle on solving problems for this particular group of people that then you can start head down your path of partnering with a technical founder or whatever. I think it could be a good way to learn some deep insights that will inform what your next product could look like.

Rob: Indeed. Thanks for the question, Devin. I hope that was helpful. Our last question for today is from Nicholas. He says, “Broker or no broker when selling a single-founder business?” Nicholas says, “I was wondering your thoughts on when selling a bootstrapped single founder business with no employees whether to use a reputable broker to facilitate the entire process, someone like Quiet Light Brokerage or to use a marketplace like MicroAcquire or Flippa. When is using a broker worth their cut of the deal?”

Obviously, there are other brokers. There’s FE International. I’m trying to think of who else, like Empire Flippers and such. I believe the commissions on those are usually 10%–15%. You and I both had experiences selling businesses through brokerage, so what are your thoughts on this?

Derrick: I think it depends on the size. I’ve had a few projects that I have sold on my own very, very casually, lightweight. I built a product called StaticKit. It had just a little bit of MRR, but wasn’t really in growth mode at all. I wanted to rehome that app and find a place for those customers who were using it to find safe ground somewhere else. I managed to reach out to a competitor and said, hey, I’m looking to exit the industry. We just lightweight negotiated a price and sold that. I also sold the IP for the level.app domain when I shut that project down. I didn’t use a broker for those.

I have had a SaaS app called Codetree that was around $4000 MRR, sort of flat on growth. At that time, it was a side project and I was building Drip. I couldn’t imagine trying to shop that around, find potential buyers, then go through the negotiations. It just would have been an immense distraction. At that phase, it made perfect sense to do it. I think even with our Drip experience, we obviously had professional help on that front.

That deal took a year to close. We needed to focus on continuing to grow and run the business. The guy who was helping us did so much legwork. It’s a full-time job for a deal of that scale. I definitely wouldn’t have tried to do that on my own.

Rob: And that’s the thing. I do think it depends on how comfortable you feel with your own skill set. Some people are good at negotiating and are naturals or they’re comfortable, and other people really don’t want to. In which case a broker is going to help you and advise you. Some people feel like they can put their business up on a MicroAcquire or Flippa.

These days, I think certainly if you have a SaaS app or a software product, I would be on MicroAcquire if I was going to pick a marketplace. They’re the leading one. I had the founder here a few months ago.

It depends a bit on your skill set and experience. The tricky part is, you say, well, I’m going to give a broker 10%. That’s a lot of money. You can also make a single mistake that costs you 20%. It’s not hard to do that, so that’s that balance. I would say if you’re running a SaaS app that’s doing north of a million dollars, I can’t imagine trying to sell that or really any business. It would be a challenge.

Now, you and I have a mutual friend. We’re in a Slack group with a small founder group. He sold his business on MicroAcquire for a good chunk of money. He did it all himself. He has a ton of experience doing that related stuff, not in software, but negotiating, cutting deals, figuring things out. Deals are a thing he’s done a lot of.

A lot of us, especially software developers, have not. We’ll do a handful of deals in our whole life. I would say again, if you’re north of a million dollars of SaaS, not only what I want to a broker I would talk to so there are people who specialize in this. Discretion Capital is a sell-side, M&A advisory, and they help SaaS companies who are north of a million dollars sell their companies and run a whole process. That’s one. Quiet Light, for sure. It has just been around and helped a lot of folks doing that.

I think you have to think about what value does the broker bring? What gaps do they fill especially the higher it gets? The other interesting thing is the higher the purchase price, the commission’s usually come down. Broker isn’t going to come and consult on a $20 million sale and take 10%. They don’t take $2 million in commission. The number actually comes down the bigger your sale gets. I think your point of the size is important to consider your experience.

I don’t know. The marketplace versus the broker thing, I guess that it’s similar. It’s like if you’re in these marketplaces, it’s a lot more. You’re on your own. They don’t have advisors. Are you willing to take the risk and make the mistake, potentially, maybe not having an optimal exit because you don’t know what standard or what you should ask for when you’re doing it for the first time?

Derrick: Yeah. I recall when I was selling Codetree. First of all, the broker had people that he knew that were interested already. He was able to bring potential buyers throughout the listing but also did some direct outreach. The people who ultimately bought it were on that shortlist of people that he knew were already looking. There was a little bit of that shortcutting the process already. He knew how to manage the leverage properly. I think he did a very, very good job.

Actually, the buyers wrote up a very honest blog post about the whole process and talked about how they reached a point where they were sort of stuck. He was just very good at doing the negotiation, definitely not the skills I would have had. As soon as we got a serious offer in the door, he was making sure to continue to look for backup offers and run that rigorous process to make sure that we had the right amount of leverage on our side.

I don’t know how much of that comes baked into some of these marketplaces, or it’s just like you receive offers and you can negotiate with them back and forth, but it’s you to potentially look for a backup and make sure you can use that as leverage.

Rob: That’s the thing, if this is your only business and you have a bunch of time to do it, and you want to get the commission, then to your earlier point, well then do it on your own. I think if you’re onto another thing, like you building Drip, you cannot manage. It was stressful enough as it was. It was enough time because I did the same thing.

I sold HitTail maybe six months before you sold Codetree. I was going through the same thing, obviously went through a broker because we were busy building this incredible business. I wanted to get rid of this. Not to get rid of it, but I want it to be off my books.There was no way I would have managed that process. So that’s the thing.

Here’s what I think, dude. I am so happy that our mostly bootstrap space has evolved to what it is, where it is easier to buy and to sell apps, because the first app I ever bought was in 2006, 15 years ago. It was a […] show. I didn’t know what I was doing. There was no material on it. There were no brokers. No one would touch this stuff. There were domainers at that point. I got taken advantage of and it eventually worked out. It was done. It was hard.

It was my first one that really caught and got $2,000, $3,000, $4,000, $5000 a month, depending on the month. It was not SaaS, so it was really, really spiky. The multiples were crazy low. I used to buy stuff between 12 and 18 months of net profit. I used to buy at Flippa. A lot of the reason I was able to quit the day job was because it was just cheap. On the buyer’s side, that’s great. But these days, the stuff we build to build Codetree to $4000 a month, that’s a great little bootstrap business, lifestyle business. You weren’t going to live off it, but it was nice side income.

To sell it for $120,000—that number is public, I’m not just disclosing anything—that was a great win for you and that kind of multiple. Even these days, I think it’s like four to six. If you’re under a million, usually it’s like SDE net profit is about four to six-ish. If you’re over a million, it’s like four to six of your revenue, not of your profit. These are ballpark numbers, can’t quote me. Yes, of course, some sell for 9 or 10. If you’re declining, you sell for less.

That’s great for us, because we’re makers and builders. It means even if our project doesn’t turn into everything we want, there’s still value there. I think they’re still going up, too, by the way. There are a lot of buyers, there’s a lot of money floating around, and there are only so many of us. There are only so many people making these things, doing a good job and even getting to $5000 even, the funnel narrows.

There is a dearth of those types of businesses, which means the supply and demand is a seller’s market in a sense. That is why these prices keep going up, which I think is good. I think it’s good for the ecosystem. I’m glad it’s made a little more official. It’s like brokers made it a little more official.

Yes, they take a cut and yeah, they have a big buyer list. Are they on the buyer side or the seller side? I hear all these arguments. I hear you but we are better off today than we were 10 years ago. Certainly more than 15 years ago.

Derrick: Well said.

Rob: All right, sir. Folks want to keep up with you. You are @derrickreimer on Twitter and of course, savvycal.com. If they want to see one of the nicest SaaS homepages on the internet, how do you do it? Every time you do it, I’m like this guy is unreal. We’ve known each other a long time and you never cease to amaze me with this whole design stuff, dude.

Derrick: I appreciate it.

Rob: All right, man. Thanks for coming on.

Derrick: Thanks for having me.

Rob: Thanks for listening again this week. Thanks for coming back every week. I’m trying to be really mindful of putting out content that I think is varied. That hopefully keeps you entertained and interested in wanting to hear the next episode. So until I’m back in your ears again next Tuesday morning, hope you have a great week pushing your business forward.