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?
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.
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 firstname.lastname@example.org.
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.
In this episode of Startups For The Rest Of Us, Rob and Mike talk about GDPR, preparing to be acquired, and technical debt. With the regulations of GDPR coming into effect, the guys discuss how it will affect small businesses and what you should do. Also an in depth discussion on things to have in order before you get acquired.
Items mentioned in this episode:
- Mike’s Indie Hackers Article
- Mike’s Interview on Product People
- Sherry Walling Interview on Mixergy
- FemtoConf Recap
Rob: In this episode of Startups For The Rest Of Us, Mike and I talked about GDPR, preparing to be acquired, technical debt and we answered more listener questions. This is Startups For The Rest Of Us episode 385.
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 built your first product or you’re just thinking about it. I’m Rob.
Mike: And I’m Mike.
Rob: We’re here to share our experiences to help you avoid the same mistakes we’ve made. What is our word this week, sir?
Mike: Why is it in Zencastr it says Chronomustard?
Rob: Chronomustard, that’s my name this week. I think that’s gonna confuse our editor. I’m trying a new thing, creativity. I’m trying to enter a different name each week just to see if I can make you laugh.
Mike: They usually do make me laugh, I appreciate that.
Rob: For sure. What’s going on this week?
Mike: I did a demo yesterday for a customer who’s looking at switching over from a competitor and they have a bunch of different users for the product that are in the competitor. When I went through and was doing the demo, afterwards he’s just like, “Wow this is way more advanced than what we’re currently using.” I’m just thinking to myself, “Is that a good thing or a bad thing?” Apparently it was a good thing.
They were looking through and signing up for it. Next week they’re gonna reach internally. Hopefully they’ll turn into a fairly large customer for Bluetick.
Rob: It’s always good to get off a demo and get that feeling that you’re gonna be making more money, it’s always worth it.
Mike: What was really interesting to me was just the fact that they had said how advanced it was in relation to this competitor because the impression that I get from their website and all the things that it seems like it does is that it’s probably more advanced than Bluetick but I got the distinct feeling that that was not the case.
I knew that they were having problems with it but I wasn’t clear until the phone call and exactly what those problems were and how they were dealing with them and what they were looking to do.
Rob: That’s awesome, man. Do you have any avenue if you sign this guys up that you’re able to find more customers like them?
Mike: I do but I think it’s gonna be more word of mouth relationship than anything else. This one came through a personal relationship so it’s not as if they came in through a marketing channel or anything like that. I knew who the person was and contact them and went from there.
Rob: You could also think about going to build with your Datanyze. Since they are using this competitor pulling down the list to people who are using the competitor doing the cold email thing, we talked a little bit about that last week. It’s obviously time consuming but that can be an interesting avenue if you do know that you are better than a specific competitor.
Rob: Probably be worth a few minutes. You have been busy, man. I was pleased to see an article on Indie Hackers, Starting and Growing a Conference for Internet Entrepreneurs, got quite a few upvotes. You said you spent several hours doing this, it’s one of the most in depth Indie Hackers Q and A I had seen.
Mike: I spent a lot of time on that, probably close to a day and a half to two days. I threw in the word because I was curious since how long it actually was, it came in at 6000 words.
Rob: It’s like a book chapter or two. It has screenshots and everything, you did a really good job. If folks are interested in hearing about the history of MicroConf, what it was like starting it, how it runs today. There’s just a ton of insight stuff, although some of it is projected revenue, I think you gave this year. Some years don’t include MicroConf Europe, it’s not all exact but there are graphs and everything that I think that Indie Hackers folks put together.
Mike: They took the attendance numbers and extrapolated with the revenue was from those numbers. It’s off a little bit but it’s not really that big deal, it’s more of the trajectory, I think, that’s important to see.
Rob: It doesn’t include sponsorships and all which are big chunk. It’s fun for me to read because I could be like, “Oh yeah.” I was nodding along like, “I remember that. I can’t believe Mike remembers this.” You are pulling stuff out, all the anecdotes that I had long forgotten.
Mike: Some of the things I had to go back. I looked through my email to see when it was that we first started talking about MicroConf and I traced it back to the exact day which I don’t know if we talked about. We had a name for it before then and we were talking about it separately and just calling it a conference or we had the name and we picked it on the day and went from there.
I don’t remember how long we talked about it before we decided to register the domain name and start looking forward or if it was just like spare the moment thing.
Rob: I remember being very spur of the moment. It just made sense, it was like, “Why don’t we just do that?” That’s cool. There’s a lot of engagement, a lot of really good comments and in depth discussion going on and 36 upvotes, I get the feeling that’s quite a few for most articles. Anyways, if you’re interested in hearing that story, we’ll link it up in the show notes but you can obviously go to indiehackers.com and give it a search. You also went on Justin Jackson’s podcast, MegaMaker. It was a couple weeks ago.
Mike: I think that was last week as well. We recorded it and then it went live either later that day or the very next day. It was all about MicroConf itself and what Starter Edition was about. We’ve announced that Justin Jackson is going to be emcee for Starter Edition.
We did that last year, Starter Edition as well, with Jordan Gal from CartHook. He was the emcee for that, we basically turned over the reins to him and let him run the show at Starter Edition which was really cool because it’s nice to be able to sit back a little bit and enjoy the conference a little bit more. I don’t know how you feel about that but it’s nice to let somebody else take the reins for a little while.
Rob: That was something that Zander, our conference coordinator, encouraged us to do because since Growth and Starter are back to back, we’d be solo energy by the fourth day of trying to emcee and run the conference that I think he knew that it would just wouldn’t come off as well as it could. Jordan certainly knocked it out the park as the emcee that was really, really good and to give them their style up there on stage is fun.
You know, with Starter, Justin is such a good fit for it because that is really the crowd that he is talking to everyday and interacting with so he knows that crowd perhaps these days, you know better than I do in all honesty. It was years ago that I was really knee deep in all of the transitioning from developer to marketer and talking about all that stuff. He just has his finger on the pulse of that. I think he’s a good fit to emcee. This year he’s also doing a talk which is cool.
Mike: How about you, what have you been up to?
Rob: I’ve just been working, kicking back a little bit. I have a spring break coming in a week or two. We are heading down to Florida, starting to warm up in Minneapolis but still in the 30s and we wanna get some sun. It’s an easy flight down to Miami and we rented up Big Ol’ Airbnb off of 80 and we’re looking forward to that.
I was enjoying, I don’t know if you’ve heard it but Sherry was on Mixergy. It’s actually her second time on Mixergy. Her first time, it was when she interviewed Andrew Warner and put it on ZenFounder and he simulcast that basically onto Mixergy. But this time it’s called Keeping Your Feet Together As A Founder and it’s Andrew Warner interviewing Sherry about the book and about the stuff she’s doing in the entrepreneurial communities. It’s really a pretty intense interview but it’s really good. Have you had the chance to listen to it?
Mike: I have not, no. I don’t get a chance to listen to Mixergy too often. I’m actually about two months behind on most of my podcast at the moment anyway.
Rob: I listen to select Mixergy interviews just because there’s a lot of them and they are long but this is one that obviously I jumped on, I just wanted to hear the content. It’s a good one, we’ll link it up in the show notes but you can obviously search for Sherry Walling Mixergy and find that in Google.
Mike: Awesome. What are we talking about today?
Rob: We’re gonna answer a bunch of listener questions and see how many we get through. It was cool, we were down to one listener question. When we announced it on the show, I think we’re up to 12 or 15 now and so we can hammer through. I feel like this cadence every other week answering these questions has become something that I’ve enjoyed and I’ve gotten positive feedback about it.
Voicemails are even better because it shows people that there are all these different people with different businesses listening to the show. You and I know we have tens of thousands of listeners but as a listener, you don’t know that. It would be hard to know or understand your fellow listeners and your fellow entrepreneurs doing it. I have enjoyed this and I think we’ll keep doing it as long as the questions keep coming in.
Our first question today is for me, it’s actually from a guy, Louis. He said, “The question I have is what would Rob wished he had prepared in advance in going through the process of selling Drip? Imagine there might be things like intellectual property who may have purchased the use with his own name but now need to be transferred to the company, manuals and processes, bank issues such as PayPal not being able to transfer, etc. The list could be endless, maybe a good topic for a book.”
I’ve actually thought about this. There are two thing I wanted to say here. The first is I’m gonna make an announcement but not really an announcement, Mike, I haven’t even told you this. I’ve started writing what I think may become a book. That’s the exact right response. I don’t know if it will yet. My goal for this year is not to tackle any big new projects.
There’s a lot to tell, there’s a lot of story that has happened since the last book I wrote. Maybe it’ll just be about Drip and the trials and tribulations, the last year of personal finance hell and being unable to fund the business and then the year of the acquisition and then the year of moving. As I started thinking about it, I was like, “Isn’t this interesting enough? Will anyone care?”
I sat down with a notebook and I just wrote out what were the most stressful parts of my life both personally and professionally since 2011 in essence. The list was crazy long. Each of them just shaped into this narrative and they link together in this very interesting way. Even if I were to write about acquiring HitTail and not use it in the book, it’s still […] for me to write about the process of growing it and then selling it. There’s a bunch of stress that went along with that sale.
I started just thinking about all the stuff that happened growing Drip. I made this big list, when I looked at it I feel like it’s interesting enough, at least worth sitting down and hacking some stuff out. I had like three pages of just bulleted list. About a week and a half ago, I just sat down one evening, I started doing it on a weekend. It’s kind of writing itself because it’s a narrative. I’m pulling out actionable things but I’m trying to get the grit of what it was actually like.
I have emails, I have Voxers, I have all this, I have my MicroConf talk from last year talking about the sale and my thought process, I started to listen to that and transcribing pieces of it. It’s cool in this day and age, all the digital elements that we have because I can’t remember exact dates but Gmail sure doesn’t forget. It remembers the exact date of this email that I sent to Derrick about this topic.
I’ve literally just been doing it on the side almost as a journal but trying to be very honest about everything, trying not to sugarcoat things. I’m about 7000 words in and it has just poured out of me, it’s all out of order, I just picked the next thing on the list that I think, “Man, I really wanna write about that today,” and I’m cranking it out.
I don’t know if it will be a book, I don’t know if I will ever release it but it’s something that I think could have the potential to be that. It’s always funny, when I got this question I started thinking, “Maybe that should be a piece of this.” Because I don’t just want it to be a narrative, I actually want it to be in typical or a podcast style and MicroConf style. I want it to have lessons that people can take away.
Whether they’re acquired or not, even just the growing part of it, the mistakes that they can avoid that I made or smart decisions that we made that I feel like people can learn from.
Mike: There are two pieces of that because there are people who would read that just because they know who you are or they’ve seen you speak and they just want the inside baseballs so to speak. They’re interested in the story, I totally hear what you’re saying about having the lessons but I think you could do both where you’ve got the story itself and then after each chapter or after each section you have a list of things that you personally pull out and be like, “Here are the lessons that you could take away from this, here’s the story piece of it and then here’s the lessons that go with each of these.”
Some of them may not have any lessons at all, it’s just something happened and you got lucky or unlucky and you just had to deal with the consequences or fallout. There may not have been anything that you could do about it. Maybe that’s the lessons, you can’t plan for everything but I think that it’s still going to be interesting to a lot of people.
Rob: I appreciate that. I kind of think of it as I think of any MicroConf talk I’ve ever given or at least the best talks that I’ve given tend to be a story, like a hero’s journey and then pulling out super actionable tactical things. That’s how I’m envisioning it. I’ve read only a couple books like that, I like it because it’s different, it’s not just a narrative. I want them to be not obvious takeaways, it’s not like work hard and persevere and you will make it. It’s not stupid stuff like that.
I realized that I think I’m telling myself that I don’t know if it’ll be a book so that I don’t feel in pressure or anxiety. I don’t want to feel forced to write it, I don’t want the writing to feel forced. I’m telling myself no one will ever read this because I wanna tell the story honestly, because there’s obviously a lot that went on that no one else knows that was very internal, that was between Derrick and I or between Clay and I or whatever.
Eventually, I’m sure I’ll have to edit some of that out but I’m trying to get it all out and then evaluate, is this worth doing? Maybe it’s an ebook or maybe it’s a series of blog posts that I’ll release or maybe it’s an audiobook, I don’t even know. It’s an interesting project. Hopefully it’ll turn into something.
Mike: Man, if it doesn’t, you did it for yourself and that’s not a big deal either. There’s something to be said for just doing things for yourself once in a while.
Rob: Exactly. That’s what I said, it’s like what’s the worst that can happen, I should just write this out. If nothing else, my kids can read it someday or something.
Mike: All of these aside and back to the question, are there any top level things that you can take away that you wish you had done that were probably a major things that you either overlooked or hadn’t thought about upfront that needed to be transferred or you wish you had done?
Rob: The prep work that I think everyone should do that you don’t think about is it’s far more mental prep work than anything else. I listened to the book Built to Sell three or four times, I listened to Finish Big multiple times, I did a lot of journaling, I did a lot of thinking. You have to know what your deal breakers are, you have to know probably what your drop dead price is. There’s a bunch of stuff that you need to think about and that it the prep work that I would focus on. I’ll just put that out there, first and foremost spend more time doing that.
The examples that the guy brought up, the guy who answered the question, most of these were not an issue. He brought up intellectual property, I had already transferred all of that into an LLC. If I hadn’t done that, it would’ve been disastrous, it would’ve been a huge pain in the ass.
One big thing that I do think you need to think about as you’re building your companies to have a clean IP, meaning that all of your contractors who touch your code, all of your employees who touch your code, you need to have them sign in their employee agreement, it should say, “Everything I do, the company owns.” I had that, I had only missed one contractor. I went back and asked him nicely, we still have a good relationship and everything was fine.
Had I not had that, it would’ve been really tough because when we went through the acquisition, they needed that. This funded company is not going to pay a premium for my startup if there are IP holes that someone could come back later and sue them or ask for ownership with the code or whatever. It’s not something you think about when you’re two, four or five person startup but it’s something that you should definitely have.
I signed to the same employee agreement, and Derrick signed, even us cofounders. We had to have agreements that basically Drip, the S Corp that owned everything own everything, that Derrick and I couldn’t walk away with that. That’s one thing I would think about.
The guy mentioned manuals and processes, that was not an issue because we were an eight person team and they’re acquiring the team. They weren’t looking to automate everything. I think if the team was walking away, yes they would want manuals and processes to hand off to the next team but there was zero questions about that. There were more questions about what our vacation policy and HR staff and employment agreements looks like than anything like that.
In terms of bank issues, they didn’t acquire the company, if you think about it. They acquired all the assets of the company and that’s typically how it’s done because they don’t want any of the liabilities. They left an S Corp that Derrick and I still own the same amount that we’ve always owned, they just bought all the internal assets of it including the code and the goodwill and the recurring revenue and employment agreements and all that stuff.
As a result, the corp still owns the bank account, they didn’t acquire any of that stuff. Thankfully we never had to setup a PayPal account or anything like that. Same thing with domain names, we just transferred them over. They were all in the GoDaddy account and we transferred them over to their GoDaddy account.
The only other thing I could think of as I was going through this list that I think would be interesting to think about it they ask for, this is typical, the standard due diligence stuff, all corporate documentation, your articles of incorporation, every single amendment you’ve ever made to them, everything. Have that all in one place because going out and finding it and scanning it is a pain in the ass.
Having record keeping doesn’t seem like a big deal when you’re a three person startup or when you’re a solo founder. But if you’re ever planning being acquired, you probably want all of this stuff somewhere so it doesn’t take you weeks to put these docs together.
The next thing is having really solid books, basically having income statements for every month. For me it was literally just a Google Doc with revenue, expenses and that kind of stuff. I also had Xero, the accounting software that they could look at. When they were asking for high level numbers, top line revenue and that kind of stuff, I was sending them Google Docs.
They’re gonna ask every single service you use, what’s every SaaS app that you pay for? Hopefully they’re all on a credit card, you could just go to credit card, that’s what I did and just started listing those out. Copies of leases and every contract you’ve ever signed for every service. Transferring the Stripe account did happen because all the subscriptions were in there.
That’s the high level overview, I think it’s something that I hadn’t thought about. When there’s a technology transfer, you think more about, “Boy, the tech has to be good and has to be automated and you want processes in place.” When it’s a company acquisition, it can be different. When people bought HitTail just as a product, they didn’t ask for articles of incorporation because they weren’t buying the team, it wasn’t a strategic acquisition. Those are my high level thoughts.
Mike: I hadn’t realized that they did not acquire the entire company itself and they were just acquiring the assets from the company. That’s the way that my wife had purchased the fitness studio that was in town. She didn’t acquire the business, she acquired the assets of the business.
I was very clear to her about just because the records of the business were obviously a little screwy and the person who own the business before couldn’t really explain certain things and was a little cagey about certain pieces of it where I’m just like, “Do not acquire the business.” Because let’s say she’s got a car, for example, that is owned by the business, if you acquire the business, you’re also acquiring the debts that go with it and any liens or anything else that goes with it. You will be on the hook for those things. If you don’t know about it, it doesn’t matter, you still have acquired them which may suck.
Rob: If you buy the company, you acquire the assets and all liabilities. That’s why almost without exception, anyone who knows what they’re doing, when they buy a “company” they’re just buying the assets of the business, that’s the standard. When Facebook bought Instagram, you can bet, their lawyers did not buy the Instagram LLC or C Corp. They bought just the assets of it.
As a result, you have to then list out what all the assets are which is interesting because you have to list out your code and the database and this, it’s just a big long list of stuff.
Mike: With my wife, there was a tax bill that ended up coming in. It was sent to her and she’s like, “No, this isn’t me because I didn’t acquire the business.” There was stuff that came up afterwards that had she’d acquired it, she would’ve been stuck with it and there is nothing she would’ve been able to do.
The other thing I find interesting is that when I worked for Pedestal Software and they got acquired by Altiris, the Altiris acquisition team came in and they handed us, all the employees, these documents that we had to sign that were basically more or less a copy of what our previous agreement with Pedestal had been for all the IP rights and signing them over to Pedestal but it was their version of it.
We’d already signed all the stuff but they said, “Yes that’s fine and everything looks good but you also have to sign these.” I think maybe there are updated ways of covering additional holes or something like that, I’m not sure.
Rob: I guess our agreements were perhaps good enough for their lawyers, they probably looked at them and said, “This covers everything.” Because it was recent, it was within the last year or something and everyone had signed. I broke everything out, Numa Group which is my umbrella LLC that owns a bunch of stuff, it owned Drip until maybe 9 or 10 months before it was acquired.
I was already in the process of ripping it out of Numa Group because that was when Derrick was taking some equity in the company and he essentially became cofounder. I was already in that process which was painful and agonizing and took five months and more money than it should have. Drip was already in an S Corp. I was very, very thankful for that because if it did not, then it would’ve been a fiasco to try it doing during the negotiation and the acquisition process.
When that all happened, I basically fired all of us from Numa Group, we all got new jobs with Drip, S Corp, Drip Incorporated. We all signed agreements at that point again even though some of us already signed up with Numa Group. Then, essentially when Leadpages acquired us, we all got fired from Drip Incorporated and all got new employment agreements with Leadpages.
I think they probably had some IP stuff in their employment agreement as well which is fine because then anything you do for them they own but they didn’t have a specific additional stuff we had to sign.
Mike: I wonder if it maybe it was because Altiris was a public company and they had additional things that they had to cover themselves, I don’t know.
Rob: I can see that, it makes sense. Thanks for the question, guy. I hope that was helpful. Our next question is actually not a question, it’s some kudos for us and it’s a voicemail.
“I just listened to episode 838 with the questions. It was great to have that interactive […] podcast, I just wanna give you guys some feedback, a long time listener. My name is Chris. I really enjoyed the episode, just hearing those questions and getting some more of your perspectives and your background and experience. […]. Take care, guys. Thank you again. Keep up the good work.”
Awesome. Thanks for calling, Chris. I wanted to play that because it’s good to hear feedback and folk’s opinion. He said episode 838 but I think he meant 383 which was just another one of these Q and A episodes. I specifically mentioned in that one that I like doing them more often and that I like getting voicemails because it shows it has the interaction. Thanks for that, man. I’m always happy to hear from folks.
Our next question is from Mr. Andrew Connell about GDPR. “Hey Rob and Mike, this is Andrew Connell from Voitanos, that’s voitanos.io. I do online training and I do it for everybody around the world or developers around the world. With the coming effectiveness of the GDPR for data privacy and personal privacy data at Europe, I’m curious if you guys can comment a little bit, of course not being lawyers, I’m not a lawyer either. I just think about what kinds of things developers really need to be paying attention to? What kinds of things you need to be careful of?
I’m asking these guys because it’s also very much in the way of how we’ve all be listeners of your show worked on doing email based marketing and collecting email addresses and potentially phone numbers and other information about users. What kinds of things you need to think about, I’ve seen things about privacy statements that you need to have on your site, how you’re collecting the data, what talent is being used, how you’re protecting it, all those kinds of things.
I’m just curious, what things do you really need to be paying attention to? There’s probably the gold standard but also what’s the standard that you can do where you’re at least defensible. Maybe you’re collecting data and the user finds out, they decided they no longer wanna be tracked by you. Can you just go back to them and say, ‘Yes I track you by your email address. Here’s all the information I have about you. If you want me to delete you, I can delete you.’ I’m just curious, do you guys have some comment there or maybe even have somebody who is a lawyer who can jump on the show and maybe comment? Thanks a lot. I love the show. See you guys in Vegas.”
The riveting conversation topic of GDPR.
Rob: Everyone is thinking about it so it’s important, it’s just such a fiasco. I’m gonna use the word stupid a lot in this conversation insight. Big parts of it, I think, are really dumb. There’s a 250 page doc or whatever and Brandon, our senior director product, went through the entire thing.
The end result is gonna wind up being something like we have to rewrite a bunch of internal policies and we’re gonna add a checkbox to a form for our users. That’s very similar to what MailChimp is doing and Active Campaign, all the ESPs. I’ll stop there and circle back because I’ve been talking a lot this episode. I know that you saw a talk at FemtoConf about it and I’m sure you have other thoughts on this.
Again couching it that we aren’t lawyers, we are not giving personal advice to anyone and certainly don’t have an exhaustive understanding of this but this is just our general thoughts on what we feel like folks might wanna do for GDPR.
Mike: The talk that I saw on FemtoConf, there’s a linkable posted in the show notes from Aleth, she’s the one who gave the talk. There’s a link to an overview of her talk as a recap from Christoph. He runs FemtoConf with Benedikt. You can go out there, there’s an overview of it but I’ll say it glosses over certain details that she talked about specifically.
With GDPR, the thing that you really have to make sure that you’re aware of is that if you touched the data in any way, shape or form, you’re on the hook for it. You have to make sure that you are both protecting it and if you are able to personally identify somebody, that you are complying to those GDPR policies.
If you have metadata about somebody, like custom fields or something like that, that’s not considered personally identifiable information but there are certain pieces that are. For example, an email address would be personally identifiable, an IP address would be personally identifiable, first name, last name, address, those kinds of things.
Rob: How is an IP address personally identifiable? That’s stupid. It’s not personally identifiable because IP address, a, can change constantly, b, you could have a single IP address for 100 people at a company, there’s so many ways that that’s not. I will stop.
Mike: You just have to be careful about what it is that you’re doing with that data. A couple of big things that I’ve seen that you have to really pay attention to if you’re selling stuff is that one, people have to be able to request a copy of all of the data that is associated with them.
If you’re running a SaaS app and it’s collecting the information, let’s say it’s Drip ESP, your customers are gathering information based on that email address, the person who owns that email address has to be able to come in and say, “Show me everything that you collected about me.” You have to provide them with the mechanism to give them that data dump. I’ve seen this recently, Facebook is doing this, Twitter is doing this.
You can go and you can request a download of all the information that Facebook has on you, the same thing with Twitter, you can get a download of it. I haven’t done that with mine yet but my understanding is that it is absurd and I’ve seen the amount that Facebook has on you, for example. There’s obviously backlash in the news right now about the amount of data and how personal it can be in certain cases. That’s something you have to pay attention to when you’re trying to comply to these, you need to give that to somebody.
Rob: Here’s what I would say, if you’re a developer, you don’t have to have an automated way. They can email you and you can go run a sequel query. I would not go and build something consul or anything especially it’s a small company. You know that you can do stuff agile and just do it when it happens, do it just in time, whatever.
They can also request that you have to delete everything, then at that point, the first time, it’s gonna be a pain in the butt but you’re gonna write that sequel query to delete it out, it probably gonna break something then you’re gonna fix it and then the next time you’ll have the same query. That’s how I would think about it. If you’re Facebook, that’s not gonna work because it’s not scalable. The odds of you getting a request when you have 1000 users or 5000 users, it’s pretty low.
Mike: The downside of that, though—I was just about to mention that—with deleting the information because you do have to comply to the right to be forgotten clauses.
Rob: Which is the stupidest thing I’ve ever heard.
Mike: I think you said it in the middle of the other comment as well, we’ll say it’s three. The right to be forgotten says that somebody can say, “Completely forget about me.” The problem I have with this is that where do you draw the line for that? I know that there’s a timeline that you have in which you can say, “We’ll get this taken care of.” You have a certain amount of time or this 14 days or 30 days to get rid of the data.
The question I have in my mind is that yes, I understand that that applies to backups but does that mean you have to go into your backups or you are only allowed to basically hold 30 days worth of backups? For the sake of arguments, say that it’s 30 days, is that all you’re allowed to maintain because that seems scary.
Rob: That’s why this is insane. It’s a legislation, it’s government getting involved in something that technically is a bad choice for a company or a bad choice for a business. We know as IT people, as developers, as professionals, as DBAs, you wanna have weekly backups or monthly backups for literally years probably. It’s not so you can hoard and use a bunch of information, it’s so if stuff goes sideways at some point and you realized you have this big error, you always go back, it’s a safety mechanism.
Mike: The other thing that bugs me about this is the right to be forgotten. I get the intent and I understand it but let’s say that somebody comes to you and says, “Rob, I want Drip to forget about Mike Taber.” What happens in three days if my contact information makes it back into Drip? How do you prevent my information from going back into the system without knowing who I am and keeping track of that? That’s a total chicken and egg problem.
Rob: None of that, as far as we’ve seen, is in GDPR. That isn’t addressed. The example is you say you want the right to be forgotten, you sign up for Rob Walling’s newsletter and you, Mike Taber, say, “I want to be pulled out of there.” You’re pulled out. What if you’re in 10 of our other customer’s accounts, are you only forgotten out of that one account? Are you forgotten out of everyone? It’s not specified.
Like you said, what if you then go to sign up to a new newsletter tomorrow and XYZ person is also hosting on Drip. There are so many edgy cases. The problem is every version is gonna be this much of a pain in the ass. If they do V2 in a year, think of how many personal hours and how many dollars have been pissed away by companies that would otherwise have been productive building products, doing interesting things, creating jobs.
Marketing alone on the Drip team which is not a huge app, we’ve wasted hundreds of hours and thousands, if not tens of thousands, on legal fees just having our lawyer’s advice and stuff. That sucks, that’s money that could’ve actually been productive and instead it’s sitting here dealing with what essentially is legislation.
Another issue I have is that in the US, they often will pass things, they’ll pass laws like this but they will exempt small businesses. If you’re 25 employees or less, you don’t have to comply to certain things. They do that because they don’t wanna put an undo burden on small companies because small companies are the ones that don’t have the budget, that don’t have the analysis council and that don’t have the bandwidth to handle a 250 page doc that’s completely opaque and everyone is confused about and freaking out. I think there should be an exception.
Isn’t this really meant to be for Google and Facebook and Apple and Fortune 1000 or Fortune 5000 Companies. How much do they care about these tiny little 3 person, 5 person, 10 person companies. They’re just trying to run a business, they’re just trying to make a living. That’s where I think they overlooked having some kind of exemption for small businesses.
Mike: There are certain pieces of it that are exempt; there’s the security officer, a dedicated security officer. Stuff like that, I believe is exempt. If you’re a small business below a certain size, you don’t have to have that. But the reality, at the end of the day is if you’re a single owner, that’s you anyway. It almost doesn’t matter. I totally agree, they’ve overreached is really what it comes down to. It doesn’t makes sense for much smaller businesses to try and have to comply to that.
Rob: Again, you and I agree, we understand the spirit of what they are trying to do. I don’t disagree with any of that, I disagree with the amount of burden that they’re placing on all the small businesses. Everyone is talking about this right now. It’s a waste of everyone’s time. When I say everyone, in our circles, in the startup circles. Yes, Facebook should worry about it but it’s so much wasted bandwidth.
Rob: I have not come across that, I don’t know about that. That’s an interesting piece.
Mike: Let me give you an example, if on your website you have Google Analytics, a Facebook Pixel, and a Drip Widget for example, somebody can come and say, “I don’t want you to track me using Facebook Pixels but the other things are okay, just not that.”
Rob: I had a guy who read all 250 pages of it and that is not on our list. I would look to see if perhaps there’s an exemption or there’s something in there that says you can otherwise not do that because, again, I haven’t heard anyone else talk about that.
Mike: The thing is there’s a piece that revolves whether or not you’re a data processor or a data controller. That’s the part that revolves on it. You mentioned earlier that there’s a question in your mind about whether or not if somebody is asked to be forgotten, is it just for that one account or is it for all them? My understanding is it’s all of them.
They could go to Facebook, you don’t have control over but they could go to Facebook and say, “Opt me out of everything, don’t track me. Forget me completely.” That has a trickle down effect on you running Drip because if you guys use the Facebook Pixel to track people, then you can’t track me, for example. Facebook essentially blocked it. Again it goes back to how do you keep track of that unless you know who the person is to not track them.
Rob: To be honest, I asked someone who I know is familiar with GDPR and had spent some time looking at it. He runs a small business, less than 10 employees. I was saying, “What are you actually gonna do here?” He said he is gonna handle things as they come in in terms of the request, in terms of deleting and in terms of giving a report of what they know.
He is seriously considering not creating all the documents because they basically say you have to have these 10 policies or 12 policies, all this internal documentation you’re supposed to have, processes to do this. He was going to say that his company is compliant with the spirit of GDPR and we’ll live up to the request but they do not have all of those policies in place.
It was like some verbiage of we believe in the spirit of it, we will comply as needed type of thing with the thought in mind that he’s not in Europe so he’s not European business so it would be very unlikely that the EU is gonna reach across the pond and come and try to take some little 10 person company out. Like I was saying, this is really more intended, my understanding is more intended for these larger companies.
A checkbox and them checking a checkbox is gonna make a difference, it’s like agreeing to a ULA, user license agreement with Apple, no one reads those things. You’re gonna put a checkbox with the link and it’s just gonna become this route thing that everyone does. It’s not gonna change anything but that is what it says technically. Consider if you’re asking for keeping your customer’s customers data somewhere, it gets more complicated.
In Andrew’s case, he runs online training. He has an online training, video training, people can sign in. He’s not collecting his customer’s customers data so it’s very much more simplified. I would consider a just in time or a simplified approach if I were in his shoes. How about you, Mike? You wanna talk about how every aspect of your business is not gonna comply and open yourself up towards the EU?
Mike: That’s the interesting thing is that for businesses that are not based in Europe, they don’t have the jurisdiction to force you to do any of that anyway. There’s literally nothing that they can do, they can’t sue you and say, “You are not complying to this.”
Rob: They could sue you in US court, they could. The EU could file a sue in Massachusetts court. You would have to fight it out, you would have to settle or you would have to fight. The odds of that happening, though, for you are almost non existent.
Mike: The thing is there’s a difference between them filing suit versus them having jurisdiction over. The sucky part would be you’re gonna have to comply to it just to make that lawsuit go away or you’re gonna have to fight it which you’ll win if you fight but you’re gonna incur a ton of legal fees over the course of doing that because they don’t have the jurisdiction and that’s what the court would rule.
I certainly wouldn’t recommend trying to fight it yourself and be your own lawyer there. I’m sure that somebody probably is skilled enough to be able to do that but I wouldn’t wanna be that person, I wouldn’t wanna risk it.
Rob: Here’s another option I heard someone throw out. They said EU customers are less than 10% of my business, I’m gonna reject, not allow EU customers anymore because I don’t have the bandwidth to do it. That’s what someone told me, that was really interesting. That’s a super bummer but at some point you have to throw your hands up and you gotta do IP detection or you just ask, “Are you in the EU, yes or no?” If they say yes, during the signup, you just say, “Sorry we can’t support you through the GDPR.” It’s pretty fascinating, I hope it does not come to that but I can imagine some businesses that’s just going to be easier and simpler to do that.
Mike: I’ve heard some people tried to, I think it came up at MicroConf Europe this past year about the legislation. There is someone there I met who was basically basing his higher business idea off of the idea that there were going to be US based businesses who aren’t going to comply to GDPR and they were gonna say. “You can use our service and you will be compliant.” I disagree that that’s a great business idea because all they have to do is comply and then suddenly your whole business value proposition goes off the window.
Rob: Obviously it’s complicated but I do think there’s a pragmatic way to approach this. As with any legislation, it will iron itself out, it will be more understood. You can watch companies like MailChimp or Drip Leadpages or whatever, GitHub, or Slack and watch how they handle it and then evaluate, “Do I need to do some other things?” You can also read that 250 pages doc and try to sort it out.
I don’t think it’s as bad as people make it out, I’m hoping it’s not gonna be that way. I do think if you’re in the EU, there is definitely more of a cause for concern if you’re running a business. Thanks for the question, Andrew. I think that was super helpful and a timely topic to discuss.
Mike: I think with that question, we’ll wrap things up for the day. If you have a question for us, you can call it into our voicemail number at 1-888-801-9690 or you can email it to us at email@example.com. Our theme music is an excerpt from We’re Outta Control by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for Startups. Visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening. We’ll see you next time.