From Code to Scale: Building SaaS and AI Products That Deliver Value

[MUSIC] >> Hi, and welcome to the Data Science Salon Podcast. If you're returning, welcome back. And thank you for being here again. And if you're listening for the first time, we're glad to have you here. Thank you for choosing the DSS podcast. We know there are many choices out there. Anna, Anna, Senior Host and the founder formulated by Home of Data Science Salon. And joining us today is Swarnandu D, an accomplished entrepreneur, technologist and mentor with 18, over 18 years of experience building scalable software systems, leading engineering teams and shaping SaaS and AI platforms that power real world businesses. Swarnandu runs two companies in a field solutions, a global product engineering firm, and all right apps, a smart mobility SaaS platform trusted across transport, delivery, and logistics ecosystems. And over his career, he has delivered over 600 digital products, helping both startups and global enterprises succeed. Congratulations, that's really awesome. And he's also the creator of SaaS product success strategy framework, and the tech blueprint architecture framework used across 250 successful tech products worldwide. And Swarnandu is deeply involved in mentoring CTOs, product managers and founders, guiding them to align technology with business goals, while staying hands-on, coding, architecture, and an AI integration. And in this episode, we'll explore Swarnandu's journey from curiosity and broken code to leading scale SaaS and AI initiatives, and how he helps organizations turn ideas into high value execution ready software products. It's such a pleasure to have you with us today. Thank you so much, Anna. It is a pleasure of mine to be in the DSS podcast. Thank you so much for having me. Well, let's go ahead and dive right in. Swarnandu, you thank you so much for joining us. And I know that you have such a long journey that's so interesting for the last 18 years from coding late nights and ethical hacking to running two successful companies. How did you get started with all this? Give us a little bit of background about yourself. Sure, thank you so much, Anna. So I started, I initially worked in a couple of companies, two startups, one was an agency. And unfortunately, I got laid off from all three companies. And then it was kind of a sure shot to know that what is going to happen if I joined the fourth one. So I started working as a consultant for one year. And then I opened my company in a fired solution. So it all started with working on a lot of different technologies, creating different type of products, even when I was part of other companies. I started working with different clients. I started working with other people, other developers in the community and learning about ethical hacking, trying out different type of technical, complex technical capabilities. And that somehow got me into probably starting something by my own. So that's where in 2012, we started with fired solutions, where we immediately built, worked in products and enterprises, enterprise-level products for different type of companies and businesses. No, that's an amazing journey. Thank you so much for sharing that. And you've delivered over 600 digital products. That's very impressive. And you've also helped scale enterprise-grade SaaS platforms. And what has really-- what do you see as the key elements that separate successful SaaS products from those that struggle to gain traction? Because there's definitely-- I feel like every day there is a SaaS product, or at least a few SaaS products being released. So how do you really gain traction? OK. In general, when I'm looking into what is the struggle and how people are getting traction, the major challenge that I see from the product development point of view are building a SaaS software point of view. First is the clarity of what people are trying to build and who they are going to be building it for. And the second part, that is discipline. So I have found myself going beyond that, not following discipline. And that hit me hard. Even if when I'm building products for clients, and when I'm building products for myself. So successful SaaS products always have a few things common. The first will be-- and that is going to be the most important, which is like a very clear understanding of the problem. So not what a founder is thinking that it may solve. It is actually what the customers are looking for. What their problem is. And if this particular SaaS software is able to solve it. The second will be a frame-driven execution, an approach which has a process, which has a very clear discipline to follow. Without following that discipline, very rarely, it will become a very big SaaS product. It is fine in the initial stage, but it is not going to be successful. And the last one is going to be continuously learning it, understanding customers, getting their feedback, and employing that in the software so that it can be improved. That is the third important aspect. So if these three things are followed or any of these things are not followed, there is a huge chance that the SaaS is not going to be a successful one. Right, I feel like a lot of the time, a lot of SaaS founders won't that quick growth, like virality. And I think it's a lot harder to get than ever, especially without a framework. And speaking about framework, let's talk a little bit about your SaaS product strategy, success strategy framework, and the tech blueprint architecture framework, which is-- I know that it's used widely across over 250 organizations. Can you walk us through how these frameworks help founders? Maybe you could talk maybe through some of your process with this, because it's very, as I said, it's very important to have a very strong framework for SaaS product. Yes, absolutely. Thank you so much for asking this question. And also, I came up with these frameworks around after five or six years in the journey. And I understood that if I am following a structure, it is important to give it a name. And if I do not give it a name, it is difficult for the bigger customers, or even the different product owners to understand what exactly we are going to be following. So what these two frameworks on one ensures that a SaaS product is following a very clear path from idea to the MVP launch. And then the tech blueprint framework is how the product is supposed to be developed technically. So both the framework is not something absolutely groundbreaking, but it is yet having a very clear structure and very clear discipline that ensures that there are specific steps taken care of, and we are not jumping. That is one of the major challenges we found with the founders who think that, I got the idea, I got some information about it. This is what I'm going to be copying from, and this is what my new unique idea, let's start development. So that is the one of the major concerns in building, even if it is an MVP stage. The reason being, if we do not follow the specific steps of creating the product, understanding, doing proper discovery of the product, understanding what are the challenges they are, what we are trying to solve, what are the features are there. All the steps properly followed, even if it is in a shorter span, will ensure that it goes to the proper product development process. So the developers get something very clear steps given to them that what they are supposed to be building. So that is one step of it. And then once it goes to the development stage, there are certain steps to be followed. Again, it is discipline and because I am a tech guy, I have been following. I have been building so many different type of software. We create very structure, very disciplined, tight strategy so that the developers are not just putting anything that comes in their head. So that's why tech blueprint is a much stricter framework, I must say, that ensures that developers and testers and product managers all are bound by a certain set of rules. And that ensures that the SaaS product becomes successful. It is one of the major things that we see that almost 90% SaaS products fail. After we started implementing this framework, we have seen a lot less video rate in all the SaaS products that we have been building. >> No, that's really impressive. Congratulations for that, that's awesome. And let's talk a little bit about AI integration because that's a big part of your work today. How do you decide where AI adds real value versus where it's more flashy demo tech? Because I feel like there's a lot of flashy demo tech out there, you know. If you're enjoying listening to my conversation with Swarn and Do, you'll have a chance to enjoy more content like this at our upcoming event, DSS SF. It's actually coming up this week on November 6. It's taking place at AWS Builders Loft in the middle of San Francisco. And it's a free community event. Thank you to our wonderful sponsors. And we can't wait to see a lot of you there. Go to Luma.com/DSSF. >> That's absolutely true. Thank you so much. And I'm asking this question, yeah. So AI, everyone wants to put something AI into their product. So all the products we have been developing after AI came, all the founders say, hey, we want to add some AI capabilities. And that is fine. If the people are thinking of adding some AI capabilities, that is absolutely fine. But it is also need to be very clear that whether that application or that product is an AI first product or not. So what do we try to say, or do we try to tell the clients that whatever we be, or even for our own product, is AI the core system? Is it AI something that is, if we remove it today, without that, also the product will work? If it is, then your AI is just an add-on. And it is fine to have some AI capability because everyone wants to see it. But do not try to put a lot of effort, a lot of money and making it a shiny AI product only because it is still looking, it is not something solving the core problem of a client. So that is how we, even for our own product, all right, we have used AI for root optimization and demand prediction. But we have seen that that has a very direct impact. Certain level of automation is always there. There's a huge amount of data are there. And AI is helping streamlining that data into a much better inside. Without that, we are not getting that type of insight. So that is one of the areas we have found that how people are using AI. Without AI, if the product still works, then it is not an AI-first product. It is fine to add some AI part of it. Otherwise, do not put a lot of effort and money into building and AI capability because your customers are not going to be getting benefited out of it. I agree with you 1,000%. And I think, again, with a lot of SaaS products, again, in my experience, it's been really more community, like people actually who use your product that's more important than having any AI or any product. If you don't have any people using it, it doesn't matter. Right? So-- and I know that you're really hands on, still, with coding, which you really need. And you're running discovery workshops, and you're acting as a fractional CTO. How do you balance really strategic leadership with really staying in the technical trenches as well? I'm going to take that, you see, that technology is something. Even if I am putting so much effort into sales and marketing, and that is something, all the companies that demand that I have to be in all these areas. But ultimately, I am from a technology background, and I know that my technical capabilities will ultimately help the product, the companies, and my clients in building something superior. And that is something we have seen. I have seen in a hard way when the first version of my own SaaS product failed. So when we started building it in my co-founder, and I, we both have together more than 40 years of technology experience. So we thought, this will just turn up like the type of SaaS product we are already building with our clients. It is not going to be a lot of issues. So we started focusing more on finance and marketing and sales, and giving the complete product development product creation part to a CTO that we have recently hired. But at a point of time, after almost spending kind of more than a few hundred thousand USD and spending almost one and a half years, we found out that the product is not going anywhere. And that was a hard lesson. And we learned that it is not, as a founder, it is important for me to stay associated there. So my involvement now, even if I do not get a lot of chance to code correctly, even if there are a lot of coding platforms, I get involved in all the other areas where my experience and expertise is going to be required. And that is something all the founders, who are tech founders, they should be doing at least in the stage of product strategy in terms of architecture, in terms of ensuring that a very clear process and discipline follows throughout the technical team. That is something very important. I put myself there ensuring that now I'm all involving all the client projects in all my product development processes at least to a certain extent where my experience will come in and people will have dependency on me. I think that's really smart. And I think, again, failure is what gets us to success. And that's where we learn the most. So thank you so much for sharing that story. And I think you just mentioned, you know, a little bit of your own failure. But what are the biggest mistakes you see kind of early stage teams make when scaling tech? And how do you help them avoid those pitfalls? I mean, I know you've learned from your own mistakes. But how do you get them to listen to you? Because I feel like that's always from the marketing perspective, at least it's always a struggle to get the founders to take the direction, right? That maybe doesn't align 1,000% with their vision, right? Especially, you know, so how do you deal with that? How do you navigate those waters? Right. So this question is very important in this respect that a lot of early stage teams, specifically founders, they get attracted to all the new shiny technologies, right? And that is something we learn in the hardware as well. And that was one of the reasons my own product failed. Because the team thought that, OK, all this new technology we should be using it. No one was there to tell them that, no, let us not do it. One of the major challenges we found that if someone is going for a new technology, the community is very small, OK? And the chances if there are issues, there are challenges, there is very less number of people who will be helping. That is their second, at new technology, it may not be that strong and may have a lot of loops that one team may not be able to understand initially, OK? So it looks good. But as the product goes to the scaling stage, it becomes very difficult to revert back to another technology. So that is the second thing. The third point is a lot of cases, CTOs or if someone, the team understands that technical aspects pretty well, they try to bring in a lot of new capabilities or advanced capabilities to earlier, like bringing in microservices capabilities to a product which is not yet there. And making a much complex architecture which doesn't make sense at that stage. So that type of clear analysis must be done before engaging into something. Because again, everything that we want to revert back, it is going to take a lot of time. It is going to waste our lot of efforts. And scaling is a big deal. It is important that a team, if they do not have clarity, they should go to the advisors or gurus and get some feedback and accordingly make a plan so that the failures do not happen. - Yeah, no, that's amazing advice. And looking forward, what trends in SaaS and AI and product engineering do you see shaping? I mean, obviously AI is the biggest trend. And maybe we could just reframe this question into more AI because I feel like that's really like changing everything. And it's much easier to stand up and SaaS product right now by yourself, right? Without a team than ever because of AI. So where do you see all this going in next three to five years for both startups and larger orgs? - Yes, that's a very trending question, right? So a lot of cases and a lot of people are already asking that maybe it is the end of SaaS and then AI is already there. So I believe it is in terms of the product aspect, whether it is SaaS is dying or not. It can say that it can be said that SaaS as a trend is probably dying and then AI is coming up because AI is a new trend. But in general, SaaS as a concept that is a substitution based ecosystem, that is still there and that is still going to be there. Maybe you know, a lot of things will be changing. So AI is not going to be a separate layer. It is going to be part of the system, right? And then every ultimately what we are buying is a software. So what now we may start seeing is that there are going to be a lot of micro SaaS, a lot of vertical SaaS, which is like very small specific problem solving software, that will be coming up, that is first thing. And the second thing will be that you will see a lot of platforms because AI has made it much easier for all these smaller components based systems to communicate with each other, right? So now all of our, I mean, I'm sure that all of us are using some type of workflows that you know, one system is publishing the data and that is the input of another system and multiple system can be chained together. And if that can be done, we are not dependent on a gigantic SaaS anymore. We are now dependent on very specific problems solving software or systems, which are ultimately connected by AI ecosystem, which is intelligently ultimately giving us the much advanced platform to work on our problems. No, that's a really great answer and I agree. I think it's going to be a lot more niche, too. And it's going to work much better, too, like more useful for the end user, exactly. And for, let's end with the advice that you have for those folks that are aspiring product leaders, TTOs or founders, what advice would you give them about building tech that really drives business value in today's competitive landscape and AI? I mean, are there any like specifics, you know, verticals you think that people should focus on if they're, you know, building products right now? - I think I should say that, you know, everyone should start with a clarity, okay? It is not just building something. It is important that what is the exact problem before we try to automate it, before we try to solve it, okay? And before jumping into building something first, saying that, hey, I have created this product because that brings the failure much faster, right? So after that, it is important to know that what framework or what processes or discipline we are going to be following. I have seen that anything at a stage without discipline will create a lot of chaos, okay? So that will be very, very important. And the third, something that I see a lot, people underestimate marketing and sales, okay? So when they are building a product, they are continuously thinking about that, hey, this is my idea and if I create a great product, okay, I'll figure out marketing and sales later, but it, a lot of case it doesn't work like that, okay? And it is important that people should have planned, should have budget and the work must be started much before it's in the product development has started, okay? So one of the major reasons I have seen so many products, even we build fail only because the founder didn't have any money to do marketing or didn't have clarity on how to do bring customers to their product. - Right, no, and I agree with you again. As I mentioned, you definitely need to have somebody to use your product first, even before you build it, you need to build it for somebody, right? So versus for yourself, 'cause I feel like a lot of the time people build this for their own problem, right? Without actually doing any use cases or R&D with other people. So, and once you put it out there, then nobody really wants your products. And people wonder why it's such a great product, right? From the tech side, but like you didn't do any marketing or research, or so. Yeah, and that's great advice. And so I wanted to thank you for sharing your incredible journey and insights into SAS AI and building products that deliver real value. It's really inspiring to hear how you combine hands-on technical work frameworks and mentorship to help organizations and start-up succeed at scale. And for listeners, stay tuned for more episodes exploring how tech leaders, likes R&D, are turning ideas into high-performance scalable software. And don't forget to share this episode with your network. And until next time, have a great rest of the week. It's taking place at AWS Builders Loft in the Medal of San Francisco. Go to Luma.com/DSSF. [MUSIC PLAYING]