Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about billing systems. Some of the topics covered include monthly vs. annual, credit cards upfront/or not, dunning, and paid vs free trials.
Items mentioned in this episode:
Mike: In this episode of Startups for the Rest of Us, Rob and I are gonna be talking about why billing systems suck, and how to make yours suck less. This is Startups for the Rest of Us Episode 378.
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 Mike.
Rob: I’m not eating a sandwich.
Mike: We’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, Rob, aside from not having a sandwich?
Rob: I’m hungry and you’re eating a sandwich.
Mike: Yes.
Rob: You have a turkey sandwich.
Mike: I do. I described it to you in exquisite details just before the podcast.
Rob: I know you did. I’m like starving. I realized it was lunch time right now. This week’s pretty good, man. I think it feels like when I dropped my 11-year old off to school, was 23 below, but it’s up to 17 below. That’s not too bad. T-shirts and shorts day.
Mike: I think it was Brennan Dunn who had asked on Twitter earlier today why you didn’t ski.
Rob: I saw that. Yeah. I have a serious answer for it.
Mike: Oh, yeah.
Rob: Yeah.
Mike: I’ll tell you what, you give your answer and then I was gonna give my answer that I was…
Rob: Oh, got it. In all honesty, I grew up, we just didn’t really have the money to go to the mountains, and get all the gear, or I should say we spent the money doing other things. We didn’t go on ski vacations. There were mountains a couple of hours drive from us in Tahoe, but it just wasn’t a thing we did, and we always played sports, and so you didn’t wanna get injured, because I had friends who busted their knees up, they needed surgery.
I ran track for nine years, and my brother played football for eight. It was just something that we’re like sports were more important to us than the potential danger of doing that. That’s the serious answer. Now, what’s your take?
Mike: Mine was gonna be that because you grew up in California, whenever the temperature got below 70, you wrap yourself in a parka and just didn’t go outside.
Rob: This is true. Yeah, that’s the real answer.
Mike: But, of course, it’s ironic that now you’re in Minneapolis and it feels like 23 below.
Rob: I know. It hurts you’re nose and stuff, but man, with the right gear, it’s not the end of the world. You don’t wanna stay out for too long, but it sounds really awful and it’s fun. The sun’s out, you know, the sun’s shining, it’s bright.
Mike: As long as you’re not standing still, you’re fine. If you’re standing out there, of course, you’re gonna get cold, but if you’re moving around, it’s not a big deal.
Rob: Right. Yep. Anyways, I wanna extend an invitation. If you’re a listener, and you or your company might be interested in sponsoring MicroConf, or sponsoring some scholarships. We have quite a few companies that are lining up to pay for folks who can’t afford to come to MicroConf but feel those people would get some value out of it.
If you’re interested in doing either of those things, we’ll give you a recognition on the podcast. You’re obviously talked about a lot at MicroConf itself. And then we have you on the website, and people are hearing about you, you’re just kind of doing good for the founder community. Get in touch with Mike at sponsors@microconf.com.
How about you, what’s going on?
Mike: Well, I’ve had a rough week of support tickets after I pushed my new release. I’ve talked about this before. I was working on this major release. I got to a point where I’d done enough testing on it that I said, “Okay, everything looks good. Let me push this out.” Pushed it out, and see here is two weeks ago on Thursday. It was the week before I went to Big Snow Tiny Conf and pushed it out, everything looked fine, everything was great for four days or so.
Then, Monday I leave. Then, I started getting a couple of support tickets, and I started to get more support tickets. I ended up spending basically a full day while I was at Big Snow Tiny Conf just working on those things and trying to figure out what was going on. It got to the point where I actually rolled back to the previous release and then the problems kept continuing, I’m like, “Oh, God. What is going on here?”
Finally, I tracked it down, it turns out that it was a library from Google that I was using for authentication that was causing the issue, that was causing like one piece of the app to break. But everything else was still working. Eventually, I fixed that. Unfortunately, it was not actually directly related to the release itself, it happened to show up at the same time. I spent a lot of time trying to figure out what I did wrong versus, “Hey, what library is causing this?”
Rob: Wow, yeah, that sucks. That happens every once in a while. Obviously, it’s something you try to avoid but it will happen with these apps that we’re just constantly changing. It’s like you’re rolling changes out, or a library itself changes and breaks things. Are you completely past it now or is there any fall out?
Mike: I’m still dealing with the support issues here and there. Part of the reason for me pushing out was that I knew I didn’t have 100% test code coverage, but I also knew that the vast majority of it was working, and I just don’t know what little things are broken. There’s been a few things here and there that I’ve had to fix, but nothing major aside from the one issue, the Google library.
Everything’s working fine. It actually functions a lot faster, and is more scalable than it was before as well. I think it’s in a better place. It’s just that week or so was rough while trying to figure out what was going on. I was doing like a lot of stuff manually.
Rob: Yeah, that’s a bummer, man. That’s when your hair is on fire, and you’re not shipping any features because you’re just rushing around from one thing to the next, trying to figure it out.
Mike: What’s worse is that it’s just things sort of worked. That was the worst part. There were fundamental changes I made, and it’s just, I couldn’t figure it out. It’s just forever.
Rob: That’s a bummer. Cool.
What are we talking about this week?
Mike: We’re gonna be talking about billing systems, and mostly why they suck, and how do you make yours suck a little bit less. This question had come to us, I asked on Twitter what people wanted to hear, and Brennan Dunn had asked a question about billing. I pointed them to Derrick’s article, Derrick your co-founder on Drip, where he’d written a blog article about when to build your own billing engine. We’ll link that up in the show notes. This discussion, I think, kind of relates back to episode 375 where we talked about how to evaluate per seat versus tiered pricing models. But this is more about the mechanics of the billing system.
I think the place to start the discussion is really what is it that you’re actually billing people for? Because this is gonna impact your product messaging, your marketing, the positioning in the industry versus competitors, and the pricing itself.
Rob: Yeah. There’s a lot of things to think about with this. Brennan’s particular question was on handling annual billing and kind of talking through do you do credits versus just do an annual bill where you bill someone upfront. We’ll certainly be talking about that as well as a number of other things that you have listed here in the outline.
Mike: As I said with the first question, what is it that you’re actually billing people for. I think you have to narrow it down and talk about it in terms of what is going to be on your pricing page. I actually saw a website earlier today where they had three different pricing tiers, and then they had the enterprise plan which you would kind of expect.
But then when you start looking through at the different limits on the different plans, it was all over the map. It was actually very difficult to figure out where you would fit into each of these. They build on the number of users, and then there were two other metrics that they build on, but both of them were variable.
Some customers may have a lot of one metric versus the second metric. Some of them may have a lot of both, and then there’s obviously room for somebody to say, “Well, I don’t need that at all, that doesn’t matter to me.” Like, “Why am I actually being billed for this?” I just think that it’s interesting to note that. You have to make sure that what you’re billing people for is what they care about.
Rob: Yeah, exactly. We talked about this a few weeks ago with per seat versus kind of a metered billing based on subscribers, or disc space, or whatever. As soon as you go to multiple of those, you’re gonna make some people mad. That’s not to say you shouldn’t do it. But like we talked about, in the early days, you don’t have a lot of data, just pick one. Pick one thing to kind of meter on and make some tiers, and go with it. Then, as you get more data, you can later add them. But the more complicated your billing, the more complicated your billing engine. That is not something that you wanna be dealing with when you’re trying to find product market fit.
Mike: Some of the things you might want to bill people on, obviously, like there’s the pricing tiers themselves and the different metrics within it, but Drip for example uses a metered billing system. You bill based on the number of subscribers that are in your account. Why don’t you talk a little bit about metered billing because that applies a lot to web hosts, for example, where you’re paying for storage, or bandwidth, or processing usage, and things like that. But talk a little bit about what was it that made you decide to choose that specifically for Drip?
Rob: Yeah. Metered billing is a bit of a misnomer for Drip. When I think of metered billing, I think of Amazon, AWS, where it’s truly like per minute billing, or per gigabyte used, whereas Drip is metered with tiers, and it’s based on subscriber count.
In the early days of Drip, it was a different metric. It was the number of new subscribers you got into your account each month because Drip was more focused around just having an email mini course. It was not a full-blown ESP. Once we became an email service provider, it just made more sense to kind of fit into the mental model that other competitors were doing. That’s how we started.
It probably won’t be that way forever. We’ve got to the point where we’re a marketing automation platform now, and there are some people with 20,000 subscribers who send 4 million webhooks a month. It really hammers our servers, and you think about it, and you’re like, “Huh. That person’s actually getting quite a bit of value out of Drip. More value than someone with 20,000 subscribers, and sending 0 webhooks, and it costs us more because we need to add more servers and such.”
There’s something to think about. Again we started fairly simple, we adjusted, we’ve had multiple versions of our billing. At this point, for the most part, how many subscribers you have should be how much value you get out of the app. That’s the key thing to think about. What is the thing in your app that someone gets a lot of value by having more of it?
With Amazon EC2, which is Elastic Computing, it’s how many minutes you have a server running. With Dropbox, it’s how much storage space you need. With something like Drip, it’s how many subscribers you have or email sends. You could argue that way, but the standard way to do it is subscribers. Or with a tool like a CRM system or a sales management system, it would most likely be seats, because the more people that are using it, the more value you get out of it.
Mike: That’s kind of an overview of the metered side of things, but then there’s also per subscription, and you also mentioned per user, and then you could feature gate based on the features themselves. You could charge more for certain features versus other features. You could have add-ons. But all of these things kind of factor into what it is that you’re actually billing people for, and that’s what you need to pay attention to when you’re looking at your billing system or you’re trying to implement one for your product.
Once you’ve decided on that piece of it, you need to understand whether or not you’re gonna be offering a free trial, or it’s essentially going to be paid upfront. That has implications on the database itself, and whether you can have a user that doesn’t have a credit card. Do they have to give you money first? Do you have the opportunity to put something in there that says, “Okay, somebody can sign up without a credit card.” Do you have to build that side of things?
These are things that I’m kind of looking at now with Bluetick. Initially, it was designed in a very particular way, and then I just kind of ripped out the subscription side of things and then did everything through like a WordPress plugin and had people paying me that way. I’m just kind of like manually doing things back and forth to kind to synchronize between Stripe, and between the application. I’m still doing that today. But it made me think about, “Oh, well, had I gone down the road of trying to design all these things in early on, it would have been a lot more difficult because I was trying to answer questions that I didn’t know the answers to, it just would have been really, really hard.”
That’s something else to think about. Are you going to require that credit card upfront or not? Can you have users without a subscription attached to them? Can users be shared between accounts or between subscriptions, for example, are you gonna have a multi-user system? Those are things to take into account.
Rob: Yeah. I think there are four stages, or four different levels of providing friction upfront. Friction is a negative way to say it, but it’s how a new trial user will think about it. You can ask for a credit card upfront and charge them in advance. Then, refund them on request. That’s the most amount of friction because they literally have to put money out. You can ask for credit card upfront and not bill them upfront, but then bill them after a 14-day trial, or 21, or 30-day trial. That’s a pretty standard way to do it.
You can not ask for a credit card upfront. I guess there’s only three, as I’ve thought through it, you cannot ask for a credit card up front then they basically have a free trial until it expires, and then at that point you ask for a credit card. I guess the fourth would be that it’s a free trial, a freemium model where it’s free perpetually at a small usage number like a Dropbox, or like Drip, Drip has a forever free plan.
Typically, when I default, it depends on the space you’re in. If you’re B2C, you’re probably gonna wanna go more either freemium or no credit card upfront. Your conversion rates to paid are gonna be a lot lower. But you’re gonna get a lot more people in the funnel. If you’re going enterprise, you either want to not have self-service sign up at all or if you’re more mid market which is below enterprise but not quite small to medium, you probably don’t wanna have a credit card because a lot of folks let’s say you’re in a $50 million company, the marketing manager may or may not have access to a credit card to just sign up for free trials. It’s not as common as we think it is when you’re dealing with really small businesses or kind of 10-person startups like we think about.
But for the most part, if you’re going kind of B to small B, B to SMB, might think of an app like HitTail, I think of maybe even like a Bluetick. They’re probably gonna have a credit card available, asking for it upfront does not tend to be too much of a blocker and having a free trial where you charge them at the end is what I’ve defaulted to in the past. Probably, if I were to launch a new app, that’s what I would do.
The one kicker there is if you have enough people who can handle the support and/or the sales burden of all the leads that you’re gonna get without asking for credit card, then by all means, do that. But you’re gonna have more pre-qualified leads, or I should say, the leads you get, you’ll have fewer of them but they’re going to be more qualified if you do ask for that credit card. It is a way to limit the number of people that are signing up for your app if you are bootstrapped. If you’re underfunded, and understaffed, asking for a credit card upfront is a good way to do that.
But there are pros and cons to each of these. It’s probably an entire episode on its own. I think we may even have one or two episodes where we just discussed that. But those are the kind of levels to think about. All of those impact your billing system, because it’s gonna impact how your billing systems works, when emails are sent out, if you have a trial versus credit card. You have an entirely different sequence of emails that need to be triggered to notify people.
My advice is if you’re gonna build a billing system that’s gonna handle this, then, you keep in mind that you very well may want to switch this. You don’t hard code a bunch of stuff. You make it extremely flexible, such that you could later go in and just change the length of your trial without modifying a bunch of code and having to retroactively update the database, or that you can switch from credit card upfront to credit card after without catastrophic consequences.
Mike: That’s all the hard part really is trying to figure out all that stuff out in advance, and knowing that if you go down a particular path with the marketing side of things, if you want to experiment or change things, or run into and educate a certain situation that you didn’t expect for example, the person signing up does not have a credit card available for them typically that they can use for this.
Or if they want to be able to sign up for it, and then use the value that they received out of it to go back to their manager and say, “Hey, can I get the corporate credit card now?” Versus asking for it upfront, kind of putting their own reputation on the line. If things don’t work out, then they look bad to their manager. Those are things that you probably don’t know upfront until you get far enough down the path of validating the product for your customers and getting them on boarded. You have to be able to reverse course on some of those things, and that’s what makes this stuff challenging.
I guess the next question is where do you store this data? Where do you store this information? I referred to this kind of thing or this question as what’s your source of authority? A lot of people just use Stripe or whatever the payment gateway is that they use for it. A lot of different payment vendors will have this data available for you, but it’s not always easy to get at and there may not always be an API for it.
I think most listeners are probably developers and they’re going to want to store this information in their own database, but you can only store so much of it. You can’t store every credit card number for example because it’s a PCI compliance violation. There’s a lot of stuff that you can’t store in your own database. There’s gonna be a need to synchronize, in some way, shape, or form between your own database and the other systems. Is that gonna be webhooks? Is that going to be a data dump that you just bring down from them, and upload into your own database? Do you need to synchronize with an accounting system? Those are all the things you need to at least think about.
But really, the fundamental question you’re trying to answer here is what is going to be your source of authority for this data, because you have to keep in mind not only all of those things, but all of the different situations that we’ve talked about previously. Where are you getting credit card upfront, or afterwards, and then other stuff that we’re gonna be talking about which is things like chargebacks and credits, and upgrades, and downgrades, and proration, and things like that.
Rob: Yeah. In the past, I think HitTail was already built, it was actually built using PayPal subscriptions. I acquired it, I turned it to Stripe, and I kept some of the info in the database but I also had to login to Stripe to do certain things, and that was a pain in the butt and I regretted it.
When we did Drip, we agreed that the Drip database itself would be the source of truth, and it was made super easy to report so that you could just do a select in the database. Didn’t need to go out and hit other APIs. That meant that every monetary transaction has to come from within the Drip app. We have a web admin where you don’t go into Stripe to refund people. You literally hit a refund button in the Drip admin, it goes out and hits Stripe and refunds it.
In very early days, it was kind of a pain in the butt because let’s say we had a refund the second month we were live and we had 20 people, 20 customers, I remember saying, “Derrick, I’m just gonna go onto Stripe really quick and do it.” He said, “No, no, no. Don’t. We want everything in the database, and I don’t wanna have to go back.” He spent an hour wiring up a little refund button, just hacking it in. It was kind of a pain in the early days because I didn’t wanna spend that time working on that. But now, once we kind of hit escape velocity, I was very, very thankful that we did take the time to do it.
Moving forward, if I were to build another app like this with recurring billing, I would want all the data. I would lean towards having all of the data in my database. But there obviously are tradeoffs with that, because it’s gonna require a little more time upfront.
Mike: Yeah. I was gonna mention that. The requirement for you to essentially do development every single time you need to make an update in one of those systems, it just adds to the number of things that you need to implement. Sometimes, they’re not always straight forward, not every vendor has an API that’s as easy to navigate and use as Stripe does. A lot of them are just terrible, some of them just don’t have something you can use.
There’s other sides of storing all of that data in your own app which is, for example, reporting or using other third party services like dunning services, or something like Baremetrics where you’re trying to figure out what does my revenue look like over time. You may be able to hook it in, and just say, “Okay, use Stripe and pull that information out.” But if you’re doing your own billing system with your own subscriptions versus Stripe subscriptions, it can be a lot more difficult to pull those reports.
Rob: That’s exactly correct, yup. It’s a bummer there. A bunch of services that you’ve named, Churn Buster, and I think Stunning, and certainly Baremetrics, and there’s a bunch that tie into Stripe subscriptions. If you don’t use that and you build your own, you miss out on that.
That is something that we did. We had to build some additional reporting that we know we’re not gonna be able to get from those apps, and that’s the tradeoff we had. The Drip billing is complicated enough that Stripe subscriptions were not a fit for us. It would have been catastrophic. We would have been very, very limited if we had used them. But there are cases where people are not bouncing up and down tiers as frequently, and you don’t want to take control of let’s say the trial and how prorating and all that’s done where Stripe subscriptions, I think, are a fit.
Mike: You mentioned upgrading and downgrading, that’s something else we should probably dive right into. I think this goes partially towards monthly subscriptions. I think you can get away with, let’s say for example, somebody decides to upgrade their account or downgrade their account, I think a lot of times you’d get away with it if they’re in a monthly subscription to not bother prorating it.
Either you just bite the bullet and take the loss on it or you kind of eyeball it, and say, “Okay, we’ll charge you this much to kind of get it in there.” Stripe does have a proration option that you can use. But if they’re on an annual plan and they decide that they wanna upgrade three months into it, what do you do? Clearly, you’re probably gonna wanna upgrade them at that point, but if they’ve already paid for a year in advance, you can’t just charge them for another year and extend the contract by another year on top of that. That’s something your billing system is going to need to take care of and handle.
In addition to that, there’s downgrades, but what happens if somebody accidentally upgrades, or they upgrade, and then the next day they upgrade again, or they upgrade an hour later, for example, maybe they chose the wrong one, how do you handle that?
Rob: Yeah. There’s a bunch of different ways to handle it, and all of them has some type of negative outcome, including just being confusing if it’s hard to explain to people, they might get confused. There are ways to do it. If you’re gonna do it annually, you can do it with credits where someone just buys a certain amount of credits upfront and then you consume them overtime. They could pay $500, get $600 in credit. Then, as they go up and down each month, you’re just drawing from their credits. That’s the way we chose to do with Drip.
Derrick and I had a three hour whiteboarding session trying to figure this out. I remember, trying to decide which approach to go. If you look at WP Engine, if you sign up for an annual account, you pay in advance, then you have overages like, I think, too many people hit your site or whatever, I think they just bill you that month. They’ll say you went over by $10, and here’s a $10 charge to your card. They trust that the card is gonna be good on file for the duration of that year. That’s certainly another way to approach it.
This is not an annual thing, but if someone’s mid-month–we have Drip customers who will literally get upgraded three times in a month, or four times in a month because their list is growing so fast. Each of those times, you can either bill them right on the spot as it goes up, which gets a little irritating for people, they don’t like seeing a bunch of charges, or you can bill them, you’re essentially billing them at the end of the month for the prior month’s usage. That’s how MailChimp does it. That’s how a lot of ESPs do it actually. When your first month billing is the plan, it bills you for the next 30 days for the plan that you’re currently on, and then, at the end of that month, it looks backwards, and it bills you for the next month, but it bills you the amount of the prior month. Again, it’s a little confusing, but it’s kind of technically the right way to do it, or certainly an accurate way to do it.
Mike: Yeah. That’s the problem with that type of metered billing, or a situation where they could go over some particular limit and you have to charge them more is that you don’t know that until afterwards. Clearly, if somebody goes over by one unit of whatever it is on a given day, you don’t wanna charge them for just that one, you wanna wait until the end of the month. It really depends on what the thing is that you’re actually billing people for. All the different other situations that could potentially come up, and anticipating those, and gearing your billing system to account for those, not just from a technical standpoint and a monetary standpoint, but how is it going to make the customer feel?
You mentioned the idea that somebody doesn’t wanna see a bunch of charges on their card, especially in a short period of time. If you’re charging them at the point where they upgrade or downgrade, that could be an issue because then they’re seeing all these things that are all on a short period of time. I use an American Express for a lot of things. I have it hooked to my phone. I will get like a little notification every time something gets charged on it. If other people have that hooked up, they’ll see it every single time you do it. You have to be sensitive to that kind of thing.
Rob: Another thing to think about is versioning your pricing and/or grandfathering. These things are related. Typically, if you’re gonna build your own system, you may change pricing overtime. You may even change what you bill on. Like I had said in the early days of Drip, we billed on the number of new subscribers, and now we bill on the number of subscribers that you have in your account at any given time.
During those changes, you don’t just want to rewrite your billing engine, you don’t just wanna rewrite that code. You wanna have a version of it that can still run at least in the short term, or if you decide to grandfather people, existing customers, which is what I’d recommend. It isn’t always the thing to do but it’s what I’ve always done. Eventually, at some point, you run an app for 10, 20 years, you probably don’t wanna have all these people still grandfathered in at your prices from 20 years ago. But grandfathering in in general, especially for long term customers, it makes them feel good, and let them know that you’ve done that. You can send out the email and say, “Hey, pricing is going up, but we’re gonna grandfather you in for now.” It’s also cool, you can use this as a way to get a bump in trials, or bump in new customers, is to be public that prices are going up in two or three weeks. If anyone’s on the fence thinking about signing up, they’ll sign up if you are gonna indeed grandfather people.
Mike: Something that’s probably not talked a lot about when you’re dealing with the billing system is things like chargebacks or credits. Let’s say that you have a customer where something goes wrong, or maybe you lost data of theirs, or something went wrong with their account, or you’ve made a promise that such and such feature will be delivered, and you had to roll it back, and it’s just not there or you wronged them in some way, or even if you just wanna give somebody a warm fuzzy feeling because you think that they deserve it or just wanna promote some good will, you may give them a credit.
If somebody’s really pissed off at you, they could do a chargeback and then those things need to somehow be reflected in whatever your source of authority is. If you’re doing that in your own database, you have to have the mechanisms in place to be able to surface those things, and then also be able to account for them in your reporting plus the customer’s reporting. If they have a page where they can go and see what they’ve been billed, they need to be able to see that stuff.
Rob: Another thing to think about is whether your free plan, if you have a free plan, if that is a billing plan. In general, I would recommend, that yes, it be a billing plan. It just helps with reporting and it helps if someone’s on a free plan that they get an email receipt at the end of every month saying, “Hey, you were billed $0 for this account.” Reminds people that the account is there. Obviously, people can cancel the account if they don’t wanna get the email anymore, but in our early days, we have compt accounts for developers who are working on integrations, and of course, we have a free plan now, and everyone gets essentially an invoice email that says, “You’ve been charged $0.” We really haven’t had issues with that. I think that’s the way to go.
Mike: Yeah. But I think that’s easy to overlook as well, because if you’re thinking about writing a billing engine, you’re not thinking about how do I send an invoice to somebody for $0 because they’re not being charged. Why would you even do that? But the points that you bring up are valid. I think the one that’s the most benefit you is that it gets you another excuse to get in their mailbox every month. Even if it’s for a free offering or you gave somebody a free plan.
I guess you probably wouldn’t do this for an annual plan, because you’re only sending them the billing emails at the billing cycle itself. You’re not gonna email them every month, but for all the other ones, you’re gonna wanna send that email regardless whether or not they got charged so that, if they’re not using that product, and you don’t have other automations in place to help bring them back, then it does remind them that the account exists, and they could use it.
I think the one other thing to think about that is probably not really commonly thought about for annual plans is that there’s an implication and an impact that an annual plan can have on an acquisition offer. If you are selling a business, or buying one, if there are people who have paid for annual plans, and let’s say that somebody gave you $1000 for an annual plan, if you’re six months into it and let’s say that you go to sell that business, well, whoever you’re selling it to is on the hook for delivering the other $500 of value that you’ve promised to that customer.
There’s almost a little bit of debt here that you’re accumulating in the product by offering that annual plan if you were to transfer ownership of it to somebody else. The reverse is true as well. If you buy a product from somebody and there’s a bunch of annual plans that have been paid, you still need to deliver on those services for the annual plans because that money is presumably already spent, or is considered inside of the bank account. But that’s something you have to take into account when you’re either acquiring or selling a company. If the company is big enough, that could mean a lot of money in one direction or the other.
Rob: I never sell lifetime plans.
Mike: Yes.
Rob: Throw that in there.
Another thing to think about is dunning. I remember, the first time I heard this phrase, I had no idea what it meant, but it just means how do you let people know that their credit card, or their payment method is failing? If you’ve used Stripe subscriptions, then you could use something like Churn Buster, or Stunning. If not, then you’re probably gonna have to either write your own. I think, with our Drip billing engine, we throw an event into Drip and it triggers a workflow in Drip. We’ve built it out in Drip which is an easy enough way to do it. But you do need to think about this.
Whether you’re gonna have to make phone calls, that’s the other thing. Are you gonna call people or are you just gonna email them, because you’re gonna get a lot more credit card members and accidental churn, in essence, or involuntary churn as it’s called. You’re gonna get a lot less of that if you make the phone calls. But do you have their number? Do you have the time to do that? I would say if you’re at any scale that it is worth your time to collect that phone number and give them a call, even if you’re not and you’re just in their early days, I would definitely use email. You’re gonna have to hit them up multiple times. You’re gonna wanna retry the charges as well, so there’s a lot to think about here.
That’s the cool part, if you do think about using Stunning or Churn Buster. They have figured out the best practices, so you don’t have to do that. I will disclose that I am an angel investor in Churn Buster. I’m not trying to necessarily promote them. But I do know that they get better results than you will probably get early on until you’ve done some testing, and you’ve seen what works, which may or may not be worth the effort.
Mike: That’s kind of the benefit of using those types of services. They’ve already got the process laid out, because they’ve worked on it, and implemented it with multiple people. If you’re doing all of this yourself, then you’re essentially forced to figure out what that process should look like, then evaluate later on whether or not it’s a good process. They’ve done that work for you so that you can just pay them. It kind of gets taken care of versus building it all out yourself and doing all the work and then kind of recovering from the mistakes that you’re gonna make along the way.
I think one of the most painful things that I’ve found is dealing with currency, taxes, and invoices. Depending on what it is that you’re selling, you may or may not have to collect sales tax for it. But currency, being able to accept currency in multiple denominations, and be able to provide invoices to people, it seems like you wouldn’t necessarily need that. But there are people in certain countries where they absolutely have to have an invoice, and there’s really no way around it. You can do them manually but it’s still painful to have to do it.
Early on, you can just do them manually, and you get on with your life but it’s nice if you can batch them up. But having an invoice in the apps so that your customers don’t have to ask you every single time, once you get to a certain scale, it really is not feasible to do them manually anymore. You just can’t do it. Either you have to build something, or you can use off-the-shelf services like Chargify or Chargebee, Biddly I think it is. Spreedly, I think that’s what they’re called. But a lot of them will create these invoices for you so that you don’t have to do it. But again, there’s downsides to that, because you have to do all the integrations with them. They will take care of a lot of these things that we’ve already talked about.
Rob: Invoices are something that will be a pain for you, if you have customers in the European Union. Because in the US, you don’t need to give every customer an invoice and they’re able to write stuff off. But in EU, they need an invoice with a bunch of specific stuff on it in order to be able to write it off.
What we did early on is just made a simple Ruby on Rails template, and it’s an invoice. You just click it right from your billing page in Drip and it spits out all the info that you need. The first few times I was doing it manually in a Word doc, and it gets old really quick, especially if you’re gonna have to do that every month. Something you’d wanna think about once it starts becoming a pain but don’t prematurely optimize that one.
Mike: Then, the last thing to think about when you’re looking at a billing system is whether or not you’re going to have multiple products. Are those products gonna be tied to specific subscription plans? For example, if you have three-tier subscription plan, and you can buy this particular add-on or service, but it’s only available if you buy the third tier. Those things have implications on your backend design, and how you account for it in not just the billing engine, but also in your reporting as well.
These are things that can be difficult. They can be hard to figure out how are you going to put those in but it is something to consider because you may get to a point or a situation where you realize that your product itself is probably something that could stand alone. But it may do better as a productized service offering where you have this add-on service, or there could be other add-on services that you discover later on, and say, “Hey, I could make an extra $500, or $1000 per customer that I sign up,” or maybe you have an onboarding fee, or a consulting fee, or something like that that you add in there.
They could be potential revenue generating opportunities, but it impacts how you implement and design everything. Those are things that are worth considering. But I wouldn’t say, as Rob said earlier, don’t premature optimize for those things. But just be aware that they do exist, and there are other opportunities there.
Rob: Lastly, you’ll wanna think about reporting. How are you going to see which payments are failing? How are you gonna see how many new trials you have, how much money you’ve made each day, how much money you’ve made each month? Are you gonna build out extensive reports, or are you just gonna have a raw sequel query in the early days?
If you’re a developer, that’s what I would do. But you gotta think about that as your team grows. As you start getting other people on board, you will need to build some type of dashboard if you don’t have one from your billing system provider, or something like a Baremetrics that can just link right into your Stripe subscriptions.
There’s pros and cons to both of these. I think if you have the ability to just use a third party, do that because building these things is such a pain. But you do get more control when you build them and overtime you can extend it. You can do exactly what you want with it, again, since we didn’t use Stripe subscriptions, we did build our own dashboards. We have some pretty killer stuff inside Drip that’s abled, that’s predictive, and then there’s also historical.
I can tell this by looking at a few numbers kind of where we are in the month at any given time. You will definitely wanna have some kind of nice reporting with the SaaS app, because your metrics are really the lifeblood of the company.
Mike: There’s advantages to integrating with these third party subscription management software companies, but at the same time, you don’t necessarily wanna go down that road early on if you can’t afford it. That’s just the tradeoff that you need to make. It’s like the classic. Do you build it or do you buy it? We kind of talked a lot about the different things to be careful of if you’re building it. If you don’t wanna go down that road, then, buying something off-the-shelf is also an option.
Rob: Well, Mike, I’m off to go eat a sandwich. If you have a question for us, call our voicemail number at 1-888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Outta Control by MoOt. It’s 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.
Episode 342 | SaaS Development Shortcuts
/
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about SaaS development shortcuts. They discuss the gap between what you think needs to be done versus what really needs to be done and give you tips on how to move faster.
Items mentioned in this episode:
Transcript
Mike: In this episode of Startups For the Rest of Us, Rob and I are going to be talking about SaaS Development Shortcuts. This is Startups For the Rest of Us episode 342.
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 you first product or you’re just thinking about it. I’m Mike.
Rob: And I’m Rob.
Mike: We’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s going on this week, Rob?
Rob: It’s been a good week and it’s memorial day weekend coming up so we are flying to California for a couple of days, just like a three or four day trip to see some folks, just looking forward to it. We haven’t been on a trip for I guess since MicroConf which is maybe six weeks ago, it’s not that long ago but looking forward to getting some sun and it’s also nice and warm up where we’re going. Kind of just easing into it. How about you?
Mike: I have to go see a specialist and have some x-rays taken because I might have a torn rotator cuff.
Rob: That is such a bummer, man.
Mike: I know. It’s not bad. If it’s a tear, it’s really small. I think it’s not bad enough where they look at it and say, “Yes, this is obviously a tear. It might just be inflamed and some other stuff.” They’re going to start with some x-rays and see if there’s any fluid buildup or some bone spurs or something like that. If that comes back kind of inconclusive then they’ll move on and do a whole shoulder MRI and see what comes out of that.
Rob: Yeah, that’s a bummer. If they find it then they have to do surgery and then you’re not able to type with that arm for a while.
Mike: Yeah. They also said that because I still have good range of motion, it just hurts when I move in certain positions that physical therapy might be something that they could work with, anti inflammatories or various other things but I’m hoping that I can dodge that surgery bullet. To be honest, that’s not something I want to go through.
Rob: Yeah, totally. It’s always a bummer to get hurt. Nowadays, when I get injured, it’s not like we’re that old but it’s like I remember getting injured running track when I was 21 and you just heal quick, your body is in really good shape and you’re younger. These types of things now, it’s going to take you awhile to get over that. You’ve also had back issues. You just don’t heal as well as you did 20 years ago or whatever.
Mike: Yeah. That actually came to mind like, “I’m not as young as I used to be. I just don’t heal as quickly.” Back then, in your 20s, you can take the bumps and bruises and shake them off and you’ll be back at it the next day. This is just like that dull ache and I’m like, “Oh, this is just going to go on and on.”
Rob: Yeah, totally. Cool, what else? What are we talking about this week?
Mike: Today we’re going to be talking about SaaS Development Shortcuts. I pulled some of this from my MicroConf talk. The basic idea is that there were some parts of my talk where I highlighted where there are gaps between what we think needs to be done versus what really needs to be done. In these places, there are some shortcuts that you can take to avoid doing work now that you can presumably do later. Some of it, you can just avoid indefinitely but there’s other pieces of it that you can push off to the future because it’s going to either take a lot of work or there’s going to be a long time for you to see any results or benefits from doing that work.
There’s workarounds that you can put in place to avoid doing it now. In some cases, you’ll take on some technical data or some other types of work data that you just have to defer really. But by doing so, it allows you to concentrate on the more important things now versus delaying your launch or delaying getting sales or just delaying moving your product further than it would if you took the month or three months or whatever to implement the things that you were looking at.
Rob: Yeah. There’s a lot of these tradeoffs that go into building any type of software, that go into building any type of business. A lot of things that you have to think about and think to yourself, do we have to do this now? Can we push it off? If we push it off, does it create more of a hassle later on? Does it create more debt later on? Not monetary debt, obviously, but technical or business debt. Or is it the same amount? Is it the same amount in three months if I build the knowledge base today, if I build the knowledge base in six months, is it the same amount of work versus when you’re in code, if you take a shortcut, we all know that technical debt will actually get worse over time. There are some of these that get worse if you don’t do them and some are the same or maybe it’s a linear progression. These are the kinds of things you have to think about as you’re trying to figure out what you can delay.
Mike: What we’re going to do is we’re going to walk around some of the different things that we might think that we need but could be delayed with various workarounds and we’ll talk about what some of those workarounds entail and then we’ll talk about some of the things that are really difficult to find workarounds for. And then we’re going to dive into some general guidelines for deciding how to push things off and whether or not you should do them now or schedule them in the near future, kind of how to prioritize them.
To kick things off with the things that we might think that we need, the first one is a sales website. It’s interesting that I ran into this where my traditional thinking all along has been, “You need a sales website in order to sell your products, to tell people what it is, what it does, how it works, how they would use it, what the value is.” What I realized is that if you’re doing direct sales with people, you don’t have to do any of that. You can get away with a lot less than you need to.
For example, I’ve got Bluetick up over 20 customers, around 20 to 25 right now. I still only have I think 3 pages on my website. One of them is a privacy policy, another one is a terms of service and the third one is just the landing page where basically it gives you an overview of what it does and asks you for an email address either to signup, to get an invitation code or to join the mailing list and go through a five part email course. That’s it. I’ve got to this point really without having a website.
Rob: This is an easy one when you’re doing direct sales. With Drip, I wasn’t even doing direct sales but it was onboarding, it’s really what I think about it as. It’s like people wanted to try, always doing emails back and forth and all we had was still that landing page from months and months of onboarding and we did the same thing, got into the high teens, low 20s in terms of customers that way.
Given that you’re still probably trying to find a product market fit at this point, it almost doesn’t makes sense to build a website because you don’t really know what your positioning is, you don’t know what your feature set is, this is still early customer development. I think there are a lot better places your time can be spent than going and trying to hack together some entire website.
Mike: The interesting part about all the stuff that you just said is that because you don’t know what to put on the website, most of it is probably going to be wrong anyway. Going that direct sales route allows you to have the conversations and get people’s feedback and understand truly what it is that they are trying to solve for and what the terminology is that they use and what resonates with them.
Once you’ve done that enough, you get to a certain point where then it makes more sense to build the sales website because you have enough information from those conversations to be able to build something that is going to be effective and pitching towards people that don’t know who you are and you haven’t had a referral or had no conversations or had nothing explained to them, that’s really the position that it puts you in. That really leads into the second one which is marketing automation.
I think people look at marketing automation as a panacea for all types of sales problems but the reality is that it’s very difficult to automate a sales process when you don’t even know what it is that people think yet or what they’re really looking for and that’s what that direct sales approach is going to solve for you.
Rob: Yeah, I agree there too. As much of a proponent as I am of email marketing and marketing automation in general, which is more advanced form of email marketing, it’s just too early at this point. Until you hit the point where you really do feel like you have a good idea of your positioning, you’re going to start to feel like you know what content people need in order to understand your product. There are questions about how you use the product but there’s also questions about the higher level architecture like, “What are best practices for sales nurturing?” That’s what you’re going to get, Mike.
We kept getting what are best practices for email automation or marketing automation? How do I structure my tags? What should I use custom fields for? How is this different than email marketing? It’s a higher level stuff, that’s the kind of stuff that you’re going to either be sending to people via email or you’re going to start pushing some blog post out at some point. That’s at the point where I think you should tip into now I’m going to actually add lead nurturing stuff and build some workflows and start doing behavior tagging because at that point you just have such a better idea of where your business is.
It’s almost a waste of time if you only have 100 website visitors or you only have 20 customers. You really need to get to the point where you’re getting 500 or 1000 uniques a month to where you’re getting at least a handful of new subscribers to go through that stuff.
Mike: The caveat here is that marketing automation is a very broad term and it doesn’t mean that there aren’t certain tactics that you can pull out of the marketing automation playbook that would be beneficial for you. For example, I just saw that Drip sent out an email with a pointer to a mechanism used by Christoph Englehardt who’s a good friend of the show, comes to MicroConf Europe, has taken notes for MicroConf Europe as well. In that article, he went over the idea of using Drip to send an email to people after you’ve captured their email address to pull them back and help with abandoned shopping cart emails. That’s a tactic that you can use to help pull people back to your website.
I actually use it for Bluetick right now where if somebody goes in, they request an invitation code that pops them over to a survey page. If they don’t fill out the survey page, it sends them an email from Drip about 10 minutes later. My hope and intent is that they will fill out the survey because they’re right there. But if they don’t, then they get a follow up email from Drip a little while later. Interestingly enough, I got an email earlier this week from somebody saying, “Hey, how did you do that? Because I’d love to know a little bit more information about it.” We actually have a demo scheduled here pretty soon. It’s tactics like that that can really help. You don’t have to go out and implement everything that’s marketing automation related but there are certain tactics that you can pull from it.
Rob: Another thing that I tend to push off, because it doesn’t get harder to do this in three or six months, it doesn’t build debt, is documentation. At first, when you’re doing hand onboarding, you’re doing direct sales, really the documentation that I had was the emails back and forth with people. I just started gathering those up. First it was an FAQ doc and then I realized some of them needed to really be flashed out. That was the best way to kick off our knowledge base.
First there was nothing. As soon as we get to the point where I knew we’re going to be emailing several thousand people on our launch list, I knew we needed something. What I did is knowing that writing documentation was going to take forever, I went in and I recorded about maybe somewhere between eight and a dozen Screencasts. Three to five minute Screencast where I walk through. This is what a campaign is. This is just basic stuff. This is what this setting does, there wasn’t a ton in the app.
I just slapped up again, that was 8 to 12KB articles. It was in a WordPress, there’s a WordPress theme, I think, that allows you to make a KB and I just put up there and that’s it. We had 8, 9, 10 KB articles at the start. Screencast or not, the ideal way to consume that, it was very fast for me to make them but within the first few months people are saying, “I really want to be able to read through them. I was at the airport, the WiFi was bad and I couldn’t play them.” Overtime, I actually paid someone to turn those Screencast into documents, like actual KB articles.
That’s the progression. You don’t need to write all the documentation upfront. It would be great if you could but you just don’t have the time. That’s the idea, you start with nothing and it really is just manual and you’re going to have more support upfront because of that but then you move into something lighter, for me that was Screencast, for you it may be something different and then ultimately you build that out over time.
Mike: The next item on the list for something you can push off until later is a billing system. It sounds like a billing system is probably not something you want to push off because you want to be able to start getting revenue as quickly as possible. There are hacks around having a billing system in place. Instead of having an automated billing process in place, you could send people manual invoices. There’s tons of different pieces of software out there that allow you to send somebody an invoice and then have them pay you, you could easily do something like that through PayPal, you could send them a PayPal invoice once a month.
Yes, that doesn’t scale but that’s not the point. The point is to allow you to avoid building out that billing system until you get to a point where it is difficult for you to keep up. Another thing that you could do is you could manually enter people’s credit cards in Stripe using the backend. There’s a WordPress plugin called WP Simple Pay which is from Phil Derksen who’s also a MicroConf attendee and friend of ours. That WordPress plugin can be used to capture those credit cards and help you with that stuff without you being involved directly and taking the credit card and entering it in.
If you want to automate some things a little bit, as Rob said, there’s that natural progression. Over time, you can add more and more things into it until you get to a point where it is fully automated and it helps you move things forward. But until you need it, there’s no point spending a lot of time doing it because a billing system can be very, very complicated. At the start, you don’t need all that complexity.
Rob: With Drip, we didn’t actually use any of those approaches, we just had a little Rail script that Derick cranked up. I think it took him less than a day. We wind up building that five days before the first billing was going to run, we were signing people up and I think we got 30-day trial so we got 25 days into the trial and I’m like, “Alright Derek, we got to get something that’s going to bill people on a couple days.” It was super simple at first, it was literally this is an amount and this is how much you’re getting billed.
Again, over the coming month, you have to upgrade and automatic downgrade and prorating and whatever else goes along with it. We built that into it but we started pretty simple. I agree, you don’t need as much logic as you think you do in the early days in billing.
Mike: One of the more common things that you probably need to implement in a SaaS application is permission system. Depending on whether you’re going to do it like a single tenant or multi tenant model on the backend, you may need to implement permissions inside the system to allow certain people access some resources and then prevent others from accessing those same resources.
This can get very, very complicated, especially if you get into the idea of having group accounts and some people with certain roles or permissions. Again, there are lots of white papers and documentations you can read out there about different ways of implementing the permission systems or claim system and it does get complicated. But in the early days, you really don’t need any of that. All you need is the ability for somebody to login and see their data and not see somebody else’s. You don’t need to create all this additional complexity with groups and roles and permissions and stuff like that, you could really get started with one user.
To Rob’s point earlier, there are certain types of debt that you’re taking on. In this case, it’s a technical debt and that can be difficult to get around. But in the early days, if you need to get around that just to help prove out the idea and make sure that things are working and people are getting value out of the app, this is one of the shortcuts that you can take. You have to be forewarned that it is technical debts you’re taking on when you use this approach but it could be what you need to do.
Rob: Yup. When we first launched Drip, it was just one login and then people wanted to invite whatever teammates and so then we had to add the ability to have additional folks. The only thing we had was owner and I think we called it an admin or something was the other role. 6, 12 months down the line, we kept getting requests for like, “I don’t want some people to mess with our settings.” We added a member, there is three tiers, owner, admin, member.
We have been able to maintain that. We are tens of thousands of users and four years into a pretty substantial SaaS app. We do get periodic requests to add more granular stuff and we started talking about that internally, what that would look like. But the good thing is now, we really understand our customer, we really understand our audience and we have had enough request for it asking in different ways. I want people to be able to come in but not export anybody or not be able to view my subscribers or not be able to send anybody. There’s all these different things.
We’re not making it up in a vacuum, it’s not like we just dream up how we think that they might use it, we have real usage patterns and real feature requests. I’m very much in agreement with you on this one. If you need multiple logins, that’s fine but as soon as you get to anything granular at all, I would pump that so far down the line unless that’s a core, core competency of your app which I’m guessing it’s not going to be.
Mike: One thing that I recently did was I repurposed our impersonation mechanism and applied it to people’s accounts to let them have multiple users inside the same account. It works fine. It’s not great, there’s certainly a lot of work that needs to be done there but for the time being it allows people to use the products and have different logins physically associated with the same account. Like I said, it’s a tradeoff but it does work. Early on, your customers are probably going to be pretty understanding about that stuff.
Rob: Another one is password reset and account management type stuff, it’s a lot of time to implement versus the actual number of minutes anyone is going to use it or the number of times someone is going to use it in the first three months of your app. I know that pretty sure we had a reset password button and I think it may have fired off an email to us or something that’s like, “Reset my password.”
Again, this is very, very early on, you’re at 20, 30, 40 customers, you’re going to get one a week and you can just do it manually and people understand. It’s not until you go a little broader and again you’re going to have to really start to scale up that you need to build this out.
Mike: Funny enough that I had mentioned this is my MicroConf talk as well but the password reset in Bluetick did not work at all for nine months. We implemented it probably six months ago but it did not work for the longest time and we would just go in and manually do if somebody came back and said, “Hey, my password reset didn’t work.” There was literally only three people who would ask in those nine months. It’s one of those really low frequency things that is important and needs to be taken care of but you can manually handle it if need be. I did have a manual backend where I could go in and I could reset somebody’s password, they just couldn’t do it themselves.
The next one is a big thing which is reporting. I think in most cases, the challenge with reporting is that unless your app is specifically designed to provide reporting services for somebody, then you can probably get away with very little reporting in the first version. Most of the reason that you would want to pump this down the road is because you don’t necessarily know what people want to be reporting on. As you have conversations with people, you’re going to learn more about it. When you are initially looking at building reports, you’re guessing what people want and it’s just not going to be helpful to you because you’re going to build a bunch of things, people are going to say, “Hey, could you do this instead?”
Now you’ve built a bunch of things that essentially you have to support longer term because you’ve already built them and put them in the app and people are expecting that those things are probably going to stick around but now you’ve got all this legacy code there and it wasn’t really what people were looking for anyway. I think that in most cases it’s best to just put this down the road and not bother with the initially. [00:19:13] had done a recent episode in the Startup chat where they talked about killing features. You can kill features like this but if you only have two reports, it’s really hard to take away one of them.
Rob: Another thing you can push off to get further down the road is the classic marketing strategies, the ones that require long iteration cycles, higher workloads like SEO and content marketing. These are things that take a long time to ramp up to, it’s not something you should push off so long because it’s not like you’re going to launch a blog and then start getting traction with either content marketing or SEO immediately.
Again, when you are under that 50 person mark, it’s just not something that you want to scale to. If you are not doing these other things of building a password reset and building a billing system, you’re not there yet, you don’t actually want to drive this type of cold traffic to your site and stuff. Everyone talks about it, they talk about this, they talk about split testing, these are things that you need to do later on, you need to wait until you’re starting to scale up marketing and you feel like the app and your team is at a place where it can really onboard people, you have documentation and you’re ready to start dealing with really new users to see how they come in and how they get onboarded and how they convert.
Mike: The next one is new feature development. The rule of thumb that I’ve taken lately is that unless I get a certain number of people asking for something or saying that that’s important, or if they’re not a customer yet and they say that, “I need this in order to be able to sign on.” It’s a deal breaker to them, I generally push that off to the side in favor of other things that more people have asked for or are higher priority because it’s not something that is being asked for a lot, therefore, it’s just less important than those other things. I’m not going to spend my time building something that very few people are going to use or it’s not going to be used very often. Instead, I’ll spend my time working on those things that people are going to use a lot, that are getting asked for a lot because those are clearly most important.
The other ones are stuff that they’re nice to have sometimes, it’s just people are asking a question because they want to know the answer to it, not because they’re actually interested in using it. That’s an interesting side note that I’ve discovered is when somebody asked you something, a great way to deflect the question is to ask him if it’s important to them. Sometimes they’ll just say, “No I was just asking, I was just wondering.” If you have that developer mindset where how do I solve problem X that somebody just presented me? You can very easily find yourself going off into the weeds and trying to do something that’s going to take you a while to do when the person was just asking, they just wanted to know because they were curious, not because they needed it.
The last one is being able to provide real time results for people. This delves partially into reporting but also if you need to do any sort of complex calculations or you’re not sure how you’re going to get the data from one place to another and it needs to be done manually for the time being until you go to a point where you automate it.
This could be any sort of situation like if you have to deal with a government website, for example, and you have to feed data into it, those are notoriously terrible when it comes to APIs and being able to send data into them. A lot of times you have to resort to various hacks like using Selenium to automate a browser, to go plugin all the different fields and stuff. Instead of doing that, hire somebody to go in and type in stuff that customers have entered, you’ve made it easy for them to either import the data or put stuff in in a way that makes sense and then you have somebody that go in and type it all in.
Most people would say, “This is a SaaS application and that should be real time.” But it doesn’t need to be, most of the time when you’re looking at those types of things, there’s customer expectations about how long it should take and then there’s also what they really needed return to them. If the time period is a 24 or 48 hour window, it’s probably not that big of a deal. Unless your whole value proposition is that it is automated and very fast, in those types of cases you probably have to do all the leg work and automation upfront. But a lot of times you can get away with just pushing it down the road. Once it gets to a scale where you can’t handle it or it is causing you far too much to not have it automated, that’s when you go down that path.
Rob: Let’s take a look at three things that are difficult to get around, things that you’re going to have to implement upfront and the things that you should be focusing on. The first one are the core parts of your value proposition. Things like features, reports, if they’re absolutely needed, automation, if that’s really what your app does. Without this, you don’t really have much value. This is probably the core piece of finding product market fit and building something people want, you should be focusing on the features that are driving value for your prospects and customers.
Mike: The next one is probably a judgment call but I find that user impersonation is really difficult to get around. You can use screen sharing, so if somebody runs into a problem, you can get on a call with them using a variety of different tools and share their screen and look at what it is that they’re seeing. That type of thing is impossible to do without the other person being present and allowing you to essentially watch them as they login and go do whatever it is.
It’s a lot easier in many cases to have an impersonation mechanism in place so that you can flip a flag on your account or in the database directly and just say, “Hey, log me in as that person.” Then you will be able to see exactly what they would see. If they come back and they have questions about how do I do this or how do I that or why is this showing up in my account this way, it allows you to go into their account, take screenshots and then send them those screenshots or do a Screencast and explain to them what it is that they’re seeing. If you’re seeing data that shouldn’t be there, then it’s a lot easier to do it without the customer present and having you say why is this there? I don’t understand myself, we wrote it. You’re in a much better position if you have that impersonation ability.
Rob: By impersonation you mean like being able to login as one of your customers, is that right?
Mike: Yes.
Rob: I totally agree, this is a huge one. We call it ghosting, you ghost in as them. But it’s incredible to be able to see the app as your customers see exactly what they need. If you don’t have that ability, it’s like you’re digging through raw data that’ll send you a bug and you can’t reproduce it but as soon as you can login as them, that’s a big deal. This is something I would build very, very early on.
The third one that’s difficult to get around is not having any type of sales channel. You need to be able to get to customers somehow. Referrals can be one, this direct sales model, you could be doing outbound cold outreach, you could just have an email list of 50 people and you email them one at a time and you’re bringing them in. You need some type of sales channel to be bringing people in for this to be worth it. Until you get the feedback, you can get a little bit of revenue and you can start building something that you hope a broader audience wants.
Mike: Actually, emailing them individually, that’s what Bluetick does. It allows you to iterate through those people and email them individually as if it was coming directly from you and you can very quickly go through large numbers of people, personalized automation at scale. But I agree. It’s difficult if you don’t have a sales channel at all, you can’t do that with five people.
Rob: That’s Bluetick.io ladies and gentlemen.
Mike: Now we’re going to move on to general guidelines for deciding what to push off. There are a couple of different criteria you can look at. The first one is is there a manual workaround of some kind? It doesn’t need to be something that is quick and easy or automated. If it takes writing sequel and running against the database manually for an individual customer to do those types of things, then it counts as a manual workaround. It doesn’t mean that it’s easy but if it’s easier to do that than it is to spend a week or two writing code, then chances are good that you can start with that and not have to go through that couple of weeks of writing code that may not be used very often.
That leads directly into the second thing which is it’s not something that you or a customer would do very often. If it’s not used very much, then there’s no real point in automating it and writing the code to do those operations.
Rob: Another guideline for thinking about when to push stuff off is if it’s going to take a long time to automate. There are even things that happen fairly frequently that if it’s like two or three months of dev time to implement, you might still be doing manually or having someone on your team do manually a year, two, three years into your business. It’s always a balance. If you can build two killer features in two months or you can build this one background task that only happens once a week or once a day or five times a day, there really is a balance to human automation versus code automation.
Another guideline that leads right into is you’re not really sure what to automate. If you have some stuff that seems like it takes manual time but maybe you don’t know how to automate it or you’re not sure exactly how that would work, then it’s a good reason to push this off. What I found is things do become clearer over time. The more people you get, the more customers you get and the further along your app gets, things just mature and it becomes easier to tell how to automate things and what you should automate.
Mike: The last situation where you should consider pushing something off is if it’s a feature or a task that different customers are going to want different things or are probably going to want different things. This is where reporting falls square into this bucket but there are certainly other things where if there’s a presentation layer over the top of the data that customers might say, “I want to see these columns versus those columns. I want to be able to filter certain things out of the data right on the screen.”
Those are the situations where you can take the stands, here it is out of the box and we will get to those things down the road when they become more important or when enough people ask for them. But because different customers are going to have those different requirements or different needs around it, you can build a lot of customization around presenting data but people are going to want different things and it can take you a long time to build even just those individual pieces.
Rob: I think that about wraps us up for the day. If you have a question for us, you can call our voicemail number at 888-8019-690 or email us at questions@startupsfortherestofus.com.
Our theme music is an excerpt from We’re Outta Control by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thank you for listening. We will see you next time.
