Episode 342 | SaaS Development Shortcuts

Startups For the Rest of Us

Episode 342 | SaaS Development Shortcuts

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 /

Apple Podcasts Google Podcasts Spotify Stitcher

RSS Feed

Share

Link

Embed

• Facebook
• LinkedIn
• Twitter
• Email

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:

• BlueTick
• Drip
• Stripe
• WP Simple Pay

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.