Episode 427 | Scaling a Software Product, Raising Prices, When to Consider CRM, and More Listener Questions

Rob:In this episode of Startups for the Rest of Us, Mike and I talk about scaling a software product, raising prices, when to consider CRM and more listener questions. This is Startups for the Rest of Us Episode 427.

Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome at building, launching, and growing software products. Whether you’ve built your first product, or you’re just thinking about it, I’m Rob. We’re here to share our experiences to help you avoid the same mistakes we made. What’s the word this week, sir?

Mike: I’m going to need some Advil for that one. I’ve got some exciting news to share with the listeners this week. In the past, we’ve talked about having some podcast sponsors on and I wanted to talk about one that I arranged with AppSumo very recently. AppSumo is offering an all-expense paid trip to MicroConf this year, and it’s not just one or the other; it’s to both. We’re in a contest in cooperation with them. It’s going to be starting as the date of this podcast episode comes out.

You can apply to that. We’ll link to it up in the show notes. You go over the webpage, enter in your email address and you’ll be entered into that contest. There’s ways you can get additional entries into the contest by sharing on social media and getting other people to submit their email addresses. For each person who enters based on your promo code that you give them, then you will get an additional entry into the contest. As I said, we’ll link that up in the show notes, but I think it’s a really awesome way for AppSumo to help support the community and the podcast but also to just help bootstrapped entrepreneurs get to MicroConf and network with other entrepreneurs.

Rob:Is it one person that wins tickets to both or is it two separate giveaways?

Mike: It’s one person who’s going to win tickets to both and then they have some money that they’re setting aside to also help cover the travel costs for it.

Rob:They’ll cover airfare and hotel then, for folks, within reason? There’s some cap on it. You can’t fly first-class from Australia or something.

Mike: No, as nice as that might be.

Rob:That’s super cool, man. I’d imagine someone listening might think, “I already bought my ticket to MicroConf,” or, “I might buy my ticket in the next week but I’m going to hold off for this giveaway.” What would you say to those folks?

Mike: That actually is covered, so if you have already purchased your ticket or you purchased one between now and the other contest, the contest is going to until, I think, February 11th. That’s basically four weeks from today’s episode. If you are selected as the winner, then you will be refunded whatever you’ve paid for your ticket so far. If you’ve bought one ticket or you’ve bought a ticket to both of them, then both of them get refunded. I would assume that if you’ve already booked your airfare and stuff, there’d just be a reimbursement that goes along with that.

Rob:Sure. Super cool. This is our first podcast sponsorship.

Mike: Yeah, definitely. I just want to say thanks to the people who are at AppSumo, and we’ll link it up in the show notes. You can go up there and enter into the contest. Hopefully, we’ll see you in Vegas.

Rob:Sounds good. On my end, Tiny Seed Applications open on January 18th. We announced that this week. Tiny Seed is, of course, the first startup accelerator designed for people who would traditionally bootstrap, and it’s my next act after Drip. I’ve already been talking to some founders, either who I know personally or who introduced themselves to me, but we’re definitely going to open the floodgates for about six weeks, starting January 18th. That should be an interesting process. tinyseed.com, if you have questions about that, if you have an idea or an app that’s already launched. We’d love to hear from you.

Mike: That’s cool. You’re going to do applications for six weeks, and then how long do you think it’s going to take to go through those applications? Do you think it’s going to be a week or five weeks?

Rob:We’ll start right away. This is my full-time thing that I’m diving into. The moment we start getting applications, I will start sifting through them. It won’t be a full six weeks of applications that we’ll have to go through at the end because I’m not the sole person making decisions. I don’t know. I think I probably need to think more about an exact timeframe, but it’s not as if we have to announce or we don’t have to offer everyone a spot the same day.

This is not Y Combinator where they have classes of 150 or something. It’ll be a small class of 10 to 15, and I envision it as, “Hey, if you’re fit, we want to invite you to be part of it,” and then people accept or don’t, and then we move onto the next one. I think we’ll be doing onesie-twosies throughout that time, but I’d love to have everybody nailed down certainly before MicroConf, which is ambitious, because that’s only two and a half months away now, but it would just be a nice milestone to hit.

Mike: That’s awesome. Anything else?

Rob:Have you updated your Mac OS to whatever the latest one is called but it has dark mode?

Mike: I have not. I’ve heard of that. Isn’t there something like a Mac app called f.lux or something like that, but it also darkens your screen? Is it similar to that?

Rob:It’s different than that. I just looked and it’s Mojave. It’s 10.14.2. It’s different than f.lux. F.lux would detect your time zone and then, as it got later into the evening, it would remove the blue light from your screen so that it would try not to affect your sleep. That actually sounds–that would be a great name for a great function of dark mode, but dark mode is just a dark theme for the entire OS, like the messages, the iOS messenger thing, the text message app. It’s all dark. It’s all greys and blacks, and the sidebars, and the top and the background are all dark.

It’s interesting. I’m using it, and I think that I like it better. I grew up programming on an Apple IIe, which is black background and green text. When I used to code all the time, I would flip my background of my editor. Sometimes, I’d go white, but, more often than not, probably 70% to 80% of the time, I would just have a black background all the time. That’s like Adam. The default background is black with white text on it because it’s just easier on your eyes.

It’s so far so good. I’m only two days into dark mode, but if you haven’t checked it out, I’d recommend giving it a whirl. I also imagine it would help folks with migraines. I know that some folks, the light from the screen, if you have a lot of white, it can give you migraines. Drip Workflows has night mode, and that was because one of our designers gets migraines, and he just decided to have this. It’s a dark mode for the Workflow Builder.

Mike: Interesting. Yeah, I’ve never really been a fan of those inverted dark modes or inverted theme colors and things like that, but I’ve never really tried it a whole lot either. Maybe if I give it a couple of days to settle in, I could get used to it, but I don’t know.

Rob:That’s the thing, yeah. It definitely takes getting used to because if you’ve used a computer with a white background for 40 to 50 years like you have…

Mike: Hey, you are older than me.

Rob:I know I am.

Mike: I’m just going to point that out.

Rob:Cool. Are you ready to dive into some questions?

Mike: Yeah, absolutely.

Rob:All right. Our first question is a voice mail. Voice mails always rise to the top of the stack. I think, actually, our first two questions are voice mails today, but let’s roll into this one.

Beckham: Hi, Rob and Mike. My name’s Beckham. I’m contacting you from Sligo in the northwest of Ireland. I’m from a company called Campus Connect. We’re avid listeners. We really enjoy the podcast, and you have an uncanny ability to cover stuff that’s happening at the time so keep up the good work. Campus Connect is a mobile app service for universities. What we do is we create an instance of the service for the university recruitment team that pushes it out to their incoming students.

It’s an onboarding service so the students can register. They can connect with their peers and they can connect with somebody on campus. We’re three years trading and we’ve grown to approximately 12,000 MRR, and things have been going reasonably well. A question that we’ve had–I guess an issue that we’ve been having is really around scale although we’ve managed to get at this point to struggle to really build on this.

Creating a new instance feed to university, obviously, is quite resource-intensive, and when we create each instances, often, in customization, they’re looking for different fields, different branding, different upselling and so on, and other few managing services. The universities we work with, they’re also using it for their students that are going out, going abroad, so it’s really for incoming and outgoing students at the moment. We feel there’s an opportunity to develop that into a universal platform and to move all our existing clients onto one central platform where we can connect them up.

At the moment, it’s quite siloed and it’s obviously difficult to scale. We have management. We’ve spoken to our clients about it. They’re interested in the idea but, obviously, the next steps are quite challenging. I’d love to get your guys’ thoughts on this. What do you think, how you would approach it? That’d be great. Keep up the good work. Thanks.

Rob:That’s a tough question, huh, Mike? They’ve made it to 12K MRR, which is nothing to sneeze at, but certainly a big challenge ahead of them. What are your thoughts on this? Do you get what he’s saying, like they do almost on-premise for each instance and then they even do some customizations to some of them, it sounds like, and they want to centralize and basically go with a more true SaaS model or a centralized cloud-based solution, it sounds like.

Mike: Yeah, that was actually a part that I missed. I didn’t realize that they do on-premise for them. I thought that they hosted each individual version of it, and that was mainly because they do customizations to each of them and the platform itself doesn’t really support customizations or a multi-tenant model, so to speak. I wasn’t sure whether that was the direction that they wanted to go or maybe you have a little insight on specifics there. Did I miss something?

Rob:I just listened back to his piece, and all he said is they create new instance for each one. I think you’re right in that it’s not on-premise; it is hosted on Campus Connect’s servers–let’s go with that assumption–but that they copy a new whole instance of it, make some customizations, probably has independent databases, I’d imagine, for each one. There’s the multi-tenancy thing that they’ll have to solve if they haven’t built that in already, which is just the ability to host multiple customers in a single database.

That’s a solved problem. That’s pretty much plug-and-chug. There’s not much risk with that, I’ll say, in terms of implementation, but there obviously are some other things that I think are going to be more difficult than just making multi-tenant.

Mike: Yeah. Taking an application from single-tenant to multi-tenant in and of itself is kind of a pain in the neck. It’s a hard problem, but I would say it’s generally solved, like there’s a lot of guidance out there that you could find fairly easily that would tell you the things to look out for and the things to do in that case. I think that, from a scalability standpoint, I don’t know if you’d want to go towards a model where it is completely multi-tenant with everybody all in one instance.

Part of that is just, one, for scalability because there’s going to be times where certain schools are repping up and directing a lot of people to the site, and then there’s other times where it’s going to be slow and, hopefully, they won’t all overlap. If they did, you wouldn’t want everybody all on one instance of it so that you could slice it across. Let’s say maybe you have 10 instances of it and 10 customers on each, for example. That’s a lot easier to manage than 100 different instances of it, and that’s probably the way that I would go in that particular case just to at least allow you a little bit more flexibility in terms of the redundancy of the whole system.

Rob:I want to break in right there just because I think this is an interesting topic. See, I wouldn’t do that because, to me, that’s pretty mature sharding. Sharding is where you can shard across single tables or database instances. There’s a bunch of different ways to do it, but what you’re talking about is basically putting Customers #1 through #10 on this database and Customers #11 through #20 on this database.

Long, long, long-term if you’re Facebook or if you scale–there was a certain point where we were considering sharding Drip because we hit scale, but that was way, way down the line. I think the added complexity of trying to manage that infrastructure, unless these are really high-intensity, a lot of computing power where you do think you’re going to need to separate them, unless you think that’s going to be that case and that you’re going to need to do that, I would consider that a premature optimization.

Mike: I see what you’re saying in terms of the performance aspect of it. I’m looking at it more from a durability standpoint, like you don’t want having to reboot one server, for example. I don’t know anything about the backend infrastructure and how they do that stuff today, but you don’t want to have to reboot every single customer all at the same time if there’s a problem with one particular customer. That’s more it than anything else. The performance, I think, comes into it to some extent but, from my standpoint, I would be a little concerned about having everything all on one system where if you don’t have an automatic failover or something like that, that would probably be an issue at some point just because of the number of people that could be hitting that site.

Rob:Again, I think that that’s solvable in a different way. You basically have your main database where everyone’s on, you have a hot-swap backup that’s sitting there, constantly replicating, and then you have redundancy in every other server up the chain. If you have a queue server, then you have two of them. If you have Redis, you have two of them. Again, this is just architecture we did at Drip to make it redundant so we could reboot any server.

I don’t even remember how many frontend. By the time I left Drip, we had 20 or 30 frontend web servers and 10-15 API servers just accepting requests and then down, and down, and down. Any of them could be recycled at any time and not affect anyone. The only thing that would actually take the system down, so to speak–and even then, I believe we would still queue up incoming requests–was the database because it’s write and it’s not read. We even had a bunch of reads moved to a separate database that would stay up for that. Anyways, that’s just an architecture thing, and sharding is one way to handle that. I just don’t know how relevant that is here.

Mike: What I was thinking about was how would you migrate people to have them on a multi-tenant server? Essentially, what you’re doing is you’re taking the machines. You’re saying, “Okay, well, let’s take Customer #1 and Customer #2 and put them on the same server.” You’re going to have to do some sort of migration probably for both of them because you’re going to want to spin up a new instance in the database, for example, just so that it’s clean and you don’t have to worry about any additional croft that’s in there.

Again, that could be a mistake based on how complex the database is or how easy it is to move that stuff onto a new server because if you’re just adding tables and stuff to help support multi-tenant, then maybe you just start with one of them and you move the second customer’s data onto the first customer’s database, but it depends on what the hardware there is, too. Maybe you just take the first customer’s database and put it onto a brand-new database server and you start with that.

At some point, you may need to start making decisions about how you’re going to manage that and how you’re going to be adding more customer data onto that database server, and is a migration–are you dumping the data out and then doing a full import? How are you going to manage that replication process to get them started and how far do you go with it? As I said, maybe you do shard the database. Maybe you do have several instances. I don’t know that and I don’t think that they’re going to know that either until they get there.

Rob:When I bought HitTail, it had two shards and it had two separate databases. Yeah, I believe it was two completely separate database instances on the same SQL server. I had to merge them, or I didn’t have to, but I wanted to because it was way complex. It was keeping things in-sync. It sucked. I merged them and I had to do some gymnastics because primary keys–some of them had the same primary keys so I had to update primary keys, which then I have to update them all over the place.

Again, that migration itself is just something you need to think through, be meticulous about and do it. There is risk there, but it’s technical risk. If you get someone smart who knows what they’re doing and you plan it out, that will work. The thing that I’m much more concerned about–let me say off the bat. If Declan can make this happen and turn it into more of a centralized multi-tenant SaaS, I absolutely think that that’s the way to go.

I think that’s how they scale this business long term because having these separate instances for each customer is just going to get hard. It’s going to be a lot to manage. It’s a lot of overhead and server costs. There’s a bunch of labor that’s going to with it. Long term, that’s not how I would prefer to do it. I do think that them trying to centralize is a good move. I think the hardest part of this is going to be talking to all of the universities, getting them all on-board with it, and figuring out which customizations that they allow or disallow. The wildcard, I think, is going to be the customers who have potentially extensive customizations that you may or may not import into the centralized version of the app.

Mike: The other thing that I would think could be a huge thing is data protection and privacy and making sure you’re that separating the data between them because I don’t know for sure how much of the stuff is installed at the customer’s site versus how much they’re hosting in their instances. Are there things that the customer really can customize on the frontend or do they give them virtual machines that they install in their environment and then direct people to there with some of the customizations on?

I don’t know how that is really set up, but I know that they’re probably going to be concerned about, “If we’re migrating the data out of our environment into yours, how do we know it’s secure? How do we know that it’s not going to go back and forth between other customers? How do we know that, if you get hacked, we’re not going to suffer some major loss?” or something like that.

Rob:Yeah, I agree. I think the hard part is doing it retroactively because you could screw things up because, again, that is a solved problem. There are a lot of–how many thousands of SaaS apps have exactly the same issue of keeping data separate? They do it.

Mike: I don’t think that having it separate is the issue; I think that convincing them that they’ve already purchased and bought into one model of having it deployed and then changing how that is done is the issue. For the IT department, they may need to go through some infrastructure review through a risk analysis or something like that, and some of them may say no.

Rob:Right, and that makes sense. That’s, I think, going to be the challenge here more than anything. It’s a big undertaking, but I would encourage them to at least evaluate how many person hours and how difficult it will actually be because I feel like–do you agree that this is probably the right choice for them? I guess the better question is–we don’t have all the details, but if you were in their shoes, based on what we know about their business, would you try to centralize to a multi-tenant scenario?

Mike: Assuming that they are deploying a completely new infrastructure for each customer, I would absolutely centralize it.

Rob:Yeah, just because of the management of all that stuff is so challenging and expensive.

Mike: Right, and just having the different instances themselves. You want to centralize it as much as you can with an obvious eye towards the performance, downtime and stuff like that. Again, it’s also something you’re going to want to take slow. You’re not going to want to dump everybody all under a new set of servers all at once or even three or four. You’ll want to start with two and that’s it, and then slowly consolidate them over time.

Rob:Another thing that occurred to me is I think this will be a cost savings for Campus Connect, and so it would be quite cool if they could keep their prices the same and consolidate because I do think that their cost for providing this service will be less, but they will also have the leeway with some of them to offer discounts if needed because I’d imagine, again, that just their cost to provide this service will be cheaper if they have 10 or 20 of these universities on the same infrastructure. I think that’s another added benefit to this. I’m sure Declan’s thought of all this, but it’s just a fun thought experiment to think through. Our next question is another voicemail and it’s about how to raise your prices when you have a lack of control.

Ben: Hey, guys. I’m Ben, the founder of Code 49 from Germany, selling apps in the Atlassian Marketplace. Thanks for your great episode about Charge More. We also love to charge more–and who wouldn’t–but we are not sure how to proceed. We can only raise prices for everyone at once, and our existing customers only get exposed to the new prices after 30 to 60 days. On top of that, we can only change prices every 30 days and rarely get any feedback when a customer cancels our subscription. The question is how would you raise prices in this scenario? Which metrics would you measure to determine if the raised prices lead to more value? Thanks for your help.

Mike: I feel like this is a really tough spot because if you can only raise prices for everyone all at once and you’re not going to get any sort of results for 30 days, that sucks. If you don’t have direct access to the customers, that makes it harder to do something like this. I wonder if there’s a way to publish it as a new app inside of the Atlassian Marketplace and see if there’s a way that you could test with new customers instead of your existing ones, and then you grandfather the existing customers into your existing pricing.

I don’t know how amenable Atlassian would be to having two apps that are in there that are basically the same kind of thing. The other thing you could do is you can talk to them and say how would they go about this because it would feel to me like you can’t possibly be the only company that has run into this particular program. What does Atlassian have to say about it?

Rob:That’s exactly what I would do, is ask them. This is a crazy limitation. This reminds me of Apple App Store stuff. This is where being in App Store cuts both ways, being in the Envato Marketplace or whatever, the Google Play Store. It gives you distribution. It’s easy distribution. It’s a nice stair step, but I would never build my full-time business on these ecosystems because of these limitations that are just so painful. You can’t split-test. You don’t get your customer’s email addresses. There’s all these limitations.

I don’t know that I have a silver bullet aside from talking to Atlassian. I think his question of, “How would you raise prices in this scenario?” Very, very carefully. I would probably inch them up 10% and just see what happens. The metrics I’d look at is are you getting less new customers in that 7 or 30-day span? Did you churn higher than the previous 7 or 30 days? It’s a very blunt instrument that’s not a true split-test–a poor man’s split-test, I’ve heard this called–but I don’t really see another easy way around it when you just don’t have the control over distribution. Thanks for the question, Ben. I hope our thoughts were helpful.

Our next question is from Rohit Shetty. He asks, “At what stage of a bootstrapped company should one consider using a CRM? I have a desktop app that’s not SaaS. It’s for the data networking industry. It’s cross-platform with binaries for Windows, Mac and various Linux distributions. I use Gumroad for ecommerce, Mailchimp for email, Google Forms for surveys. Email support and follow-up is using Gmail with stars or snoozing to remind to follow up.”

“All this means is that customer data is quite fragmented and spread around. Wondering if having a CRM to bring all of this data together would be useful, or is it the organizational freak in me just wanting to have everything together, and it’s not really going to help me grow my product? If you think CRM is useful in this situation, could you suggest some? My average monthly revenue is around $1200 and has been at that level for more than a year now despite my attempts to grow it. This is a nights-and-weekends project.” Thanks, Rohit. What do you think, Mike? I don’t think CRM is what he needs. Do you?

Mike: No, I don’t think so either. It sounds like if you were having trouble with lots of customers falling through the cracks and support issues because people feel like they’re not being paid attention to, or their needs aren’t met, or you’re losing sales opportunities because you forget to follow up with them or check in with them or send them invoices and stuff like that, then I would say yes, but it doesn’t sound to me like that’s the case. It sounds to me like the data is just in a bunch of different places, and it’s kind of annoying that you don’t have a centralized location for it because it doesn’t seem to me like the MRR really justifies that as the top problem that you have.

Rob:I would agree to that. Also, CRM is really more for moving people through a process. It’s like sales-based. I don’t think of it as a repository for a software company like you. To be honest, we either use our own database. If I was running a SaaS app, it would be the multi-tenant database houses the data that you need. That’s aside from automation and Google Forms and stuff, but it would house all the financial stuff, or I used to do and still do use Drip as a central repository for a lot of data.

I would think about whether or not you want to pipe everything into Mailchimp as custom fields since you use Mailchimp for that purpose or if you want to try to get everything into segment. You could pipe data via Zapier and stuff, but, all that said, I don’t see what having this all in one place is really going to do for you. I just don’t know how that grows your business. I’m with Mike at $1200 monthly revenue, I think you have a lot of bigger fish to fry in terms of either keeping more customers, finding new ones, growing your top-of-the-funnel, whatever. I would the time into that instead of trying to consolidate what data you have.

Every business is like this. I’ll give an example. We used to use Stripe for charging for Drip, and we use Drip for the email automation, and we did use Google Forms or Typeform for some surveys, and we used Help Scout and, later, Zendesk for support. Stuff was fragmented, I’ll say, but it’s just the nature of the beast. Take a deep breath, and just do the best you can, and focus on growing your top one.

Mike: I think that’s about all the time we have for today. If you have a question for us, you can call it into our voicemail number at 1-888-801-9690 or you can email it to us at 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. Visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening. We’ll see you next time.