annual renewals

Rob: In this episode of the Startups For The Rest Of Us, Mike and I talk about SaaS revenue patterns, increasing annual renewals and answer more listener questions. This is Startups For The Rest Of Us episode 376.

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: And I’m Mike.

Rob: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What is the word this week, sir?

Mike: There’s no word this week but next week I will be headed to BIG SNOW Tiny Conf East. Spending a couple of days up there. There’s about a dozen people or so that go up each year and just hang out and hit the slopes every day and then talk business in the evening. That’s definitely a good time, and I’m really looking forward to it. It’s been a while since I’ve been skiing.

Rob: Yeah. You go there every year, you just come away with a lot of motivation and a lot of good ideas. It seems to really, really work for you. I’m glad that you’re able to go back again this year.

Mike: Yeah. I definitely need the time away from my computer, to be honest at this point. I’ve been heads down for the past several months straight. Haven’t really had any time to come up to breathe.

Rob: It’s always good to get away whether it’s to go on a retreat, or to do something like this. I think it’s a good call, man. I actually wish I could go this year. I won’t be able to, obviously, it’s sold out and stuff but I don’t ski, so I would show up to drink hot cocoa, and I don’t know what I’d do, watch movies or something, just snow shoe or something. I do think it’d be a lot of fun to go to one of them. At one point there were three each year, but I don’t know if there’s a Europe one this year, I think it might be just East and West?

Mike: Yes, just East and West this year. I think the Europe one, they couldn’t get enough people committed to going. There was interest but just nobody stepped up and said, “Hey, we’re definitely in.”

Rob: Yeah, that makes sense. Cool. Hey, we got a note from a listener. His name is Francois Lagier. He says, “I just wanted to reach out and say thank you. Rob and Mike, I’m a co-founder of a new SaaS company called cloudforecast.io. I wanted to reach out and say thank you for a few things.” He has a bulleted list of thanks, which is cool to get this detailed stuff.

“First, thank you for all the good content in Startups For The Rest Of Us. I recently started listening to your podcast, and I’ve been searching the archive for any episodes mentioning the word “SaaS”. As a new entrepreneur, I’m learning so much. Second, you mentioned Perfect Audience many times for your retargeting strategy. Both my co-founders and I were part of the early [00:02:35] of Perfect Audience.” Interesting. “And we are very proud of our work there. Thank you for putting a smile on my face every time you mention it.”

I’ve been a fan of Perfect Audience for a long time and Brad, one of the founders, I’ve spoken with him on the phone several times. In fact, I called him, he was one of the founders that I called during the Drip acquisition because he’s gone through an acquisition. I just wanted to get his sense of dos and don’ts and how it went there. I always appreciate being able to talk to him.

And then back to Francois’s email. “Third, I listened to episode 319 a few days ago and Rob literally mentioned the problem we are trying to solve.” He quotes me, and I say, I had a counter reminder every two weeks. It would ping us and it would say, “Check AWS spelling.” “Thank you for confirming that our idea is not completely crazy, since cloudforecast.io is a daily email report that breaks down your forecasted AWS spending by products tags and regions allowing you to understand where your money’s going. Once again, thank you for everything, have a great week.”

Mike: That’s awesome. Thanks, Francos. I really appreciate the email. It’s very interesting looking at the report that he had sent over as well. Just seen the forecast of the cloud computing spend. It’s interesting seeing it broken down like this. I don’t have nearly the expenses that are shown here. I don’t have to worry about it as much, but I can definitely see how large our installations using cloud services would definitely find that appealing.

Rob: Yeah. Thanks for the email, Francois. I really appreciate it. What else is going on with you? What’s the update on Bluetick?

Mike: I’m working on a couple of minor bugs but right now I’m trying to close out the final testing process for deploying the latest release I’ve been working on. I’m hoping that that will go up by the end of today. It’s basically a series of major improvements to test ability, and test coverage, and then overall resilience of the app in different error conditions and performance scalability, etc. The big thing is that it makes it easier and safer for me to make a bunch of updates moving forward just because the increased test coverage makes it obviously less prone to error. When things go wrong, I’ll be able to see them before it hits the production server because there are certain sections of the app that were critical to the entire thing running and being able to send out the emails and recognize when replies came in.

I won’t say that they were completely hacked together, but there was a lot of code in there that handled specific edge cases that needed to be separated out a little bit, I’ll say. Just the refactoring will make it easier to make changes in a way that does not terrify me to do so.

Rob: Yeah, it’s such a luxury. I say it’s a luxury, it’s now a must have. I think I’ve said this before, never again will I run an app that does not have full test coverage. That’s cool. Did that take you a few weeks?

Mike: Yeah, it’s taken me probably four or five weeks at this point. There were a couple places where I thought it was done a few weeks ago and then ran into a couple of issues. I have one entire section of the app completely taken care of and then I didn’t realize that there was implications of the changes that I made over in the job scheduler. I had to basically refactor a lot of that code as well. Of course, once you do that, then you got to go through all the tests. But in doing so, I’ve realized that it made things a lot easier to write a suite of tests. I was able to do that and I basically doubled the number of unit tests that are in the app based on this set of changes.

Rob: That’s cool. Time well spent, I think. It’s one of those trade-offs of you’re trying to move fast so you don’t write the test and then it will eventually come back to bite you. It tends to come back in delayed features later on, or decreased feature velocity because you start pricking things or a lot of bugs, quality, that’s my experience with test is that they had that 20%, 25% upfront. But with Drip, have been able to continue moving at a pace that a lot of apps that are 5 years old are not, it’s because of that. Derek and I have commented many times that having a software company with no technical founders is a tough way to go. I bring this up because I’ve seen several companies do it. Unless you find that contractor or the salary employee number one who is just really hell bent on writing the test, it’s easy to just push that aside and I think it’s still a detriment of a lot of software companies that are trying to do it.

Mike: Yeah. It’s definitely a tough position to be in. I can’t stress, the unit test side of things, it’s always a trade-off because you want to move faster but if you don’t take the time to write those tests and have them in place, then later on you’ll get to a point where things are breaking left and right and you have no choice but to stop and go back and in some way shape or form, put them in place because otherwise, you really can’t make any progress forward. There’s always that balancing act between how quickly you’re moving versus how many tests you’re implementing.

Rob: For sure. Let’s dive into our listener questions today. The first one is about SaaS revenue patterns. It’s from Basil Abbas from clockit.io. And he says, “Hey, Mike and Rob. Huge fan of your show, and I’ve been religiously following it for two years. It has provided ton of value in each episode and helped us launch our SaaS app to $2,500 in MRR in the first year. In year one of the operation, I’ve noticed there are some patterns to how the MRR grows month to month. For example, in the month of January, February, and March, we are growing at roughly 30% or 40% and then we failed to 15% to 20% for the rest of the year. November was a fantastic month with 40% growth until Thanksgiving and now we have 0% growth in December. We also noticed that one week before and after major holidays in the US, our growth flat lines, but it picks up after. In your experience, have you come across such patterns?”

Mike: I think in B2B SaaS, yes. I’ve definitely seen this with Bluetick lately where in December things are more or less flatlined and that was probably due to a combination of things, mostly me stepping away from the marketing but I’ve heard from various other founders that the same kind of thing tends to happen to them as well. Rob, I think you commented on this in the past where you just take December off because it’s not really worth doing anything except preparation for January and February. I have seen things dip in the summer months as well, and then they pick up after the summer.

In terms of B2C stuff, I don’t know. I would imagine in December, you can probably count on some sort of a revenue bump because you’re going into the holiday season, you can get people to buy stuff for either as gifts or gifts for themselves, to be honest. Definitely done that with my book as well. That’s what I’ve seen. Rob, what about you?

Rob: Yeah. I definitely have seen patterns. The pattern you mentioned is odd. He says the first three months of the year, they grew a ton, and then half that rate for the rest of the year. Obviously it’s going to depend on the app. I remember when I had a [00:09:20] jobs, which is a job board, tons of traffic on Sunday evening because everyone was dreading going to work the next day. Or they didn’t have a job and they pissed away a weekend and they were scrambling thinking like, “I really need to gear up in this.” It’s this fascinating pattern of that.

With just straight ahead SaaS, when I think about HitTail and Drip, I remember it was either April and May were always sketchy. I attributed it to being tax time here in the US. December was always a train wreck, flat at best. Sometimes you’d lose customers. Other than that though, all the rest of the months were pretty similar, and I don’t remember there being anything, any kind of summer slowdown. I don’t know. There are definitely some patterns but I think that you want to look once you have two or three years, you can really see more of a recurring pattern to find out. Because some months would just be slower but it wasn’t year to year that it was the same, it’s just randomness. These things can be somewhat random.

Basil had a second question and I’m going to rephrase it slightly because if I read exactly what he says, folks will be confused but he says, could you also touch on if it’s okay to consider a 5% weekly MRR growth rate? Should I think about this as percentage or should I think about it more as like a dollar amount? I think is really what he’s getting at. Because if you think about it, let’s say you’re doing $5,000 MRR and 5% weekly growth rate would you put at $250 each week. Do you think of we wanna grow by percentage each week or we’re going to continue to grow by percentage each week or are we going to grow by $250 each week, so that when you hit $10,000 you’re actually now growing at 2 1/2% a week.

The way I think about this, and there’s a few ways to think about this. I think that what you have in place today will continue to add the dollar amounts. Let’s say you have a bunch of existing traffic from SEO or you’re doing Outbound or you’re doing paid ads or whatever, that is going to continue to give you a dollar amount in general and not a percentage. As your revenue goes up, you’re not going to necessarily see that you’re going to keep up with the percentage growth. If you want to keep growing at 5% week over week, you have to either increase those traffic channels or you have to add new ones to keep it at 5%. If you think about it, if you go to $20,000 or $30,000 growing at 5% week over week is really, really hard whereas if you’re at $2,000, growing 5% is not that much. You’re just adding a small trickle of revenue.

Mike: I was going to point it out. It depends on what you’re total amount is right now, because going from 5 customers to 10 is a lot easier than going from a 1000 customers to 10,000. The amount of time that it takes is going to make a big difference based on how many customers you currently have.

Rob: For sure. I do like to think about it in percentages because it’s more aggressive. But realize if you do just have linear traffic coming in, linear conversion rate all the same, it’s that dollar amount is what’s going to stay. There’s another factor that comes into this, it’s the bigger you get, the more churn hurts. Because you’ll plateau eventually. When you have 1000 or 10,000 customers, a 5% churn rate is a hell of a lot of people that you have to replace. When you only have 20 customers, 5% churn rate is 1 person. You got to think about all this. As you scale, you do come into new problems to continue to grow.

Alright, our next question is about annual renewals and how to encourage more of them. It’s from [Gareth Helsall 00:12:59] from driverguardian.co.uk. He says, “Hope you’re doing well. I get a ton of value from the podcast. Thanks for the output. Our business is not SaaS, but I would love your input. We have an annual product that our members pay for once a year. At the minute we send three renewal email reminders. One month before, one week before, and three days before. We also send a letter that is designed to arrive after the last email. We’re considering sending text messages that go out before the letter as it would save on postage cost if we could get a response. I would appreciate any input or discussion on about what you think, [00:13:33] for renewal should be for a single time annual recurring payments products.” What do you think?

Mike: If anyone who’s not at a computer is not familiar with driverguardian.co.uk. Essentially, looks a lot like AAA here in the US where you get this membership and provide you various discounts for just showing your AAA card, but at the same time, it also give you coverage if you ran out of gas or if your car breaks down or you blow a tire or something along those lines. There you can call AAA and they’ll come and they will help you out. They’ll send you a tow truck, it’s kind of like having insurance to the point that if your car breaks down, they’ll come help you and you don’t have to pay the emergency towing rates at that time whenever that happens.

I have my own AAA membership, and what they do is they just automatically bill me at that point. They have my credit card on file and they don’t even really ask for renewal. It’s just your honest automatic renewal. That works obviously if your credit card is not expired, but even if it is, depending on what company you have that is doing your credit card processing, it may still work after the fact. If for example, Stripe I know in certain situations, if a credit card expires, it will still bill properly even though the credit card itself is expired. That’s something you might want to take a look at.

The other things is AAA does send a letter in the mail that basically says, hey here is all the information. But again, they already bill me for it and I don’t actually have to pay that invoice. It just automatically gets paid anyway. I feel it’s just a reminder that hey, we’re about to bill you for this. I think that sending out those renewal email reminders is helpful, but definitely taking a look at sending them physical letters is probably a good strategy to go after. Just because you’re putting something physical in front of them and if it’s not going to the right place it may very well be returned or it will get forwarded over versus email. Email delivery can be hit and miss, I’ll say. Especially depending on how many emails you’re sending them on a regular basis anyway. That’s the big question I would raise at this point is how many emails are you sending them throughout the course of the year to begin with and do you know that you’re getting into their mailboxes.

Rob: Yeah. I think the approach I would take or I know the approach I would take is what you said with AAA. As a customer, the fact that I set it up once and they notify me, they’re like, “Hey! We’re going to rebill you in a month.” I don’t have to go log in or click any buttons or anything, it’s just done and it’s always there. I would move the whole business model to automatically renew every year and you’re very upfront about this, when they sign up, “Hey. This will renew automatically.” Maybe it’s a checkbox that’s checked by default. “Hey, do you want us to bill you each year?” And some people will uncheck it, and then you have a different thing if that makes you feel more comfortable.

Personally, I would just say this auto renews every year. That’s the point, and you can easily cancel it with one click and we’re going to notify you multiple times before we do it, and then do the parts that you mentioned, which is these three emails but instead of saying, “Hey, renew.” It should say, “Hey, we’re going to bill you and it’s this much. Just click right here if you want to make any changes to this. If you want to opt out, we won’t bill you.” I do love the idea of SMS as well. I think that if postage costs are a killer, then you could send SMS and avoid sending letter altogether.

I think moving towards an opt out model is the way I would go with this and then still notify the people to make sure that they do receive the stuff.

Mike: I did notice on their site they have one of the selling points is that it says “no auto renewal” and it actually puts you in a tough spot because of this side of it. I don’t know whether that’s because specifically laws over in the UK or in Europe that say that you can’t do that or if it’s just something that you guys came up with that you want to pitch to people because you were tired of being auto billed for stuff that you didn’t really want or need.

But really, I view it almost like the donor cards here in the US where it’s statistically proven that if you have a opt out model versus an opt in model, you’re opt out rate is going to be substantially lower than if you reverse it. People will basically just choose the path of least resistance and they’re not going to bother to go through that actual work in order to opt out but the reverse is true as well.

Rob: I would bet that if they pull the “does not auto renew” off the marketing site, there would be almost zero impact to their conversion rate. Unless this is some big competitive advantage and I don’t feel like it is, I think that that shouldn’t impact most things especially if you really want to do it and give people the option.

Obviously, going backwards, if you have 5000 existing customers, you’re going to grandfather them into what you do now. But I would consider, to be honest, adding in this as a feature and emailing everybody and saying, “Hey, we’ve set up this thing for your convenience. By popular request.” I’m sure someone has requested this at some point. Because I use services, when they don’t auto renew me, and I say, why didn’t you bill this? I actually don’t want to have to go in and re-enter my credit card every 6 months or every 12 months. Certainly, someone has requested at some point. Bill it and see how many existing customers you can get on auto renew and go from there. I’ll bet it’ll have an impact on your bottom line for sure.

Alright, our next question is from Ovi Negrean. His company is socialbee.io. It says, “Hey guys. In a recent episode, you talked about how there are not as many productized services that have been turned into SaaS as you thought. As another data point, socialbee.io has also started with a large service component and I wrote why it’s good to start with a service first in Medium,” and we’ll include that link. “I think it’s indeed an under utilized technique they can turn more wanna-preneurs and entrepreneurs.” There we go, Mike, anther data point.

I think I was the one who made that comment and I still think it’s a lot fewer productized services to SaaS have been done as I think perhaps should be done. I still see so many people shooting for the fences. I also think far few people use this stair step approach too. These are both lower risk, more repeatable, higher chance of success. These are approaches that do that for you and I still think that it’s not as popular as it probably should be.

Mike: This is one of my 2017 predictions. We covered this in the Predictions Episode back in episode 370. The comment I had made was that I didn’t have very many data points. I felt like the bar for launching the SaaS was going to continue to become harder to reach but startups who were going to go the route of offering a service as a first based approach followed by implementing SaaS was going to become more prevalent. I didn’t see a lot of data points is really the problem. We really appreciate you sending that in.

Rob: Our next email is from Calvin. It’s about choosing your text stack. He says, “Hey guys, I’m not a software developer, I’m more of a marketer, but my question is this: As a non technical founder, how do you choose what type of code to build your app on?” He’s asking about the text stack. “I’m trying to build a rank tracker.” What do you think, Mike?

Mike: It’s so heavily dependent on what it is that you’re trying to do. It’s hard to just give a general answer for that. You really need to have somebody who has that technical background to be able to make the decisions because depending on what you’re building, certain types of technical decisions can back you into a corner that’s really hard to get out of or the entire thing could end up falling down at some point because it just can’t scale or do the types of things that you need it to do.

A rank tracker is probably one of those things where you need to choose the right technology because if you don’t, it’s not going to scale the way that you need it too and you’re not going to be able to create things in a distributed manner or spread out the jobs and the spidering that needs to go with it on order to be able to do what you need to do.

The other thing to consider especially in this particular case is that if you are scraping websites in order to do any sort of a rank tracker, you have to be a little bit careful because you can get banned from them. I know of at least two people who had to deal with issues where their scraping techniques were noticed and their app was essentially banned from those websites. They looked at it as, oh, you’re basically DDOS-ing our site. It’s like, oh no, I’m spidering it but they don’t see it that way. If your entire business rests on doing that, then it’s significant risk if that vendor or that company decides to take action to prevent you from doing it.

I ran into this 12-15 years ago with McAfee. I was scraping their website using a Perl Script and then they kept changing things around on their websites so it made it difficult to find what the anti-virus definition numbers were. Because that was what I was trying to pull. They kept changing things around and eventually I wrote a script that would pull it down and it would parse it in five different ways and try and get to what the ID was because they just kept changing the HTML and I noticed that they were alternating it between them. I just figured I do that.

This is a hard question to answer just because it depends so heavily on what it is that you’re building.

Rob: I like the points you brought up. I think that building a rank tracker has some dangers to it. I don’t think you shouldn’t do it because of that but know that there are substantial risks. A rank tracker, this is not for search engines you mentioned specifically. It’s a rank tracker for another ecosystem and it’s going to almost always be against the terms of service. If you do it, you’re going to have to do it on the down low like Mike said. It’s going to be a part of your process that A) rank trackers are brutal because anytime the UI changes, it’s going to break everything and so you’re going to have a fire drill. Know that going in. So you’re going to want to developer who doesn’t have a 1-2 week delay to get back to you. You’re going to want someone who’s able to hop on things.

Second thing is you will likely need to get a bunch of cheap servers with different IPs because at any given time, some of them are going to get blacklisted just like you said, Mike. You can’t do this at scale without that. The people I know who have built these had to do these massive server farms and at any given time, all running the same code at any given time like 20% of them were banned and blacklisted and they would cycle them through. That will be an operational thing that you will perpetually have.

Again, I’m not saying don’t do this but to think about that up front. His question is how do you decide on what language to use and the way you do that is you learn about the language and which are good at different things. Like Python and Perl are really good at scraping. I would probably use Python in this case. His question wasn’t what technology should he use but that’s probably what I would do. I would look for a Python Django developer and build your scraper and build your web front and all in Python.

But the broader question is if you’re not building a rank tracker, and you’re building a different type of SaaS, what languages should someone consider? These days, I would say Ruby on Rails, Python Django. Those are probably one of the two, those are common, you’re going to be able to find developers. If you ever wanted to sell, they’re not languages that people shun. When I had HitTail in Classic ASP, someone was asking if they could buy it. As soon as I told them it was in Classic ASP, they said they had no interest in it so that they would have to rewrite the whole thing. We eventually rewrote it on Ruby on Rails and it was much more sellable.

.NET and Java also can be looked at that in the startups space. They’re not as appealing because the .NET and Java developers, they’re more enterprisey and it’s not as easy to find startup developers who are going to be into that. It’s going to be easier with these other ecosystems. Now, there are other languages that are up and coming. I think if you really wanted to get ahead of the curve, there’s Elm, Elixir and Phoenix. I think those are going to perhaps pull some market share in terms of startups being built. Those are going to slowly pull market share from Ruby and or Python. This comes from conversations with Derrick, he’s my co-founder at Drip, and then other developers that I’m hearing talking about these things. People are really excited about them and are looking for jobs in them and they’re not that widely available.

If I was a non technical founder, I don’t think I would branch into that because it is too new still, and I’ll probably go with something more tried and true.

Mike: Yeah. The big question there is are the problems that you are likely to run into things that have been solved before and with bleeding edge products or technologies or text stacks, sometimes you’re just blazing new ground yourself and there is no solutions or resources out there and you basically have to do a lot of research and development to solve particular types of problems versus with established products like Ruby on Rails, it makes it easier for you to find a common solution to a common problem.

Rob: One other stack you could consider is PHP. There are obviously a lot of apps built in that and ones that scale as well, I’m pretty sure Facebook is built in PHP. Obviously, WordPress, which scales pretty well. But it is, in my experience of these three languages I’m recommending actually, PHP is the only one I know and it can be a complete cluster. I think I would seek more towards the Python, Ruby part of things. If PHP well written and well structured is a perfectly acceptable web language but there’s so much of it that is not, it’s easy to hang yourself.

Alright, let’s go to our next email. It’s about corporate structures and trademarks from Dylan DiMartino. He says, “Hey guys, two quick questions I’d like your opinion on. Number one, I have a consulting company incorporated in the state of Louisiana but I want to start a SaaS with it’s own name. Would you suggest simply creating it under the umbrella of my current corp or should I start a separate entity? I notice a lot of the big apps share the same name as their parent company, Uber and Snapchat. Is this standard practice? Is it worth it? Does it make marketing easier?”

I think there are two aspects to that. One is does it matter that the product name and the corporation match from a marketing perspective? And then the second thing I think of course is the liability. Do you lump it in with consulting, then those assets are unprotected. What do you think, Mike?

Mike: This is interesting question to me mainly because I’m going through it right now where I am spending off Bluetick into its own separate corporate entity. Having just recently talked to both my CPA and my attorney, I’m spinning it off into its own separate LLC. The question I’m going through right now is does it really matter whether or not the app itself is the same name as the company and I’ve decided that no, it really does matter because the app is the front end facing. I will be likely going with a company name that is different than the product.

I do that because I don’t think that it makes any difference at all to the end user but couple things you do have to keep in mind is that when you’re putting things into terms and conditions and privacy policy and stuff like that, the company name is what’s going to have to be listed there along with the product name.

The reason I decided against going with product name as the company name is one, there’s already a company out there called Bluetick Incorporated or something like that, Bluetick Outfitters, something along those lines. But bluetick.com and bluetickinc.com are both taken so I didn’t want to run in any sort of trademark infringement problems with that and because it’s a software app and I think that was in the petroleum industry or something like that, it’s different enough that I can call the app that, and it’s not a big deal but calling the company Bluetick would probably be an issue. I’m going to go with something different. I haven’t decided on what yet, I could do that in the next couple of days and then just make sure that you keep in mind all the stuff associated with places where the customer is actually going to see the company name. That’s the big thing to keep in mind. Because you don’t want the company name to be so nonsensical or off the wall that if they read it or happen to glance at it, they don’t look at it and say, “Wait a second, why am I getting this email?” Especially if down the road, the company gets acquired or you sell it or something along those lines.

That leads to the second piece of this which is should you put it underneath your current corporation or spin it off as a separate entity. I decided to spin it off as a separate one just to keep all the books separate so that if later on I do decide to sell it, or if I do any sort of fund raising or anything like that, I want to have the books, at least reasonably decent, from a very early stage as opposed to trying to separate it out much later. I’m past the point where I feel like I needed to do validation because I probably wouldn’t build a product and go incorporate and do all the things that are “necessary” things that you’re supposed to do until after you’ve gotten to the point where you have revenue coming in the door and you know that it’s going to be something that it would be worth spinning it off into its own entity.

Before that you can easily end up in a situation where you get to five to eight customers and then you have to shut it down because it’s just not making enough money. At that point it costs you more to spin up the company and then shut it down than it did for the amount of money that you gather from customers.

Rob: Yeah. I think that’s a good perspective. I think in a perfect world, the corp would match the product name but I don’t think it really matters that much honestly because the only confusion I can imagine is the credit cards. When you get a credit card statement and it’s going to have corp name typically and not the product name, that’s the time where you may get confusion. I’ve seen folks set up their corp.com and all it is is a page that says confused about a charge from us? You probably use one of our apps, and then it has a few of them. I really don’t think it’s that big of a deal from a branding perspective.

One thing to think about is the liability, well, two things, one is liability. If you mix your consulting firm with a product, if one of them were to get sued or something then they are both in the same bucket and there’s no firewall between them. You have to use your judgment as to how big of a concern that is for you. For me, when I had a bunch of products, they were all under the newer group umbrella and that name didn’t match any of the products. That was never an issue for me and I wasn’t concerned about the liability so it’s a bunch of small products that really weren’t likely to have a lawsuit come in. Again, it’s risk tolerance there.

And then the other aspect of it is if you ever want to sell it, if you just sell the technology, that’s one thing but if it ever gets acquired and people really want the financials broken out and if it’s a startup acquisition, strategic, like we did with Drip, they bought all the assets in the company, it would’ve been a disaster. It would’ve been a disaster if Drip was still under the group. I spun it out maybe a year before the acquisition because it was just growing so much that I knew it needed to be its own company. At that point, I started realizing we’re probably between $30,000 and $50,000 MRR. I would hate for liability of Drip or of the  group to spill into one another and then there needs to be a firewall.

The process of ripping that out was a pain in the butt. It took several months and I paid a lawyer several thousand dollars to write up all the paperwork and try to make sure everything was transferred. I had to set up separate payroll. The group had to let go all of us, had to fire the employees and then hire them, through Drip. It was pretty crazy. I had two Gusto accounts, two different corporate credit cards, two bank accounts, two stripe accounts, too many things is what it was. But it was the right call. You got to think about that. If you’re just plugging away and starting something you think you’d get to a few grand and hope to eventually sell it, personally, I’ll probably just throw it under the same corporation assuming that you judged the liability and how much risk you’re willing to take on.

Like Mike said, setting up the entire other entity and then never getting the product off the ground, or never getting it past of couple grand in revenue, it is a lot of expense, you don’t think there’s that much expense but there is setting up upfront, if you’re on a state with an annual fee like California charges $800 a year just to have a corporation there and then you need separate software for the books, and then the CPA is going to have to file separate tax return. That’s an extra cost. There’s a lot to think about there, but I do think you’re thinking about it right.

And then his second question was, “Is it worth going through any steps for the legal protection during your early development stages? Specifically a trademark on your app name.” What do you think about that?

Mike: I don’t think so. If you’re not making any money from it, it probably doesn’t make a difference. It’s funny I did recently see this lawsuit of a company called TWiT versus Twitter.

Rob: Yes. TWiT is This Week in Tech, it’s Leo Laporte’s company.

Mike: Yeah, something along those lines. I think that previously they had taken the standpoint oh this is just a couple of techies in the garage building this app on the side for some sort of social things, it’s not a big deal. Now it’s suddenly a big deal.

Rob: TWiT is a podcasting network in essence, video and audio, and they’re located Northern California. Leo Laporte has long time been basically a tech newscaster for decades. He has his network, and maybe 30 shows in there, few dozen employees, and they have a studio up there North of San Francisco. As these guys were coming up, he has the trademark and the stuff for TWiT, and I don’t know if he has Twitter or not but he certainly has things that I think that early on he and Evan Williams had talked. He has some type of written agreement but it’s not super ironclad, and then he definitely had verbal agreements he has talked about on the show before that hey as long as they stay out of streaming audio and video, that we’re in separate areas, but Twitter’s now getting into that.

For Twitter, you know what they’re going to do? They’re going to settle, right? They’ll pay him some money. I think, I don’t know. They’re big enough, they’re a public company. It’s not that they’re doing great but this type of thing is not catastrophic at their scale. These lawsuits are things that you just throw some lawyers on it and then eventually you settle in and you pay someone $5 million or $10 million and it goes away.

Mike: The point is that they got the app to that point without having had all that stuff. And yes, it’s going to cost them, as you said, maybe it’s $5 million or $10 million which sounds like a heck of a lot of money but how much does Twitter pull in in a year. At the end of the day, it’s not really that big a deal to them to have not have that trademark from day one, or have registered it, or have gone with a different one. It’s really just like you’re trying to solve for a problem that you don’t have and you may never have. Because I don’t think that most of us are going to be in a position where we have a business as large as Twitter and are defending against the trademark because we never filed it or we never acquired it very early on in the startup.

Rob: Right. I think I have mixed feelings about this one. Filing a trademark is a couple hundred bucks. It’s not very expensive, it’s not like a patent. Software patents are $15,000-$30,000 if you file one. Whereas a trademark is inexpensive, and it’s fairly easy to do. You can go to LegalZoom or there’s a bunch of services that do this, and it’s pretty straightforward. Now if you do it and you get rejected, then you have to go and justify and do all this stuff.

I’ve only filed for one trademark. Of all the apps and all the stuff that I’ve done, and it was for Drip and I got rejected the first round. I was like, “Oh, good grief.” I don’t know. I wouldn’t say don’t do it, I do think that if you don’t have an app yet, it’s probably jumping the gun. But it isn’t that much time or money to do it. You just got to weigh it out. I don’t know if there’s a right or wrong one here, right or wrong answer.

Mike: I think it depends on how much money you are actually making from it. Because if you haven’t made a dime from it, probably not worth filing the trademark but when you get to the point where you’ve made maybe $1,000 or $2,000, at that point you might consider it once you’ve made $10,000, $20,000, $30,000 maybe really consider it. You can always push it off too because you could file it based on prior usage. There’s that as well. I think with the Twitter issue, Twitter didn’t do it first, it was the TWiT Company. They didn’t file for a trademark until it was a year after Twitter was founded but they had been previously using it. I think that’s why they have that trademark.

Rob: Yeah, you’re probably right. If you haven’t made any money from it, you probably shouldn’t file it but there’s a resonance thing there but I hear you. Cool. I think that wraps us up for the day.

Mike: Yup, I think so too. If you have a question for us, you can call it into our voicemail number at 1-888-801-9690 or you can email it to us at 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.