Episode 358 | Bootstrapping into the Enterprise, Avoiding Death by Google, Selling to Outside the U.S. and More Listener Questions

Show Notes

In this episode of Startups For The Rest Of Us, Rob and Mike answer a number of listener questions on topics including bootstrapping into enterprise, avoiding death by Google, storing customer pricing data, and selling to companies outside the US.

Items mentioned in this episode:


Rob: In this episode of Startups For the Rest of Us, Mike and I discuss bootstrapping into the enterprise, avoiding death by Google, selling to companies outside the US and we answer more listener questions. This is Startups For the Rest of Us Episode 358.

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: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, sir?

Mike: I’m headed over to the Businesses Software Conference this coming week. That’s from Sunday to Wednesday. I think that by the time people hear this, it’ll be Tuesday. If anybody happens to be around, feel free to get in touch with me and I’m more than happy to chat for a few minutes and just talk about business.

Rob: For those who don’t know, Mike and I both have very high opinions of Business Of Software, and in fact it’s one of the reasons that we started MicroConf back in 2010, 2011, is that Business Of Software does such a good job with a certain strata.

Originally, it was cellphone and software companies and there’s a lot more folks going after IPOs and raising moneys. It has developed into a lot of B2B SaaS and it’s a larger scale. I was thinking of it like, if you outgrow MicroConf, you could graduate up to BOS. There are a lot of parallels in terms of how we run the show and I have a lot of respect for what Mark’s put together. BOS, it’s like a step up in terms of a lot of things that’s more expensive, it’s larger and it’s for larger organizations but I do still have a lot of respect for it. In fact, I was planning to go because my wife, Sherry, is speaking next week at BOS. I have a ticket and everything and we had plane flights and then our live in nanny, remember her? She moved out.

Mike: I don’t remember her specifically, but I do remember [00:02:01].

Rob: You remember the story, yeah. She actually had a family health issue and she had to move out suddenly to go help out with her family which is obviously a real bummer for them but it means we don’t have her because she was going to fly back with the kids on Sunday and I was going to hang around for the conference. Since Sherry is speaking, she gets priority on this one. I will only be in Boston over the weekend. Are you and I going to see each other, though?

Mike: I don’t know. I was going to talk to you about that. But we’ll talk about it after the show.

Rob: We’ll have to figure that out.

Mike: That’s actually an interesting side note because most people don’t realize that we aren’t anywhere close to each other, and haven’t been for seven years. We used to live in the opposite sides of the country, now you live in Minneapolis and I live about an hour west of Boston.

Rob: Right. We see each other generally twice a year, at the two MicroConfs.

Mike: Yup, and that’s about it.

Rob: Cool. On my end, it’s like every couple of months, doing scaling stuff. Right now we’re trying to take the load off the database, drip it to a large system, we’ve already denormalized tables off into Redis and into other data stores but just wanted time pulling them off to reduce load because we’re starting to get some cue backups, peak times and obviously want to keep things moving through.

Now that I’ve sold the company, I think scaling is my least favorite thing. Before I sold, it was like operations, it was HR and taxes and all that stuff but I don’t have to worry about that for the company anymore because I don’t own it, but I think this has become my new thing that I don’t want to ever do again.

I want to hire good people to do this, not have to do it myself, basically. Not that I’m not doing it myself, granted I’m not writing the code and we’ve had the luxury of, since Leadpages does have so many resources that we actually have some really smart senior scaling architects that we’ve been able to pull over and so I have actually slowly stepped away from any involvement or planning in that which I think is good both because they’re smarter than I am at doing this stuff, as well there’s just other things to be done with a product of this size.

Mike: I think the hard part about those scaling issues is that when you run into them, they are typically things that you can’t solve very quickly and those problems are just going to linger for the entire time that you have that customer base using those particular resources that are getting bottlenecked for whatever reason. You can’t fix them quick enough. I think that’s what the stressful part about it is that for however long it is, if things are going to be backed up and even when you go to deploy stuff that will fix it, you’re not absolutely sure that it’s going to really fix it just because your test suites don’t typically have the load on them that your production system does. It’s just stressful. I ran into my own this morning but not nearly at the scale as yours, I’m sure.

Rob: Right. It’s always stressful because in the early days, you only have few customers and you’re worried about even losing three of them. We’re at the scale where obviously it’s a different thing but still, there’s a lot of stress to it at both ends of the spectrum. What we actually did, it’s interesting, the app is so large and so many servers that it is virtually impossible to simulate the load and to actually test approaches. We test them as best we can and then we push them in. To date, they have all improved, we noticed that things got faster.

About three weeks ago, we split cues apart into their own separate scaling groups and it was certainly going to make everything faster. In fact, each individual thing was faster but since they’re all pointed at the database, it actually started having the database thrash because there was too much throughput to it and it wasn’t traffic guarded, it was just having a big pile up at the database layer, starting to slow things down. We actually reverted that and we recombined the cues about 48 hours ago and it was just a huge shift. Suddenly, everything started going back to where it was three or four week ago which was in a much better position. That’s one of the things that’s hard about it. We haven’t had that happen in the past where we launched something that made it really slow but man, you really got to keep your eye on this stuff.

Mike: One of the things that I did when I started running into some scaling issues, I found some raise conditions but with raise conditions it’s similar but it’s still difficult to replicate. What I did was I created, I forgot what it was, it was like 10 scripts and I just launched them all at the same time, pointed them at the same location and just let it go and then looked at everything afterwards and said to this thing hold up, where did it fall over? It worked great, the thing was responding 30 requests a second or something like that which doesn’t sound like a lot but it was all on my local machine.

Rob: Cool. What else is going on with you?

Mike: Not really much, just spending a fair amount of time on support issues at the moment. I think I have to look at outsource and some of that stuff just because there are two different types of problems that are coming in; one’s general usage and questions about how the app already works. And then there are things where something just isn’t actually working the way that it’s supposed to and those things would probably have to get escalated to me. I have to look at how to delineate between them and then bring somebody in to help serve as a buffer to help maximize my time in the most productive places.

Rob: Yup. Boy, that is one of the first things that I always outsource. It’s easy enough to train and they can always escalate to you and it doesn’t seem like a big burden and I’ve heard folks tell me, oh no, it’s only a few emails a day. But it’s the distraction and the fact that you need to get back to it quick and you have to task switch. As soon as you get someone good in there who’s doing it, they will take more and more and more of that burden off your plate. When it grows to 30 minutes a day, an hour a day, two hours a day, you don’t have to worry about it, it just naturally scales up.

Especially solo founders, but anybody who’s bootstrapping, it just buys you so much time and really support is obviously always super important, but it’s extremely important in the early days for you to be more involved because you’re still doing customer development, and you want to hear the questions so you know what docs to build and what on boarding to build and you want to hear the concerns and the bugs so that you can fix super-fast for these early adopters. You have to transition out of that at some point.

Mike: Yeah. Mostly it’s the time looking into different things and then turning around and getting back to them. As you said, it’s not the time itself to answer somebody but it’s the context that goes along with it. There has been days where I spent two or three hours doing support and sometimes it’s just looking at stuff. Just like this morning, I spent a couple of hours trying to troubleshoot an issue and come to find out nothing was actually wrong, it was just things were backed up.

Rob: Yup, that makes sense. If you hire a support person, obviously part time, and they start wrapping up, then you’re going to basically be their backing engineer, they’re going to escalate to you when there’s a tech thing that they’re unable to do. The next hire I would do, because you’re going to hire a developer I suppose after that, that person should be the backing engineer and it’ll be a drag for a little while but it’ll free you up to run the business and then they essentially are the technical escalation, and that also will just pull a huge weight off of you from having to troubleshoot API calls and dig into people’s JavaScript, and just all the stuff that is, as you said, very time consuming.

Mike: The only other thing I have going on is that I’m probably going to be taking over some of the marketing efforts from my wife’s fitness studio. The interesting thing there is I really just have to make the decisions about what to do and then say, “Here, you go do this.” That’s nice, actually.

Rob: Got it. She is your minion on this case.

Mike: I would not phrase it that way. However you could pick a case for that argument.

Rob: Cool, that’ll be good. It’ll be nice for you not to have to implement. I’ve enjoyed being able to do a little bit of that with Sherry as well. Talking through books in Zen Tribes in Zen Founder stuff and being able to say here’s what I would do but then I don’t have to get in and write all the copy or whatever. Cool.

We are answering listener questions today. We have several, we’re going to kick it off with a voice mail or two. Our first voicemail is from Mark Stevens, and he has a comment on our Build Versus Buy discussion we had a couple episodes ago.

Mark:               Hi Rob, it’s Mark Stevens from Ideal Solutions here. I’m a big long-term fan of your podcast. To add my two cents to your episode on build or buy, I’m a big fan of building because that’s quite often where you figure out how to pivot your company and find the product you really want to end up doing. I’m looking forward to hearing Sherry talk at the Business And Software conference next month. I hope you’ll be there and we can catch up. Bye.

Rob: It sound like Mark’s saying he likes to build it because he uses it almost as exploration into perhaps another business idea or even a way to pivot his current business. That’s an interesting way to think about it. I guess in my head, if you’re pre-product market fit and it’s build versus buy, and you found something else that was super interesting… I’m trying to think of you built email marketing software and then you built a drag and drop builder and suddenly you’re like, oh, this drag and drop builder is a better business than email marketing software itself and an ESP. That’s one example I could think of.

Certainly for past product market fit, and you’re already scaling, then you’re not going to do that. It’s probably not going to pivot your company to sell this other product. It’s an interesting thought, I hadn’t thought about that angle of it.

Mike: Like most questions. I think the particular topic that we talk about is very context sensitive, where you are and the journey of the application or the business that you’re building and specifically what it is that you’re looking to either build or buy as to whether or not that’s a road you go down. You have to take it all down, the context of your current situation in mind.

Rob: Alright, our next voicemail is about how to bootstrap a B2B enterprise SaaS app.

Randy:             Hey guys, this is Randy from [Nolin 00:11:49] Office. Just discovered the podcast a couple of weeks back and I’ve been soaking in the information, great work. I have one weird question for you, we’re the weirdos trying to start an enterprise level B2B SaaS and bootstrap it and we’re really struggling with the education and consumer buy in process. Any advice or tips you can offer or previous episode you can point it to, I’d love to hear about it. Thanks again, please keep up the great work. Thank, bye.

Rob: Alright. Good question. The first thing I would do is I would go to startupsfortherestofus.com and I would search for ‘enterprise’ and search our episodes because I know that we’ve talked about this in the past, probably not super in depth. It might not be an entire episode but we’ve answered a lot of questions about this. You could probably cherry pick three, four, five episodes and get a lot of our thoughts on this. Aside from that, or in addition to that, Mike, I imagine we both have thoughts on what he’s talking about. What are your thoughts?

Mike: I think the first thing that jumps into my mind is that if you’re really targeting the enterprise, look around at your competitors and see how it is that they’re getting into their customers. If they’re at any level of scale and they’re having any level of success, then chances are good that the way that their selling into their customers is working at least to some extent and look to see if that is one, if it’s appealing to you, and two, you think that it is a mechanism for getting in front of those customers that you could replicate.

I feel like when you’re talking about enterprise level customers, there are certain ways that they are accustomed to buying and acquiring software. If you don’t follow those paradigms, then it can be very challenging to get into those environments. Looking around at what other people are doing and what they’re having success with, especially if it relates to the type of software that you’re selling, that’s probably where I would start.

Rob: Yeah. If you’re going to bootstrap into the enterprise, a, it’s going to be very long road because the enterprise sales circles are long and the enterprise is pretty cautious. They’re going to want to go with experience providers.

First thing I would try to do is to get a single case study that you can point to, and you’re going to point everyone at that during your sales process because without that, no enterprise is going to have confidence in a small team of people to deliver. What that means, you have to go slightly below enterprise and do more of a midmarket company or whether you get an enterprise company to do it for way cheaper than they should, I don’t know that I’d offer to do something for free but that’s a big deal, having logos on your website that you can name drop during sales calls. That will also show you how much of a pain it’s actually going to be.

That first one maybe is a semi-custom, you’re really the scratching and clawing because you don’t have product market fit yet, you don’t know if you built anything people want, you don’t know a lot of things at this point, and so you’re really just trying to get in front of a customer.

The challenge here is when you’re bootstrapping to small businesses and solo founders and all that, you have a volume play and you can talk to 100 people, 200 people and you can get 100 people using your app and then you figure out, you listen to the feedback and you can pivot based on that and you add features based on that. But in the enterprise, it might take you a year or two years to get five customers, and the deals are way bigger but the number of voices that are talking to you, and that you’re hearing from, is going to be a lot smaller. It’s going to be a lot harder to parse out the noise. When you have 100 people telling you, you start to see clusters of features and ideas and directions and then there’s noise around there at the outside edges. Like, okay, we’re not going to do that. When you only have five people, pretty hard to figure out what is signal and what is noise. Thanks for that question, I hope that was helpful.

Our next question is about how not to get killed by Google. It’s from Jukah and he says, “What can we do to avoid being too dependent on Google? If they block you from AdWords or their search results for whatever reason, how does your business survive?”

Mike: Start using Bing.

Rob: That’s the worst advice ever.

Mike: Google’s got their hands all over the internet, so that makes it difficult. There are also large players and depending on what type of business you have, your biggest channel may not necessarily be directly from Google or from search engines. If you have links plastered all over the place, then you’ll get a lot of traffic from people just by virtue of having those links coming back to your site from relevant articles or content that people put out there. There’s also other things like advertising channels that you can use either buy sell ads or Facebook or Twitter or various other places. I’ve heard people having good success with Instagram marketing depending on what type of business you’re running.

And then there’s also channel partners. If you look at a lot of for example the enterprise base, if you go look at some of these websites, there is very little there that tells you really what the enterprise level product does or how it works or gives you a download link. That’s because they use sales reps and channel partners to talk directly to people. They’re essentially bypassing Google at that point.

Don’t get me wrong, Google does serve an important function for them, but it’s not the full source of traffic or customer acquisition for them. By leveraging other channels, it gets you in front of those customers and you don’t have to rely completely on Google. This question really seems centered around relying too much on Google search results and I don’t know if you’re doing regular white hat, or you have maybe some grey hat strategies that you’re going to get heavily penalized by Google or get slapped the classic Google slap. That said, it could happen at any time or they could even just accidently drop you from their algorithms, you never know what’s going to happen. Unfortunately, that’s out of your control. You have to find other ways.

The last one I would say is email marketing is one of those things that’s just simply not going to go away anytime soon. If you have an email list that you’re adding people to on a regular basis, even if they do something like that, you still have that email list to go after and you can still leverage that for the time being until you figure out what to do about it or until some sort of corrective measures take place.

Rob: Yup. I like that. I think it’s diversification is the biggest thing. If you know how to rank in Google, then do that first, and then spend the next six months of your marketing trying to figure out on how to not be reliant on Google. Facebook ads, you named a bunch of ideas there, that’s it. As someone who has had a number of businesses, either severely impacted or completely decimated from over reliance on Google, I’ve never had a large business that Google killed. It was always these micro businesses were really the only marketing channel was SEO and Essence.

I had some apps, I’m trying to think of the biggest one was probably doing a couple grand a month and then it went to $300 a month after whatever Panda, Penguin, or one of these things several years ago.

I can’t imagine having a $50,000, $60,000, $70,000 a month business with employees that was strictly relying on Google. I personally would not feel comfortable building a business like that. I think that’s something to take into consideration as you’re thinking of what businesses to start there, a lot of considerations. Do you want to hire a low price point, do you want employees or not, what customers do you want, and who do you want to be reliant on? There are other factors like a friend of mine built an app that was based on the Twitter API, and this was several years ago. You remember Twitter basically just nuked a bunch of their folks.

Building a business that’s reliant on any single provider is a large risk. That’s the mindset, I don’t think there’s any easy answer other than diversification of leads basically, and like you said, building your own email list is a big way to do that.

Mike: Yeah. I think there’s a subtle thing there with the email list which is it takes the control of your channel out of other people’s hands and put it in your own. You can send those emails and you can put them into a different provider or you can even send them from your own mail client if the worst came to pass and you had to do that, but at the same time, you’re really just shifting where the responsibility is and where the control is for that traffic acquisition source or the revenue generation piece of it.

Rob: Yup, that’s one of the reasons I’ve always been such a proponent of email marketing, why I decided to launch Drip and why I’ve never gone down the road of building a whole Facebook community. Brian Clark from Copyblogger calls it Digital ShareCropping. It’s like building a community on Facebook or on Twitter or on Myspace or YouTube and then you don’t have control of that. That provider can just someday decide, oh, you paid all these ads and you built this following on Facebook and now we’re going to change our algorithm. Even though they are your followers, they’re only going to see one out of five posts instead of every post like they used to. You understand Facebook’s reasons for that. I bet they had customers complaining or whatever but suddenly you are basically at the behest of this large organization who’s going to do what’s in their best interest and not yours.

Once you have an email list, you are so much more in control. I like your point that even your ESP, you’re not reliant on them because you can always export and go somewhere else and send broadcasts and be in touch with your list from the 500 or 600 ESPs that are out there. It’s a good question, thanks for asking. I hope that was helpful.

Our next question is a general question and then with a specific one, it’s about storing customer data and what he should store. I’ll read through it and we’ll see which part of this we want to attack. “Hey Rob and Mike, I’m having trouble coming up with a strategy for tracking my user information for my SaaS app. I understand this may be a little on the technical side for the podcast, but what fields in your customer/user table. What should I be tracking, how is it setup? For instance, do you have a monthly pricing amount field or do you just have a plan field, like plan type = gold and then the gold has a dollar amount attached to it in a separate join table. Are there any advantages, disadvantages to use one method over another? Thanks for the podcast, I have been listening from the beginning and I look forward to each new episode every week. This is from Mike Richards.”

I’ll jump in on one thing. For the monthly pricing amount field versus just having a plan type, we usually have both. The plan type has a plan name because people want to know what plan they’re under, but every individual customer has a dollar amount field on there, some record. I don’t know if it’s a customer table or a join table or whatever it is. But it allows us to have crazy flexibility with pricing per customer. Of course that’s copied over when they first sign up, there is the template for the plan. Gold plan is $30.

When you sign up under gold, it’s going to put $30 in your dollar amount. But let’s say you want to give a free month or you want to give a price break or a discount, there’s just so much you want to do on a per customer basis. You don’t want to keep having to create a new plan every time you do that. Let’s say I want to charge $28 to this customer, just because. You don’t want to have to go in and put you’re gold, minus two, plan. You just want to be able to update that to $28. Same thing if they ask for, hey, I want to add another user to my account. Alright, that’s $3. It’s going to be $33, you don’t have to go and create your gold plus one user plan. You want to just be able to edit that in the row itself.

I’m not going to dive into all the rest of this. You could’ve asked a more broad question but I think the thing to think about is as you’re doing this, it’s thinking about what are you going to want to change in the future and to leave yourself the most flexibility that you can. I think that’s the key thing. You don’t necessarily need to over engineer the code around this, but over engineering a data model, I found, has its advantages because changing data models especially with join tables and adding more flexibility tends to be really hard. You have thoughts on this, Mike?

Mike: Yeah. I would agree with you that storing the dollar amount is definitely a wise idea and then storing the plan name. I’m early enough on Bluetick that I don’t have either of those stored right now. Honestly, it’s painful because I do have early access customers who have a discount that’s applied and that’s solely in Stripe. Even going into stripe, I can look and see how many subscriptions I have and it gives me the price but it doesn’t give me the price after the discount has been applied. It’s a little bit misleading when I look at some of the data because they don’t appear to know how much the person’s going to get charged until after they get charged. I would definitely keep those things in your own database.

The other thing to keep in mind is where you’re going to be managing that billing, is it going to be something custom that you do in your own app or are you going to use an online provider like Chargebee or there’s 30 of them out there. Chargebee is one that I’ve looked at in the past that manages recurring subscriptions and then the other option is to just use Stripe system directly.

One thing I would definitely do is you’re going to have to have some way of matching up the subscriptions for customers in your database up against whoever your payment provider is. If that’s Stripe, there’s a Stripe customer field of some kind and I would store each of those inside of your database so that if you need to, in the future, ever go look up data in Stripe and pull it back into your database, then you have that option. I’ve written scripts that’ll just go out and pull back billing information or things like that that if I need to import the data later, I can, especially if you’re later registering hooks with them to have your application notified that oh, this particular charge happened, update the billing information and local database and be able to show that inside your apps so that the user doesn’t have to go someplace else.

Rob: Yup, that’s a big one. I think for billing, we built our own script, it took a few days and then we’ve expanded that since then, that was a very, very good decision based on how complex metered billing is. I would link towards doing that in the future, I‘m not sure I will ever use a Chargebee or even Stripe’s subscriptions API. It’s too many limiting factors and I’ve heard too many people who are limited by that. Not having it in your code is the thing, it’s not a terrible decision, it’s not a decision I personally will do in terms of using an external billing system.

Other thing we did early on and Derek actually, you came up with this, I think this is a very, very good idea is that our database is essentially the master or the database of record for all charges. As an example, we never went in and refunded Stripe charge directly in stripe. Even when we were at 10 customers, I needed to refund somebody, he put a refund button in the Drip admin area so that when I clicked that, it went into our database marked as refund and then it went out and hit the stripe API.

The point is he wanted all the numbers in our database to be accurate, that we’re like, oh yeah, that one refunded and go in. Or this one tweaked the billing code or this discount or these edge case things. You don’t want those to only be in your payment provider for a lot of reasons but what happens when you want to change payment providers? If we had this switch from Stripe to someone else, it will always be a pain to write the code to do that but we would have all the data and switching would actually not be as hard as it would’ve been 10 years ago.

Mike: Yeah, that’s a really important point, figuring out what your source of authority is going to be. If you’re going to stick with the same payment provider, then it’s not a big deal. I’m running into this now because I just did certain things to get things done and I’m regretting some of those choices, I’ll say, just because I don’t have the data locally so it’s a little bit more difficult to run some of the reports.

Rob: Yeah, that’s always the trade off, moving fast versus doing stuff that’s going to keep you good in the long term but there will be no long term if you don’t move fast in the early days. It really is this perpetual balance.

Our next question is from Andrew Martin and he’s asking about selling SaaS to companies outside the US. He says, “Hey guys, Startups For the Rest of Us has been one of the main sources of information in my journey into learning to be a marketer and entrepreneur. Still working full time but I have a SaaS based company that I plan to fully launch this year. I’m a single founder and at this point, I’ve done all the development and the marketing. With the limited amount of outreach I’ve done at this point, I’ve managed to attract a couple companies that are based outside the US. Aside from convenience related things, like currency localizations etc., are there legal or tax related issues to having subscribers in other countries, is this something that ends up being specific to every country?”

Mike: I think the interesting thing with this question is that everyone does this type of thing a little bit differently and I wouldn’t say that there is probably anyone you could point to that you could accurately say they are the ones who are doing it correctly. It’s just because the laws in some cases are so obscure or the regulations of the different things that you have to file are very difficult to know in advance before you run into them and run a follow of whatever regulation and they jump all over you for not submitting taxes or for not collecting VAT in a specific country that is a particular amount. There’s all these things that are just difficult to know in advance.

I think generally speaking, like Bluetick for example, I’ve over simplified things and I only deal in US dollars. When the billing goes out, it’s billed in US dollars and then it’s converted on the back end using Stripe or whatever the currency is. Whether that’s Australian dollars or what have you, it doesn’t really matter. In my accounts, I’m treating it all as US dollars.

You can optimize things and charge in local currency, in some ways that’s a marketing thing just because people prefer to see their own currency when they’re looking at services that they’re purchasing and I know that it is more effective, I’m not just doing it right now. And then, beyond that, in terms of filings and stuff, really, I would say that’s outside the realm of my expertise or knowledge at this point. I just wouldn’t go into buffering advice on that stuff.

Rob: Yeah, I agree. This can get really complicated. I think it’s about learning what to do that’s mostly correct because I think if you genuinely try to do everything to the letter of the law, I don’t know that that’s going to be feasible for a single founder. I do believe that all of this stuff is country to country, that you might have a unified policy. I know that they have this unified privacy policy and that’s changed twice in the past three years. I had it when I was still independent, I had to pay lawyers to draft the contracts and I kept getting questions, they said Safe Harbor is no longer allowed, so then you have to have this contract drafted, so I paid a lawyer for a grand and now people in the EU, if they were going to use Drip, then they would have to sign this doc. They would e-sign it, it’s a big freaking pain in the neck, to be honest. And then they changed it again. Within the last six months, they’re like, nope. That doesn’t work anymore now. They had given you a model contract after which we modeled ours after. And they’re like, nope, it’s something different now.

I got to be honest, given the choice, if I was talking to 20 US companies and 2 European companies, and it was early and you’re still trying to figure stuff out, I don’t know if I would bother with it right now. It’s just one more thing that adds headache, it adds paperwork and they need invoices whereas companies in the US don’t, there is difference like the Can Spam Laws of the US are different in Canada and they’re different in Germany but not in the rest in the rest of the EU. Each of these things is a pain in the neck and I would be cautious into just diving in because people want to pay you money.

If the only people asking are Europeans and there’s a specific reason for that, that’s fine. But being that you’re in the US, you know the laws, you know things are generally how they operate, I would personally lean towards doing the things that you know about and that your legal counsel and your CPA are going to know about because it’s mostly done at a federal level. I’m not saying not do this but you just really got to think do you want to get into the complexity of trying to track all this stuff and keep track of it.

I know some SaaS founders, especially small SaaS founders doing $10,000-$20,000 a month and they deal with the EU companies and a lot of them are small business, whatever, it’s freelance or something. They don’t even bother with EU compliance agreements, the safe harbor thing, they just need maybe the invoice at the end of each month and you can just have your app generate that and then that’s it. They’re not technically complete and compliant with every EU statute and law but since it’s two really small businesses dealing together, the odds of that blowing up are fairly low.

Maybe that’s part of the risk tolerance question, are you willing to maybe do 70% or 80% of it right with the chance that if you traveled to the EU one day, maybe they would come after you for VAT, I don’t expect that to happen. I guess that’s the worst that could happen or they could take you to court in the EU. You got to think about these things realistically, like what’s going to happen. If you’re not a Fortune 1000 company, is it going to be on their radar? I’ll say it’s a personal preference or a risk tolerance and you got to think about what you’re willing to take on.

Mike: I think a lot of that also boils down to are you making a reasonable effort to do the right thing versus actively skirting the laws. You can say, hey, I did this and I did this and I didn’t know about that over there. I know that there’s this classic legal thing to say, ignorance is not a defense of whatever your actions were, but the reality is when it comes to paying taxes or filing paperwork and stuff, they will let you slide a lot if you just legitimately didn’t know and you looked like you were trying to do the right thing and you screwed up, versus if you were actively doing things that skirted whatever the laws happened to be. If you really are ignorant of what those laws are because you didn’t look them up, they are likely to give you a lot more flexibility and lenience than if you were actively putting accounts overseas and some Cayman Islands account to try and avoid paying taxes. I would take that into account as well.

Rob: That’s a good point actually.

Our last question for the day comes from [Fabrichio 00:33:16], and the question is about the right time to scale marketing. He says, “I love your podcast, I hear it every week driving on the East Rally Roads. Thanks for the good advice and interesting angles. It’s been six years since we started bootstrapping our personal finance software. We soft launched a year and a half ago…” Wow, so four and a half years in development. “In order to have users help us debug, improve the UX, find product market fit and optimize. Marketing efforts were small but brought enough users to iterate and improve.

Today, 5% of downloads become active. They use it at least once a month and 1½% pay monthly or yearly. We feel good about the direction and we get nice reactions from users but still we know there are many things to improve. We’re concerned about potentially damaging the brand if we make broad marketing campaigns when part of the first time users will be disappointed while others might not. We’ve identified some market niches but most missing features are common to all users and have no specific market common denominator so we can target a specific audience. In parallel, we have a big waiting list for other operating systems as we support only windows. When is the right time to scale marketing considering product market fit is a never ending activity?”

Mike: I think the first thing to consider is that you can’t please everyone so you’re going to have to move forward at some point. You can’t wait until you have all the information because that will never come to pass. You’ll never be in a position where you have all the information in front of you and readily available to make the optimal decision. You’re going to make those decisions about when to move forward and with what segments of your market with incomplete information.

I would say maybe take a segment of those people, if you’re really not sure and you’re really uncomfortable just blasting something out, take 20% of them and send out an email to those people and advertise things into them. If you also have a fairly large list, you can upload that into Facebook for example and do some targeted Facebook ads and look alike ads and see if that starts to pan out without going through your entire list. That actually brings another point, if you upload the entire thing to Facebook, you’re going to get much better information about the types of people that you should be targeting in order to get their interest in your ads and then bring them over to your website.

I don’t know if I would worry too much about disfavoring your brand. I’ve had discussions with people about brand strategies and things like that and it seems to me like until you’re much further along, trying to focus too much on the brand itself versus getting the right types of customers into your app, I don’t wanna say it’s a waste of time, but it seems like there are better places to spend your time than on trying to figure out what your brand is going to look like and how it’s going to be perceived. As long as you’re solving the problems for the customers that you have now, it doesn’t necessarily matter that you’re not talking in the right way to people who are prospective customers down the road. It’s going to take several touches before those people sign up for your app or become a customer anyway. Just by virtue of them seeing things, that is probably enough even if it doesn’t speak to them right away.

Rob: Yup. I think those are good points. I think it makes sense to do it when the money makes sense. If you can pump $1 into marketing efforts and you can get the $1.50 or $2, $3 back, that’s when you’re there. That means your churn is low enough that you can then put the money in and then you can use the profits that come out of that to build more features, to get closer to product market fit, and to market more.

I would be less concerned about having users come in and be disappointed, I think you can set expectations up front, I think you can improve on boarding, I think you can add features overtime but I wouldn’t hesitate to start running marketing if you do have a core group of users who are stoked and who are paying you. The percentages, it sounds like you are running a premium deal, 1 1/2% sounds fine. That’s in the range, I typically hear between 1% and 3%. It depends on how long you give folks. I think Dropbox was at 1%, after a year people start paying or maybe it was 3. But that was the general range.

1 ½% is in the middle there, you can obviously improve that but I think you’re on the right track. I personally would start marketing, I’d start getting more people in there and then you’ll know, you look at the first month or the first two months and if people are churning out quickly or their usage is not there, you should know the patterns of what it takes to get someone to a paying user status, you will know if that money’s going to pay itself off pretty quickly. If it doesn’t, that’s when you stop marketing, which I’ve had to do in the past. If it does, then you keep going with it. It builds that snowball, both the feature momentum part of market fit momentum and also marketing momentum. It was a good question. Thanks for sending it in.

Mike: I think that’s about all we have time for today. If you have a question for us that you want us to answer on the air, give us a call at our voicemail number, 1-888-801-9690 or you can email it to us at questionsatstartupsfortherestofus.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, we’ll see you next time.

Twitter Digg Delicious Stumbleupon Technorati Facebook Email

Comments are closed.