/
RSS Feed
Show Notes
In this episode of Startups For The Rest Of Us, Rob talks with Brian Casel of Audience Ops, about recovering from a 40% decline in MRR. They start the story back in 2016 and work through the decline, audience ops rebound, the start of Ops Calendar, and Brian’s decision to learn how to code.
Items mentioned in this episode:
Rob: Welcome to this week’s episode of Startups for the Rest of Us. I’m your host, Rob Walling. Each week on this show, we cover topics related to building and growing ambitious yet sane and sustainable startups. We realize that starting a company is hard. More than half of being a startup founder is managing your own psychology and much of being a founder is making decisions with incomplete information where the right answer is impossible to find through math or data.
This week’s episode, I talk with Brian Castle about overcoming a 40% decline in MRR and rising from those ashes. This is Startups for the Rest of Us episode 474.
Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome in building, launching, and growing startups. Whether you’ve built your fifth startup, or you’re thinking about your first. I’m Rob and today with Brian Castle, we’re here to share experiences to help you avoid the mistakes we’ve made.
Welcome back to the show. Thank you for joining me again this week on Startups for the Rest of Us. We have many different show formats. This week is a conversation with someone you’ve likely heard of, Brian Castle. He hosts the Bootstrapped Web podcast with Jordan Gal. And I’ve been listening to that podcast for many years. Hope you enjoy our conversation today.
But before we dive into that, I want to let you know about a MicroConf announcement we’re making this Friday, December 13th. It is by far the biggest we’ve made since launching the conference a decade ago. I really encourage you to go to microconf.com, make sure you’re on the email list. If you’ve attended a MicroConf in the past or you have tickets now, you’re already on the list and you’ll hear about it. But it really is big news and I’m not just saying that to try to sensationalize it or encourage you to go over there. But there’s a lot that’s been going on in terms of the planning of MicroConf for 2020 and we have a lot of new things coming and would love for you to be in the loop on all that’s going on. There’s a lot that’s going to be announced. microconf.com, make sure you’re on the email list.
I enjoyed the conversation I had today with Brian Castle. To set a little bit of the stage, Brian is a frontend designer and UX guy by trade, and then he learned to do some frontend development work. He had been doing a lot of consulting and eventually started dabbling and building products as many of us do. He started at a SaaS app called Restaurant Engine which was originally designed. His vision was for it to be Squarespace for restaurants, but really it evolved almost into a productized service where he had to do a lot of hand holding with the restaurant managers. I think that probably got his gears turning on its software plus service. That offered more value than just straight up building another website builder.
In early 2015, he sold Restaurant Engine for a tidy sum. He talks about that. He said it wasn’t life changing money, but it was enough to go towards a new home. We joined his story at that point where he sold Restaurant Engine and he’s about to start a new productized service. I hope you enjoy this conversation with Brian Castle.
Brian, thank you so much for joining me on the podcast.
Brian: Hey Rob, thanks for having me on.
Rob: Absolutely, man. We joined your story in the middle as I like to say where things are going up into the right. You’ve launched Audience Ops, productized service, and you launched it 2015 and over the course of about the next 18 months, it is all up into the right and you grow from zero dollars in MRR from April of 2015 to 50K of MRR by September of 2016. What was that feeling? Have you ever launched a product that grew that quickly. It’s productized service so it’s not all software, we get it. Have you ever launched anything that had had that much success for that long?
Brian: No, definitely not. I definitely didn’t expect to grow that fast. Looking back on it, it sort of makes sense. Obviously what I’ve learned with productized services is that you can charge a lot more per customer and that helps accelerate the growth rate. If you really nail a market and you’re solving a problem, specific value proposition all that, then I found that growing a recurring productize service like that can really happen. You can grow that revenue pretty fast.
But when I launched it in April 2015, I did not set out to even hit that. The goal was what’s the fastest thing that I can do to get 10K MRR and hit that within two months.
Rob: Right. Like you said, it’s the average revenue per user, a lot of people don’t realize it when that’s $500 a month or $1000, does not take many customers to get you to that 10K, 20K, 30K price point. I’ve seen it with MicroConf companies, with TinySeed companies trying to launch at $20 average revenue per customer app and get to any scale is a very long road even if you have a big audience or have a lot of traffic. Whereas the folks who are plug and away adding two customers a month at $500 average revenue per customer, that’s a grand a month of MRR that you’re growing. It’s a nice base to have.
Brian: Yeah. Audience Ops has, for the most part, been between $1000 and $2000 a month in terms of average per customer. I think it’s great to be able to grow a service like that so quickly. It has some downsides to it too when you’re charging that much because you just see crazy swings in MRR. You can add just a couple of customers, lose just a couple in a week and you’re seeing swings in 5K or 10K MRR. That can really screw with you.
Rob: Right. Stuff we won’t dig into here is you’ve talked a lot about productized services, there are pros and cons to them, you can grow quickly as you’re saying the price points are high and that’s great. Obviously the cons are hey, it’s not as easily scalable as pure software. You do have to hire staff. 50K MRR SaaS company might have 3, 4 people working on it. And a 50K productized service probably has a team of 15 or more. There’s pros and cons to this.
But the thing that’s cool is you launched it and 18 months later, obviously there was a lot of work that you had to do but you have this 50K MRR business now that’s supporting you because after you exited your prior app restaurant engine, I imagine you didn’t want to sit and burn through that cash. You mentioned to me offline that in 2016, you actually spent most of your restaurant engine money on a new house.
Brian: Yeah, that’s right. It wasn’t a life changing exit or anything, but it was a chunk of cash. I looked at that and I really thought about what is going to be in my next business to replace that income. I wanted to get into SaaS software right then in 2015. I looked at a few ideas, but the thought back then of basically burning all of that cash within a year and then maybe getting somewhere close to 10K MRR, which was a big maybe. That kind of scared me.
That’s what lead me to start looking at I kind of know productized services fairly well at this point. That seems to be the fastest way to get to a viable recurring revenue source to then free up my time. Obviously, a lot of work goes into building the team and the systems to remove myself, but that’s always been the goal with the service companies is to grow the cash flow to fund my time to work on stuff.
Rob: You’re a 50K MRR with Audience Ops, it’s fall, September 2016. Since everything is going up into the right, you’re feeling great, you already had two full time W-2 people, you turned 2 more people, they were contractors, you put them on salary and then you started looking at launching the SaaS app. You’re starting to build OPS Calendar. You did some validation there and started upping your expenses. What was the thought process there?
Brian: Right around that time, I guess it was around September into October, I had the idea for this software called OPS Calendar at the time, it was like an editorial software calendar with some process stuff built into it. You can automate content processes and things. Essentially, that was the precursor to my product today—ProcessKit. But back then, that’s what I was doing. At that point, I didn’t personally have the ability to just build an app myself. I‘ve always been a frontend developer and a designer, not a backend. It would definitely require outsourcing and hiring developers to build the functional app.
I did some presale, I got 10, 13, 14 people to prepay based on the idea and a promise that they will someday use this idea. That, combined with the growth rate on Audience Ops, and I had some profit saved up at this point. Okay, I’m good with spending around 5K a month on an outsourced developer and that turned into two or three guys overseas that I was working with.
Rob: Since we didn’t cover it before, could you give people just a two sentence explanation of what OPS Calendar, what it is and the purpose it would serve if it had made it to market, so to speak.
Brian: The idea with OPS Calendar, it was essentially an editorial calendar software with some production process stuff built into it. You and your team can build a process for how you produce blog articles, and podcasts, and social media, and map all that stuff to a calendar to see who needs to do what by when and also to schedule blog posts and social post to the calendar.
Back then I was running Audience Ops which is a content service, we do blog content as a service so obviously it was born out of that. That was essentially the idea with OPS Calendar at the time.
Rob: Yeah, cool. There’s a six months chunk where really from November of 2016, right after you ratchet up these expenses, things hit the skids with Audience Ops. I think this is one of the tough parts of your journey, it seems like. You want to walk us through the timeline there, what happened?
Brian: We’re three years later now and this is still one of those periods of time that I still look back on. Like, “Man, that was painful.” What happened was basically that growth from Audience Ops, 0-50K, that started to plateau right around October, November into the holidays and then started to decline through the holidays, in the January, February into about March or April is when it started to finally turn back around. It was painful on a number of fronts because it coincides right at the time that I decided to start spending a lot of extra cash on developers and employees all at the same time. There was that part of it.
And then it was also just like, “Why is this happening?” Everything was growing just fine up until that point. What is causing the reduction in leads or the increase to churn, it was probably a combination of both. I was looking at it in a thousand different angles to try to uncover what was actually causing it. It’s still unclear to me to this day. I have a few ideas, some hunches of what it could have been. But when you’re in it and you’re trying to fix it, you just don’t know what exactly is broken. It’s really frustrating.
Rob: Absolutely. That’s devastating. 40%? That’s a huge drop. 50K down to 30K. That’s a lot of salaries, that’s probably all your net profit on this thing. I’ve seen SaaS apps plateau, I’ve seen them right over the top, so to speak, when they start to decline. But I’ve never heard of a drop that fast that wasn’t due to some big platform risk. Like, “Hey, I’m integrated with Shopify and they just completely cut off our access.” Or, “I’m a Twitter client and they cut the API.” Or a Google change. Something that was just decimating.
But just to have that happen seemingly out of the blue, it sounds like, and three years later not have been able to pinpoint what happened, must have been terrible. It sounds like it went on for five months and you were just trying to fix it this whole time. Is that what it was?
Brian: Yeah. There are a few things. It was probably a combination of things that I look back on. One was in summer 2016, it was the first time that I hired a sales person for Audience Ops. There was somebody on the team, actually still on the team today, and I put that person into a sales role to remove myself from the sales. That was one remaining jobs that I was still doing in Audience Ops, the team was handling other stuff. It’s not any fault of his, he actually did a really great job of closing a lot of accounts that summer. Bringing out a lot of clients, but a lot of those clients that he sold and closed churned a lot faster than other clients have come on.
I take that as my fault for the training, maybe some of the compensation structure that I really didn’t structure and situate to have a sales person really set the right expectations for customers. Basically the way that I do when I do sales calls for Audience Ops is for me, when I do it, it’s really about let me tell you exactly what’s happening in Audience Ops and almost talk you out of signing up for Audience Ops to make sure that you’re really on board for this. There’s that, we just saw a string of cancellations.
Then the holiday season hit and that slowed down. It was weird because the previous holiday season was actually a pretty big spike in growth for us, but it didn’t happen in 2016. In January, now we’re in the thick of this six month period where sales are stalling, we’re seeing this churn. I go away to the Philippines, my wife has some family there. We were there for a whole month. My plan was to work a little bit while we’re there, but it’s a completely different timezone and that means I literally could not do any sales calls. Even the leads that we had, I couldn’t really even talk to them. Combine that with terrible WiFi while I was there. That was stressful as well.
Rob: How did that manifest itself? What was the peak moment or a moment you can remember where you lost your **** or you were feeling extremely mad about it?
Brian: Anyone who knows me, I am really pretty level headed, I think. I tend to compartmentalize pretty well. Poor sleep, bad eating habits and exercise and all that definitely starts to pile up. Because it’s like I could go exercise today, or I could keep working and try to fix this thing. That was a choice every single day.
Rob: Right. You just dug in and just grinded it out, I shall say. Probably took a toll on your body and mental well being, too.
Brian: Yeah. Into March, April 2017 is when things started to turn around. It’s almost like I don’t really know because it wasn’t a sudden turn around either. It took all of 2017 to dig back out and back up to where it was. But, we definitely improved a lot of things. That was when we really improved the new customer on boarding process heavily. Again, to reinforce those expectations. That I think had a really big impact on customer retention. If they have a really fantastic first month with Audience Ops, they’re really likely to stay on for a year or more at that point.
I worked on some new marketing stuff during that time and some new content, some webinar stuff. I think that seemed to help as well.
Rob: It’s something I talk a lot to entrepreneurs, especially new entrepreneurs don’t understand that they’ll see someone who’s built a business up to 10K a month. You may be able to sell that for $250,000 or something, there’s all these factors. But whatever, you can sell it for quite a million dollars. But people will say, “Why wouldn’t you just keep that? Just keep it and keep running on the side. It’s only three hours a week or five hours a week. Just keep running it.” Usually, there’s a couple of reasons, one because distraction is distraction and there’s opportunity cost to that. But the bigger one is that none of the businesses we have run on autopilot for years. They always get smacked around by something. Sometimes it’s Google, and sometimes it’s a competitor, and sometimes it’s platform risk, and sometimes it’s something you never would’ve guessed, it’s a key employee quitting, it’s something that you have a tough time identifying like what happened with you.
Then you have to shut everything down, stop doing what you’re focused on, and you have to turn your focus back to this thing that you’re tired of working on anyways. At a certain point, eventually, you give in. I’ve done this with multiple businesses and I’ve seen people do it as well, where you’re just like, “Forget it. I just got to sell this thing. I got to get it off my plate.”
Brian: Yeah. It hasn’t really come to that point in Audience Ops, but I can definitely say that there have been times. This period in 2016 was definitely one of those where it was like my mindset is trying to get this brand new idea for a SaaS off the ground. It wasn’t even in existence yet. It was just like get this thing to market. That was my number one goal. Working with developers, I’m paying for developers. I want that to happen as soon as possible. And then I have to stop and work on this churn problem in Audience Ops. Yeah, that was pretty painful.
Rob: We’ll talk in a second about how essentially you did turn that around through 2017. But I’m curious, that low point, this five, six months where things from November to March, April, when they are just in the thrawf and you can’t dig it out. You said that’s still a point that you remember very vividly. I have moments like that in three, four, five months period as well. I learned a lot from them and they impact the way that I do things today. They impact the way that I think about business and the way I ran my apps after that. I’m curious, what lesson or lessons did you take away from that? That impact the way that you make decisions.
Brian: I found that there are one or two of those points in my career so far that I can look back on, that I feel like really influenced the way that I work today. I think in some ways that’s a good thing and in some ways, I do things to a fault today to try to prevent that from happening again. On the positive side, I’ve been through enough of those ups and downs in the MRR graph to know that no matter how well something might be going today, I still have to play it extremely conservative.
We’re like three years out from that, Audience Ops is actually doing really well and I have a profit savings saved up that I’m able to deploy on new products and ProcessKit and things like that. But I’m actually hesitant to spend anything. Because it’s like just keep the reserves in check just in case, you really never know. You look at the news, the economy and stuff. I look at things almost afraid of what could happen.
Tactically, on the sales side of it, I talked about how that period I had a salesperson and then there was a string of churn that came in the months after that. That has caused me to really delay and delay on trying to put a salesperson in place again on Audience Ops.
I’m actually now doing that finally in the end of 2019 with a new strategy behind it and some new structure, but it took me three more years. I have removed myself from every other aspect of Audience Ops. I really spend less than two hours a week on this business, but those two hours are doing the sales calls. Because I just want to make sure that that message is being sent to new customers as they get on. I’m finally coming around to being okay in letting that role go.
Rob: That makes sense. I was going to ask, obviously, if you brought a salesperson and it didn’t work out, you had to turn the app around but after that, I would think that if you do want to get that sales, you would just try and try again. Most sales people don’t work out. The first one you find, frankly, more of the first VAs that I find, the first one almost never works out. So I just hire one, two, three, four and it’s frustrating and it takes time, but eventually, you find someone and then you’re able to let it go. Is that where you’re at now? Is that something you’re looking at doing, trying again and stepping away?
Brian: Yeah. I’m trying again because I think it will actually help impact the business, growth, and the overall health of the business to get me out of that role. Speaking about it now in 2019, I just have a lot more space to breathe. Financially and time wise and so many more things inside the business are more optimized now than they were back then. The on boarding stuff is really locked in, things like that. I just think it’s probably a better time to try to get that off my plate now than it was.
Again, things did start to turn around in 2017, but it took all of ‘17 into the beginning of ‘18. ‘18 was really when I finally got my bearings back in terms of having some space to play with.
Rob: Right. It sounds like it, and that April 2017 point could have been celebratory because you’re bringing your first paying customers in for your SaaS up OPS Calendar, but your financial runway was basically gone. You had to turn around over the next six, seven, eight months. What were a couple steps that you took, it was all hands on deck at that point, right? We’ve lost 40% revenue, we’re still declining at this point. What were some steps you took to turn this around and get out of the tailspin?
Brian: Just to be clear, there’s two parallel products in play here. One is Audience Ops which is in the site crisis mode, and then OPS Calendar which is trying to get off the ground but then I would have to pause, paying for the developers, right at these critical moments as we’re bringing these new customers on to the software. I just didn’t have the cash to fund for the development and couldn’t move fast and all that stuff. That was really frustrating.
But with Audience Ops to start to turn it around, I did a number of different things to try to attack the problem from different angles. One was that new customer on boarding again. I worked with my team a bit to see how can we just make sure that customers are really happy after their first month and that clearly has had an impact on improving churn over time. Just focusing on retention. I think that also helped with customers like referring other leads to us, that has that side effect too.
I did work on some new marketing materials. A whole round of new content, I think I did a recorded webinar that I put into the marketing system at that point, worked on the email automations that helped to nurture. I just went through the whole funnel. Everything that leads and customers see as they find out about Audience Ops, as they go through the sales process, as they get educated and nurtured and on boarded. I tried to improve every step of the funnel over that in early 2017.
Those are the kinds of improvements that you just don’t see moving the needle overnight, you just do that work then maybe a few months later things start to improve.
Rob: Right, and it worked because you turned it around over the next six or eight months.
Brian: I think it has definitely returned to where it was and has grown beyond that but it doesn’t really see the growth rate that it saw in that very first year. But I think that’s sort of a natural slowing down that a business sees. At least I’ll see it that way.
Rob: Yeah. It’s hard to say without going out and really beating the bushes and trying to generate a bunch of leads and doing cold outbound, focusing on SEO or running ads, there’s a natural threshold that always sets in. It seems to me like you’ve always been cool with that plateau because that plateau provides you with a full time income budget to build other apps which is really what you want to do. That’s your lifestyle choice.
Brian: Yeah, exactly.
Rob: They were working on OPS Calendar, your developers were, and you got your first paying customers in April and then you had to pull them off because you didn’t have the money, and then in July in 2017 you’re able to get them back to work on OPS Calendar, and then you get a little bit of traction right that latter half of 2017 but you never found product market fit with OPS Calendar. By February of 2018, you were still trying to push it forward, but some calamities happened. It sounds like there was a code base thing you want to talk us through what it was like dealing with that.
Brian: Throughout that year of 2017, it was trying to bring those first customers on and got a few handful of paying customers, but over the summer there whatever savings I had was gone from that period of Audience Ops. I’m not one of these people who just goes crazy on the credit card. Once I see a little bit of balance on there, I’m just too risk averse and debt averse to really go too heavy on that. I just pause and I don’t really spend until I have the cash in the bank account. I had to pause those developers over the summer which really, really hurt because I felt like it was at a critical time.
As we get into 2018, I went on a trip and we had been pushing off this upgrade from Vue one to Vue JS. At the time, I wasn’t a developer, I didn’t even really understand what Vue was. The developers chose that framework. That upgrade broke everything. I came home from that trip looking at a situation where I could pay those developers to go fix every single feature that I had just paid them for the last 18 months to build. Essentially, spend all that money and all that time again to rebuild the app, which was not going to happen.
It was also we’re having a hard time converting these customers, even a lot of the early prepaid customers didn’t end up continuing on as full customers. That said to me you know what, this thing isn’t really right. Because we have a process feature in OPS Calendar, and people were using that side of it and they were not touching the social media calendar stuff. That was also a signal to me that really the product that I deep down wanted to build was more of a process oriented tool.
Here I am in early 2018, probably going to “pivot” the product, if you will, to something else. Probably a new name and everything. I’m having a problem with these developers, but at that point I just decided to just stop everything. Just pause all work on OPS Calendar, take a month and figure out what I’m going to do. My conclusion was that I’m done with being limited by not being able to build apps myself. As a designer and front-end developer and product person, I’ve always felt, and this really brought it to a head was this experience with OPS Calendar, I’ve always felt this frustration that I can’t move fast enough because I’m always waiting for the developers to finish a feature. Sometimes I can’t move at all because I don’t have the cash to pay developers.
Let me bypass that by investing my time in learning back in development. I learned Ruby on Rails. I basically decided all of 2018, I’m going to use all my full time hours to make myself a full stack developer. I know I won’t be a very good one, but at least I’ll be able to take any idea and build it into a product and bring it to market, and that’s essentially what I do.
Rob: You were just about 18 months into OPS Calendar and I’m going to guess tens of thousands of dollars paying developers. You put on maintenance mode. You effectively shut it down. What was that decision like? How hard was it for you?
Brian: I think it was somewhere around $30,000 or $40,000 that I put into over that period of time. It sort of sucked, but it was also I don’t really have any other option here. I’m not going to just keep spending on something that’s clearly not working. I knew that the tech underneath the app, they technically built the features that I designed and speckled, but there were underlying architectural issues that I could just feel as a user.
That was another reason moving to let me just try to build it myself because at least I could design the thing from the inside out the way that I feel like it should be built. It was hard, but it was also I’m moving on. At that point I was also really excited about this idea for what the next version is which became ProcessKit, which is what I’m working on today.
Rob: I’m curious, deciding to learn to code from scratch, you’ll often hear folks send questions in to this podcast and say, “Should I learn to code if I’m going to watch a SaaS app?” The answer’s always it depends. Do you think that’s something you’re interested in? I would at the minimum learn to code well enough to know if the developers are trying to pull one over on you so you have a concept, you can talk to them. I don’t write production code anymore myself, but I wrote code professionally for 10 years.
I can still have architectural conversations. When Derrick and I were building Drip, I could go pretty deep on the tech stuff. It’s an asset to have for sure. But I’m curious, instead of learning to code, why not launch another productized service? Because you seem to be good at them, they seem to work out for you. Audience Ops is obviously successful and profitable. Why continue to seek after something that is showing you so much resistance in essence, which is a true software base SaaS app?
Brian: Number one, I’ve always been interested in software. I’m not new to software today. I’ve been working on it in different forms for many years. That has always been my number one interest in terms of what I want to create on the web. I’ve been building on the web for over a decade. That’s really always been where I’ve been heading with this. Even since I started Audience Ops, yeah I worked very hard on building it and building the team and the processes, the systems and everything. It’s always been with the end goal in mind of removing myself so that I can fund my time to work on software.
Like you said, the scalability aspect. Yes, I believe a service company can run without you and be profitable without you in the day to day like it is for me, but it’s clearly not as scalable as a SaaS that has hit product market fit and has that growth. Just in terms of the value of an asset and all that.
Also, I just wanted to go back to what you’re saying about the decision to learn to code or not, I agree with you. In many cases, it may not be the smartest choice, or maybe you should just learn a very light understanding of it so that you can communicate with developers. I think there are few caveats that made my situation a little bit unique from where most people are that I come across at least.
Number one, I’m not starting from scratch. I had been a frontend HTML, CSS, little PHP, little JavaScript work. But professional level frontend stuff for years. Building websites, doing a lot of work with advanced WordPress stuff, working on major websites for agencies and things like that. I was not completely new to basic coding and programming. I just never really learned a back end stack like Ruby on Rails, and working with databases and things like that.
There was that. That gave me a head start. And then the other thing is that I had the time. I really have full time hours to throw at this. If I didn’t have that, if I was doing this nights and weekends, I don’t think it would be possible to make as much progress as I did over the last now almost two years. I don’t think I would have been able to really make a lot of progress with it if I couldn’t work on it full time every day.
Rob: Right. You had a lot of time to focus and it was something that as you said, you already had a basis for.
Brian: And I had a lot of help too. A lot of my close friends are software developers, Rails developers, I had of people that I could turn to for support and they’ve been super helpful.
Rob: Totally. That’s the thing. You’re in the developer community already even if you’re more of a frontend developer/designer. It’s like you live in that world and it’s not such a far stretch to be like, okay, I want to go one layer deeper and see how it interacts with the service side code. Cool.
That takes us to spring of 2018. Audience Ops is back, profitable, and you were able to free up your time and spent most of 2018, as you said, learning Rails. What was the most surprising part of that experience of taking that six or eight months and digging into service side code and learning to build your own software top to bottom for the first time?
Brian: In the early months, I knew that it would be a very big effort and that it would take me a long time to get decent at it. It was a little bit frustrating going through tutorials and courses and then still not quite being able to build anything real yet, but then just hacking away at it a little bit more for another month or two and then I can build something very simple.
Over the course of 2018, I went through a bunch of courses, I worked with a coach which was very helpful, and then I did some throwaway practice project apps. By the end of that, I was able to put together a simple app called Sunrise KPI. That was the first real app that I’d built.
I should mention that the idea for ProcessKit I had throughout 2018. I bought the domain. I spent some money on that domain. I was putting sketch ideas for what ProcessKit would be, but I also knew that I wasn’t capable of building it yet. I had to get those skills up and it wasn’t until the end of 2018 I had felt confident in actually starting to build what is now ProcessKit.
Rob: Yeah. If someone’s listening to this and they are thinking about themselves learning to code, what would be a piece of advice, either a warning or just a hey, do this, this is what really worked for me, this is what fast tracked me.
Brian: Early on, I definitely wanted to stay away from the newest, trendiest, most complex frameworks, especially like the JavaScript frameworks and stuff. I’m sure there’s plenty of technical benefits to those, but I wanted boring, tried and true, non trendy stuff. It came down to a decision between Ruby on Rails or PHP in Laravel.
I went through a couple of weeks with PHP Laravel, some tutorials. I could follow along with those, but then I found I couldn’t take what I’d learned and go build something simple. I went through a one on one course on Rails. I did a month on PHP in Laravel and then a month on Rails. I found that at the end of the month on Rails, I was able to take that and build something simple. I continued to double down on Rails from there.
I went through a number of courses on that. Tip number one is to stick with something like Ruby on Rails, or PHP with Laravel. Something that has a huge developer community with tons of resources and educational stuff. That’s a big number one. Number two is to try and find mentors. I go to friends like I talked about. I paid a couple of people for paid mentorship for a while and I’ve learned to code in Rails developer communities, I go to that for some help as well. I frequently talked with friends about code questions. I hit up codementor.io quite a bit when I really get stuck.
Rob: Sounds cool. You mentioned ProcessKit which we haven’t really covered in this conversation. You want to tell folks what that is? Is it the next generation of OPS Calendar done in the way based on your learning from the first time?
Brian: At this point, the way that it’s positioned is that it’s really a projects tool. It kind of like a project management software, but it’s process driven. If your projects really follow the same script every time, they’re very repeatable and you’re doing a lot of the same stuff, whether you’re onboarding customers to a service or to a SaaS or something like that and you need your team to follow a certain process, that’s really where ProcessKit comes in. It’s different from the project management tools where you might run your tasks and projects in one of those tools, but you have your documentation, your SOPs over in a silo somewhere else. That’s where those kinds of operations tend to fall apart, the team just never really follows the SOPs.
ProcessKit sort of brings those together, and then also builds in automation steps. You can say if this then that, if it is is this type of project then assign these tasks to these people, calculate these due dates, and link up with Zapier and all that kind of fun stuff.
Rob: Cool. Where is that project in terms of launching? This is the part of the interview where I ask you questions I already know the answer to. What status is ProcessKit at right now?
Brian: It launched, it has customers. I’ve been doing the slow launch things over the past really throughout ‘19. I think I started on boarding the first customers around June, the very first ones. Today, we’re in November. I’ve been sending early access, invites pretty regularly since then. It was up on Product Hunt about two weeks ago and now it’s out there.
Rob: Is it everything you wanted and more to own a SaaS app? Is it just growing up into the right by itself? You make money while you sleep? I was going to say is it back to the same slug as OPS Calendar, but I don’t think it is. This time really is different. I get the feeling that there is more potential here. Is that pretty accurate?
Brian: First I heard your interview with Jane Portman this morning and I completely relate to that, probably so many other early SaaS founders with the long slow SaaS ramp of death. It’s real.
It’s very slow and the revenue is nowhere new replacing the income that I get from Audience Ops. But yeah, it’s less than a year in, and it does have more customers now than OPS Calendar did. It resonates with people a lot more, the problem and the solution, and the positioning. At least with my audience, the people that I’m connected to. But it’s early on. It really just launched a couple of weeks ago. Now that the new website is up, I’m starting to kick into gear. That shift away from just going to the early access list to actually marketing this thing and getting new traffic and new leads and that sort of stuff.
Rob: Now the real work begins is what I like to say. Getting to launch is like 30% of the journey. That’s where folks who are listening, we could do Startups for the Rest of Us drinking game where like if you get to launch and you don’t have some type of launch list that you’ve been building, then you have a problem. That’s the first base or the first quarter of the journey. And then now you’re launched and now the real work begins. That’s where it’s like you probably don’t have product market fit yet.
Now, I’m going to spend the next six months figuring that out as I grow very slowly. Then, you do get to product market fit, now I need to find a sustainable source of leads when it’s relatively scalable. Then you spend the next 6-12 months figuring that out. That’s why it’s the long slow SaaS ramp. These things are in stages and it’s truly the Cinderella stories that don’t have these steps in this order. It’s always a grind.
Even the Cinderella stories, like I said, there are no Cinderella stories, but even the ones that we look at and say, “Oh my gosh, that grew so fast.” It was a complete grind behind the scenes. This is never easy.
I wish you the best of luck with ProcessKit, because it’s essentially a second iteration of a SaaS app. You’ve obviously fought very hard for multiple years to get this out. This is something you really believe in. You can tell that it’s not an opportunistic product. It’s like I’m going to ship dog food to people on the internet because I could make money. You’re building this because this is something you need and you believe in. I hope that you’re able to make it work.
I think longer term, if for some reason it doesn’t work out, would you build another SaaS app again or would you consider doing a productized service?
Brian: At this point, I am pretty committed personally to doing software whether that’s ProcessKit or another idea or several other ideas, I’m pretty focused primarily on ProcessKit right now. I would use the productized service model if it came to that. No, I should say that I’m actually still using the service model in many ways. Obviously there’s Audience Ops that continues to grow, but even in ProcessKit, now we’re launching a Done with You process service to help you and your team improve and audit your processes, get you set up on ProcessKit as a paid service. That’s sort of like a productized service built on the software, which I really love that model.
You asked about how is it. For me right now, in that slow grind on ProcessKit, I’ll be honest, I’m really loving it. I’m really loving doing everything from the design to the code and talking to customers every day because being able to talk to customers and then literally iterate on the feedback that I got on the feature that I could ship by the end of the week, that just feels so empowering. I know that it won’t be forever, but at this point, Audience Ops is back to growth and profitable in steady state and a really amazing, fantastic team that I have that space to breathe now. I’m not worried about having to cut off the development cycles because of cash flow or things being built in the wrong way or things like that.
Rob: Yeah. There’s definitely a luxury to being able to control that whole pipeline, the manufacturing pipeline. Like I said, I don’t write code anymore, but when I was getting started all the way through Drip, everything before that, I wrote at least some code. Even if it was just maintenance, even if it’s just tinkering here, it was just tweaking. Because finding developer to make a three line code change in PHP or Cold Fusion or classic ASP or .NET or any of those things, it’s a huge amount of work to find someone just to do that. If you know the basics of code, to then just learn, I didn’t know some of those languages but I picked up a book or I went on Stack Overflow, whatever and you Google it, and you’re like, “I’m going to make this change and see if it doesn’t break anything.” If it doesn’t, it’s like wow, I just saved myself like a week of recruiting someone just because you know how to do the basics.
It cuts both ways. I think then you can also get mired in it and then you’re not working on the things you should be and that’s where as we started Drip originally, Derrick said, “Hey, I want to build it on Rails.” I said, “Cool.” Originally I was going to learn Ruby but eventually I said, “You know what, I actually think I shouldn’t because I will get into the repo and start tweaking things. And I should be talking to customers, I should be building processes for this business, I should be doing all the other things that don’t involve the coding.” There’s a point where that makes sense. And if obviously for building a venture backed startup and you’re raising money, you probably shouldn’t be the one digging into the code. Maybe someone on your team is. But there’s a balance there.
But that’s not what you’re doing. You’re building something that you want to build, that you want to exist in the world, and you’re willing and able to take it slow and that gives you a luxury.
Brian: Taking it slow, I’m as impatient as they come with things. I constantly want to move fast and execute and ship something new every single week. But bigger picture, that what’s this podcast and MicroConf and everything is all about. It’s about embracing that slow model of taking your time and making sure that things are done right. I’m all about it.
Rob: That’s right. Ambitious founders who want to build interesting things, build sizable business but are not willing to sacrifice their lives, their health, their relationships, whatever it is, even in your case, it’s a lifestyle that you don’t want to sacrifice to do it and that’s what it’s about. It’s about retaining that control.
Brian: 100%.
Rob: Thanks so much for coming on the show, man. If folks want to keep up with you, and they like the podcast, they should search for Bootstrapped Web, podcast you release every week or two with Jordan Gall. I’m a listener, have been for years. If they want to keep up with you on Twitter, you are @casjam and of course processkit.com is where your SaaS app lives. Any other places folks might want to look out for you?
Brian: Audience Ops is still kicking. Great team over there. Yeah, you hit it. That’s it.
Rob: Sounds great. Thanks again, man.
Brian: Thanks. Thanks, Rob.
Rob: If you have any questions for Brian or myself after hearing this interview, I’d love it if you would tweet me @robwalling or send a question into questions.startupsfortherestofus.com and I would be glad to have Brian back on the show to answer questions you have about any of his experiences, or productized services, or anything else that you feel like he could lend some insight into. If you have an unrelated question for the show, you can leave me a voicemail at 888-801-9690. Or you can always email us questions.startupsfortherestofus.com. You can find us in all the podcasting marketplaces and directories, just search for Startups.
If you’re interested in the full transcript or to make a comment on an episode, just hit up startupsfortherestofus.com. This was episode 474. Our theme music is an excerpt from We’re Outta Control by MoOt, it’s used under Creative Commons. Thank you for listening, and I’ll see you next time.
This week’s episode, I talk with Brian Castle about overcoming a 40% decline in MRR and rising from those ashes. This is Startups for the Rest of Us episode 474.
Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome in building, launching, and growing startups. Whether you’ve built your fifth startup, or you’re thinking about your first. I’m Rob and today with Brian Castle, we’re here to share experiences to help you avoid the mistakes we’ve made.
Welcome back to the show. Thank you for joining me again this week on Startups for the Rest of Us. We have many different show formats. This week is a conversation with someone you’ve likely heard of, Brian Castle. He hosts the Bootstrapped Web podcast with Jordan Gal. And I’ve been listening to that podcast for many years. Hope you enjoy our conversation today.
But before we dive into that, I want to let you know about a MicroConf announcement we’re making this Friday, December 13th. It is by far the biggest we’ve made since launching the conference a decade ago. I really encourage you to go to microconf.com, make sure you’re on the email list. If you’ve attended a MicroConf in the past or you have tickets now, you’re already on the list and you’ll hear about it. But it really is big news and I’m not just saying that to try to sensationalize it or encourage you to go over there. But there’s a lot that’s been going on in terms of the planning of MicroConf for 2020 and we have a lot of new things coming and would love for you to be in the loop on all that’s going on. There’s a lot that’s going to be announced. microconf.com, make sure you’re on the email list.
I enjoyed the conversation I had today with Brian Castle. To set a little bit of the stage, Brian is a frontend designer and UX guy by trade, and then he learned to do some frontend development work. He had been doing a lot of consulting and eventually started dabbling and building products as many of us do. He started at a SaaS app called Restaurant Engine which was originally designed. His vision was for it to be Squarespace for restaurants, but really it evolved almost into a productized service where he had to do a lot of hand holding with the restaurant managers. I think that probably got his gears turning on its software plus service. That offered more value than just straight up building another website builder.
In early 2015, he sold Restaurant Engine for a tidy sum. He talks about that. He said it wasn’t life changing money, but it was enough to go towards a new home. We joined his story at that point where he sold Restaurant Engine and he’s about to start a new productized service. I hope you enjoy this conversation with Brian Castle.
Brian, thank you so much for joining me on the podcast.
Brian: Hey Rob, thanks for having me on.
Rob: Absolutely, man. We joined your story in the middle as I like to say where things are going up into the right. You’ve launched Audience Ops, productized service, and you launched it 2015 and over the course of about the next 18 months, it is all up into the right and you grow from zero dollars in MRR from April of 2015 to 50K of MRR by September of 2016. What was that feeling? Have you ever launched a product that grew that quickly. It’s productized service so it’s not all software, we get it. Have you ever launched anything that had had that much success for that long?
Brian: No, definitely not. I definitely didn’t expect to grow that fast. Looking back on it, it sort of makes sense. Obviously what I’ve learned with productized services is that you can charge a lot more per customer and that helps accelerate the growth rate. If you really nail a market and you’re solving a problem, specific value proposition all that, then I found that growing a recurring productize service like that can really happen. You can grow that revenue pretty fast.
But when I launched it in April 2015, I did not set out to even hit that. The goal was what’s the fastest thing that I can do to get 10K MRR and hit that within two months.
Rob: Right. Like you said, it’s the average revenue per user, a lot of people don’t realize it when that’s $500 a month or $1000, does not take many customers to get you to that 10K, 20K, 30K price point. I’ve seen it with MicroConf companies, with TinySeed companies trying to launch at $20 average revenue per customer app and get to any scale is a very long road even if you have a big audience or have a lot of traffic. Whereas the folks who are plug and away adding two customers a month at $500 average revenue per customer, that’s a grand a month of MRR that you’re growing. It’s a nice base to have.
Brian: Yeah. Audience Ops has, for the most part, been between $1000 and $2000 a month in terms of average per customer. I think it’s great to be able to grow a service like that so quickly. It has some downsides to it too when you’re charging that much because you just see crazy swings in MRR. You can add just a couple of customers, lose just a couple in a week and you’re seeing swings in 5K or 10K MRR. That can really screw with you.
Rob: Right. Stuff we won’t dig into here is you’ve talked a lot about productized services, there are pros and cons to them, you can grow quickly as you’re saying the price points are high and that’s great. Obviously the cons are hey, it’s not as easily scalable as pure software. You do have to hire staff. 50K MRR SaaS company might have 3, 4 people working on it. And a 50K productized service probably has a team of 15 or more. There’s pros and cons to this.
But the thing that’s cool is you launched it and 18 months later, obviously there was a lot of work that you had to do but you have this 50K MRR business now that’s supporting you because after you exited your prior app restaurant engine, I imagine you didn’t want to sit and burn through that cash. You mentioned to me offline that in 2016, you actually spent most of your restaurant engine money on a new house.
Brian: Yeah, that’s right. It wasn’t a life changing exit or anything, but it was a chunk of cash. I looked at that and I really thought about what is going to be in my next business to replace that income. I wanted to get into SaaS software right then in 2015. I looked at a few ideas, but the thought back then of basically burning all of that cash within a year and then maybe getting somewhere close to 10K MRR, which was a big maybe. That kind of scared me.
That’s what lead me to start looking at I kind of know productized services fairly well at this point. That seems to be the fastest way to get to a viable recurring revenue source to then free up my time. Obviously, a lot of work goes into building the team and the systems to remove myself, but that’s always been the goal with the service companies is to grow the cash flow to fund my time to work on stuff.
Rob: You’re a 50K MRR with Audience Ops, it’s fall, September 2016. Since everything is going up into the right, you’re feeling great, you already had two full time W-2 people, you turned 2 more people, they were contractors, you put them on salary and then you started looking at launching the SaaS app. You’re starting to build OPS Calendar. You did some validation there and started upping your expenses. What was the thought process there?
Brian: Right around that time, I guess it was around September into October, I had the idea for this software called OPS Calendar at the time, it was like an editorial software calendar with some process stuff built into it. You can automate content processes and things. Essentially, that was the precursor to my product today—ProcessKit. But back then, that’s what I was doing. At that point, I didn’t personally have the ability to just build an app myself. I‘ve always been a frontend developer and a designer, not a backend. It would definitely require outsourcing and hiring developers to build the functional app.
I did some presale, I got 10, 13, 14 people to prepay based on the idea and a promise that they will someday use this idea. That, combined with the growth rate on Audience Ops, and I had some profit saved up at this point. Okay, I’m good with spending around 5K a month on an outsourced developer and that turned into two or three guys overseas that I was working with.
Rob: Since we didn’t cover it before, could you give people just a two sentence explanation of what OPS Calendar, what it is and the purpose it would serve if it had made it to market, so to speak.
Brian: The idea with OPS Calendar, it was essentially an editorial calendar software with some production process stuff built into it. You and your team can build a process for how you produce blog articles, and podcasts, and social media, and map all that stuff to a calendar to see who needs to do what by when and also to schedule blog posts and social post to the calendar.
Back then I was running Audience Ops which is a content service, we do blog content as a service so obviously it was born out of that. That was essentially the idea with OPS Calendar at the time.
Rob: Yeah, cool. There’s a six months chunk where really from November of 2016, right after you ratchet up these expenses, things hit the skids with Audience Ops. I think this is one of the tough parts of your journey, it seems like. You want to walk us through the timeline there, what happened?
Brian: We’re three years later now and this is still one of those periods of time that I still look back on. Like, “Man, that was painful.” What happened was basically that growth from Audience Ops, 0-50K, that started to plateau right around October, November into the holidays and then started to decline through the holidays, in the January, February into about March or April is when it started to finally turn back around. It was painful on a number of fronts because it coincides right at the time that I decided to start spending a lot of extra cash on developers and employees all at the same time. There was that part of it.
And then it was also just like, “Why is this happening?” Everything was growing just fine up until that point. What is causing the reduction in leads or the increase to churn, it was probably a combination of both. I was looking at it in a thousand different angles to try to uncover what was actually causing it. It’s still unclear to me to this day. I have a few ideas, some hunches of what it could have been. But when you’re in it and you’re trying to fix it, you just don’t know what exactly is broken. It’s really frustrating.
Rob: Absolutely. That’s devastating. 40%? That’s a huge drop. 50K down to 30K. That’s a lot of salaries, that’s probably all your net profit on this thing. I’ve seen SaaS apps plateau, I’ve seen them right over the top, so to speak, when they start to decline. But I’ve never heard of a drop that fast that wasn’t due to some big platform risk. Like, “Hey, I’m integrated with Shopify and they just completely cut off our access.” Or, “I’m a Twitter client and they cut the API.” Or a Google change. Something that was just decimating.
But just to have that happen seemingly out of the blue, it sounds like, and three years later not have been able to pinpoint what happened, must have been terrible. It sounds like it went on for five months and you were just trying to fix it this whole time. Is that what it was?
Brian: Yeah. There are a few things. It was probably a combination of things that I look back on. One was in summer 2016, it was the first time that I hired a sales person for Audience Ops. There was somebody on the team, actually still on the team today, and I put that person into a sales role to remove myself from the sales. That was one remaining jobs that I was still doing in Audience Ops, the team was handling other stuff. It’s not any fault of his, he actually did a really great job of closing a lot of accounts that summer. Bringing out a lot of clients, but a lot of those clients that he sold and closed churned a lot faster than other clients have come on.
I take that as my fault for the training, maybe some of the compensation structure that I really didn’t structure and situate to have a sales person really set the right expectations for customers. Basically the way that I do when I do sales calls for Audience Ops is for me, when I do it, it’s really about let me tell you exactly what’s happening in Audience Ops and almost talk you out of signing up for Audience Ops to make sure that you’re really on board for this. There’s that, we just saw a string of cancellations.
Then the holiday season hit and that slowed down. It was weird because the previous holiday season was actually a pretty big spike in growth for us, but it didn’t happen in 2016. In January, now we’re in the thick of this six month period where sales are stalling, we’re seeing this churn. I go away to the Philippines, my wife has some family there. We were there for a whole month. My plan was to work a little bit while we’re there, but it’s a completely different timezone and that means I literally could not do any sales calls. Even the leads that we had, I couldn’t really even talk to them. Combine that with terrible WiFi while I was there. That was stressful as well.
Rob: How did that manifest itself? What was the peak moment or a moment you can remember where you lost your **** or you were feeling extremely mad about it?
Brian: Anyone who knows me, I am really pretty level headed, I think. I tend to compartmentalize pretty well. Poor sleep, bad eating habits and exercise and all that definitely starts to pile up. Because it’s like I could go exercise today, or I could keep working and try to fix this thing. That was a choice every single day.
Rob: Right. You just dug in and just grinded it out, I shall say. Probably took a toll on your body and mental well being, too.
Brian: Yeah. Into March, April 2017 is when things started to turn around. It’s almost like I don’t really know because it wasn’t a sudden turn around either. It took all of 2017 to dig back out and back up to where it was. But, we definitely improved a lot of things. That was when we really improved the new customer on boarding process heavily. Again, to reinforce those expectations. That I think had a really big impact on customer retention. If they have a really fantastic first month with Audience Ops, they’re really likely to stay on for a year or more at that point.
I worked on some new marketing stuff during that time and some new content, some webinar stuff. I think that seemed to help as well.
Rob: It’s something I talk a lot to entrepreneurs, especially new entrepreneurs don’t understand that they’ll see someone who’s built a business up to 10K a month. You may be able to sell that for $250,000 or something, there’s all these factors. But whatever, you can sell it for quite a million dollars. But people will say, “Why wouldn’t you just keep that? Just keep it and keep running on the side. It’s only three hours a week or five hours a week. Just keep running it.” Usually, there’s a couple of reasons, one because distraction is distraction and there’s opportunity cost to that. But the bigger one is that none of the businesses we have run on autopilot for years. They always get smacked around by something. Sometimes it’s Google, and sometimes it’s a competitor, and sometimes it’s platform risk, and sometimes it’s something you never would’ve guessed, it’s a key employee quitting, it’s something that you have a tough time identifying like what happened with you.
Then you have to shut everything down, stop doing what you’re focused on, and you have to turn your focus back to this thing that you’re tired of working on anyways. At a certain point, eventually, you give in. I’ve done this with multiple businesses and I’ve seen people do it as well, where you’re just like, “Forget it. I just got to sell this thing. I got to get it off my plate.”
Brian: Yeah. It hasn’t really come to that point in Audience Ops, but I can definitely say that there have been times. This period in 2016 was definitely one of those where it was like my mindset is trying to get this brand new idea for a SaaS off the ground. It wasn’t even in existence yet. It was just like get this thing to market. That was my number one goal. Working with developers, I’m paying for developers. I want that to happen as soon as possible. And then I have to stop and work on this churn problem in Audience Ops. Yeah, that was pretty painful.
Rob: We’ll talk in a second about how essentially you did turn that around through 2017. But I’m curious, that low point, this five, six months where things from November to March, April, when they are just in the thrawf and you can’t dig it out. You said that’s still a point that you remember very vividly. I have moments like that in three, four, five months period as well. I learned a lot from them and they impact the way that I do things today. They impact the way that I think about business and the way I ran my apps after that. I’m curious, what lesson or lessons did you take away from that? That impact the way that you make decisions.
Brian: I found that there are one or two of those points in my career so far that I can look back on, that I feel like really influenced the way that I work today. I think in some ways that’s a good thing and in some ways, I do things to a fault today to try to prevent that from happening again. On the positive side, I’ve been through enough of those ups and downs in the MRR graph to know that no matter how well something might be going today, I still have to play it extremely conservative.
We’re like three years out from that, Audience Ops is actually doing really well and I have a profit savings saved up that I’m able to deploy on new products and ProcessKit and things like that. But I’m actually hesitant to spend anything. Because it’s like just keep the reserves in check just in case, you really never know. You look at the news, the economy and stuff. I look at things almost afraid of what could happen.
Tactically, on the sales side of it, I talked about how that period I had a salesperson and then there was a string of churn that came in the months after that. That has caused me to really delay and delay on trying to put a salesperson in place again on Audience Ops.
I’m actually now doing that finally in the end of 2019 with a new strategy behind it and some new structure, but it took me three more years. I have removed myself from every other aspect of Audience Ops. I really spend less than two hours a week on this business, but those two hours are doing the sales calls. Because I just want to make sure that that message is being sent to new customers as they get on. I’m finally coming around to being okay in letting that role go.
Rob: That makes sense. I was going to ask, obviously, if you brought a salesperson and it didn’t work out, you had to turn the app around but after that, I would think that if you do want to get that sales, you would just try and try again. Most sales people don’t work out. The first one you find, frankly, more of the first VAs that I find, the first one almost never works out. So I just hire one, two, three, four and it’s frustrating and it takes time, but eventually, you find someone and then you’re able to let it go. Is that where you’re at now? Is that something you’re looking at doing, trying again and stepping away?
Brian: Yeah. I’m trying again because I think it will actually help impact the business, growth, and the overall health of the business to get me out of that role. Speaking about it now in 2019, I just have a lot more space to breathe. Financially and time wise and so many more things inside the business are more optimized now than they were back then. The on boarding stuff is really locked in, things like that. I just think it’s probably a better time to try to get that off my plate now than it was.
Again, things did start to turn around in 2017, but it took all of ‘17 into the beginning of ‘18. ‘18 was really when I finally got my bearings back in terms of having some space to play with.
Rob: Right. It sounds like it, and that April 2017 point could have been celebratory because you’re bringing your first paying customers in for your SaaS up OPS Calendar, but your financial runway was basically gone. You had to turn around over the next six, seven, eight months. What were a couple steps that you took, it was all hands on deck at that point, right? We’ve lost 40% revenue, we’re still declining at this point. What were some steps you took to turn this around and get out of the tailspin?
Brian: Just to be clear, there’s two parallel products in play here. One is Audience Ops which is in the site crisis mode, and then OPS Calendar which is trying to get off the ground but then I would have to pause, paying for the developers, right at these critical moments as we’re bringing these new customers on to the software. I just didn’t have the cash to fund for the development and couldn’t move fast and all that stuff. That was really frustrating.
But with Audience Ops to start to turn it around, I did a number of different things to try to attack the problem from different angles. One was that new customer on boarding again. I worked with my team a bit to see how can we just make sure that customers are really happy after their first month and that clearly has had an impact on improving churn over time. Just focusing on retention. I think that also helped with customers like referring other leads to us, that has that side effect too.
I did work on some new marketing materials. A whole round of new content, I think I did a recorded webinar that I put into the marketing system at that point, worked on the email automations that helped to nurture. I just went through the whole funnel. Everything that leads and customers see as they find out about Audience Ops, as they go through the sales process, as they get educated and nurtured and on boarded. I tried to improve every step of the funnel over that in early 2017.
Those are the kinds of improvements that you just don’t see moving the needle overnight, you just do that work then maybe a few months later things start to improve.
Rob: Right, and it worked because you turned it around over the next six or eight months.
Brian: I think it has definitely returned to where it was and has grown beyond that but it doesn’t really see the growth rate that it saw in that very first year. But I think that’s sort of a natural slowing down that a business sees. At least I’ll see it that way.
Rob: Yeah. It’s hard to say without going out and really beating the bushes and trying to generate a bunch of leads and doing cold outbound, focusing on SEO or running ads, there’s a natural threshold that always sets in. It seems to me like you’ve always been cool with that plateau because that plateau provides you with a full time income budget to build other apps which is really what you want to do. That’s your lifestyle choice.
Brian: Yeah, exactly.
Rob: They were working on OPS Calendar, your developers were, and you got your first paying customers in April and then you had to pull them off because you didn’t have the money, and then in July in 2017 you’re able to get them back to work on OPS Calendar, and then you get a little bit of traction right that latter half of 2017 but you never found product market fit with OPS Calendar. By February of 2018, you were still trying to push it forward, but some calamities happened. It sounds like there was a code base thing you want to talk us through what it was like dealing with that.
Brian: Throughout that year of 2017, it was trying to bring those first customers on and got a few handful of paying customers, but over the summer there whatever savings I had was gone from that period of Audience Ops. I’m not one of these people who just goes crazy on the credit card. Once I see a little bit of balance on there, I’m just too risk averse and debt averse to really go too heavy on that. I just pause and I don’t really spend until I have the cash in the bank account. I had to pause those developers over the summer which really, really hurt because I felt like it was at a critical time.
As we get into 2018, I went on a trip and we had been pushing off this upgrade from Vue one to Vue JS. At the time, I wasn’t a developer, I didn’t even really understand what Vue was. The developers chose that framework. That upgrade broke everything. I came home from that trip looking at a situation where I could pay those developers to go fix every single feature that I had just paid them for the last 18 months to build. Essentially, spend all that money and all that time again to rebuild the app, which was not going to happen.
It was also we’re having a hard time converting these customers, even a lot of the early prepaid customers didn’t end up continuing on as full customers. That said to me you know what, this thing isn’t really right. Because we have a process feature in OPS Calendar, and people were using that side of it and they were not touching the social media calendar stuff. That was also a signal to me that really the product that I deep down wanted to build was more of a process oriented tool.
Here I am in early 2018, probably going to “pivot” the product, if you will, to something else. Probably a new name and everything. I’m having a problem with these developers, but at that point I just decided to just stop everything. Just pause all work on OPS Calendar, take a month and figure out what I’m going to do. My conclusion was that I’m done with being limited by not being able to build apps myself. As a designer and front-end developer and product person, I’ve always felt, and this really brought it to a head was this experience with OPS Calendar, I’ve always felt this frustration that I can’t move fast enough because I’m always waiting for the developers to finish a feature. Sometimes I can’t move at all because I don’t have the cash to pay developers.
Let me bypass that by investing my time in learning back in development. I learned Ruby on Rails. I basically decided all of 2018, I’m going to use all my full time hours to make myself a full stack developer. I know I won’t be a very good one, but at least I’ll be able to take any idea and build it into a product and bring it to market, and that’s essentially what I do.
Rob: You were just about 18 months into OPS Calendar and I’m going to guess tens of thousands of dollars paying developers. You put on maintenance mode. You effectively shut it down. What was that decision like? How hard was it for you?
Brian: I think it was somewhere around $30,000 or $40,000 that I put into over that period of time. It sort of sucked, but it was also I don’t really have any other option here. I’m not going to just keep spending on something that’s clearly not working. I knew that the tech underneath the app, they technically built the features that I designed and speckled, but there were underlying architectural issues that I could just feel as a user.
That was another reason moving to let me just try to build it myself because at least I could design the thing from the inside out the way that I feel like it should be built. It was hard, but it was also I’m moving on. At that point I was also really excited about this idea for what the next version is which became ProcessKit, which is what I’m working on today.
Rob: I’m curious, deciding to learn to code from scratch, you’ll often hear folks send questions in to this podcast and say, “Should I learn to code if I’m going to watch a SaaS app?” The answer’s always it depends. Do you think that’s something you’re interested in? I would at the minimum learn to code well enough to know if the developers are trying to pull one over on you so you have a concept, you can talk to them. I don’t write production code anymore myself, but I wrote code professionally for 10 years.
I can still have architectural conversations. When Derrick and I were building Drip, I could go pretty deep on the tech stuff. It’s an asset to have for sure. But I’m curious, instead of learning to code, why not launch another productized service? Because you seem to be good at them, they seem to work out for you. Audience Ops is obviously successful and profitable. Why continue to seek after something that is showing you so much resistance in essence, which is a true software base SaaS app?
Brian: Number one, I’ve always been interested in software. I’m not new to software today. I’ve been working on it in different forms for many years. That has always been my number one interest in terms of what I want to create on the web. I’ve been building on the web for over a decade. That’s really always been where I’ve been heading with this. Even since I started Audience Ops, yeah I worked very hard on building it and building the team and the processes, the systems and everything. It’s always been with the end goal in mind of removing myself so that I can fund my time to work on software.
Like you said, the scalability aspect. Yes, I believe a service company can run without you and be profitable without you in the day to day like it is for me, but it’s clearly not as scalable as a SaaS that has hit product market fit and has that growth. Just in terms of the value of an asset and all that.
Also, I just wanted to go back to what you’re saying about the decision to learn to code or not, I agree with you. In many cases, it may not be the smartest choice, or maybe you should just learn a very light understanding of it so that you can communicate with developers. I think there are few caveats that made my situation a little bit unique from where most people are that I come across at least.
Number one, I’m not starting from scratch. I had been a frontend HTML, CSS, little PHP, little JavaScript work. But professional level frontend stuff for years. Building websites, doing a lot of work with advanced WordPress stuff, working on major websites for agencies and things like that. I was not completely new to basic coding and programming. I just never really learned a back end stack like Ruby on Rails, and working with databases and things like that.
There was that. That gave me a head start. And then the other thing is that I had the time. I really have full time hours to throw at this. If I didn’t have that, if I was doing this nights and weekends, I don’t think it would be possible to make as much progress as I did over the last now almost two years. I don’t think I would have been able to really make a lot of progress with it if I couldn’t work on it full time every day.
Rob: Right. You had a lot of time to focus and it was something that as you said, you already had a basis for.
Brian: And I had a lot of help too. A lot of my close friends are software developers, Rails developers, I had of people that I could turn to for support and they’ve been super helpful.
Rob: Totally. That’s the thing. You’re in the developer community already even if you’re more of a frontend developer/designer. It’s like you live in that world and it’s not such a far stretch to be like, okay, I want to go one layer deeper and see how it interacts with the service side code. Cool.
That takes us to spring of 2018. Audience Ops is back, profitable, and you were able to free up your time and spent most of 2018, as you said, learning Rails. What was the most surprising part of that experience of taking that six or eight months and digging into service side code and learning to build your own software top to bottom for the first time?
Brian: In the early months, I knew that it would be a very big effort and that it would take me a long time to get decent at it. It was a little bit frustrating going through tutorials and courses and then still not quite being able to build anything real yet, but then just hacking away at it a little bit more for another month or two and then I can build something very simple.
Over the course of 2018, I went through a bunch of courses, I worked with a coach which was very helpful, and then I did some throwaway practice project apps. By the end of that, I was able to put together a simple app called Sunrise KPI. That was the first real app that I’d built.
I should mention that the idea for ProcessKit I had throughout 2018. I bought the domain. I spent some money on that domain. I was putting sketch ideas for what ProcessKit would be, but I also knew that I wasn’t capable of building it yet. I had to get those skills up and it wasn’t until the end of 2018 I had felt confident in actually starting to build what is now ProcessKit.
Rob: Yeah. If someone’s listening to this and they are thinking about themselves learning to code, what would be a piece of advice, either a warning or just a hey, do this, this is what really worked for me, this is what fast tracked me.
Brian: Early on, I definitely wanted to stay away from the newest, trendiest, most complex frameworks, especially like the JavaScript frameworks and stuff. I’m sure there’s plenty of technical benefits to those, but I wanted boring, tried and true, non trendy stuff. It came down to a decision between Ruby on Rails or PHP in Laravel.
I went through a couple of weeks with PHP Laravel, some tutorials. I could follow along with those, but then I found I couldn’t take what I’d learned and go build something simple. I went through a one on one course on Rails. I did a month on PHP in Laravel and then a month on Rails. I found that at the end of the month on Rails, I was able to take that and build something simple. I continued to double down on Rails from there.
I went through a number of courses on that. Tip number one is to stick with something like Ruby on Rails, or PHP with Laravel. Something that has a huge developer community with tons of resources and educational stuff. That’s a big number one. Number two is to try and find mentors. I go to friends like I talked about. I paid a couple of people for paid mentorship for a while and I’ve learned to code in Rails developer communities, I go to that for some help as well. I frequently talked with friends about code questions. I hit up codementor.io quite a bit when I really get stuck.
Rob: Sounds cool. You mentioned ProcessKit which we haven’t really covered in this conversation. You want to tell folks what that is? Is it the next generation of OPS Calendar done in the way based on your learning from the first time?
Brian: At this point, the way that it’s positioned is that it’s really a projects tool. It kind of like a project management software, but it’s process driven. If your projects really follow the same script every time, they’re very repeatable and you’re doing a lot of the same stuff, whether you’re onboarding customers to a service or to a SaaS or something like that and you need your team to follow a certain process, that’s really where ProcessKit comes in. It’s different from the project management tools where you might run your tasks and projects in one of those tools, but you have your documentation, your SOPs over in a silo somewhere else. That’s where those kinds of operations tend to fall apart, the team just never really follows the SOPs.
ProcessKit sort of brings those together, and then also builds in automation steps. You can say if this then that, if it is is this type of project then assign these tasks to these people, calculate these due dates, and link up with Zapier and all that kind of fun stuff.
Rob: Cool. Where is that project in terms of launching? This is the part of the interview where I ask you questions I already know the answer to. What status is ProcessKit at right now?
Brian: It launched, it has customers. I’ve been doing the slow launch things over the past really throughout ‘19. I think I started on boarding the first customers around June, the very first ones. Today, we’re in November. I’ve been sending early access, invites pretty regularly since then. It was up on Product Hunt about two weeks ago and now it’s out there.
Rob: Is it everything you wanted and more to own a SaaS app? Is it just growing up into the right by itself? You make money while you sleep? I was going to say is it back to the same slug as OPS Calendar, but I don’t think it is. This time really is different. I get the feeling that there is more potential here. Is that pretty accurate?
Brian: First I heard your interview with Jane Portman this morning and I completely relate to that, probably so many other early SaaS founders with the long slow SaaS ramp of death. It’s real.
It’s very slow and the revenue is nowhere new replacing the income that I get from Audience Ops. But yeah, it’s less than a year in, and it does have more customers now than OPS Calendar did. It resonates with people a lot more, the problem and the solution, and the positioning. At least with my audience, the people that I’m connected to. But it’s early on. It really just launched a couple of weeks ago. Now that the new website is up, I’m starting to kick into gear. That shift away from just going to the early access list to actually marketing this thing and getting new traffic and new leads and that sort of stuff.
Rob: Now the real work begins is what I like to say. Getting to launch is like 30% of the journey. That’s where folks who are listening, we could do Startups for the Rest of Us drinking game where like if you get to launch and you don’t have some type of launch list that you’ve been building, then you have a problem. That’s the first base or the first quarter of the journey. And then now you’re launched and now the real work begins. That’s where it’s like you probably don’t have product market fit yet.
Now, I’m going to spend the next six months figuring that out as I grow very slowly. Then, you do get to product market fit, now I need to find a sustainable source of leads when it’s relatively scalable. Then you spend the next 6-12 months figuring that out. That’s why it’s the long slow SaaS ramp. These things are in stages and it’s truly the Cinderella stories that don’t have these steps in this order. It’s always a grind.
Even the Cinderella stories, like I said, there are no Cinderella stories, but even the ones that we look at and say, “Oh my gosh, that grew so fast.” It was a complete grind behind the scenes. This is never easy.
I wish you the best of luck with ProcessKit, because it’s essentially a second iteration of a SaaS app. You’ve obviously fought very hard for multiple years to get this out. This is something you really believe in. You can tell that it’s not an opportunistic product. It’s like I’m going to ship dog food to people on the internet because I could make money. You’re building this because this is something you need and you believe in. I hope that you’re able to make it work.
I think longer term, if for some reason it doesn’t work out, would you build another SaaS app again or would you consider doing a productized service?
Brian: At this point, I am pretty committed personally to doing software whether that’s ProcessKit or another idea or several other ideas, I’m pretty focused primarily on ProcessKit right now. I would use the productized service model if it came to that. No, I should say that I’m actually still using the service model in many ways. Obviously there’s Audience Ops that continues to grow, but even in ProcessKit, now we’re launching a Done with You process service to help you and your team improve and audit your processes, get you set up on ProcessKit as a paid service. That’s sort of like a productized service built on the software, which I really love that model.
You asked about how is it. For me right now, in that slow grind on ProcessKit, I’ll be honest, I’m really loving it. I’m really loving doing everything from the design to the code and talking to customers every day because being able to talk to customers and then literally iterate on the feedback that I got on the feature that I could ship by the end of the week, that just feels so empowering. I know that it won’t be forever, but at this point, Audience Ops is back to growth and profitable in steady state and a really amazing, fantastic team that I have that space to breathe now. I’m not worried about having to cut off the development cycles because of cash flow or things being built in the wrong way or things like that.
Rob: Yeah. There’s definitely a luxury to being able to control that whole pipeline, the manufacturing pipeline. Like I said, I don’t write code anymore, but when I was getting started all the way through Drip, everything before that, I wrote at least some code. Even if it was just maintenance, even if it’s just tinkering here, it was just tweaking. Because finding developer to make a three line code change in PHP or Cold Fusion or classic ASP or .NET or any of those things, it’s a huge amount of work to find someone just to do that. If you know the basics of code, to then just learn, I didn’t know some of those languages but I picked up a book or I went on Stack Overflow, whatever and you Google it, and you’re like, “I’m going to make this change and see if it doesn’t break anything.” If it doesn’t, it’s like wow, I just saved myself like a week of recruiting someone just because you know how to do the basics.
It cuts both ways. I think then you can also get mired in it and then you’re not working on the things you should be and that’s where as we started Drip originally, Derrick said, “Hey, I want to build it on Rails.” I said, “Cool.” Originally I was going to learn Ruby but eventually I said, “You know what, I actually think I shouldn’t because I will get into the repo and start tweaking things. And I should be talking to customers, I should be building processes for this business, I should be doing all the other things that don’t involve the coding.” There’s a point where that makes sense. And if obviously for building a venture backed startup and you’re raising money, you probably shouldn’t be the one digging into the code. Maybe someone on your team is. But there’s a balance there.
But that’s not what you’re doing. You’re building something that you want to build, that you want to exist in the world, and you’re willing and able to take it slow and that gives you a luxury.
Brian: Taking it slow, I’m as impatient as they come with things. I constantly want to move fast and execute and ship something new every single week. But bigger picture, that what’s this podcast and MicroConf and everything is all about. It’s about embracing that slow model of taking your time and making sure that things are done right. I’m all about it.
Rob: That’s right. Ambitious founders who want to build interesting things, build sizable business but are not willing to sacrifice their lives, their health, their relationships, whatever it is, even in your case, it’s a lifestyle that you don’t want to sacrifice to do it and that’s what it’s about. It’s about retaining that control.
Brian: 100%.
Rob: Thanks so much for coming on the show, man. If folks want to keep up with you, and they like the podcast, they should search for Bootstrapped Web, podcast you release every week or two with Jordan Gall. I’m a listener, have been for years. If they want to keep up with you on Twitter, you are @casjam and of course processkit.com is where your SaaS app lives. Any other places folks might want to look out for you?
Brian: Audience Ops is still kicking. Great team over there. Yeah, you hit it. That’s it.
Rob: Sounds great. Thanks again, man.
Brian: Thanks. Thanks, Rob.
Rob: If you have any questions for Brian or myself after hearing this interview, I’d love it if you would tweet me @robwalling or send a question into questions.startupsfortherestofus.com and I would be glad to have Brian back on the show to answer questions you have about any of his experiences, or productized services, or anything else that you feel like he could lend some insight into. If you have an unrelated question for the show, you can leave me a voicemail at 888-801-9690. Or you can always email us questions.startupsfortherestofus.com. You can find us in all the podcasting marketplaces and directories, just search for Startups.
If you’re interested in the full transcript or to make a comment on an episode, just hit up startupsfortherestofus.com. This was episode 474. Our theme music is an excerpt from We’re Outta Control by MoOt, it’s used under Creative Commons. Thank you for listening, and I’ll see you next time.
Episode 386 | Balancing Feature Development with Marketing, the Cost of Technical Debt, and More Listener Questions
/
RSS Feed
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike answer a number of listener questions. The topics include balancing development and marketing, overcoming hesitations about partnering, and the costs of technical debt.
Items mentioned in this episode:
Rob: In this episode of Startups for the Rest of Us, Mike and I talk about balancing feature development with marketing, the cost of technical debt, and answer more listener questions. This is Startups for the Rest of Us Episode 386.
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.
Mike: I have the plague.
Rob: We’re here to share our experiences to help you avoid the same mistakes we’ve made. You were sick all weekend?
Mike: Yeah. My eldest son got sick the last Wednesday, I think it was. It was like Wednesday and Thursday and we sent him back to school on Friday. Then my wife got sick between Friday and Saturday and then I got sick between Saturday and Sunday. It’s been a rough week to say the least.
Rob: Yeah. That’s brutal. Being sick just tears you up, means you can’t get anything done, especially when you don’t have vacation time, you don’t have to paid time off and you’re trying to drive a business forward, it’s like every hour is precious.
Mike: Yeah. Fortunately for us, it was kind of over the weekend but still we’re recording now, we don’t usually record till Thursday but today’s Monday and after this podcast episode, I’m probably gonna go to bed.
Rob: Right, right. Yeah. Today, we’re actually continuing kind of a continuation of last week’s episode. I had picked out several questions last week that you and I were gonna go through and answer and we only got through a couple of them because the GDPR conversation was so extensive. I think that was a good thing. I think we went in depth and gave ideas and feedback but it meant that we had this big block of unanswered questions and I wanted to keep going with them.
Now we have a few voicemails and some others today. But before we do that, I want to tell you, I know I haven’t talked about Drip features in a while but I’m pretty excited about this upcoming feature. We’ve been working on it for–I’m trying to think–it’s gotta have to be about four months now so it’s one of the larger features we’ve embarked on but it’s a visual email builder.
Mike: Oh, nice. What’s that involve?
Rob: A lot of stuff. Yeah, you can imagine not only the frontend which is obviously a lot of dynamic stuff, a lot of Javascript and pointing and clicking and moving things around the screen but then taking something that is essentially JSON and translating into the table-based email render to HTML is a challenge.
We found some AltSize and trade secret workarounds that we found, we’ve really done a lot of research and I think I’ve done a good job with it. But what I’ve heard from folks who have built visual email builders is building the visual portion of it is one project and it will takes six months or nine months, depending on how many […] we have on it and how good they are. Then just doing the table-based rendering and getting all of that to work and working all the clients is at whole separate project. It can take as long as building the actual visual builder. This is why a lot of upstart ESPs don’t build them because the time investment is so extensive.
Mike: When you say rendering the stuff and the clients–I understand what you mean by the differences between them–but when you go back to the visual email builder, what advantages does that have over what Drip does now?
Rob: Right. Today, Drip just has a nice little WYSIWYG text editor and I’m still gonna use that. I never use visual email builders because I like the personal interaction or it just feels more like you’re getting a plain-text email when you send using our standard plain-text template. This is how I’ve always recommended doing it. I believe the conversation rates are higher when you do that.
However, there are a few industries where they have done tests–so they’ve done tests across many industries in terms of visual email with a lot of images and table-based layout, two columns and this and that versus just something that kind of looks like a plain-text email, much like we send out to a MicroConf list, or I send out to my blogs Software by Rob list, they tend to be more personal. It’s from Rob Walling, Founder, it looks like he’s actually typing it to you. But there are few industries—ecommerce is one and travel is another—where having back these more exotic layouts and emails can and will convert better.
Since we do have a large ecommerce contingent and since we’ve been focusing on commerce-based businesses, people who are selling things, we have found a time to break ground on a visual builder. It allows you to do the things where you see the fancy, neat template, you can just insert your images and have that layout. It’s not something I’m gonna recommend for everybody but there are instances and match your converts better.
Mike: Got it. Kind of like if you go over to MailChimp for example, they’ve got like 30 or 50 different templates you can choose from and okay, that makes sense.
Rob: Exactly.
Mike: That makes sense.
Rob: Right. We won’t have 30 or 50 templates to start with but obviously that’s a direction that you’ll wind up going and it’s become table stakes. Again, in certain industries if you’re doing ecommerce and you’re working with companies using let’s say a platform like Shopify, BigCommerce, or WooCommerce, or if they have their own custom solution for ecommerce, they tend to want to send emails with a lot of images and not just to frustrate top to bottom flow where it’s image-text, image-text, you wanna have things that just look nicer than that.
Mike: Yeah. Things that come to mind for that are things like Amazon, Newegg, or ThinkGeek, all those, it’s exactly the same. I totally get what you’re saying where that’s going, but it totally makes sense.
Rob: Yup. The reason I’m excited about it is because I feel much like we did with workflows, we went back to the first principles and said, “What did everyone else do wrong? What do we hate about builders? How can we do this differently?” It isn’t just look at what everyone did and copy the best features, just like we’re doing things that are different than anyone else. There are obviously gonna be commonalities. There’s stuff on the left that you’re text and your image block and your divider and whatever, then there’s the email on the right. That’s common stuff but there’s certain paradigms that we use that I think are superior and gonna make for a better user experience.
The team has been working hard on it and everytime I see it down the road, I’m like, “Man, this is super cool, actually. I wanna use this even though I don’t really…” Like I said, I don’t use other visual builders as a rule when I’m writing my emails because I’ve always liked the more plain-text feel.
Mike: Awesome. Let’s dive right into the episode and they’ve got a couple of questions outlined here. Let’s get started on this.
Rob: For sure. Our first one is a voicemail and it’s about how to balance feature development and marketing specifically for an IOS app. But let’s hear the question and we can figure out what form we wanna answer it.
Steven: Hi Mike and Rob. This is Steven Johnson with […] Plus, an iOS and Mac app for hikers. My website is […]studios.com. I have a question about how you work […] user feedback. I’ve been getting a lot of feedback about my app on the Apple Watch, it’s still like I’m missing out on some opportunities as well as on just keeping up with where the market’s going.
However, right now I’ve really been prioritizing a lot of marketing efforts, working on conversion rates, lowering churn, […] partnerships with business development and […] by knowing […] you talk a lot about having more marketing always speeds out features and I completely agree with that. I’m just trying to figure out how do I kind of balance these two priorities and knowing how to balance user requests that come in, especially one that feel like the market’s making changes and I feel like am I missing out on something, maybe I am and maybe I’m not, but I know that there’s opportunities that I’m not capturing with my marketing, I know there’s conversion opportunities as well as churn that I need to work on. I’m just curious about your thoughts on that. Thanks for the show. Love what you guys do. Thanks.
Mike: I think this is an interesting question mainly because it’s an iOS and Mac app but there’s also the recurring annual subscription from productivity. I think the prices–there is a free plan–but then they range from $20 a year up to $80 a year which is of around what, $5-$8 a month, something along those lines. I think that the challenge here is identifying why that churn happens. Is it legitimately because people are churning out and they’re no longer using it or is it just they find that the app doesn’t help them nearly as much as they thought it would? I think it’d be easy to assume that, “Oh, you should be doing this.” Or, “You should be implementing that feature.” But I think I might dive a little bit more into the churn itself and start ask a lot more detailed questions about why the people aren’t using that.
My concerns/fear here would be that what you’re offering people is conceptually what they want but either the implementation itself is not really what they’re looking for or it doesn’t really quite match up with what the value proposition they were sold on is and it could turn out to be that somebody tries one app and they think that it’s gonna work and once they get out of the field and they’re using it, it sort of works or does most of what they want but it’s not quite enough so they just decide to switch and use something else. Maybe look at your performance metrics or your usability metrics to see like are people actually using it after three or four months in or is it that they’ve paid for and it was a low enough price point that they said, “Well, I paid $50 for this and it’s not a big deal so I’ll just try this other thing over here for another $50.”
As I said, the fear/concern that I would have is something that people use and it may just not be able to deliver on the promise. It’s not to say that you can never deliver on that promise. The fear that I have is it even possible to do what it is that they really want. I don’t know the answer to that, you have to ask people to find out. But as you said, the other component is like do you invest more on the marketing side and try and ramp it up or do you drill in and start trying to fix those things and add more features?
I think the first place to start to find out why people are churning out and what the fundamental issue is there and from there look back and say is it important enough for you to fix? The reason I say that is because there’s a question for road map and what is the most important to you, not roadmap, runway is more it than anything else, are you able to make ends meet with the app the way it is or are you chewing through runway and sort of losing money on it as you’re going along? In that case, you need to lean more towards scaling things up and then fixing things versus being able to make ends meet on a regular basis and you don’t have to worry about it as much. At that point, you can dig in and start fixing things in the app. That’s probably the place that I would start. Rob, I’m sure you have some thoughts on this as well.
Rob: Yeah. This is the age-old question. I think it’s a really good one to think about. I think in general, as developers, we think features are the answer, and in general, they are not. Not to say, all at all times because in certain markets, in certain niches, it really will make a big difference like Drip launching workflows was game changing for us, it doubled our month over month growth. It can happen.
But so many of the little features that are constantly being requested, if you have thousands of users you’re gonna get 50 or 100 feature requests a month and most of them you need to not build. Not only to keep the product simple enough that it doesn’t become bloated, but because you just don’t have the time to build them all. The caller is so much closer to his business than we are so it’s hard for me to make a recommendation to him, but my recommendation in general would be stir away from the mindset that I just need this one more feature to do this thing, unless everyone’s requesting it.
There comes a certain point where 10% of your feature requests are for the exact same feature. At that point, that’s when we break down–in the early days, we build a lot more now, we have a team of 18 developers or whatever, but in the early days when we were super cash and resource trapped, it was pretty much no by default and yes to these highly focused things that we knew were gonna move the needle. That’s how I balance it.
I think that the caller’s approach to doing joint ventures and focusing on marketing is genius. That’s exactly what I would be doing because the more marketing you do, assuming it’s effective, the more revenue you get, and that revenue will allow you to then hire a contractor in essence or perhaps the first time employee, how ever you wanna work it. But hire a developer that you can supervise because that will then, I should take one step back first, first person I would hire is a part-time VA to handle all your support, if you’re still handling that, because that will free up.
Then start thinking about hiring someone to write the code and this is the part that developers always struggle with because no one “is going to write the code as well as I do.” However, if you can free up 12-30 hours of your time in a week and features are still moving forward and you have some budget to pay someone, it can be game changing for your business and that frees you up to focus on really moving the needle.
I think marketing in the early days is such a big deal because you need to get the revenue to allow yourself to start stepping away from certain roles that while you may enjoy doing them are probably in the early days are less effective and what more if the needle is matched.
Thanks for the question. I hope that was helpful. Our next question is about overcoming hesitations about partnerships to move the business forward.
Joshua: Hi Mike and Rob. This is Joshua from [Perspexa Labs]. First, thanks so much to this podcast. Every episode is invaluable. My question is this, how do I overcome my hesitancy of partnering with someone to move the business forward?
For context, I run a B2B SaaS company that offers monthly subs in the range of 100-350 a month, and we’ve plateaued about $2,500 in MRR I co-founded the business with an office colleague but I just realized circumstances he really isn’t able to participate materially in the business anymore and our product is solid at this point but I know we need to move the needle and sell the marketing in a big way. Try as I might, I just can’t seem to crack that nut.
I know that finding the right person to bring onboard will probably do wonders and turn us into a vital business but on a do-it-yourself-er and I just have trouble, one, convince myself that I ought to do this, and two, coming up with the vital way to achieve it. Any advice for effectively a solopreneur who doesn’t wanna be stuck in a half business for forever? Thanks so much for the both of you. Everyone, go leave a review to this podcast on iTunes. Thanks guys. Bye.
Rob: Joshua was kind enough to also send us an email with a bit more background and he said, “The main product outreach is at [perspexalabs.com], we’ve got a core group of customers and service businesses like pest control and electricity and we’ll soon be getting into healthcare providers because our revenue is only $2,500 a month with margins of around 70%. It’s not enough yet to pay salaries. I’m guessing that bringing someone onboard will probably need to be an equity arrangement which I’d be fine with.
With regards to my own efforts to sales and marketing I’ve gone to the Traction book and tried several different approaches including online ads, cold-calls, cold-email outreach and attended a very targeted trade show. That really hasn’t generated fruit as nearly all of our current customers are referrals from other customers. Unmentioned to my question bills are related issue, should I let my current co-founder remain in the business? I’d really like him to be here if we can get into healthcare because of his connections, but I know this isn’t the first priority anymore.” What do you think, Mike? It’s a tough one.
Mike: Yeah. I think you can almost divide this into two entirely different things. One of which is what to do about the co-founder and then the other is how do you move the business forward when you’ve got $2,500 a month and not enough money to do a lot and you’ve also obviously got the co-founder onboard and I don’t know what the relationship there is in specifically call that out.
Rob: It sounds like it’s still amicable and he’d like to keep him on if they were to go into healthcare but not if they don’t. You don’t know if they vested so the first thing is that you should have done four year vesting probably so that your co-founder wouldn’t own the entire percentage that they had. Because if they decide to leave, that will go back into the pool to get the next person.
Mike: I think, with regards to what to do about the co-founder, that’s probably the first thing to do. It sounds like you wanna keep them on but the question is how much is he going to be able to contribute. As Rob said, the vesting schedule maybe he owns 25% because he’s stuck around a year, 50% because he’s stuck around for 2 years. That seems to me like the first thing to look at and try and figure out and if he has to walk away because he’s just not involved, that doesn’t mean he still doesn’t own a certain percentage of the business anymore and can’t contribute under the […] capacity or something along those lines. That’s something I think you have to work out with your co-founder and sit down and have an honest conversation about what him stepping away from the business really means for the business and for the relationship between you guys.
Then once you’ve figured that out, the next question to tackle is what do you do about the business itself. I think you didn’t specify what your own personal situation is or whether you’re taking money from the business and living off of it. But with the $2,500 a month, it sounds to me like because you’re a do-it-yourself-er, it might be a viable strategy to go out and find a business coach who can walk you through a bunch of different things and that does a couple of things.
One, is it avoids handing equity over to somebody else, and two, it still allows you to do those things yourself and you get that personalized assistance from somebody else and a sounding board from somebody who’s vested in the business because you are paying them to give you ideas and take a hard look at what it is that you’re doing and how effective those things are but you’re still doing those things yourself and you still don’t necessarily hand over control to a third party or a co-founder or another partner in the business and avoid some of those other issues that maybe you’re struggling with right now.
I don’t think that it’s wise to introduce too many changes all at once. That could be a nice bridge scenario where you are involving somebody else but you’re not handing over the reins to somebody else in a co-founder capacity while you’re having your current co-founder step away from the business a little bit. That’s probably where I’d start looking and see if that makes sense to you.
Rob: Yeah. I think you’re right, there are two separate issues here, it’s existing co-founder and then pulling on a new partner. I think given that the business you have to de-risk the business a small amount that bringing on a new partner, you could obviously give equity without giving an enormous amount. It wouldn’t need to be a third of the equity or something. It depends on your aspirations and think where the business is headed and who you can find but I’m thinking in the 10%-20% range given where you are. If you were gonna go raise funding and you’re gonna go try to find like a COO or something or a CTO, they get 5%, but you’re in a little bit different situation because it doesn’t sound like you’re gonna get so big so fast, that that’s gonna be warranted. As a result you have to bump that equity to 10% or 15% or whatever. But at this point, in my opinion wouldn’t just be an even split.
I think the hard part is finding that person and vetting them and it’s like a marriage because you guys are gonna have shared ownership of things and breaking that up later can be like a divorce. I think getting over your hesitation is one thing, but I think the harder thing is to find someone who is good enough or who’s gonna work with your style, who’s willing to be in the trenches with you, who I think it really wants to stick around and is able to work because it sounds like this is gonna be nights and weekends, people are not cut out for that in general, most people just think they wanna do it and then a month or two months and they just flick out or they just decide not to do it.
I think finding someone who meets all this criteria is really hard but I think if you can, then what I would look at doing is definitely have kind of a trial period, maybe 90 days, just to say how things feel, I would definitely have four year vesting on that with the one year cliff, meaning they don’t get any shares until they’ve been around for a year. I think that’s how I would approach it and I would look to be meeting people in person so I would be going to the MicroConfs and the businesses software and these conferences where there are folks who could potentially be in that pool for you separately regarding your current co-founder. I think you just need to make the choice sooner rather than later whether they’re going to healthcare. If you’re gonna go onto it and he wants to stay around, you wanna keep him around, that’s great, and if you’re not, then I think the decision is made there.
I know it’s not always that crystal clear but it does, given that information you’ve provided, seem perhaps how I would perceive. Thanks for the question, hope that was helpful.
The next question is about technical debt. Mike, does technical debt really come back to bite you?
Mike: Oh, yeah. No question on that.
Rob: Alright. The subject line of the email is actually, “Have technical debt decisions been easy to pay down later or did they really come back to bite you?” He says, “Love the show, listened for the past year, really love the practical advice. I’m looking for your technical perspective about what matters in the early days of getting a site running while keeping customers happy with mission critical data, building a data heavy B2B SaaS startup.
The frontend is in Angular, the backend is in Rails, intermediate self-taught developers, new things I haven’t done before can sometimes take a week or two to figure out. I’m making early technical debt tradeoffs hosting using Heroku versus AWS, database PostgreSQL versus Aurora, and the other miscellaneous things relating to data structures.
I’m not looking for technical help but the question is more geared to your experience of how much this stuff matters up front and really needs to be solved to get functional versus it’s not too hard to change it later. Theoretically important but won’t kill you so pick the simpler thing even if you know you’ll need it to change it after launch. Am I wasting a lot of time by taking the shortcut now and having to pull the app apart later to move it around when I have real customers using it in production?”
Mike, this is not gonna be as long as GDPR, I promise, but I feel like we have a lot to say on this, so go. Just start rolling with this. What do you think?
Mike: Yeah. Do we have like beeps cued up immediately for all the profanity that’s about to be dropped on this?
Rob: Yeah. Technical debt, it’s a *.
Mike: Yes, it is, yes, it is. I think looking back on this particular piece of it, some of the things that he had brought up, the things like hosting and the database selection and the data structures that you’re using on a backend, some of those can be really hard to change later on, versely impossible. In some cases, you’re looking at a complete rewrite.
You at least have to have enough technical knowledge to make those decisions in a way that is not going to completely kill the app later on or force you to do an absolute rewrite from the ground up. That said, I do know people who have done complete rewrites after they’ve gotten to a point where they’ve gotten customers onboard and it basically delays things, you may have to take three, six, nine months of accepting the fact that you’re just not gonna make any progress on the features in order to fix that fundamental positions that will bust it.
Then, there’s kind of a second level which is where you’re trying to make decisions about how do you structure the data or how do you create the database in such a way that it makes easy to do certain queries or provide a solid error handling, error returns to the API for example. I think in those cases, you can mitigate them to some extent by using dependency injection and creating these interfaces that sit in front of it and if you need to rewrite one, then you can, you’re almost swapping out an entire layer of the application for another in a very specific way.
I’ll give an example with Bluetick, like the backend storage system for storing emails has been rewritten four times. It’s because at first it was like let’s just get something working and then it was trying to optimize for local storage and then the next level was things are not working in local storage because there’s so much data coming in at all times like I just can’t scale that much on one machine and then I kind of move everything into the cloud and into the Azure tables in no sequel storage. Then the fourth rewrite was essentially making that more scalable and optimized.
Each level on the way like there was some level of rewrite but because it was essentially being able to flip a switch and say instead of using this set of data structures, you can do those on a per user basis or on small sub-segments of the users and not affect others. I would definitely do some research on dependency injection.
The other nice by-product of them is that it helps with writing unit test to be able to make sure that those things that are working from one version of your rewrite to the next in that particular component or module. Beyond that, there’s always gonna be things that you run into where you think that one way is a good way to solve a technical challenge and you turn around and find that it just wasn’t, you get down in the weed sometimes and you realize that you made a really, really big mistake and the only way to resolve that at that point is to rewrite it and there’s nothing you can do at that point.
The only way to have mitigated those four types of problems is to run into them and then realize after the fact that it was a mistake. It’s really hard to generalize from one application or problem space to the next and say like, “Oh, you should never do it this way. You should always do it this way.” Those things don’t apply. Each problem space has its own unique way of storing data or things that need to be surfaced to the user and you don’t always know what those are until afterwards. Sometimes, you just make the best decision that you have and you find out later that it was wrong, there’s nothing you can do.
Rob: Yeah. I would just say in general, technical debt is underrated in the startup space. I think people think that it’s not a big deal and it’s a way bigger deal than most people do because if you aren’t technical, it’s hard to understand why you can’t just quickly rewrite a piece or quickly change a decision you made later. These metaphors don’t always work but it’s akin to building a building and then needing to go back and replace the concrete foundation because you poured it incorrectly. You literally have to jack the building up and it’s just painstaking and agonizing to replace that and that’s what code is. You’re building things on top of each other.
I think of it like a 4×4 matrix where there’s basically two binary things. One is I know that this is a shortcut and I’m gonna take it anyways versus I don’t know this is a shortcut like I accidentally introduced technical debt. I think that’s the switch you’re talking about.
Then I think the other one is it’s easy to undo later versus it’s a complete fiasco to undo it. You can imagine that 4×4 matrix and we’ll go through all of those matching up but obviously any decision you make on purpose to introduce technical debt, you need to explore and thought experiment like how hard is this to undo later. If it’s hard, then don’t do it.
There were a lot of decisions Derrick and I made in the early days that were very slow, they caused Drip development to be very slow in the early days and it was pretty agonizing when we were bleeding cash and we couldn’t get the features out the door to keep people from churning because it was a very specific feature set that people wanted, and it was taking us months to build them and it was because Derrick wanted to build them very carefully with extensive unit test and he wanna do it right and he had to refactor the database twice in the first year of the app, because the app went from a very simple thing to very complicated thing.
It was agonizing but it was the right decision, because now, it would be catastrophic right now, we would probably have to have rewritten major parts of Drip. I don’t know if it would have impacted the acquisition or if it just would have been post acquisition or what it would have been but it would have been really hard and between he and I, we figured out a good sense of what was gonna be hard to change later–things that are easier to change later like you said where you can just build an interface and then swap it out later. Obviously those are the ones that you can maybe take shortcuts on.
But I think some people take shortcuts on like not running unit test, some people make cold-quality shortcuts where they just start hacking things together and later on, everything’s buggy because you took a shortcut and you didn’t build that right in the first place. In general, I have seen no less than half a dozen or maybe closer to a dozen companies get to the point where they’re between 10k and 50k MRR, they’re growing fast and they have to rewrite their entire codebase. I’ve seen some that have done it more than ones.
It is so painful to spend six months of standing still while your competition gains on you because you took shortcuts in the early days. Now, you’re just hanging out, waiting to build more features until your codebase can be completely rewritten. I would say proceed with caution, obviously, you’re always gonna have some level of technical debt, but be very deliberate about those choices because I think it’s easy to be in such a hurry to get to the point where you have more revenue and this is certainly a tradeoff because in the early, early days, when you just trying to get to $5,000 or $10,000 revenue, you’re gonna have to make some trade offs but try to take shortcuts on things that are easy to change later. That’s how I think about it.
Mike: I think one of the biggest places to make that trade off is that when you’re looking at unit tests, I’m not saying you write unit tests for everything because I certainly don’t think that that has a ton of value for a startup but I do think that there’s value in having like continuous integration server of some kind or a build system put in place so that later on you don’t have to figure out, “Okay, how am I gonna deploy my app?” You want that to be a systematic thing where you can literally just click a button and it runs through everything and is able to deploy the app.
But with that comes at least some level of unit tests or a mechanism for running those, and even if you don’t write a ton of unit tests, as bugs come in, you should be adding those unit tests to make sure that if a bug comes in and it breaks something that you had a unit test in there so that later on, as you’re making other changes, it doesn’t break that again.
Like I said, I don’t think you should write unit tests for everything, but I do think that as those bugs come in you should be writing them to make sure that once you fix a particular problem that you don’t have to refix it 3, 4, 5, 10 different times moving forward because it just keeps coming up.
Rob: Thanks for the question. I hope that was helpful.
Next question is from Jay Pablo Fernandez and he says, “I just finished going through all my newsletter subscribers and I noticed there are a few industries that are well-represented such as education, health, IT and government. When it comes to my product, they all use it in the same way. The feature set they made is pretty much the same. I wouldn’t say they are verticals in the SaaS way of thinking. I can sell to all of them or I can focus on one industry. Are there any advantages to either approach?”
Mike: I think this is a tough question, as you said you don’t wanna paint yourself into a corner and make people think that you don’t serve their industry. I think what I would do in this case sn focus on the specific problem that you solve and then maybe have different case studies for each of those industries and even segment your list a little bit so that when you talk to them, when you’re sending out newsletters or you’re sending out articles to them, maybe you’ll only send an article that highlights a case study for the electric and gas industry to those people who were subscribers that fit into that bucket. It seems to me like that would probably be an appropriate way to go, but at the same time there’s value to be had to for saying, “Hey, this also works in other industries because there’s gonna be some crossover between them.”
Let’s say that you have a case study on the nuclear power plant industry, if it’s safe enough for them to use, pure application, then whatever other industry they happen to be in, they would probably translate that and say, “Oh, well, if these guys are using it, then surely it’s passed master and I could use it as well.” I would think about it in terms of just trying to make sure that you’re covering enough of each of them but not focusing so hard on any of them that it makes people think that, “Oh, this is not for me.”
Rob: I think I might try to run an experiment. He has this list and he has these four sectors, four verticals, and I would consider trying to do physically exploratory calls, I don’t know if you wanna call it customer development or even just sales calls, if the product’s already there, across all of them, and figure out that you wanna validate your assumption that they use it in the same way with the same feature set. Because I find that a little bit hard to believe, just having run the apps that I’ve run, different industries tend to want slightly different feature sets and have a slightly to just enough it settle but by the time you really get and they start using it, it becomes a pain-in-the-butt to have four different industries or wanting something just slightly, “Oh, just tweak this one thing, oh, can I just have a setting to do this? But we have a permission in the reporting thing.” It’s just enough that there will be a difference. I guess it’s what I’m guessing.
If you have the time to do this upfront and just have a bunch of phone calls with these folks and try to do the demos and try to figure out is it truly gonna be something that they all can use, then that’s fine. But I do think you’re gonna find differences in payment terms, like you said sales cycle because government’s gonna take forever to come through, maybe in your early days since you’re trying to get ahead of funding running out or whatever, you go after the ones that close quickest, which I don’t know if that’d be IT, education, sure it seems like it’s gonna take a long time too, so focus on the one that are gonna close the quickest and get the early value in order to keep around long enough to focus on all four.
But I would try to answer that question, there’s still a question in my mind of is the product actually gonna serve all four? If that’s the case and you can work your entire list and work all four of them at once and try to get as many customers paying you on day one, then that’s what I would do. Right now, you’re just trying to get revenue and see how people use the app and if they’re gonna get value out of the app and there are across four different industries, then you’re gonna learn more about all four and maybe later you decide to focus down on one industry.
I do think that there are some advantages focusing on one industry in terms of how your marketing can really speak to people so you’re gonna close more deals probably, how you are sales conversation can focus on them, how your features set can focus, and how word of mouth would be such a big component of it. Assuming that people in your industry hang out at conferences, or hang out online, word of mouth if you just become the defacto in in the industry and in a vertical then you can land and expand words like, “Alright, we are the go-to for this task in the IT space. Now we’re gonna start adding on these other verticals.”
That’s the other way to approach it. It’s just a pick one based on your information so far, your best guess, and then later on, a year or two down the line, once you own a big chunk of this, you’ll expand into the others but I feel like you don’t have enough information to do either approach right now and I would try to close as many deals as I could, see if they actually will all use it and then try to make the decision once you have a little more information.
For our final question of the day, we have a question from Ed Freyfogle. He was a MicroConf Europe speaker this year. He says, “Hey, guys. Long time listener, first time asker. One target audience of my SaaS service is academic researchers. They are not the best customers as typically they’re low budget and they only need this service for a project or semester. Nevertheless their niche seems to like my service. Often they ask for academic discounts. My pricing is already very affordable and I offer discounts for annual purchases. Still, I can’t help but wonder if I might be able to grow this niche by offering an academic discount.
Alternatively, I have also thought about selling to universities and offering them a bulk rate. But so far I’ve always been busy with other things so I haven’t acted on this idea. I’m wondering if you guys have any advice on academic discounts in general, how to ensure they are not abused by other customers and selling to universities. Thanks for the great show, I learn a lot.”
This is a tough question. I like the fact that he’s thinking pretty strategically about it. I think that if you haven’t had the time to try to sell to the universities and offer them a bulk rate, if you haven’t made the time, it’s probably not that important. That’s where I found like this is right. It’s like you go toward the money’s coming in and your biggest fires are. I’m guessing that unless you are to hire someone to handle that that it’s not gonna make it to the top of your to-do list anytime soon.
I tend to think about discounts in two ways. There is academic and then there’s non-profit discounts. I don’t know if you have a non-profit discount as well, that’s something that I would consider modelling it after and there you just ask for proof of their non-profit status which can totally be abused. I think with DotNetInvoice we had profit one and it was maybe 1 in 20 or 1 in 30 who ask for it and show the stock seemed a little bit like, “You signed up with this just to get the discount.”
In terms of academic stuff, it depends on what volume you have coming in, it’s like if it really isn’t education it’s 1 in 50 people ask for it. You can always have an unpublished academic discount and you just need to get proof from them, I don’t know it’s a student ID or if it’s a professor ID, what it is, but it’s gonna be a process, it’s fairly lightweight. I personally don’t see a huge drawback to doing it. I’m curious when people email and ask for academic discounts and you say no, how many sales do you think you loose? Is it worth even doing any of this effort to get those sales?
Your pricing is already reasonable, if you offered another 20%, 30%, 40% off for academic discounts and that’s probably the range, I would think, although I haven’t done any research about this, but mentally it would be in that range. Is that worth it if you have to go through validation of some type of ID, I don’t know, there’s some trade offs here.
If the volume is high enough that you’re asking this question, I would probably just do an experiment where the next time I got an email about it, I would say, “Yes, we have a 25% discount, but you have to prove you’re a student or you’re faculty.” See where it goes from there and handle it as a one off to start and then I don’t know if it has support people or not, but if you distract them to do that and then tally up in a Google Spreadsheet how often it gets asked and which sales come through, you can start getting at least a little bit of data about it.
Those are my initial thoughts without a ton of experience, to back that up, it’s more of the got feel, so much of entrepreneurship is making enough as you go along. It’s just figuring out what’s the priority and making the best judgment call based on the information you have. What do you think, Mike? You have other thoughts?
Mike: I’ve looked at the academic discounts in the past. You just do a quick search for academic discounts for software and you’ll find that they can be upwards of 85% which is extremely high especially for something like a SaaS, I mean. Is the money that you’re getting even enough to offset the cost of you actually doing business for that person? I don’t know the answer to that. I think you need to figure out what that is.
Rob: Yeah. I know that Microsoft and Adobe and those guys discount because they’ve been pirated so much. Too often students who don’t have the money and they do these huge discounts. When you’re a SaaS app, especially when you’re Bootstrap like this and cash is important, there’s no chance I would offer a discount that large.
Mike: Yeah. I mean I think that part of the reason that those types of companies offer discounts that are high is one, it’s downloadable software so they don’t have to worry about their own cost, and two, they’re really just trying to make sure that there’s some form of legitimacy for the software that you’re using and giving that high of a discount helps them to get market penetration so that Microsoft has 90% market penetration on the best app for Office and Windows.
I agree, I wouldn’t go that high, but it’s not to say that you couldn’t have a discount for students versus a discount for academic researchers/the university itself. Because if somebody’s using it for a class, then they’re probably not going to be able to pay nearly as much as the person who’s doing it for the university and offering it on behalf of the class itself. I might think about that, but I do agree with Rob that you probably want to go through and run at least some tests to find out like what is it that people are using it for.
Something else to consider is that if somebody is purchasing it on behalf of the classroom because they’re teaching it, what’s the value of having those people in the class know about your product and then they leave and graduate and go out and do things in the workforce and having them know, “Hey, I can come over to opencagedata.com and buy this stuff off-the-shelf and we use it in our classroom so it has a lot of legitimacy.” There’s probably some value in that, I don’t know what that level is because I mean if you go through like an engineering degree, chances are good you’ll probably use Autocad some place along the way. When you get out into the industry like you first thought is, “Oh, I need to create some 3D models of something. Where’s the copy of Autocad?” There’s a student discount that you can get but once you get out in that at the real world, your company has to pay for it.
Having those people go to their bosses and say, “Hey, I use this data over here from opencagedata.com. We should buy a license for that.” There’s value there. I don’t know what that is but I definitely think there’s some value there. I would look into it, I don’t know how much time and effort I would spend on it because the return on that is probably gonna be wild. It’s gonna be a couple of years.
Rob: Yeah. Those are good points. I like your idea of not making an academic discount but making it a student discount. It’s an interesting thing because students really don’t have the money whereas if a university is buying it for a class, they do have some budget, and he’s right, his prices are reasonable like a university should be able to afford it.
Mike: Even with like a student. A student could probably get away with a free trial or even like the extra small plan that they have there for like a class or project or something like that but the university, if it’s for a class, and they’re buying it on behalf of the students for a class, I’ll offer them a 30% discount if you’re a student and you just want to use it for yourself, maybe it’s a 60% discount. I don’t know, but if you separate them, I think that there’s a way of targeting those people in that way that says, “Oh, we give individual students 60% and for universities we give them 30%.” It shows that you’re doing both. It shows you’re helping out on both sides.
Rob: It’s a question of whether or not the volume of incoming request warrant spending the time to figure all this out. If the answer is no, we have reasonable prices and we aren’t able to support any of these because you don’t have the bandwidth. It’s less about money and it’s more about Bootstrap startup with not a lot of time and just having yet another program to maintain and then we have to get a fax of your idea or an email with a screenshot and then check that off that it’s approved and then they just want more process that you have to wait if that’s gonna be worth it for in order to make another few discounted sales.
Mike: Thanks for the question, Ed. I think that about wraps us up for the day. If you have a question for us, you can call it into our voicemail number at 1-888-801-96-90 or you can email to us at questions@startupsfortherestofus.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 and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening and we’ll see you next time.
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.
Mike: I have the plague.
Rob: We’re here to share our experiences to help you avoid the same mistakes we’ve made. You were sick all weekend?
Mike: Yeah. My eldest son got sick the last Wednesday, I think it was. It was like Wednesday and Thursday and we sent him back to school on Friday. Then my wife got sick between Friday and Saturday and then I got sick between Saturday and Sunday. It’s been a rough week to say the least.
Rob: Yeah. That’s brutal. Being sick just tears you up, means you can’t get anything done, especially when you don’t have vacation time, you don’t have to paid time off and you’re trying to drive a business forward, it’s like every hour is precious.
Mike: Yeah. Fortunately for us, it was kind of over the weekend but still we’re recording now, we don’t usually record till Thursday but today’s Monday and after this podcast episode, I’m probably gonna go to bed.
Rob: Right, right. Yeah. Today, we’re actually continuing kind of a continuation of last week’s episode. I had picked out several questions last week that you and I were gonna go through and answer and we only got through a couple of them because the GDPR conversation was so extensive. I think that was a good thing. I think we went in depth and gave ideas and feedback but it meant that we had this big block of unanswered questions and I wanted to keep going with them.
Now we have a few voicemails and some others today. But before we do that, I want to tell you, I know I haven’t talked about Drip features in a while but I’m pretty excited about this upcoming feature. We’ve been working on it for–I’m trying to think–it’s gotta have to be about four months now so it’s one of the larger features we’ve embarked on but it’s a visual email builder.
Mike: Oh, nice. What’s that involve?
Rob: A lot of stuff. Yeah, you can imagine not only the frontend which is obviously a lot of dynamic stuff, a lot of Javascript and pointing and clicking and moving things around the screen but then taking something that is essentially JSON and translating into the table-based email render to HTML is a challenge.
We found some AltSize and trade secret workarounds that we found, we’ve really done a lot of research and I think I’ve done a good job with it. But what I’ve heard from folks who have built visual email builders is building the visual portion of it is one project and it will takes six months or nine months, depending on how many […] we have on it and how good they are. Then just doing the table-based rendering and getting all of that to work and working all the clients is at whole separate project. It can take as long as building the actual visual builder. This is why a lot of upstart ESPs don’t build them because the time investment is so extensive.
Mike: When you say rendering the stuff and the clients–I understand what you mean by the differences between them–but when you go back to the visual email builder, what advantages does that have over what Drip does now?
Rob: Right. Today, Drip just has a nice little WYSIWYG text editor and I’m still gonna use that. I never use visual email builders because I like the personal interaction or it just feels more like you’re getting a plain-text email when you send using our standard plain-text template. This is how I’ve always recommended doing it. I believe the conversation rates are higher when you do that.
However, there are a few industries where they have done tests–so they’ve done tests across many industries in terms of visual email with a lot of images and table-based layout, two columns and this and that versus just something that kind of looks like a plain-text email, much like we send out to a MicroConf list, or I send out to my blogs Software by Rob list, they tend to be more personal. It’s from Rob Walling, Founder, it looks like he’s actually typing it to you. But there are few industries—ecommerce is one and travel is another—where having back these more exotic layouts and emails can and will convert better.
Since we do have a large ecommerce contingent and since we’ve been focusing on commerce-based businesses, people who are selling things, we have found a time to break ground on a visual builder. It allows you to do the things where you see the fancy, neat template, you can just insert your images and have that layout. It’s not something I’m gonna recommend for everybody but there are instances and match your converts better.
Mike: Got it. Kind of like if you go over to MailChimp for example, they’ve got like 30 or 50 different templates you can choose from and okay, that makes sense.
Rob: Exactly.
Mike: That makes sense.
Rob: Right. We won’t have 30 or 50 templates to start with but obviously that’s a direction that you’ll wind up going and it’s become table stakes. Again, in certain industries if you’re doing ecommerce and you’re working with companies using let’s say a platform like Shopify, BigCommerce, or WooCommerce, or if they have their own custom solution for ecommerce, they tend to want to send emails with a lot of images and not just to frustrate top to bottom flow where it’s image-text, image-text, you wanna have things that just look nicer than that.
Mike: Yeah. Things that come to mind for that are things like Amazon, Newegg, or ThinkGeek, all those, it’s exactly the same. I totally get what you’re saying where that’s going, but it totally makes sense.
Rob: Yup. The reason I’m excited about it is because I feel much like we did with workflows, we went back to the first principles and said, “What did everyone else do wrong? What do we hate about builders? How can we do this differently?” It isn’t just look at what everyone did and copy the best features, just like we’re doing things that are different than anyone else. There are obviously gonna be commonalities. There’s stuff on the left that you’re text and your image block and your divider and whatever, then there’s the email on the right. That’s common stuff but there’s certain paradigms that we use that I think are superior and gonna make for a better user experience.
The team has been working hard on it and everytime I see it down the road, I’m like, “Man, this is super cool, actually. I wanna use this even though I don’t really…” Like I said, I don’t use other visual builders as a rule when I’m writing my emails because I’ve always liked the more plain-text feel.
Mike: Awesome. Let’s dive right into the episode and they’ve got a couple of questions outlined here. Let’s get started on this.
Rob: For sure. Our first one is a voicemail and it’s about how to balance feature development and marketing specifically for an IOS app. But let’s hear the question and we can figure out what form we wanna answer it.
Steven: Hi Mike and Rob. This is Steven Johnson with […] Plus, an iOS and Mac app for hikers. My website is […]studios.com. I have a question about how you work […] user feedback. I’ve been getting a lot of feedback about my app on the Apple Watch, it’s still like I’m missing out on some opportunities as well as on just keeping up with where the market’s going.
However, right now I’ve really been prioritizing a lot of marketing efforts, working on conversion rates, lowering churn, […] partnerships with business development and […] by knowing […] you talk a lot about having more marketing always speeds out features and I completely agree with that. I’m just trying to figure out how do I kind of balance these two priorities and knowing how to balance user requests that come in, especially one that feel like the market’s making changes and I feel like am I missing out on something, maybe I am and maybe I’m not, but I know that there’s opportunities that I’m not capturing with my marketing, I know there’s conversion opportunities as well as churn that I need to work on. I’m just curious about your thoughts on that. Thanks for the show. Love what you guys do. Thanks.
Mike: I think this is an interesting question mainly because it’s an iOS and Mac app but there’s also the recurring annual subscription from productivity. I think the prices–there is a free plan–but then they range from $20 a year up to $80 a year which is of around what, $5-$8 a month, something along those lines. I think that the challenge here is identifying why that churn happens. Is it legitimately because people are churning out and they’re no longer using it or is it just they find that the app doesn’t help them nearly as much as they thought it would? I think it’d be easy to assume that, “Oh, you should be doing this.” Or, “You should be implementing that feature.” But I think I might dive a little bit more into the churn itself and start ask a lot more detailed questions about why the people aren’t using that.
My concerns/fear here would be that what you’re offering people is conceptually what they want but either the implementation itself is not really what they’re looking for or it doesn’t really quite match up with what the value proposition they were sold on is and it could turn out to be that somebody tries one app and they think that it’s gonna work and once they get out of the field and they’re using it, it sort of works or does most of what they want but it’s not quite enough so they just decide to switch and use something else. Maybe look at your performance metrics or your usability metrics to see like are people actually using it after three or four months in or is it that they’ve paid for and it was a low enough price point that they said, “Well, I paid $50 for this and it’s not a big deal so I’ll just try this other thing over here for another $50.”
As I said, the fear/concern that I would have is something that people use and it may just not be able to deliver on the promise. It’s not to say that you can never deliver on that promise. The fear that I have is it even possible to do what it is that they really want. I don’t know the answer to that, you have to ask people to find out. But as you said, the other component is like do you invest more on the marketing side and try and ramp it up or do you drill in and start trying to fix those things and add more features?
I think the first place to start to find out why people are churning out and what the fundamental issue is there and from there look back and say is it important enough for you to fix? The reason I say that is because there’s a question for road map and what is the most important to you, not roadmap, runway is more it than anything else, are you able to make ends meet with the app the way it is or are you chewing through runway and sort of losing money on it as you’re going along? In that case, you need to lean more towards scaling things up and then fixing things versus being able to make ends meet on a regular basis and you don’t have to worry about it as much. At that point, you can dig in and start fixing things in the app. That’s probably the place that I would start. Rob, I’m sure you have some thoughts on this as well.
Rob: Yeah. This is the age-old question. I think it’s a really good one to think about. I think in general, as developers, we think features are the answer, and in general, they are not. Not to say, all at all times because in certain markets, in certain niches, it really will make a big difference like Drip launching workflows was game changing for us, it doubled our month over month growth. It can happen.
But so many of the little features that are constantly being requested, if you have thousands of users you’re gonna get 50 or 100 feature requests a month and most of them you need to not build. Not only to keep the product simple enough that it doesn’t become bloated, but because you just don’t have the time to build them all. The caller is so much closer to his business than we are so it’s hard for me to make a recommendation to him, but my recommendation in general would be stir away from the mindset that I just need this one more feature to do this thing, unless everyone’s requesting it.
There comes a certain point where 10% of your feature requests are for the exact same feature. At that point, that’s when we break down–in the early days, we build a lot more now, we have a team of 18 developers or whatever, but in the early days when we were super cash and resource trapped, it was pretty much no by default and yes to these highly focused things that we knew were gonna move the needle. That’s how I balance it.
I think that the caller’s approach to doing joint ventures and focusing on marketing is genius. That’s exactly what I would be doing because the more marketing you do, assuming it’s effective, the more revenue you get, and that revenue will allow you to then hire a contractor in essence or perhaps the first time employee, how ever you wanna work it. But hire a developer that you can supervise because that will then, I should take one step back first, first person I would hire is a part-time VA to handle all your support, if you’re still handling that, because that will free up.
Then start thinking about hiring someone to write the code and this is the part that developers always struggle with because no one “is going to write the code as well as I do.” However, if you can free up 12-30 hours of your time in a week and features are still moving forward and you have some budget to pay someone, it can be game changing for your business and that frees you up to focus on really moving the needle.
I think marketing in the early days is such a big deal because you need to get the revenue to allow yourself to start stepping away from certain roles that while you may enjoy doing them are probably in the early days are less effective and what more if the needle is matched.
Thanks for the question. I hope that was helpful. Our next question is about overcoming hesitations about partnerships to move the business forward.
Joshua: Hi Mike and Rob. This is Joshua from [Perspexa Labs]. First, thanks so much to this podcast. Every episode is invaluable. My question is this, how do I overcome my hesitancy of partnering with someone to move the business forward?
For context, I run a B2B SaaS company that offers monthly subs in the range of 100-350 a month, and we’ve plateaued about $2,500 in MRR I co-founded the business with an office colleague but I just realized circumstances he really isn’t able to participate materially in the business anymore and our product is solid at this point but I know we need to move the needle and sell the marketing in a big way. Try as I might, I just can’t seem to crack that nut.
I know that finding the right person to bring onboard will probably do wonders and turn us into a vital business but on a do-it-yourself-er and I just have trouble, one, convince myself that I ought to do this, and two, coming up with the vital way to achieve it. Any advice for effectively a solopreneur who doesn’t wanna be stuck in a half business for forever? Thanks so much for the both of you. Everyone, go leave a review to this podcast on iTunes. Thanks guys. Bye.
Rob: Joshua was kind enough to also send us an email with a bit more background and he said, “The main product outreach is at [perspexalabs.com], we’ve got a core group of customers and service businesses like pest control and electricity and we’ll soon be getting into healthcare providers because our revenue is only $2,500 a month with margins of around 70%. It’s not enough yet to pay salaries. I’m guessing that bringing someone onboard will probably need to be an equity arrangement which I’d be fine with.
With regards to my own efforts to sales and marketing I’ve gone to the Traction book and tried several different approaches including online ads, cold-calls, cold-email outreach and attended a very targeted trade show. That really hasn’t generated fruit as nearly all of our current customers are referrals from other customers. Unmentioned to my question bills are related issue, should I let my current co-founder remain in the business? I’d really like him to be here if we can get into healthcare because of his connections, but I know this isn’t the first priority anymore.” What do you think, Mike? It’s a tough one.
Mike: Yeah. I think you can almost divide this into two entirely different things. One of which is what to do about the co-founder and then the other is how do you move the business forward when you’ve got $2,500 a month and not enough money to do a lot and you’ve also obviously got the co-founder onboard and I don’t know what the relationship there is in specifically call that out.
Rob: It sounds like it’s still amicable and he’d like to keep him on if they were to go into healthcare but not if they don’t. You don’t know if they vested so the first thing is that you should have done four year vesting probably so that your co-founder wouldn’t own the entire percentage that they had. Because if they decide to leave, that will go back into the pool to get the next person.
Mike: I think, with regards to what to do about the co-founder, that’s probably the first thing to do. It sounds like you wanna keep them on but the question is how much is he going to be able to contribute. As Rob said, the vesting schedule maybe he owns 25% because he’s stuck around a year, 50% because he’s stuck around for 2 years. That seems to me like the first thing to look at and try and figure out and if he has to walk away because he’s just not involved, that doesn’t mean he still doesn’t own a certain percentage of the business anymore and can’t contribute under the […] capacity or something along those lines. That’s something I think you have to work out with your co-founder and sit down and have an honest conversation about what him stepping away from the business really means for the business and for the relationship between you guys.
Then once you’ve figured that out, the next question to tackle is what do you do about the business itself. I think you didn’t specify what your own personal situation is or whether you’re taking money from the business and living off of it. But with the $2,500 a month, it sounds to me like because you’re a do-it-yourself-er, it might be a viable strategy to go out and find a business coach who can walk you through a bunch of different things and that does a couple of things.
One, is it avoids handing equity over to somebody else, and two, it still allows you to do those things yourself and you get that personalized assistance from somebody else and a sounding board from somebody who’s vested in the business because you are paying them to give you ideas and take a hard look at what it is that you’re doing and how effective those things are but you’re still doing those things yourself and you still don’t necessarily hand over control to a third party or a co-founder or another partner in the business and avoid some of those other issues that maybe you’re struggling with right now.
I don’t think that it’s wise to introduce too many changes all at once. That could be a nice bridge scenario where you are involving somebody else but you’re not handing over the reins to somebody else in a co-founder capacity while you’re having your current co-founder step away from the business a little bit. That’s probably where I’d start looking and see if that makes sense to you.
Rob: Yeah. I think you’re right, there are two separate issues here, it’s existing co-founder and then pulling on a new partner. I think given that the business you have to de-risk the business a small amount that bringing on a new partner, you could obviously give equity without giving an enormous amount. It wouldn’t need to be a third of the equity or something. It depends on your aspirations and think where the business is headed and who you can find but I’m thinking in the 10%-20% range given where you are. If you were gonna go raise funding and you’re gonna go try to find like a COO or something or a CTO, they get 5%, but you’re in a little bit different situation because it doesn’t sound like you’re gonna get so big so fast, that that’s gonna be warranted. As a result you have to bump that equity to 10% or 15% or whatever. But at this point, in my opinion wouldn’t just be an even split.
I think the hard part is finding that person and vetting them and it’s like a marriage because you guys are gonna have shared ownership of things and breaking that up later can be like a divorce. I think getting over your hesitation is one thing, but I think the harder thing is to find someone who is good enough or who’s gonna work with your style, who’s willing to be in the trenches with you, who I think it really wants to stick around and is able to work because it sounds like this is gonna be nights and weekends, people are not cut out for that in general, most people just think they wanna do it and then a month or two months and they just flick out or they just decide not to do it.
I think finding someone who meets all this criteria is really hard but I think if you can, then what I would look at doing is definitely have kind of a trial period, maybe 90 days, just to say how things feel, I would definitely have four year vesting on that with the one year cliff, meaning they don’t get any shares until they’ve been around for a year. I think that’s how I would approach it and I would look to be meeting people in person so I would be going to the MicroConfs and the businesses software and these conferences where there are folks who could potentially be in that pool for you separately regarding your current co-founder. I think you just need to make the choice sooner rather than later whether they’re going to healthcare. If you’re gonna go onto it and he wants to stay around, you wanna keep him around, that’s great, and if you’re not, then I think the decision is made there.
I know it’s not always that crystal clear but it does, given that information you’ve provided, seem perhaps how I would perceive. Thanks for the question, hope that was helpful.
The next question is about technical debt. Mike, does technical debt really come back to bite you?
Mike: Oh, yeah. No question on that.
Rob: Alright. The subject line of the email is actually, “Have technical debt decisions been easy to pay down later or did they really come back to bite you?” He says, “Love the show, listened for the past year, really love the practical advice. I’m looking for your technical perspective about what matters in the early days of getting a site running while keeping customers happy with mission critical data, building a data heavy B2B SaaS startup.
The frontend is in Angular, the backend is in Rails, intermediate self-taught developers, new things I haven’t done before can sometimes take a week or two to figure out. I’m making early technical debt tradeoffs hosting using Heroku versus AWS, database PostgreSQL versus Aurora, and the other miscellaneous things relating to data structures.
I’m not looking for technical help but the question is more geared to your experience of how much this stuff matters up front and really needs to be solved to get functional versus it’s not too hard to change it later. Theoretically important but won’t kill you so pick the simpler thing even if you know you’ll need it to change it after launch. Am I wasting a lot of time by taking the shortcut now and having to pull the app apart later to move it around when I have real customers using it in production?”
Mike, this is not gonna be as long as GDPR, I promise, but I feel like we have a lot to say on this, so go. Just start rolling with this. What do you think?
Mike: Yeah. Do we have like beeps cued up immediately for all the profanity that’s about to be dropped on this?
Rob: Yeah. Technical debt, it’s a *.
Mike: Yes, it is, yes, it is. I think looking back on this particular piece of it, some of the things that he had brought up, the things like hosting and the database selection and the data structures that you’re using on a backend, some of those can be really hard to change later on, versely impossible. In some cases, you’re looking at a complete rewrite.
You at least have to have enough technical knowledge to make those decisions in a way that is not going to completely kill the app later on or force you to do an absolute rewrite from the ground up. That said, I do know people who have done complete rewrites after they’ve gotten to a point where they’ve gotten customers onboard and it basically delays things, you may have to take three, six, nine months of accepting the fact that you’re just not gonna make any progress on the features in order to fix that fundamental positions that will bust it.
Then, there’s kind of a second level which is where you’re trying to make decisions about how do you structure the data or how do you create the database in such a way that it makes easy to do certain queries or provide a solid error handling, error returns to the API for example. I think in those cases, you can mitigate them to some extent by using dependency injection and creating these interfaces that sit in front of it and if you need to rewrite one, then you can, you’re almost swapping out an entire layer of the application for another in a very specific way.
I’ll give an example with Bluetick, like the backend storage system for storing emails has been rewritten four times. It’s because at first it was like let’s just get something working and then it was trying to optimize for local storage and then the next level was things are not working in local storage because there’s so much data coming in at all times like I just can’t scale that much on one machine and then I kind of move everything into the cloud and into the Azure tables in no sequel storage. Then the fourth rewrite was essentially making that more scalable and optimized.
Each level on the way like there was some level of rewrite but because it was essentially being able to flip a switch and say instead of using this set of data structures, you can do those on a per user basis or on small sub-segments of the users and not affect others. I would definitely do some research on dependency injection.
The other nice by-product of them is that it helps with writing unit test to be able to make sure that those things that are working from one version of your rewrite to the next in that particular component or module. Beyond that, there’s always gonna be things that you run into where you think that one way is a good way to solve a technical challenge and you turn around and find that it just wasn’t, you get down in the weed sometimes and you realize that you made a really, really big mistake and the only way to resolve that at that point is to rewrite it and there’s nothing you can do at that point.
The only way to have mitigated those four types of problems is to run into them and then realize after the fact that it was a mistake. It’s really hard to generalize from one application or problem space to the next and say like, “Oh, you should never do it this way. You should always do it this way.” Those things don’t apply. Each problem space has its own unique way of storing data or things that need to be surfaced to the user and you don’t always know what those are until afterwards. Sometimes, you just make the best decision that you have and you find out later that it was wrong, there’s nothing you can do.
Rob: Yeah. I would just say in general, technical debt is underrated in the startup space. I think people think that it’s not a big deal and it’s a way bigger deal than most people do because if you aren’t technical, it’s hard to understand why you can’t just quickly rewrite a piece or quickly change a decision you made later. These metaphors don’t always work but it’s akin to building a building and then needing to go back and replace the concrete foundation because you poured it incorrectly. You literally have to jack the building up and it’s just painstaking and agonizing to replace that and that’s what code is. You’re building things on top of each other.
I think of it like a 4×4 matrix where there’s basically two binary things. One is I know that this is a shortcut and I’m gonna take it anyways versus I don’t know this is a shortcut like I accidentally introduced technical debt. I think that’s the switch you’re talking about.
Then I think the other one is it’s easy to undo later versus it’s a complete fiasco to undo it. You can imagine that 4×4 matrix and we’ll go through all of those matching up but obviously any decision you make on purpose to introduce technical debt, you need to explore and thought experiment like how hard is this to undo later. If it’s hard, then don’t do it.
There were a lot of decisions Derrick and I made in the early days that were very slow, they caused Drip development to be very slow in the early days and it was pretty agonizing when we were bleeding cash and we couldn’t get the features out the door to keep people from churning because it was a very specific feature set that people wanted, and it was taking us months to build them and it was because Derrick wanted to build them very carefully with extensive unit test and he wanna do it right and he had to refactor the database twice in the first year of the app, because the app went from a very simple thing to very complicated thing.
It was agonizing but it was the right decision, because now, it would be catastrophic right now, we would probably have to have rewritten major parts of Drip. I don’t know if it would have impacted the acquisition or if it just would have been post acquisition or what it would have been but it would have been really hard and between he and I, we figured out a good sense of what was gonna be hard to change later–things that are easier to change later like you said where you can just build an interface and then swap it out later. Obviously those are the ones that you can maybe take shortcuts on.
But I think some people take shortcuts on like not running unit test, some people make cold-quality shortcuts where they just start hacking things together and later on, everything’s buggy because you took a shortcut and you didn’t build that right in the first place. In general, I have seen no less than half a dozen or maybe closer to a dozen companies get to the point where they’re between 10k and 50k MRR, they’re growing fast and they have to rewrite their entire codebase. I’ve seen some that have done it more than ones.
It is so painful to spend six months of standing still while your competition gains on you because you took shortcuts in the early days. Now, you’re just hanging out, waiting to build more features until your codebase can be completely rewritten. I would say proceed with caution, obviously, you’re always gonna have some level of technical debt, but be very deliberate about those choices because I think it’s easy to be in such a hurry to get to the point where you have more revenue and this is certainly a tradeoff because in the early, early days, when you just trying to get to $5,000 or $10,000 revenue, you’re gonna have to make some trade offs but try to take shortcuts on things that are easy to change later. That’s how I think about it.
Mike: I think one of the biggest places to make that trade off is that when you’re looking at unit tests, I’m not saying you write unit tests for everything because I certainly don’t think that that has a ton of value for a startup but I do think that there’s value in having like continuous integration server of some kind or a build system put in place so that later on you don’t have to figure out, “Okay, how am I gonna deploy my app?” You want that to be a systematic thing where you can literally just click a button and it runs through everything and is able to deploy the app.
But with that comes at least some level of unit tests or a mechanism for running those, and even if you don’t write a ton of unit tests, as bugs come in, you should be adding those unit tests to make sure that if a bug comes in and it breaks something that you had a unit test in there so that later on, as you’re making other changes, it doesn’t break that again.
Like I said, I don’t think you should write unit tests for everything, but I do think that as those bugs come in you should be writing them to make sure that once you fix a particular problem that you don’t have to refix it 3, 4, 5, 10 different times moving forward because it just keeps coming up.
Rob: Thanks for the question. I hope that was helpful.
Next question is from Jay Pablo Fernandez and he says, “I just finished going through all my newsletter subscribers and I noticed there are a few industries that are well-represented such as education, health, IT and government. When it comes to my product, they all use it in the same way. The feature set they made is pretty much the same. I wouldn’t say they are verticals in the SaaS way of thinking. I can sell to all of them or I can focus on one industry. Are there any advantages to either approach?”
Mike: I think this is a tough question, as you said you don’t wanna paint yourself into a corner and make people think that you don’t serve their industry. I think what I would do in this case sn focus on the specific problem that you solve and then maybe have different case studies for each of those industries and even segment your list a little bit so that when you talk to them, when you’re sending out newsletters or you’re sending out articles to them, maybe you’ll only send an article that highlights a case study for the electric and gas industry to those people who were subscribers that fit into that bucket. It seems to me like that would probably be an appropriate way to go, but at the same time there’s value to be had to for saying, “Hey, this also works in other industries because there’s gonna be some crossover between them.”
Let’s say that you have a case study on the nuclear power plant industry, if it’s safe enough for them to use, pure application, then whatever other industry they happen to be in, they would probably translate that and say, “Oh, well, if these guys are using it, then surely it’s passed master and I could use it as well.” I would think about it in terms of just trying to make sure that you’re covering enough of each of them but not focusing so hard on any of them that it makes people think that, “Oh, this is not for me.”
Rob: I think I might try to run an experiment. He has this list and he has these four sectors, four verticals, and I would consider trying to do physically exploratory calls, I don’t know if you wanna call it customer development or even just sales calls, if the product’s already there, across all of them, and figure out that you wanna validate your assumption that they use it in the same way with the same feature set. Because I find that a little bit hard to believe, just having run the apps that I’ve run, different industries tend to want slightly different feature sets and have a slightly to just enough it settle but by the time you really get and they start using it, it becomes a pain-in-the-butt to have four different industries or wanting something just slightly, “Oh, just tweak this one thing, oh, can I just have a setting to do this? But we have a permission in the reporting thing.” It’s just enough that there will be a difference. I guess it’s what I’m guessing.
If you have the time to do this upfront and just have a bunch of phone calls with these folks and try to do the demos and try to figure out is it truly gonna be something that they all can use, then that’s fine. But I do think you’re gonna find differences in payment terms, like you said sales cycle because government’s gonna take forever to come through, maybe in your early days since you’re trying to get ahead of funding running out or whatever, you go after the ones that close quickest, which I don’t know if that’d be IT, education, sure it seems like it’s gonna take a long time too, so focus on the one that are gonna close the quickest and get the early value in order to keep around long enough to focus on all four.
But I would try to answer that question, there’s still a question in my mind of is the product actually gonna serve all four? If that’s the case and you can work your entire list and work all four of them at once and try to get as many customers paying you on day one, then that’s what I would do. Right now, you’re just trying to get revenue and see how people use the app and if they’re gonna get value out of the app and there are across four different industries, then you’re gonna learn more about all four and maybe later you decide to focus down on one industry.
I do think that there are some advantages focusing on one industry in terms of how your marketing can really speak to people so you’re gonna close more deals probably, how you are sales conversation can focus on them, how your features set can focus, and how word of mouth would be such a big component of it. Assuming that people in your industry hang out at conferences, or hang out online, word of mouth if you just become the defacto in in the industry and in a vertical then you can land and expand words like, “Alright, we are the go-to for this task in the IT space. Now we’re gonna start adding on these other verticals.”
That’s the other way to approach it. It’s just a pick one based on your information so far, your best guess, and then later on, a year or two down the line, once you own a big chunk of this, you’ll expand into the others but I feel like you don’t have enough information to do either approach right now and I would try to close as many deals as I could, see if they actually will all use it and then try to make the decision once you have a little more information.
For our final question of the day, we have a question from Ed Freyfogle. He was a MicroConf Europe speaker this year. He says, “Hey, guys. Long time listener, first time asker. One target audience of my SaaS service is academic researchers. They are not the best customers as typically they’re low budget and they only need this service for a project or semester. Nevertheless their niche seems to like my service. Often they ask for academic discounts. My pricing is already very affordable and I offer discounts for annual purchases. Still, I can’t help but wonder if I might be able to grow this niche by offering an academic discount.
Alternatively, I have also thought about selling to universities and offering them a bulk rate. But so far I’ve always been busy with other things so I haven’t acted on this idea. I’m wondering if you guys have any advice on academic discounts in general, how to ensure they are not abused by other customers and selling to universities. Thanks for the great show, I learn a lot.”
This is a tough question. I like the fact that he’s thinking pretty strategically about it. I think that if you haven’t had the time to try to sell to the universities and offer them a bulk rate, if you haven’t made the time, it’s probably not that important. That’s where I found like this is right. It’s like you go toward the money’s coming in and your biggest fires are. I’m guessing that unless you are to hire someone to handle that that it’s not gonna make it to the top of your to-do list anytime soon.
I tend to think about discounts in two ways. There is academic and then there’s non-profit discounts. I don’t know if you have a non-profit discount as well, that’s something that I would consider modelling it after and there you just ask for proof of their non-profit status which can totally be abused. I think with DotNetInvoice we had profit one and it was maybe 1 in 20 or 1 in 30 who ask for it and show the stock seemed a little bit like, “You signed up with this just to get the discount.”
In terms of academic stuff, it depends on what volume you have coming in, it’s like if it really isn’t education it’s 1 in 50 people ask for it. You can always have an unpublished academic discount and you just need to get proof from them, I don’t know it’s a student ID or if it’s a professor ID, what it is, but it’s gonna be a process, it’s fairly lightweight. I personally don’t see a huge drawback to doing it. I’m curious when people email and ask for academic discounts and you say no, how many sales do you think you loose? Is it worth even doing any of this effort to get those sales?
Your pricing is already reasonable, if you offered another 20%, 30%, 40% off for academic discounts and that’s probably the range, I would think, although I haven’t done any research about this, but mentally it would be in that range. Is that worth it if you have to go through validation of some type of ID, I don’t know, there’s some trade offs here.
If the volume is high enough that you’re asking this question, I would probably just do an experiment where the next time I got an email about it, I would say, “Yes, we have a 25% discount, but you have to prove you’re a student or you’re faculty.” See where it goes from there and handle it as a one off to start and then I don’t know if it has support people or not, but if you distract them to do that and then tally up in a Google Spreadsheet how often it gets asked and which sales come through, you can start getting at least a little bit of data about it.
Those are my initial thoughts without a ton of experience, to back that up, it’s more of the got feel, so much of entrepreneurship is making enough as you go along. It’s just figuring out what’s the priority and making the best judgment call based on the information you have. What do you think, Mike? You have other thoughts?
Mike: I’ve looked at the academic discounts in the past. You just do a quick search for academic discounts for software and you’ll find that they can be upwards of 85% which is extremely high especially for something like a SaaS, I mean. Is the money that you’re getting even enough to offset the cost of you actually doing business for that person? I don’t know the answer to that. I think you need to figure out what that is.
Rob: Yeah. I know that Microsoft and Adobe and those guys discount because they’ve been pirated so much. Too often students who don’t have the money and they do these huge discounts. When you’re a SaaS app, especially when you’re Bootstrap like this and cash is important, there’s no chance I would offer a discount that large.
Mike: Yeah. I mean I think that part of the reason that those types of companies offer discounts that are high is one, it’s downloadable software so they don’t have to worry about their own cost, and two, they’re really just trying to make sure that there’s some form of legitimacy for the software that you’re using and giving that high of a discount helps them to get market penetration so that Microsoft has 90% market penetration on the best app for Office and Windows.
I agree, I wouldn’t go that high, but it’s not to say that you couldn’t have a discount for students versus a discount for academic researchers/the university itself. Because if somebody’s using it for a class, then they’re probably not going to be able to pay nearly as much as the person who’s doing it for the university and offering it on behalf of the class itself. I might think about that, but I do agree with Rob that you probably want to go through and run at least some tests to find out like what is it that people are using it for.
Something else to consider is that if somebody is purchasing it on behalf of the classroom because they’re teaching it, what’s the value of having those people in the class know about your product and then they leave and graduate and go out and do things in the workforce and having them know, “Hey, I can come over to opencagedata.com and buy this stuff off-the-shelf and we use it in our classroom so it has a lot of legitimacy.” There’s probably some value in that, I don’t know what that level is because I mean if you go through like an engineering degree, chances are good you’ll probably use Autocad some place along the way. When you get out into the industry like you first thought is, “Oh, I need to create some 3D models of something. Where’s the copy of Autocad?” There’s a student discount that you can get but once you get out in that at the real world, your company has to pay for it.
Having those people go to their bosses and say, “Hey, I use this data over here from opencagedata.com. We should buy a license for that.” There’s value there. I don’t know what that is but I definitely think there’s some value there. I would look into it, I don’t know how much time and effort I would spend on it because the return on that is probably gonna be wild. It’s gonna be a couple of years.
Rob: Yeah. Those are good points. I like your idea of not making an academic discount but making it a student discount. It’s an interesting thing because students really don’t have the money whereas if a university is buying it for a class, they do have some budget, and he’s right, his prices are reasonable like a university should be able to afford it.
Mike: Even with like a student. A student could probably get away with a free trial or even like the extra small plan that they have there for like a class or project or something like that but the university, if it’s for a class, and they’re buying it on behalf of the students for a class, I’ll offer them a 30% discount if you’re a student and you just want to use it for yourself, maybe it’s a 60% discount. I don’t know, but if you separate them, I think that there’s a way of targeting those people in that way that says, “Oh, we give individual students 60% and for universities we give them 30%.” It shows that you’re doing both. It shows you’re helping out on both sides.
Rob: It’s a question of whether or not the volume of incoming request warrant spending the time to figure all this out. If the answer is no, we have reasonable prices and we aren’t able to support any of these because you don’t have the bandwidth. It’s less about money and it’s more about Bootstrap startup with not a lot of time and just having yet another program to maintain and then we have to get a fax of your idea or an email with a screenshot and then check that off that it’s approved and then they just want more process that you have to wait if that’s gonna be worth it for in order to make another few discounted sales.
Mike: Thanks for the question, Ed. I think that about wraps us up for the day. If you have a question for us, you can call it into our voicemail number at 1-888-801-96-90 or you can email to us at questions@startupsfortherestofus.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 and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening and we’ll see you next time.
