This episode is part two in a two-part conversation. If you haven’t already, listen to Part 1 first.
This week is the second part of a conversation between Rob and Jordan Gal, the founder of CartHook. In the episode, Rob and Jordan dig into the 4th, 5th and 6th stages of SaaS growth and compare their journeys 1:1 between growing Drip and growing CartHook. They come across several parallels between their journeys, as well as some differences. This episode is part two in a two-part conversation.
Jordan started CartHook as cart abandonment software and later pivoted into a checkout replacement solution for Shopify. He has been on the podcast several times answering listener questions and has spoken at a handful of MicroConfs. He is also the co-host of the Bootstrapped Web podcast.
Every time we come up against the hill and then climb it and get to the top, when we look outward, we see so much more. So, the opportunity just keeps getting bigger the further we go. We’re not even close. We’re just barely getting started.
– Jordan Gal
What we discuss with Jordan Gal
- 1:10 Rob’s experience with Stage 4: Escape Velocity
- 4:35 Jordan Gal’s experience with Stage 4: Escape Velocity
- 9:06 Parallels between Drip & CartHook’s journeys
- 9:50 Jordon on hitting limitations and looking beyond money
- 15:27 A fast-growing business isn’t profitable
- 17:26 Rob’s experience with Stage 5: Scale
- 21:54 Jordan’s experience with Stage 5: Scale
- 25:10 Stage 6: Company Building
- 27:39 The range of skills founders need when building a startup
- 30:18 Jordan Gal on the future of CartHook
Links from the show:
- Bootstrapped Web
- Jordan Gal | Twitter
- [Watch] Two Years in the SaaS Trenches – Jordan Gal | MicroConf Starter 2017
- [Listen] “We Went from Hundreds of Free Trials to a Few Dozen…On Purpose” with Jordan Gal | Episode 476
How can I support the podcast?
If you enjoyed this episode with Jordal Gal, let him know by clicking on the link below and sending him a quick shout out on Twitter:
Rob: Welcome to the special bonus part two episode of Startups for the Rest of Us, this week. If you haven’t heard the episode that came out on Tuesday, Jordan Gal and I got into such a good conversation, we ran really long. I just let it go. I didn’t want to cut it off because we were talking through our journeys. I wanted to cover the first six stages of SaaS growth. It took us longer than I thought it would to get through everything, given the anecdotes and deep-diving into what it looked like to grow Drip and CartHook.
This episode covers the final stages of SaaS growth that we didn’t have time to cover in part one. If you haven’t already listened to part one, I would highly recommend doing that so you have the context as we finish up our conversation with Jordan Gal of CartHook.
Stage four, I’m calling escape philosophy. This is where you have product-market fit and you’ve discovered at least one, maybe two, repeatable channels that are driving leads. You’re converting. You have repeatable sustained growth. Maybe that growth rate is increasing month-to-month. Maybe it just fits $3000–$5000 a month.
If you haven’t raised the Series A, it doesn’t take that much time growing it to $5000 a month to build a hell of a business. For me, I put escape philosophy. It was for about $25,000 MRR up to about $80,000 MRR. It’s probably about $1 million when I think about it. Maybe three of three. During that time, we’ve already done some integrations, but we realized they were working really well. The more integrations we build, not only did we drive traffic, but we were able to retain customers more because they would link them up and there’s just a lot of value created. We did quite a bit of content with some success. It was enough success to keep doing it but it was not the main driver of growth. There was an ROI there. We did some pay-per-click and it worked.
I was doing a ton of podcasting, public speaking, and that was raising it. It was hard to measure but it just continued to have Drip in the conversation. They used to say Infusionsoft and Ontraport as the lower-end marketing automation because I ran thousands a month. Soon, I wanted Drip to be the number three or number two, frankly, just to be the other one that was mentioned in all the blog posts and in all the conversations.
I started hearing it on podcasts and seeing it on blogs with people I’ve never met, never talked to, didn’t reach out to, to say hey, should you mention this? It just started getting on people’s radar because enough people were using it. We also have a ‘Powered by Drip’ link that contributed during that time. I was doing more outreach to influencers and friends who I knew. We were doing cross-promotion and stuff.
It was a bunch of things. There was not one thing that worked amazingly for us. There were about probably two that drove half of our trials in any given month and three to probably grow 75% or 80%. During that time, we grew to a headcount of five people in total. It was me and Derrick, then we had a guy doing support, and another developer. They’re our first customer success.
A person, Ana Jacobs, who many of you know from MicroConf, she’s been in MicroConf circles. She was in Fresno and she was doing essentially marketing work and agency and really wanted to get into products. She was an early game-changer for us because I was doing all the sales demos and trying to do onboarding calls. I’m just not good at that. You’ve got to know your strengths and that’s not my strength at all. She was able to take that off my plate. Not only did I think our conversion rate went up but we’re able to handle bigger customers who wanted someone to hand-hold them.
At a certain point, I started saying I’m just not going to do these anymore. Although Drip’s starting price was $50 a month, we have people approaching us like hey, I remember bringing a list over and we’ll pay you $500-$800 a month. That’s substantial growth for an app that’s doing $40,000–$50,000 a month. The fact that we were able to service them, work with them, and do the extra that they want was a big transition for us during this time.
Still total chaos in terms of the business. I was starting to burn out, in all honesty. I made personal mental health mistakes in terms of just not hiring more out. Everyone was doing their job in terms of building products, onboarding customers, and anything else I took on. I shouldn’t have done that. It seemed like the right decision at that time to keep the business moving forward. I was trying to maximize growth. In fact, I maximize my personal unhappiness because I was doing a bunch of tasks that I didn’t want to do.
That was my escape philosophy phase. Really, your escape philosophy was more with the second product, what CartHook is now. You listed it as a $20,000–$80,000. I think we’re actually in a similar range of thinking about these stages.
Jordan: Yes. We broke every rule. We did not do what I would suggest anyone do. We just built an isolation and we just launched. We fully went the ‘build it and they will come’ route and it just happened to work. This stage for us was, again, a huge success and so much pain.
I’m looking at our ProfitWell graph from all time. It was a theme for us where we have a few months of incredibly fast growth, then sustained period of no growth, and then forcing our way out of it again. The reason it happened to us, it’s the same thing that happened in this phase from $20,000–$80,000, we got the product right. That’s what people wanted. That guest at a customizable check I would upsell that worked with Shopify and allows you to do all this marketing stuff, that’s what the market wanted.
As soon as we released it, the word of mouth was huge and we got overwhelmed with demands. We did one thing that was really, really, important for the whole trajectory of the business as soon as we released it and got too much demand. In the first 30 days, we had, let’s call it 100 or 200 sign-ups. It was $100 a month. We were like this. We found the right thing, but the product wasn’t quite ready yet. After that first month, it was just total chaos. We couldn’t keep up. We couldn’t onboard people. We didn’t even know how to support our own product. What we did, we decided we need to slow it down.
How do you slow down demand? We did it in two ways. We first said you have to do a demo. You got to talk to me. I want to understand who you are or what you’re trying to do and build a relationship. The second thing we did was we tripled the price. We went from $97 a month to $300 a month. We assumed those two things would lead to slower demands. No such thing happened. It just stayed exactly the same, which is where we realized okay, we mispriced the product. Thank God we realized it in 3X the price, and then I just went to work just doing one or two demos every day for forever.
Those demos are really important, obviously, to hear what people wanted but also for the psychology of the team. It was just still the four of us at this point. We eventually hired a few more. We ended up with a team of six or eight towards the end of this phase. In the beginning, it was just the four of us. The motivation we got from my conversations was wild. People were like, I cannot believe you built this. This is exactly what I want. We just heard a variation of that over and over and over. That gave us the motivation to just keep going.
The problem was that the product was just not good enough yet. A checkout product, you can’t be 75% good. If you do anything wrong, you cost people money. We went through this period of growth despite the product not being good enough which just meant a lot of very, very, frustrated customers. That just gets you after a while.
For me, mentally, in this period, I had a really rough time because I’ve basically gone two years of working on this product, took this huge risk, took money from friends and family, then from my point of view, I got it right. I found the right product at the right time for the right market which is rare enough, and then the tech just couldn’t satisfy it.
The tension within the team was tough. The tension with the customers was tough. We just kept growing. We got to around $80,000 in this phase. I’m supposed to be happy, right? I just went $0–$5000 in one year, $5–$20,000 in another year, then $20,000–$80,000 in four months. I’m supposed to be happy. I was anything but happy. It was mentally very difficult. As we brought in new employees, they just entered a world of pain. If you’re trying to support people, trying to help people get onboarded, everything we were doing was just filled with pain, but we knew we were on to the right thing. That just helped us get through it. It was not pretty.
Rob: Yeah. You effectively caught lightning in a bottle. You were early to that space of this replacing the checkout in Shopify. Again, it’s being prepared but getting a little lucky to have been at that place right at the right time and done that because if you have done it a year later, the window is over. You couldn’t do it.
It’s interesting to hear about our journeys. The parallels and then the not parallels. Drip was essentially entering a completely crowded market and trying to build a less expensive, easier to use version of these clunky, expensive tools that were generally not loved. That was a very different approach than what you took with CartHook which was I see an opportunity, I need to shoot this gap and get there right as this opens up. You’re being early.
I had a talk called The Unfair Advantages of Building a SaaS. One of them is being early. In this case, you were early. It was because you were there. Outsiders couldn’t have known that this opportunity was available. That’s the thing. Doing things in public, creating opportunities.
Jordan: Yeah, that’s right. I’m curious to hear from your side. At this stage for me is when I started to hit some real limitations in my experience. When it was a group of four of us, it was pretty straightforward, Guys, let’s make some money together. Let’s do this. Let’s change our lives by building this thing together.
Once we started hiring people, that got tested. I remember, specifically, one conversation that Ben pulled me aside and said look, man. You’re our leader. We need you to go beyond money. Our employees here don’t stand to make millions of dollars if we sell this thing. They need to work for something more than just that. That conversation with Ben I appreciate and think about all the time. That was a real turning point on me needing to look beyond money and create something of a mission, something more important.
I had a challenge because I am very against the ‘change the world, make the world a better place,’ […]. I didn’t want to become a phony and say that that type of thing is our mission when I didn’t believe it. I needed to figure out a way to authentically create a mission for the company that I felt was honest and sincere. Did you encounter something like that as you started to grow the team?
Rob: Not in that way. I think it’s because, from the start, building Drip wasn’t about making money. I never said that. It was more about building a really cool product. There was a lifestyle component to it, but by the time we have three, four, five people, it became, we are truly innovating in this space and building an amazing product for people who don’t like these other alternatives. Isn’t that cool? We are makers and we want to have a very high standard of building an amazingly easy-to-use product that is super powerful for people.
All of our team members, including me, loved the product. We were enamored with this power that we could have. When we looked around our competitors, we were like, that product’s like a toy compared to Drip. That product is super hard to use and expensive. We genuinely believe that we were not making the world a better place but we were email marketing and marketing automation just more accessible. I think at one point I said we’re trying to bring marketing automation to the masses, which is a little bit manifesto-ish and highfalutin. It sounds, in retrospect, whatever, but it really was.
That was something that our team was just onboard with. We talked about that during the interview process. As everyone comes in, it’s like look, this is Drip. You’ve heard about it. You’ve seen it. It’s this product that’s genuinely helping marketers do better things and be more relevant. The codebase is great and the product is easy to use. It’s powerful. It was just all of that. We were proud of it. There was a sense of pride among the Drip employees that I think, partially, I was really proud.
Derrick and I were really proud of what we built but also because it was a damn good product. I think from the start, I didn’t do it intentionally, right? It’s how we think about it. Derrick and I are makers. You know why I wanted to make money? It’s so I can make whatever I want to do, so I have the freedom to do that. Money has never been an end to me. It was the freedom that was the end. I think I accidentally stumbled into, oh, building a great product motivates other people as well or at least the people who should be on that bus.
Jordan: Yeah, I admire that and I think it’s fantastic. That was not my journey. I went into it trying to be clever. How do I basically make $50,000 a month for myself while not doing any work type of thing? It’s not surprising that you went in with that mindset and didn’t have to figure it out in the middle.
For me, it had to get figured out along the way. It’s only recently, over the past two years, that I fell in love with what we do. It took longer to get there. Where we found authenticity is in helping other entrepreneurs. That’s where we get our pride. As opposed to, we’re so proud of this product. We’re very proud of the results. We see these companies come in and just become more successful because of our product. Then, they hire more people. Then, they grow.
What we like to look at is we like to look at the individual level and not the business level. The people running the company, the people working at the company, they have better lives because we help them find more success. It took some time for the clouds to part and to have clarity on that.
Rob: That’s what it became for us was as well, actually. Users would come in from another tool. We call them Infusionsoft refugees where they were coming and try to escape this tool that they didn’t like. They would be so over the moon with it. They would tell us which is so much easier, or this is changing my business. That did become our huge part of motivation, it wasn’t the results. I’m glad you called that out. I think it started with, oh, didn’t we build a great product? Then, it became, oh, aren’t we helping entrepreneurs get more leads or do this easier?
Another memory I have from this escape philosophy phase was up until that $25,000–$80,000 MRR, I kept thinking we’re going to be profitable soon. We would be profitable. We’d break even then we’d grow. Then, I’d hire. Then, we’d grow. Then, I’d hire. We were never very rarely losing much money. Never raised funding. I was pulling some money off the HitTail for a while. At a certain point, Drip was totally sustainable.
I kept thinking much like you, like when is the time when I can start making money at this business? It comes down to this thing that says something that I said at several MicroConf talks of a fast-growing business isn’t really profitable. If you do want to make money out of it, you can. You’re just going to slow the growth.
Jordan: Yes. That is one of the absolute, most critical conversations in the entire experience of building this company. It was the conversation I had with you where I was not trying to be a jerk but it could’ve been viewed as a jerk question. I think we were at $10,000 MRR and you were over $100,000. I was like, you must be profitable. What are you possibly doing at that stage if you’re not pulling profit at $100,000? I could not even fathom it. I couldn’t imagine.
That’s what you said to me. You said look, when you get here, you will have a trade-off decision. If you starve it too early, you’re going to kill the whole trajectory of it. You might also exhaust your team because you won’t be investing in hiring to keep up with the growth. It might sound like an easy decision to be profitable but wait until you get here and then let me know. You were right and then another $100,000.
Rob: Oh, man. We should couch this whole thing of CartHook and Drip are very successful apps in the grand scheme of things. In terms of so few products making it to product-market fit, even fewer make it to a million ARR, fewer make it to multiple millions of ARR. I don’t want to normalize it and say everyone should travel the same journey that you and I did or anything like that.
I do want people to know that if you grow and you do grow fairly quickly in a space, you do have success, I think it’s good to be aware of these stages so that as you enter them, like when you hit product-market fit, it’s like okay, now I should be thinking about repeatable marketing channels. At a certain point, you find one or two and it’s like okay, mental check. I’m in an escape philosophy phase. What did I say about this? It’s going to be chaotic. It’s this and that. That’s really why I wanted to talk through this to get people set. Again, it’s not going to be for every app. It’s $20,000–$80,000. It’s this and that. I think certain apps grow faster and slower, obviously, but I do think that these stages can be helpful as a mental model.
That actually brings us to stage five which I’m calling scale. For Drip, that was $80,000. It was about a million, $83,300 and up. For us, we went into a million, and then into multiple millions. We have 10 people. We were acquired. I stuck around for a year-and-a-half. By the time I left, I believed there were about 60 people working on Drip under the lead pages umbrella. We weren’t independent of the whole scale phase. We were acquired basically mid-scale, I would say.
Part of the early scale was hiring more people, which again, was that decision, that tradeoff of we’re not going to be profitable. We’re still growing. I think this market’s very big. Part of that decision was I was burning out pretty bad but also do we raise money? Or do we sell?
I got five potential acquirers contacting us in a span of about 15 months. As you do when you get on the radar and you built this many brands, two emails a month, three emails a month, from people who said we will fund you. Sometimes, it was junior venture capitalist prospecting and stuff. Other times, it was serious people who I knew had the money and really wanted to invest in a fast-growing SaaS app.
That was a big decision for us as to whether to get acquired and take the chips off the table or whether to basically raise a round, double down, and be like all right, we’re going to do this for two, three, four more years before we think about next steps.
Jordan: We’ve talked about the corporate and the financing side of things a lot through this journey. I think you did things exactly right on the corporate position you are in. Like the amount of equity you had, you hadn’t raised money. You got to this point and then the risk-reward calculations of selling or not, I think you did the right thing. You don’t know what’s going to happen in the future and you built something that’s growing really fast, is very attractive, and you don’t need $100 million acquisition in order for it to be a success.
If you raised a bunch of money, if you’re at the exact same revenue that you were at but you had raised $3 million, you’re in a completely different world. You limit your option set when you take money early. I’ve always thought about that. What we’ve always looked at is how do we raise just enough to get going but to keep those relatively low acquisition offers into play? It’s just much more likely to get acquired for under $50 million than it is to get acquired for over $50 million.
Rob: Yeah. It was a calculated gamble. Derrick and I have talked about it since then over beers. I asked him—this was probably six or eight months after the acquisition, we’re having beers, and we’re still both working at Drip—do you ever wake up and regret it that we sold? He said never once. I said me neither. I have never woken up in a day.
I think part of that is the acquisition took 13 months. We have a hell of a long time to think about it. Derrick and I were very cautious. We think things through. We’re not flipping. It was not an impulse decision. By the time we got to that point, it was like no, we really want this to happen. The harder part would have been if we got there and that hadn’t happened because we were bought into it at that point.
I’ve heard you talking on your podcast about taking some chips off the table about the big raise from the clubhouse app and the founders each took a million off the table, I believe. Some people think oh my gosh, that’s catastrophic. How can you do that? It’s a pre-launch app so I’m like wow. I can’t even believe it.
Aside from that, taking enough chips off the table, I was like look, my whole net worth, I’m worth millions and millions of dollars in completely illiquid private company stock. I have whatever I have, $50,000 in the bank, and I had a couple of $100,000 in a retirement account. That’s my net worth right now and I’m concerned. There was a huge stock market drop and SaaS valuations were cut in half as we’re talking about the acquisitions. Recessions, competitors were just jumping at our heels. There was all this stuff going on that I was thinking, it was exactly that type of press. Let’s not talk it through the podcast before but it really is.
It’s like do I take some chips off the table here or do I double down, keep going, and see what happens?” It would be different for everyone, but I do think having a small win early on and getting to some money that is in your bank account where you can then take bigger risks like, I’m now in a position where I can just take bigger risks. I can grow a TinySeed which is not going to really pay me much for years. I can do that now because of this.
Stage five for Drip, as I’ve said, was scale. It was $80,000 and up to acquisition. For you, you named it out about $80,000–$200,000 of MRR. You want to talk through what your experience was like getting there?
Jordan: Yes. This was the opposite. Book cased by failure first and then really big success towards the end of the stage. When we got to $80,000 with all that pain, we came to the realization of okay, you know what we’re going to have to do? We’re going to have to break another cardinal sin. We’re going to have to rewrite the app. And we did.
Rock, who is now the CTO, is probably the CTO right now because he’s successfully pulled off a rewrite of an app with hundreds of customers and hundreds of thousands of dollars a day in payment processing. We got stuck at $80,000. We got stuck at $80,000 for months and the churn is wild. Churn was like 15% per month. Just growing and losing $20,000 in both directions every month. Just adding $20,000 in MRR and losing $20,000 in MRR. Just over and over and over. That’s why that stage was so exhausting.
We came to the conclusion that we had to rewrite it. It has to be better. We have to take the lessons learned, all the mistakes we made, and just make a better version of it. That’s what we did and then it worked. They pulled it off between Ben, […], and Rock. They pulled it off. As soon as we released version 2, the thing just popped. We went from $80,000–$200,000 again in just a handful of months. That stage was really okay.
Let’s build out the team, let’s build out a support team, a success team, QA, different engineering leads. Let’s get this thing ready so we can actually handle what we have in front of us. Let’s get marketing so I’m not doing it. Let’s get success so I can stop talking to customers. All these different things like building up the company. It was the rewrite and the growth from that is what allowed us to hire about 20 people. That’s when everything just became much more promising. That’s what I look at as that stage for us. Then, at the end of the stage, we got stuck around $200,000. That’s kind of what led us to the next phase.
Rob: I’m calling this the sixth stage of SaaS growth. Obviously, there are many more because we’re going to wrap this up around a few million single-digit ARR. Getting to $20 million, $50 million, $100 million. Of course, there are stages you get to 100 employees, 500, then 1000. We’re not going to cover those because we haven’t done them. After the scale phase, you specifically called out that there’s this transition of all right, we’re scaling but north of about $200,000 at least for you, given the timing, it became company-building where you have to, as a CEO, as a founder, your mindset has to shift. Talk us through what that phase has been, what it feels like.
Jordan: Yes. We built a team in that stage five, the $80,000–$200,000, but we really didn’t build the company infrastructure. We hired the people that we needed but when someone got hired, it was, here’s a laptop. Here’s someone else that does the job similar to yours. I wish you the best of luck. That was effectively our employee onboarding.
The next stage, the company-building stage is when we really have to figure out a lot more around process, a lot more around org structure, reporting structures, where the lines are in the company of who’s responsible for what, and under what circumstance. I needed a lot of help with that. I had never done it before. We hired people, coaches, actually, thanks to an intro from you, who has been hugely helpful (and still is). That’s the phase that we’re in now. We are well over $200,000 in MRR. It feels like we’re just now really starting to set the foundation for being able to grow to 50 and 100 employees. Before we do that, we really need to get our act together in many ways.
It feels like for a very long time, survival was just the only real goal. Now, we’re transitioning into, how do we make this a great place to work? How do we make the mission something that’s clear, that’s everyone’s working towards? How do we attract great talents? How do we keep the employees happy so that they don’t get bored of them wanting to go on to their next challenge? That’s pretty far removed from me convincing a potential customer that they should use our product because of X, Y, and Z. It’s just a new skill set that I’m being forced to learn.
What I will say is, I started off at the other end cynical. How do I make a repeatable revenue? This process of going from that to building a real company, by far the most fulfilling experience has just been the other people involved. Developing other people, watching them succeed, watching their confidence grow once they really settle in.
I talked about this week, we signed our biggest customer ever. I didn’t talk to them. It just makes me really proud and happy about what we’ve done, what we’ve built, and just watching the team kind of start to turn into a higher caliber version of ourselves. That feels like the stage we’re in now. It’s tough to tell what comes next. I’m sure it’ll be crazy because it’s been that way the whole way. This stage right now feels pretty amazing.
When the crisis hits, we just have the ability to take care of people the way we have been able to, it feels amazing. It’s much more fulfilling than starting out and saying let’s make money together. That part of it has been great.
Rob: Building a startup changes you for the better, doesn’t it?
Rob: Yeah. You know what, with Drip as we talked through these stages, just the range of skill sets that you need if you’re going to start a company as a founder to do the customer development, to convince a developer to help you or to pay them or to scrap and cold email, to do a launch, and then to grow to $20,000. Then, to start hiring. Then, hire more. Then, hire managers who hire managers. Then, being at a company-building. What a broad range of skill sets that you have to learn on the fly or makeup as you go along or what have you.
This is a reason back in the day when venture capitalists would fund a company. The founder would grow it to a certain amount. Then, they’d oust the founder. They kind of have a clause. Either the VCs owned enough or they have a clause and it’s like hey, we can boot you. Oftentimes, the founder isn’t the best person to run a $100 million company because a $100 million company with X thousand employees is a very different skill set than what you and I have talked about today.
Personally (I’ll speak for myself), I don’t want to run a team of even 30 people. That doesn’t sound fun to me. Certainly, 50, 100, 1000, people. Maybe I don’t understand what that requires, but it sounds like a burden. It’s partially because my goal was never to build companies. My goal was never to make a bunch of money. It really was to achieve freedom so I can work on interesting problems, interesting projects, and make things. It all comes from making. When I roll that back, it’s like if I want to do that, then I need to make money. If I want to make money, I think I’m going to use my skill set and start a company.
Companies were a means to an end and have been. I, of course, loved talking about it or I wouldn’t have done 500 episodes of this. I’m curious, from your perspective, you’re going to come back on the podcast and you’re going to talk to us about stages seven and eight. Who knows what they’ll be. Do you see yourself running a team? You think you could be happy running a team of 50? 100?
Jordan: Yes. I think I could. I think that’s what I want. I remember when we started out. I remember looking at the Inc. 500 magazine every year as I grew up. The only thing I paid attention to was the ratio of revenue to employees. I didn’t care about the total revenue. I wanted the ratio. I wanted the revenue per employee because looking at a company that made $100 million but had 1000 employees, I looked at that and said that just sounds miserable.
If a company was making $20 million with eight employees, I thought to myself that’s what I want. I want efficiency, I want a small team. I want everyone to be in a small tight community. I still want that efficiency but I think I wanted it to be a lot bigger.
One of the things we’ve said is that every time we come up against the hill, then climb it, and get to the top of that hill, when we look outward, we see so much more. The opportunity just keeps getting bigger the further we go. We’re not even close. We’re just barely getting started. The more we grow, the more it feels that way.
Right now, if an amazing acquisition ever came through, something that I just could not say no to, I am 100% certain that I would regret selling because we’re just starting.
Rob: Just starting, man. I love it. I’m serious about you coming back to talk. We’ve got to figure out what’s after company-building.
Jordan: There’s not too much drama. That’s all I ask.
Rob: I love this conversation. This may be the longest episode of the Startups for the Rest of Us ever. I couldn’t cut it off. I feel like what we’re talking through, I think it’s insanely valuable. It certainly was entertaining for me to listen to your stories and reliving them with you.
Jordan: First, thank you for guiding along. Sorry for making it long. Just 2X the speed. I am proud of us that we stayed away from the darkness.
Jordan: There’s a lot of darkness that we just didn’t touch on and that’s always there. There’s a skill in ignoring that darkness and moving forward that we exemplified in this podcast.
Rob: There are a whole nother hour and 10-minute episode of us just talking about the worst part of each of these stages. That’s something. Maybe that’ll be in your memoir.
Jordan: Thanks for having me on, man. I really appreciate it.
Rob: Absolutely. If folks want to keep up with you, you’re @jordangal on Twitter. Of course, carthook.com, if they want to check out what you’re working on. Bootstrapped Web, that’s the podcast I tune into every week. They can hear you on your journey, man. Thanks again.
Thanks again for joining us. Again, to recap these first six stages of SaaS growth are prelaunch, post-launch/pre-product-market fit, product-market fit, stage four’s escape philosophy, stage five is scale, and stage six is company-building.
I appreciate you joining me twice this week. I look forward to seeing you next Tuesday for episode 500. Talk to you then.
In this episode of Startups For The Rest Of Us, Rob and Mike answer a number of listener questions, the topics include scaling a software product, raising prices, and when to use a CRM.
Items mentioned in this episode:
- AppSumo-MicroConf Giveaway
- MicroConf Growth Edition
- MicroConf Starter Edition
Rob:In this episode of Startups for the Rest of Us, Mike and I talk about scaling a software product, raising prices, when to consider CRM and more listener questions. This is Startups for the Rest of Us Episode 427.
Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome at building, launching, and growing software products. Whether you’ve built your first product, or you’re just thinking about it, I’m Rob. We’re here to share our experiences to help you avoid the same mistakes we made. What’s the word this week, sir?
Mike: I’m going to need some Advil for that one. I’ve got some exciting news to share with the listeners this week. In the past, we’ve talked about having some podcast sponsors on and I wanted to talk about one that I arranged with AppSumo very recently. AppSumo is offering an all-expense paid trip to MicroConf this year, and it’s not just one or the other; it’s to both. We’re in a contest in cooperation with them. It’s going to be starting as the date of this podcast episode comes out.
You can apply to that. We’ll link to it up in the show notes. You go over the webpage, enter in your email address and you’ll be entered into that contest. There’s ways you can get additional entries into the contest by sharing on social media and getting other people to submit their email addresses. For each person who enters based on your promo code that you give them, then you will get an additional entry into the contest. As I said, we’ll link that up in the show notes, but I think it’s a really awesome way for AppSumo to help support the community and the podcast but also to just help bootstrapped entrepreneurs get to MicroConf and network with other entrepreneurs.
Rob:Is it one person that wins tickets to both or is it two separate giveaways?
Mike: It’s one person who’s going to win tickets to both and then they have some money that they’re setting aside to also help cover the travel costs for it.
Rob:They’ll cover airfare and hotel then, for folks, within reason? There’s some cap on it. You can’t fly first-class from Australia or something.
Mike: No, as nice as that might be.
Rob:That’s super cool, man. I’d imagine someone listening might think, “I already bought my ticket to MicroConf,” or, “I might buy my ticket in the next week but I’m going to hold off for this giveaway.” What would you say to those folks?
Mike: That actually is covered, so if you have already purchased your ticket or you purchased one between now and the other contest, the contest is going to until, I think, February 11th. That’s basically four weeks from today’s episode. If you are selected as the winner, then you will be refunded whatever you’ve paid for your ticket so far. If you’ve bought one ticket or you’ve bought a ticket to both of them, then both of them get refunded. I would assume that if you’ve already booked your airfare and stuff, there’d just be a reimbursement that goes along with that.
Rob:Sure. Super cool. This is our first podcast sponsorship.
Mike: Yeah, definitely. I just want to say thanks to the people who are at AppSumo, and we’ll link it up in the show notes. You can go up there and enter into the contest. Hopefully, we’ll see you in Vegas.
Rob:Sounds good. On my end, Tiny Seed Applications open on January 18th. We announced that this week. Tiny Seed is, of course, the first startup accelerator designed for people who would traditionally bootstrap, and it’s my next act after Drip. I’ve already been talking to some founders, either who I know personally or who introduced themselves to me, but we’re definitely going to open the floodgates for about six weeks, starting January 18th. That should be an interesting process. tinyseed.com, if you have questions about that, if you have an idea or an app that’s already launched. We’d love to hear from you.
Mike: That’s cool. You’re going to do applications for six weeks, and then how long do you think it’s going to take to go through those applications? Do you think it’s going to be a week or five weeks?
Rob:We’ll start right away. This is my full-time thing that I’m diving into. The moment we start getting applications, I will start sifting through them. It won’t be a full six weeks of applications that we’ll have to go through at the end because I’m not the sole person making decisions. I don’t know. I think I probably need to think more about an exact timeframe, but it’s not as if we have to announce or we don’t have to offer everyone a spot the same day.
This is not Y Combinator where they have classes of 150 or something. It’ll be a small class of 10 to 15, and I envision it as, “Hey, if you’re fit, we want to invite you to be part of it,” and then people accept or don’t, and then we move onto the next one. I think we’ll be doing onesie-twosies throughout that time, but I’d love to have everybody nailed down certainly before MicroConf, which is ambitious, because that’s only two and a half months away now, but it would just be a nice milestone to hit.
Mike: That’s awesome. Anything else?
Rob:Have you updated your Mac OS to whatever the latest one is called but it has dark mode?
Mike: I have not. I’ve heard of that. Isn’t there something like a Mac app called f.lux or something like that, but it also darkens your screen? Is it similar to that?
Rob:It’s different than that. I just looked and it’s Mojave. It’s 10.14.2. It’s different than f.lux. F.lux would detect your time zone and then, as it got later into the evening, it would remove the blue light from your screen so that it would try not to affect your sleep. That actually sounds–that would be a great name for a great function of dark mode, but dark mode is just a dark theme for the entire OS, like the messages, the iOS messenger thing, the text message app. It’s all dark. It’s all greys and blacks, and the sidebars, and the top and the background are all dark.
It’s interesting. I’m using it, and I think that I like it better. I grew up programming on an Apple IIe, which is black background and green text. When I used to code all the time, I would flip my background of my editor. Sometimes, I’d go white, but, more often than not, probably 70% to 80% of the time, I would just have a black background all the time. That’s like Adam. The default background is black with white text on it because it’s just easier on your eyes.
It’s so far so good. I’m only two days into dark mode, but if you haven’t checked it out, I’d recommend giving it a whirl. I also imagine it would help folks with migraines. I know that some folks, the light from the screen, if you have a lot of white, it can give you migraines. Drip Workflows has night mode, and that was because one of our designers gets migraines, and he just decided to have this. It’s a dark mode for the Workflow Builder.
Mike: Interesting. Yeah, I’ve never really been a fan of those inverted dark modes or inverted theme colors and things like that, but I’ve never really tried it a whole lot either. Maybe if I give it a couple of days to settle in, I could get used to it, but I don’t know.
Rob:That’s the thing, yeah. It definitely takes getting used to because if you’ve used a computer with a white background for 40 to 50 years like you have…
Mike: Hey, you are older than me.
Rob:I know I am.
Mike: I’m just going to point that out.
Rob:Cool. Are you ready to dive into some questions?
Mike: Yeah, absolutely.
Rob:All right. Our first question is a voice mail. Voice mails always rise to the top of the stack. I think, actually, our first two questions are voice mails today, but let’s roll into this one.
Beckham: Hi, Rob and Mike. My name’s Beckham. I’m contacting you from Sligo in the northwest of Ireland. I’m from a company called Campus Connect. We’re avid listeners. We really enjoy the podcast, and you have an uncanny ability to cover stuff that’s happening at the time so keep up the good work. Campus Connect is a mobile app service for universities. What we do is we create an instance of the service for the university recruitment team that pushes it out to their incoming students.
It’s an onboarding service so the students can register. They can connect with their peers and they can connect with somebody on campus. We’re three years trading and we’ve grown to approximately 12,000 MRR, and things have been going reasonably well. A question that we’ve had–I guess an issue that we’ve been having is really around scale although we’ve managed to get at this point to struggle to really build on this.
Creating a new instance feed to university, obviously, is quite resource-intensive, and when we create each instances, often, in customization, they’re looking for different fields, different branding, different upselling and so on, and other few managing services. The universities we work with, they’re also using it for their students that are going out, going abroad, so it’s really for incoming and outgoing students at the moment. We feel there’s an opportunity to develop that into a universal platform and to move all our existing clients onto one central platform where we can connect them up.
At the moment, it’s quite siloed and it’s obviously difficult to scale. We have management. We’ve spoken to our clients about it. They’re interested in the idea but, obviously, the next steps are quite challenging. I’d love to get your guys’ thoughts on this. What do you think, how you would approach it? That’d be great. Keep up the good work. Thanks.
Rob:That’s a tough question, huh, Mike? They’ve made it to 12K MRR, which is nothing to sneeze at, but certainly a big challenge ahead of them. What are your thoughts on this? Do you get what he’s saying, like they do almost on-premise for each instance and then they even do some customizations to some of them, it sounds like, and they want to centralize and basically go with a more true SaaS model or a centralized cloud-based solution, it sounds like.
Mike: Yeah, that was actually a part that I missed. I didn’t realize that they do on-premise for them. I thought that they hosted each individual version of it, and that was mainly because they do customizations to each of them and the platform itself doesn’t really support customizations or a multi-tenant model, so to speak. I wasn’t sure whether that was the direction that they wanted to go or maybe you have a little insight on specifics there. Did I miss something?
Rob:I just listened back to his piece, and all he said is they create new instance for each one. I think you’re right in that it’s not on-premise; it is hosted on Campus Connect’s servers–let’s go with that assumption–but that they copy a new whole instance of it, make some customizations, probably has independent databases, I’d imagine, for each one. There’s the multi-tenancy thing that they’ll have to solve if they haven’t built that in already, which is just the ability to host multiple customers in a single database.
That’s a solved problem. That’s pretty much plug-and-chug. There’s not much risk with that, I’ll say, in terms of implementation, but there obviously are some other things that I think are going to be more difficult than just making multi-tenant.
Mike: Yeah. Taking an application from single-tenant to multi-tenant in and of itself is kind of a pain in the neck. It’s a hard problem, but I would say it’s generally solved, like there’s a lot of guidance out there that you could find fairly easily that would tell you the things to look out for and the things to do in that case. I think that, from a scalability standpoint, I don’t know if you’d want to go towards a model where it is completely multi-tenant with everybody all in one instance.
Part of that is just, one, for scalability because there’s going to be times where certain schools are repping up and directing a lot of people to the site, and then there’s other times where it’s going to be slow and, hopefully, they won’t all overlap. If they did, you wouldn’t want everybody all on one instance of it so that you could slice it across. Let’s say maybe you have 10 instances of it and 10 customers on each, for example. That’s a lot easier to manage than 100 different instances of it, and that’s probably the way that I would go in that particular case just to at least allow you a little bit more flexibility in terms of the redundancy of the whole system.
Rob:I want to break in right there just because I think this is an interesting topic. See, I wouldn’t do that because, to me, that’s pretty mature sharding. Sharding is where you can shard across single tables or database instances. There’s a bunch of different ways to do it, but what you’re talking about is basically putting Customers #1 through #10 on this database and Customers #11 through #20 on this database.
Long, long, long-term if you’re Facebook or if you scale–there was a certain point where we were considering sharding Drip because we hit scale, but that was way, way down the line. I think the added complexity of trying to manage that infrastructure, unless these are really high-intensity, a lot of computing power where you do think you’re going to need to separate them, unless you think that’s going to be that case and that you’re going to need to do that, I would consider that a premature optimization.
Mike: I see what you’re saying in terms of the performance aspect of it. I’m looking at it more from a durability standpoint, like you don’t want having to reboot one server, for example. I don’t know anything about the backend infrastructure and how they do that stuff today, but you don’t want to have to reboot every single customer all at the same time if there’s a problem with one particular customer. That’s more it than anything else. The performance, I think, comes into it to some extent but, from my standpoint, I would be a little concerned about having everything all on one system where if you don’t have an automatic failover or something like that, that would probably be an issue at some point just because of the number of people that could be hitting that site.
Rob:Again, I think that that’s solvable in a different way. You basically have your main database where everyone’s on, you have a hot-swap backup that’s sitting there, constantly replicating, and then you have redundancy in every other server up the chain. If you have a queue server, then you have two of them. If you have Redis, you have two of them. Again, this is just architecture we did at Drip to make it redundant so we could reboot any server.
I don’t even remember how many frontend. By the time I left Drip, we had 20 or 30 frontend web servers and 10-15 API servers just accepting requests and then down, and down, and down. Any of them could be recycled at any time and not affect anyone. The only thing that would actually take the system down, so to speak–and even then, I believe we would still queue up incoming requests–was the database because it’s write and it’s not read. We even had a bunch of reads moved to a separate database that would stay up for that. Anyways, that’s just an architecture thing, and sharding is one way to handle that. I just don’t know how relevant that is here.
Mike: What I was thinking about was how would you migrate people to have them on a multi-tenant server? Essentially, what you’re doing is you’re taking the machines. You’re saying, “Okay, well, let’s take Customer #1 and Customer #2 and put them on the same server.” You’re going to have to do some sort of migration probably for both of them because you’re going to want to spin up a new instance in the database, for example, just so that it’s clean and you don’t have to worry about any additional croft that’s in there.
Again, that could be a mistake based on how complex the database is or how easy it is to move that stuff onto a new server because if you’re just adding tables and stuff to help support multi-tenant, then maybe you just start with one of them and you move the second customer’s data onto the first customer’s database, but it depends on what the hardware there is, too. Maybe you just take the first customer’s database and put it onto a brand-new database server and you start with that.
At some point, you may need to start making decisions about how you’re going to manage that and how you’re going to be adding more customer data onto that database server, and is a migration–are you dumping the data out and then doing a full import? How are you going to manage that replication process to get them started and how far do you go with it? As I said, maybe you do shard the database. Maybe you do have several instances. I don’t know that and I don’t think that they’re going to know that either until they get there.
Rob:When I bought HitTail, it had two shards and it had two separate databases. Yeah, I believe it was two completely separate database instances on the same SQL server. I had to merge them, or I didn’t have to, but I wanted to because it was way complex. It was keeping things in-sync. It sucked. I merged them and I had to do some gymnastics because primary keys–some of them had the same primary keys so I had to update primary keys, which then I have to update them all over the place.
Again, that migration itself is just something you need to think through, be meticulous about and do it. There is risk there, but it’s technical risk. If you get someone smart who knows what they’re doing and you plan it out, that will work. The thing that I’m much more concerned about–let me say off the bat. If Declan can make this happen and turn it into more of a centralized multi-tenant SaaS, I absolutely think that that’s the way to go.
I think that’s how they scale this business long term because having these separate instances for each customer is just going to get hard. It’s going to be a lot to manage. It’s a lot of overhead and server costs. There’s a bunch of labor that’s going to with it. Long term, that’s not how I would prefer to do it. I do think that them trying to centralize is a good move. I think the hardest part of this is going to be talking to all of the universities, getting them all on-board with it, and figuring out which customizations that they allow or disallow. The wildcard, I think, is going to be the customers who have potentially extensive customizations that you may or may not import into the centralized version of the app.
Mike: The other thing that I would think could be a huge thing is data protection and privacy and making sure you’re that separating the data between them because I don’t know for sure how much of the stuff is installed at the customer’s site versus how much they’re hosting in their instances. Are there things that the customer really can customize on the frontend or do they give them virtual machines that they install in their environment and then direct people to there with some of the customizations on?
I don’t know how that is really set up, but I know that they’re probably going to be concerned about, “If we’re migrating the data out of our environment into yours, how do we know it’s secure? How do we know that it’s not going to go back and forth between other customers? How do we know that, if you get hacked, we’re not going to suffer some major loss?” or something like that.
Rob:Yeah, I agree. I think the hard part is doing it retroactively because you could screw things up because, again, that is a solved problem. There are a lot of–how many thousands of SaaS apps have exactly the same issue of keeping data separate? They do it.
Mike: I don’t think that having it separate is the issue; I think that convincing them that they’ve already purchased and bought into one model of having it deployed and then changing how that is done is the issue. For the IT department, they may need to go through some infrastructure review through a risk analysis or something like that, and some of them may say no.
Rob:Right, and that makes sense. That’s, I think, going to be the challenge here more than anything. It’s a big undertaking, but I would encourage them to at least evaluate how many person hours and how difficult it will actually be because I feel like–do you agree that this is probably the right choice for them? I guess the better question is–we don’t have all the details, but if you were in their shoes, based on what we know about their business, would you try to centralize to a multi-tenant scenario?
Mike: Assuming that they are deploying a completely new infrastructure for each customer, I would absolutely centralize it.
Rob:Yeah, just because of the management of all that stuff is so challenging and expensive.
Mike: Right, and just having the different instances themselves. You want to centralize it as much as you can with an obvious eye towards the performance, downtime and stuff like that. Again, it’s also something you’re going to want to take slow. You’re not going to want to dump everybody all under a new set of servers all at once or even three or four. You’ll want to start with two and that’s it, and then slowly consolidate them over time.
Rob:Another thing that occurred to me is I think this will be a cost savings for Campus Connect, and so it would be quite cool if they could keep their prices the same and consolidate because I do think that their cost for providing this service will be less, but they will also have the leeway with some of them to offer discounts if needed because I’d imagine, again, that just their cost to provide this service will be cheaper if they have 10 or 20 of these universities on the same infrastructure. I think that’s another added benefit to this. I’m sure Declan’s thought of all this, but it’s just a fun thought experiment to think through. Our next question is another voicemail and it’s about how to raise your prices when you have a lack of control.
Ben: Hey, guys. I’m Ben, the founder of Code 49 from Germany, selling apps in the Atlassian Marketplace. Thanks for your great episode about Charge More. We also love to charge more–and who wouldn’t–but we are not sure how to proceed. We can only raise prices for everyone at once, and our existing customers only get exposed to the new prices after 30 to 60 days. On top of that, we can only change prices every 30 days and rarely get any feedback when a customer cancels our subscription. The question is how would you raise prices in this scenario? Which metrics would you measure to determine if the raised prices lead to more value? Thanks for your help.
Mike: I feel like this is a really tough spot because if you can only raise prices for everyone all at once and you’re not going to get any sort of results for 30 days, that sucks. If you don’t have direct access to the customers, that makes it harder to do something like this. I wonder if there’s a way to publish it as a new app inside of the Atlassian Marketplace and see if there’s a way that you could test with new customers instead of your existing ones, and then you grandfather the existing customers into your existing pricing.
I don’t know how amenable Atlassian would be to having two apps that are in there that are basically the same kind of thing. The other thing you could do is you can talk to them and say how would they go about this because it would feel to me like you can’t possibly be the only company that has run into this particular program. What does Atlassian have to say about it?
Rob:That’s exactly what I would do, is ask them. This is a crazy limitation. This reminds me of Apple App Store stuff. This is where being in App Store cuts both ways, being in the Envato Marketplace or whatever, the Google Play Store. It gives you distribution. It’s easy distribution. It’s a nice stair step, but I would never build my full-time business on these ecosystems because of these limitations that are just so painful. You can’t split-test. You don’t get your customer’s email addresses. There’s all these limitations.
I don’t know that I have a silver bullet aside from talking to Atlassian. I think his question of, “How would you raise prices in this scenario?” Very, very carefully. I would probably inch them up 10% and just see what happens. The metrics I’d look at is are you getting less new customers in that 7 or 30-day span? Did you churn higher than the previous 7 or 30 days? It’s a very blunt instrument that’s not a true split-test–a poor man’s split-test, I’ve heard this called–but I don’t really see another easy way around it when you just don’t have the control over distribution. Thanks for the question, Ben. I hope our thoughts were helpful.
Our next question is from Rohit Shetty. He asks, “At what stage of a bootstrapped company should one consider using a CRM? I have a desktop app that’s not SaaS. It’s for the data networking industry. It’s cross-platform with binaries for Windows, Mac and various Linux distributions. I use Gumroad for ecommerce, Mailchimp for email, Google Forms for surveys. Email support and follow-up is using Gmail with stars or snoozing to remind to follow up.”
“All this means is that customer data is quite fragmented and spread around. Wondering if having a CRM to bring all of this data together would be useful, or is it the organizational freak in me just wanting to have everything together, and it’s not really going to help me grow my product? If you think CRM is useful in this situation, could you suggest some? My average monthly revenue is around $1200 and has been at that level for more than a year now despite my attempts to grow it. This is a nights-and-weekends project.” Thanks, Rohit. What do you think, Mike? I don’t think CRM is what he needs. Do you?
Mike: No, I don’t think so either. It sounds like if you were having trouble with lots of customers falling through the cracks and support issues because people feel like they’re not being paid attention to, or their needs aren’t met, or you’re losing sales opportunities because you forget to follow up with them or check in with them or send them invoices and stuff like that, then I would say yes, but it doesn’t sound to me like that’s the case. It sounds to me like the data is just in a bunch of different places, and it’s kind of annoying that you don’t have a centralized location for it because it doesn’t seem to me like the MRR really justifies that as the top problem that you have.
Rob:I would agree to that. Also, CRM is really more for moving people through a process. It’s like sales-based. I don’t think of it as a repository for a software company like you. To be honest, we either use our own database. If I was running a SaaS app, it would be the multi-tenant database houses the data that you need. That’s aside from automation and Google Forms and stuff, but it would house all the financial stuff, or I used to do and still do use Drip as a central repository for a lot of data.
I would think about whether or not you want to pipe everything into Mailchimp as custom fields since you use Mailchimp for that purpose or if you want to try to get everything into segment. You could pipe data via Zapier and stuff, but, all that said, I don’t see what having this all in one place is really going to do for you. I just don’t know how that grows your business. I’m with Mike at $1200 monthly revenue, I think you have a lot of bigger fish to fry in terms of either keeping more customers, finding new ones, growing your top-of-the-funnel, whatever. I would the time into that instead of trying to consolidate what data you have.
Every business is like this. I’ll give an example. We used to use Stripe for charging for Drip, and we use Drip for the email automation, and we did use Google Forms or Typeform for some surveys, and we used Help Scout and, later, Zendesk for support. Stuff was fragmented, I’ll say, but it’s just the nature of the beast. Take a deep breath, and just do the best you can, and focus on growing your top one.
Mike: I think that’s about all the time we have for today. If you have a question for us, you can call it into our voicemail number at 1-888-801-9690 or you can email it to us at email@example.com. Our theme music is an excerpt from We’re Outta Control by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for Startups. Visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening. We’ll see you next time.