Carl: Hello and welcome to the SaaS growth podcast. This week, we're here with Rao Cherjala, the founder of Xspeed Software and SaaSLogic. So SaaSLogic is a startup company that's focused on making your SaaS's billing and subscription management easy. So how are you today, Rao?

Rao: I've got it there, Carl. Thank you. Thanks for letting me to be on your show.

Carl: Thanks for being here, man. Let's start how I always start this, run me through SaaSLogic and how it came to be.

Rao: Yeah, so SaaSologic is a subscription management and billing platform. What what we are seeing in the industry is a lot of business models are moving towards subscription from the concept of buying and keeping forever. But so everybody needs to handle subscriptions it's it may sound like a simple on the surface, but as you start peeling the layers, it is, there's quite a bit of complexity because, you need to be able to Subscription is basically, you need to be able to really discover your price point very easily, right?

That means you want to be able to introduce different pricing models. You want to see what sticks and what doesn't stick. So it is almost like an experiment. So if you have a flexible pricing subscription management platform that allows you to really create different pricing models as and when you need, I think you will be able to discover that price part very quickly.

Otherwise, it's going to take forever. So that's what we wanted to solve. We wanted to allow our customers to really experiment with their pricing and then find the Price point very quickly and also subscription management is the complexity comes because every time you allow your customer to really change the pricing subscriptions upgrade, downgrade and all those things.

It'll have a financial downstream impact on your financial systems like, your. If you're using QuickBooks or NetSuite or things like that it will have an impact on what in your accounting systems as well. We provide the whole integration with all these things, and we allow you to really provide a flexible pricing points.

That's how we make it easy to our customers so that they can go to market very quickly without getting bogged down with the complexities of subscription management.

Carl: Yeah, so how do you help people manage that complexity? How does SaaSLogic get into that process? 

Rao: So we have a features like, let's say you, like I said, you have a CRM product. You, it may have 20 features. And you don't want to sell all the 20 features in one bundle, because your customers may not need it, right? Some customers may need 5P features, basic features.

Some customers may need 10 features. The other customer may need all 20 features. So you want to be able to build your pricing models. Based on that. So what we do is we allow you to really define all the 20 features that you have for your product. We let, first you come onto our platform, define the product, define all the 20 features that you have.

And then we also allow you to really create pricing packages. And each package can have these, Features and then and we allow our customers to be subscribed to those when customers allows Subscribed to your product to one of these packages. We basically just hold that information and manage for you, right?

So that's how we provide. Yeah

Carl: pricing from the product, but also

Rao: product.

Carl: individual features to turn off, off and on, like flags. So that sounds really Yeah, I can definitely see how that would be very difficult to do by yourself, especially when you're managing an entire subscription and payment system at the same time.

For sure. 

Rao: And we also provide EPA so that you when the customer logs into your system, you really want to know what kind of features they subscribe to. We have EPA. So you can call with APS. We will be able to tell you in real time. What are the features are

Carl: Oh, okay. So you provide an analytics layer as well on top of that, so you can see how your customers are actually interacting with paid features. So just see what moves the needle. Is that the idea?

Rao: API layer so that you can you can integrate your product with our our system so that you know exactly what customer has subscribed to, what are features they should be accessing on your system. 

Carl: Okay, that makes a lot of sense. Yeah. Obviously, subscriptions is quite a core part of a lot of businesses, and it's very important. What are the benefits of, outsourcing that to someone like you and SaaSLogic versus keeping it in house?

Rao: It's a, see some subscriptions. It's a, it's like you, you want to get to your market faster, right? If you really want to do subscriptions you're, even if you want to build the basic system, you're looking at six months and then on top of that, as you start. Going along the journey of your product, you're going to come across scenarios where you have to accommodate new scenarios.

So you want to constantly spend your development effort, not only on core product, you're also going to spend time on the subscriptions. The subscription management doesn't really add any value to your core product. Your customers don't care about your subscription and things like that. I'm sure you want to provide the best customer experience, but if that is not your focus is really to make your CRM product the best.

Not you're not going to build a lot of features into subscription management. So it's going to be secondary for you. So give it to somebody like us, where subscription is the first feature of our product. We'll try to, we'll be the best. We are going to evolve with the industry. We bring all the features that are required to provide the best customer experience when it comes to subscription management, and you focus on providing the best customer experience for your core features.

That way you, you'll be the best. You don't you're not going to get distracted and you can go to market fast. You can react to your customers for your core features faster.

Carl: You did mention before about experimenting with different price points and different subscriptions and models. So have you what's your experience with actually doing that and doing it in a way that doesn't completely throw off existing customers with constant price changes and all sorts?

Rao: So what we do, the way we do is when you come up with a new pricing, you still have to honor the. Pricing that you provided to your customers, previous customers. So when I say you come up with a new pricing you just have to provide that in such a way that you honor the whole system for the people that already subscribed and from going forward, you just, retiring the existing pricing model and then providing the new one.

So that actually, we try for, we experiment with that in our own product, actually. That is very critical. You don't want to surprise your customers by changing the whole price for, a day saying that, Hey, from today onwards, you have to pay more or whatever, right? You just need to honor the existing pricing. Going forward, you need to be able to introduce the new model, and then you retire the old one. That actually we are doing in our own product, actually.

Carl: Have you got any advice for people who are trying to find that right pricing for their product? And how they might go about working out whether they need to charge more or less or even just change the packages?

Rao: Yeah, you, that's what, right? Yeah, you are, you basically, that's, my suggestion is always start with simple models, right? Don't make it too complex. And then you start trying to add slice and dice your features have the simplest plan first when you are really going into the market and then start Once you get some traction, then start creating a more complex scenarios. One of the differentiation that we bring to the market, product is we handle any complex billing scenario, right? Because we don't come up with come out with, there's some set of parameters. These are the only Parameters that you need to use to model your pricing plan. You can define your own pricing parameters, right?

For example, number of users that might be a parameter that you want to use for your product that may be irrelevant for somebody else, right? And then, maybe amount of storage could be a pricing parameter for some other product. We will be able to define those things. We allow you to define your own parameters, and we allow you to redefine your pricing plan.

And we have some flat models, fixed price models, and adhered models. We allow all these scenarios but you don't, I, my suggestion is don't start with the complex tiered model or whatever, if your product doesn't need it initially. Start with something simple, where people can really adapt. And then once you've got some traction, then experiment with the complex scenarios.

Carl: I suppose it makes sense. If you're using something like SaaSLogic and you, let's say you start with only, even with only one plan you might use that sort of feature specific thing to work out where you might be able to break out another plan and what actually provides value to your users in a way that they're actually willing to pay for it.

I suppose that's quite an important little thing that, a little bit of analytics that can be really helpful in breaking out those payments.

Rao: Yeah for example, SaaS logic, we actually we are trying to provide all the features to everybody at this point, right? We just or if you have different levels of revenue, we just charge different amounts. But otherwise we are not really trying to confuse. I get this, I don't get that.

We don't do that. We just say keeping it simple, just go with all the features that we have.

Carl: We've definitely all seen the models, the subscription models where what they provide in the more expensive plans, you just don't care about. It's Oh, you can have, let you color the header blue. And it's who cares? That's not important to me. And so obviously no one buys those higher plans.

So it's a waste of effort in that respect. So you've also got, again you also founded XSPEED, which is a custom software development company. So you've had years and years of experience working in software, working with SaaS and importantly scaling SaaS. Can you run us through some of the things that you see over and over again in scaling SaaS?

Especially lessons that you're learning right now as you're building SaaS logic.

Rao: Yeah, so that's true. I come from the background of software development for a long time. And then XP has been in business for about 15 years. Part of XP, we build SaaS products for our customers. The genesis for SaaS logic is actually from We have observed this pattern of creating a subscriptions into our customers, SaaS we said, okay, we seem to be doing this again and again, which is not a cool feature of the product.

So that's when we started this SaaS logic. Going back to some of your questions about this scaling SaaS products and things like that. Some of the patterns, you're going to, the subscription management is one of them. You're going to see again and again, which we've abstracted out.

Another thing you're going to see is most of the times when you are building a SaaS product, you start with very small and then you don't really think about the scale. And you just want to put it out as quickly as possible and test it out. So you go with MVP. So for the lucky companies that really graduate from the MVP stage to the next level, your problems are, scaling and you never really saw all these things in the MVP stage and you really have a lot of volume of traffic coming to you you, which you are not prepared for.

Now you have to go back and take a look at your architecture. What is my infrastructure? Can I scale it horizontally? Those things, if you did not address in the initial stages of your product development, you're going to have to really almost redo a lot of things. And some of the enterprise features single sign on across different identities, like most of the customers.

If you are B2B. Your business customers are going to have their own identity provider, right? You don't want them to really create another user ID password in your system. You usually, ideally, you want them to really log into their IDP, and then we should be able to allow them into your product.

Those things usually are not thought through initially, but That becomes a thing when you really start scaling and when you have pre built business customers coming. Things like that. And then also security. I don't think, how you really protect your customers information, right? Sometimes we start putting everything into your database, which is even clearer.

And and then when you really, you have to go for SOP 2 compliance. When you go for SOC 2 compliance, all these things have to be validated and to make sure that you're handling the customer information properly. So most of the times, initially, you don't think through all those things.

Now, you come and say, Oh, I have to encrypt this. I have to protect these things. Those things you have to start bringing the encryption mechanisms and then key vaults and all those things into the picture. So there's some of these enterprise features 

Carl: is a huge one, actually. I've worked in a bunch of SaaSs and it's, the smaller ones is definitely like almost an afterthought and you start doing there's almost no access control on database and any dev can look at production data and it's a whole, it's a whole thing, right?

Yeah.

Rao: Yeah, access controls is one aspect. Another one is data protection how you're storing some of the security information. You probably want to create cryptography and things like that you want to encrypt and then store in some place. We have AWS Secrets Manager and then Azure has KeyVault and things like that.

You probably want to start using them as early as possible in the journey of your product development. And then if you are going to global you also have things like GDPR compliance, right? So data residency people, and if you are, if you have European customers, you want to make sure that you're, you have ability to store their information in European data centers.

And then vice versa in U S probably we want to store here. Those kinds of things are the patterns that you coming, keep coming across again and again, in any. SaaS product development everything, you cannot take care of them in initial days, but anything that you can address, if you start with the right framework you probably can address a lot of those things in the initial days.

When you enter MVP itself?

Carl: So once someone's like they're out of the MVP, they've got a bit of a business running now, what do you think the first thing someone should do to help scaling in the future?

Rao: So the scaling is you today, it's easy to get infrastructure right, because of the public cloud. So you want to make sure that your application is horizontally scalable. That you want to make sure those features are there and once you, those features are there. If there's always a discussion whether it's cost effective to use cloud or, on prem servers. It's a debatable, but in a, in your early days, most of the companies that are coming into scene today, they don't have a lot of infrastructure experience. Most of the modern SaaS companies, they probably have never seen how a server looks like, right?

They're just using public cloud. So public clouds are probably the thing that you want to use. So you want to build solutions in such a way that you can use this public cloud and then scale as quickly as possible. That way you, you have elasticity, you're not over provisioning the infrastructure at the same time, you're not under provisioning when it is required.

In the retail industry as most of us know there's a peak season, like a November and December timeframe. The traffic to your websites, if you have e commerce website or whatever, it basically grows tremendously compared to the regular seasons. But In the earlier days, you, you always prepare, provide, provision infrastructure to cater to those, whatever, 60, 90 days.

And where it is not required, remaining period of the time, year. So you're wasting your infrastructure. If you use something like cloud, you will be able to scale it up when you need and shrink it down when you don't need it. So you want to make sure you will be able to take advantage of cloud infrastructure.

That is the 1st thing and then also if you have a really application that really needs to scale well, extremely well you also want to look at the underlying databases that you're using. If you're using typical something like Postgres, it's pretty scalable. It will just satisfy millions of users.

But if you're just going crazy a number of users, then Postgres can also have issues because Postgres is not really horizontally scalable Database. Most of the relational databases. You want to start looking at either a NoSQL database that could be horizontally scalable, or you even have versions of relational database like CockroachDB and then, you got to buy it and things like that.

They are relational databases, but they can be horizontally scalable. So you want to start looking at those kind of things if you really need super scalable applications.

Carl: Would you say that's a concern for most SaaS companies in their future? Or is there something else you'd recommend that they focus on before they start investing in infrastructure scaling?

Rao: It's it's I wouldn't say it is most of the SaaS companies, I would say these are like for really something like have users around the globe and then you're something like a Twitter or, a notification system that is being used by millions and millions of users.

When you, when user base reaches millions of users. That's when you have to start looking after these databases, horizontally scalable databases. But I think other most of us, I would say it is required for a very SaaS product, right? That's another thing we have to be careful. You don't want to use the products, this kind of products, unless they are really required.

So you need to be very conscious about your Ambitions and then what your target base is, how far you're going to grow. Those things you should be really clear about and then use the right technology. Don't don't use a hammer to, drive the nail down. 

Carl: Yeah, you don't use a hammer or the screw. Yeah.

Rao: Yeah,

Carl: cool. So have you got any We'll go back to SaaSLogic and your subscription management business. So have you, what have you learned moving from this almost software business this client based business into this, to a SaaS yourself? And what lessons do you think you could share with the listeners today?

Rao: yeah. Product sale is, product, first of all, I think when we are in solution, custom solutions business, which is like speed we are most of the times we are project based. We develop a product after that we tend to be there to maintain, but again, we may not be there when our project ends.

In product, when you're developing product, you need to have the mindset of, there is no end date for product, right? It's a constantly evolving. So you need to really you need to really have the mindset of operations, right? When you are in a software development mode, you are, you're project based, you're done, and then you just move on.

But when you are in a product development, product, actually, you need to have the mindset of operations. You need to bring a lot of operations. Complexities, you need to handle those things. That is a new thing. If you're coming from services business operations or the product is entirely different, even if you're using cloud, you need to be reasonably familiar with infrastructure, you need to be able to maintain that on all that's one thing, and then marketing sales and marketing of products is Very different from your custom software develop so I, in the product, actually, we, we need to really have, if it is a SaaS product you want to really have a plan to really sell it in a PLG mode, meaning as much as possible.

Initially, you're not going to have an army of salespeople. If it is a sales led growth, I think it takes a lot of investment. So if possible, you want to really make sure that people can subscribe to your product and start using it without having to go through some training or people having to sell or convince them, right?

I think That's what we are trying to do. See if your product can be can take a PLG approach that way. You'll get the traction faster. And then once you start getting that traction, if you have to add some complex features where you need to have salespeople to convince, then you can add them later.

If you start with complexity first, and then if you need sales people to really sell those things that's, I think, going to be a little difficult. They need a lot more capital. PLG

Carl: Have

Rao: probably the better project possible. 

Carl: This is definitely a message I've heard over and over again, is keep it as simple as possible because it's easier to add complexity than take it away. And and specifically with the subscription one I was, when I was talking to Lucas Furman, he was talking about his woes about adding something like 40 currencies to a subscription and then he added a new tier or changed a tier and suddenly had to go through and update all 40 of these and every single pricing thing and it was just horrific amounts of complexity and a simple change suddenly becomes like

Rao: Oh, yeah. That's what I think yeah. That's some of the complexities, especially when you are talking about changes to financials you need to be extremely careful.

Carl: yeah, that's, yeah, it's just the complexities can compound and multiply and suddenly become a huge headache. So what have you found has worked for the low touch sales model in SaaS logic so far? So what sort of actions have you taken that have helped increase the number of signups you're getting? 

Rao: Yeah, what we have done is, when the initial days, we we learned a lot actually from our initial days we, and during the product development there's always a set of features. There is 80 percent of times people need it. And then there's going to be 20 percent of the features that would be required very rarely.

I think some initially, but when we started developing the product we tried to solve every edge case, right? We came up with features that are actually, available for the 20 percent of the times and things like that, right? So most of our product screens and things like that they are made for solving these edge cases.

In that process, what we figured out is we made. The simple and then basic things very complex, right? So 80 percent of the times people just, they just want to get started and do it. Those are simpler stuff without focusing on that. On those cases, we focused more on the edge cases trying to solve those things.

And when we try to put those in front of the customers. It was difficult for people to really just achieve what they wanted to achieve. We had to really just train them. So then we realized. We went back and then said, Let's make the simple things simple. And provide a way to achieve the complex things.

Right? Provide a, some off path. Approach just have a button or something to bring up those advanced features and they'll be able to really achieve that. They provide a way, we provide a way, but they should not be coming in the way of doing the simple things. That's one of the biggest lessons we learned and then as we are still solving those things.

And with that, we are getting closer to being a PLG motion for SaaS logic. We still say, we're still using salespeople at this point, but I think we are very close to becoming, using a PLG motion. 

Carl: You've definitely hit on because I do a lot of SaaS onboarding optimization and landing page optimizations. So you've definitely hit on a lesson that comes up over and over again about keeping things as simple as possible. And the idea that people just want to get what they want to get done, right?

So this and getting in the way of that in any way, shape and form is really detrimental, especially if you have a, again, a low touch free trial sign up system with someone, they're just trying it out and then they signed up to your app because they want to do something. And if it's, if that's hard, that's really difficult for them to do, then they're just going to bounce.

And it's really, you have a really low conversions off that. So there's definitely a lot of wisdom and just trying to keep things as simple as possible, especially your main flows and your main value offering. So I

Rao: Yeah. User experience design is actually that's something that Pretty complex, so you want to designing systems and complex backends and all that is a lot of engineering effort. It's can be done. Have to design your user experience in a way that your users can really understand. Sometimes that is the most complex part. UX, user experience, design of your product.

Carl: again, it's very difficult, especially with some more complex concepts to add, to create that Simple visualization and simple way of doing it. That's, there's a lot of complexity and simplicity, but yeah. So there's definitely

Rao: challenge.

Carl: a huge challenge and I'll definitely, yeah. Again, I've worked on apps.

We were doing a it was a data extraction for academic papers. And it's, it turns out that's incredibly complex, the sort of requirements set there. And it was a massive challenge just working out exactly how or what all the requirements were and then how to distill that in such a way that it wouldn't be an unwieldy monstrosity to actually use.

Rao: Presenting that information.

Carl: Yeah. And letting and giving them all the options they need. And as you said, you've got all these edge cases that you don't want to put forward, but Are there, and you have to address, otherwise your software doesn't work, or it breaks in 10 percent of cases, and that's too many. So there's definitely some truth in that. Other than that are you, it sounds like you're a bit of a proponent for the software itself being the main sort of salesperson for your own application, and letting the software speak for itself. Do you say you agree with that?

Rao: Yeah, it's I agree.

Carl: So have you found that working with salespeople, has that been valuable for you at this point? Especially earlier on in the journey as you may not know how to make the software resonate with your customers. 

Rao: It is so it's working today actually we depend quite a bit on sales people that's working but I think we are moving raising more and more since we have a concrete set of features and as as we make more and more of these features simpler and simpler presentation wise our goal is to move towards PLG motion. But today. Some of the flows are a little complex. So we, we still depend on salespeople quite a bit. We basically, we get the leads and then somebody will give a demo of the product and things like that. That's what we are doing. We are. Coming to a point where they'll be able to sign up and they get access to our sandbox and they will be able to play on their own.

That's something that we're getting very close to that way your sales becomes a lot more scalable than people, right? 

Carl: Would you say that using salespeople early has been helpful for you guys? Because I know a lot of a lot of the challenge early on with sale, with having a landing page and making a product sell itself, is that you aren't, you don't get the opportunity to actually hear customer objections when they're on the page, and they'll just bounce and you don't know why.

Do you think that having those salespeople and that high touch process has been helpful? And setting up the low touch one,

Rao: Yeah, that's a very good point. So we, very true actually, salespeople actually have been helpful for us in that initial days because we were able to listen to our customers and then understand what is missing and then some of the objections. We actually changed our product features quite a bit based on those feedback in the early days.

So I would agree that salespeople have been very helpful for us initially.

Carl: do you think you'll keep them for more enterprise customers? Because I know that's very common when you get to the three tiers and then the ask us price. Do you think you'll keep

Rao: Yeah, we're going to have both approaches. I think they're going to be some simple options for people to really use it. That would be PIG and then sales people, I think are going to be part of the equation for us because we need to integrate with as much as I say it is simpler to use, but there's always going to be some level of integration required between Our product and then our customers SaaS product.

So that's where I think sales is always going to be involved. But we are also, our product also supports subscriptions for non software businesses as well. For example, if you have a meal plan or, things like that, some kind of goods that people want to receive on a monthly basis. Those kind of things, still there also, there is also going to be some software behind them, but we support those kind of subscriptions also. But in any way you go, there's going to be some sort of integration with us. I think that's fair. I think that since that human touch is required salespeople will be in the loop in our case, I think most of the times.

Carl: a little while back we touched on GDPR and ideas about running a multinational software business, which is a lot easier now with the, like with the internet, with like scalable cloud infrastructure, it's easier to even accidentally. end up with a bunch of global clients. Have you got any, are there any sort of pitfalls to that?

And again especially around compliance and things like GDPR and even like the Americas with Americans with Disabilities Act and all sorts of, data handling requirements. Are there any major pitfalls people should be aware of?

Rao: Yeah, it's it's actually complex actually to achieve when you you're really a global company achieving GDPR is is not an easy task. And most of the companies. I come from a software development background. We develop products for our customers. Initially, like I said, we, people don't care about GDPR and then just start developing to really serve the customers locally, right?

And then they start getting customers from other regions, and then we have to follow the rules and regulations of that European GDPR, to follow the data residency rules of Europe. When you do that, there are two ways. One is you really just make the data reside in Europe or you just have a disclaimer saying, Hey, our data is going to, your data is going to stay in the us but you just consent to your, you give us the consent so that we can host your data here.

I see a lot of companies actually just putting a consent form and then usually we just say, I agree, and then that's how they just. Say they're in compliance with GDPR, but if you really want to make the data stay in Europe and then for European customers, if you want the data for US people to stay in the US, it is actually you have a complexity in your software architecture. So either you need to have some kind of database sharding where, based on the customer's profile, you just go to that database versus this database, or you use something like UGAbyte, which is a distributed relational database. You should be, you'll be able to define some kind of data residency rules.

Based on some, address and things like that, it go to the partition in Europe versus here automatically. 

Carl: But if you don't already have multiple partitions in your software, it's surely it's not worth adding that just to separate the data.

Rao: It's not it's not that easy. So a lot of people just struggle to do that. 

Carl: Consent

Rao: that is one of the things that we provide as a service as part of XPS software development, we bring some of those skills.

Carl: thanks for coming. That's been great chatting, Rao. Again, so you're CEO of SaaSLogic, that's Rao Chijala. Where can people find you?

Rao: I'm on LinkedIn, UMLA. If you search, you'll be able to find me. And then also anybody interested in SA Logic you can go to SaaS logic.io, our website. There is, there's a contact information you can reach us. You can reach me on LinkedIn. So thank you Carl.

Carl: Again, thanks for coming.

Rao: has been a good conversation.

Carl: yeah, it's been great fun. So everyone else, we'll see you next week.