Episode 378 | Billing Systems Suck, Here’s How to Make Yours Suck Less

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.