 Alright, so before we get started just to tell you guys that about this tool like you can actually ask questions throughout the session on the Q&A tab on your right and we will answer them at the end of the session, right? Yeah, so this session is going to be about how Purple is using platform engineering to scale, right? And myself is Anshul Sao and I am the CTO and co-founder of assets.cloud, which is a modern DevOps platform which enables platform engineering and our guest here is Suresh who is the co-founder and CTO of Purple, which is like Unicorn D2C brand and I am sure you have played a significant role in this journey. So with that, let me just start with some questions Suresh. So could you just start with your brief introduction about Purple and yourself and a little bit about the journey to becoming a Unicorn? Sure. First of all Anshul, thanks for having me. Super excited to be a part of this initiative. Yeah, I mean about Purple, where do I start? I think it's been about 11 years now that we've been a part of this journey. For people who don't know about Purple, Purple is a beauty tech company. We have two business units. One is a D2C beauty platform, which is purple.com. We see about 12 million monthly active users on app and web there. So pretty scaled up platform for beauty in India. And the second part of the business is about CPG, which is we have our own brands where which we distribute offline to tens of thousands of touchpoints, brands like Faces Canada, Good Wives, Carl Meesey, which are all into the beauty and personal care space. So that is about the business. Well, being the co-founder CTO, of course, a lot of time initially was spent on building the platform itself. And it is truly endearing to see the kind of growth that we've had, especially in the last two, three years. So yeah, that's a bit about the business. Great, great. And I'm sure, although it's so scaled up in a massive system now, but it must have had its own humble beginnings. So if you can just describe about how the technology landscape has changed on Purple over the years, so that our audience can relate to different stages of being in a company. Sure. I think, I would say we were very fortunate to be a part of this evolving tech eco space where the macro trends are also changing, right? So right from the beginning in 2012, where AWS was also in a nascent stage into India and you were kind of seeing players between having dedicated servers and managing everything on their own and we were one of those in the beginning. Now, where infrastructure was available as a service and now platforms are available as a service, that evolution is truly being really remarkable. As for Purple, I think yes, typically when I speak to new joinees in my company, I just draw a square and I say that that was our architecture back in 2012. So we had one machine and that used to do everything, the database was also set there, the couch base servers were inside that and everything was that, right? We were always a very lean team, right? So till about 2019, 2020 when even at that stage we had 3 or 4 million now, we had only 15 to 20 engineers. And hence the evolution for us is one of grit and a scale up in the right manner. The evolution of technology, obviously we took the same route, right? I think we started with a monolith, it was easy to manage, lesser people were collaborating in the code, right? So it was fairly easy to manage from that perspective. We started out by branching out the databases into different servers, started introducing new kinds of databases like Elasticsearch or RIDIS or MongoDB to ensure that the right kind of database is used for the right use case. We started with a logical division first in our application where, you know, while hosted on the same physical server, same repository, but logically it was segregated into APIs and front end code. So we started breaking the monolith in that way. But I think over the last 2-3 years it has really evolved into a truly microservices based architecture to, you know, to stay true to the use case that we have right now because we are operating at tremendous scale. And the evolution specifically in the last 3 to 4 years has been one of breaking the entire back end system into one giant monolith into multiple domain-based services. And that is the journey that we are still on right now. We are about 80-85% there but, you know, that is a journey that we still take. So we have seen like increase in massive complexity over the years. We have witnessed about 7 or 8 different kinds of databases that we use for different use cases and just for everybody's perspective. The kind of applications that we use, that we build for our customers are obviously the storefront applications, but also the martec applications as well as the supply chain applications as well as data driven data applications. So it's a plethora of things that we do to ensure that we are able to serve our customers right. Right. So it's safe to say that it has become a very diverse system and a very contrasting of, you know, how it started. And yeah, so in this journey where you were actually breaking down monolith into microservices and all, were there any specific challenges related to infrastructure per se which you faced? And of course these challenges would have been different at different times but something which comes in top of your head if you can talk about that. Right. I'm sure you remember few instances very distinctly and I think till the time we were a small team and we were on a monolith. Right. We used to feel very powerful, very empowered. You could, you know, you could change, deploy changes very faster. You can actually ensure that you are actually contributing to the value creation side rather than the operations side of things. And that is exactly where everybody, you know, wants to be right. But I think the moment our scale started growing, we realized that this architecture is not going to be our friend for too long. And hence we decided to take off, you know, branching out different domain-based services whether catalog became a different service and something else became a different service and that journey. When we started doing that journey, right, I think the first challenge that we faced was that the dynamics completely changed for us from an infrastructure perspective. Right. So imagine a team, you know, maybe, you know, working out of one auto scaling group and a few database servers now suddenly having to manage Kubernetes clusters, a lot of intra, you know, service conversations at play. So interactions between services. Right. So suddenly that complexity started increasing and just like a frog in a boiling pot, we didn't realize it initially. But when we started with three or four services, that became a very big problem for us. And I think that I still believe that, you know, maybe 2019, 2020 was that time where that problem became too large for us and tried, you know, a bunch of things as recommended by various people. So, you know, we had a dedicated DevOps team because prior to that, it was hardly, you know, it was a very easy thing to manage on our own few servers and, you know, and the observability management and all of these things are managed. But I think post that, you know, we tried out, you know, outsourcing the entire infrastructure management to a company, but that did not work for us because, you know, nobody will be able to understand your content. The way you are engineers are able to understand your context. And I think the sheer lack of, you know, that context avoids people from prioritizing in the right manner. And, you know, there are many cases where people were trying to go buy the book, but probably, you know, there is a combination of a short term plus long term solution we required. So that didn't work for us. We also, you know, tried some bits of automation at our end where, you know, from a stage where we were at where individuals had knowledge on how to do specific things. We graduated to a checklist manifesto where we had checklists of, you know, what things need to be done and I'll give you specific examples, right? What happens if, you know, you add a new server or a new service into the mix, right? There are n number of things that you need to do. You need to provision the right user accesses in your database. You need to ensure the certain observability and the right kind of logging at an infrastructure level is done. You need to ensure that the right scaling of that infrastructure is done and so on and so forth. So a bunch of things that we had in our checklist, but again, and, you know, loosely written automation for some part of it. But what we realized was that again, we landed up on the same problem of, you know, tribal knowledge. There are few people who knew how to operate those and again, at the end of the day, engineers did not feel empowered and they did. They've always felt that there's this separation of responsibilities that, you know, my role is to develop the application and then somebody else will take it to production and run it there. And that sort of really, you know, time and again, stifled that growth or that ambition of transforming the infrastructure at the desired pace. Yeah, yeah. In fact, yeah, that I totally agree and relate to because as engineers, if you don't feel that your time is going into the value creation or you get bogged down by some other, you know, external factors, and it just doesn't work, right? Like you just feel that maybe this is like I'm hampering the growth of the company or something like that, right? And most of the time, these factors are not in your control and we have designed it in such a way that developers feel, OK, this is not my cake. Like if it was a monolith, I could have owned it, but now it has become too many things to, you know, manage it, right? So given that all through your experience and you have tried multiple things, like you said, did you evolve to any, you know, opinion of your own, right? Like how it should be done so that maybe you don't have the solution yet, but maybe the opinion, OK, if we somehow enable this and maybe you can relate it to the monolith days, right? Then maybe it will start working for us. Did you have something like that? No, absolutely. And I think around that time, I also, you know, was reading a lot on how to structure things internally. And I came across this concept from Spotify, which talked about giving developers the autonomy, right? And engineers the autonomy because at the end of the day, engineers are your best problem solvers, right? And you want to give your best problem solvers the entire autonomy of right from development stage to deployment to managing the infrastructure blueprint to performance management, you know, right to iteration of, you know, what should be the sizing of this infrastructure and so on. And that is what you would want to give as, you know, as a leader to your developers and you would want to empower your developers, right? But in such a case, right, what ends up happening is that if it is truly autonomous, then there will be a lot of inefficiencies built into the system. Every team would want to do things in their own way, which might not be aligned to how we want to build an engineering org. You know, in many cases, many teams will repeat the same things. For example, everybody will try to solve for logging is a problem. Everybody will try to solve for configuration management is a problem. And there is a lot of inefficiency built into this, right? And hence the one thought that really stuck into me was the concept of aligned autonomy, right, where there is true sense of autonomy for the engineers. But at the same time, you invest into the platform which ensures that this autonomy is given to them in a very aligned manner, right? Which is aligned to the way you would want to run the organization, the way the garden is that you would want to put on top of this. And that is something that, you know, I thought would be the perfect way that you could solve this problem. But at that point of time, it was still just an abstract thought, right? Yeah, and what you said, it truly applies across the companies also, right? Even like a one company solving certain things is not helping, like there are hundreds of engineers doing the same thing across the companies as well. And it totally would make sense if there is something which can enable this aligned autonomy. In fact, in recent times, like in the last couple of years, this platform engineering term has come up, right? And if you just go into the depth of it, like what exactly it is, I feel that it is totally aligned autonomy, right? That is what they preach. And what they are saying is that, okay, your DevOps should become enablers and, you know, a developer should be able to self serve. If you like build it yourself and deploy yourself and all those philosophies actually come to the same point where you build but build with gardens, right? And I would say then it is pretty much like what you just mentioned, right? All about achieving aligned autonomy through platform engineering, if I may put it that way, right? Absolutely. And I think, you know, if you go into the core tenets of platform engineering and till, you know, very recently, maybe a year or two ago, I didn't know that it was officially called platform engineering. It was just very intuitively you felt that this is the right way to go about things, right? And I think that concept has also now taken a very formative shape in my mind in terms of how it should be. I wouldn't say that we are 100% there, but at the core of it, the basic tenet is that given that you would want to give autonomy to your developers, there are a lot of common problems that they would want to solve for, right? That is point number one. Point number two is that, you know, while they are solving for these common problems, they will also have their own set of individual problems, right? And the role of the platform engineering function in my head is to ensure that they create tools or platforms on top of which developers can feel empowered to solve their problems, right? For example, if I'm building a search application, you know, I might want to spin up an elastic search instance just to try it out on Sandbox. If it did not work, I might try something else. In the historical times, people used to raise a request to DevOps team. It almost became like a government office because the DevOps team is getting requests from all the application teams. And the core job then of the DevOps team was also to manage the operations which is provisioning, optimizing and things like that. Whereas they should be focused on solving the problems. How do I make sure that, you know, I automate the operations? How do I ensure that there is security tenets built into what I'm doing? How do I ensure that observability is built into every application that has been up by default? How do I ensure that I give five options of different kinds of logging to my developers, which is all inbuilt and complete driven, right? If these are the kind of things that either DevOps people or the platform engineers solve, then you truly reach a stage where the developers are truly empowered and they are truly aligned and still have the autonomy. True, true. Now, it's perfectly bang on point. And in fact, even when we were solving our engineering problems in capillary, this was the one observation which was uncanny. In fact, there was a term for it called ticket ops, you know, because if you just go and see the cadence of DevOps team, they just talk about tickets. They just say, OK, 100 open, 30 closed, this I cannot do this. So it becomes too micro, you know, we are losing the macro level things by doing very day to day things. And it's a waste of talent and time both, right? Like, those people are talented engineers. They should not be investing time in doing one of tasks, right? So yeah, totally, totally agree with what you just said. OK, so for my next section, let me take you back some year, like a year or so, where we came and pitched facets to you, right? First of all, I would like to know, were you looking out for something at that point when we came? And what made you choose facets? Because it was a very early experiment for you as well. We were just starting up and, you know, the credibility was actually not there as such. So how did you make that difficult choice that you should try us out? Right. So I think, you know, at that point of time, like I mentioned that, you know, that was becoming a big bottleneck for me to carry on the transformation journey, right? Imagine a company not being able to solve for the problem of scale because you are bottlenecked at the DevOps level, right? So at that point of time, I was actively looking for automation options, right? And automation for both QA as well as for infrastructure automation. And all the things or companies, you know, that I evaluated and there again, a bunch of things I was looking at. So if I was looking at, you know, if there are tools that can automate infrastructure for me. And we also evaluated if there is a company who can come in and try it, you know, the automation scripts for us. And, you know, that we can maybe do an Ansible or Terraform combination. And that is something that we can do. So these are the options that we were evaluating actively when we reached out to Fazit. But, you know, I think there are problems in both, right? While at an abstract level and at a theoretical level, it sounds really, you know, beautiful and really utopic that, you know, there is one platform which will come in and the automation scripts will come in and they will automate your infrastructure. But if you really think about it at a tactical and an operational level, right? You would need a lot of collaboration because unless there is collaboration between teams, unless it is a very declarative kind of a infrastructure management, you would always end up still going to the teams who are managing the scripts. They might have written it for once, but somebody needs to then manage it. Sure, the thing that used to take X amount of time might take X by three, but the problem will still reduce to a ticket ops of that sort, right? So unless it is a declarative format, which is controlled by my developer, that all those solutions were not really solving our problems. But we still wanted to go ahead with something because that could have been still better than what the stage that we were. And it also needed to be collaborative, right? Because, you know, just the versioning control between, you know, what is on Sandbox versus what is on development infrastructures. Plus, the extensibility was just not there that, you know, I can just tweak a few things and spin up another thing. So for achieving all those things, we still needed to go through some hoops. And that is where I think we spoke and that really stuck a chord with me because almost everything that I was looking for was something that was available out of the box. Or at least the platform was extensible to accommodate that, that as well. And sure, you're right that, you know, I wouldn't agree on the credibility part because, you know, managing from the same platform, managing an infrastructure of a company like Capillary, which in itself has a lot of complex clientele and different kinds of deploys in different regions. I'm sure that that definitely lent credibility. But, you know, one thing that really stuck me was how, you know, capable the team was and how open they were to listen to the feedback that we had for them. As well as, you know, there are certain things that we wanted in a certain way, which was not probably available out of the box, but over a period of time were built together. So that was, I think, the rationale on where we were in the journey and how did we pick facets. True. And we were also very fortunate to get purple in that sense because, you know, the kind of requirements which were coming from your side. And we built, co-built many features together, right? Like running your production workloads on spot or whether it be the very pine-grained R-back control to actually put in those guardrails. And it was very aligned, right? What you wanted and what you were building was so aligned that it was a natural partnership. So yeah, I totally agree. And regarding the solution which you said earlier, like getting the Terraform scripts written, it is still, you know, a choice for many people. But I just feel that, you know, building is just the 10% of it, right? The majority part is maintaining it and people generally, like, overlook that part. And so basically, they are generally investing in something which will work for them for six months, right? But what after that? Yeah, because there's always a question of instant gratification, right? And especially now in executive way, you can, you know, can very easily generate scripts that can automate bits and pieces for you. But will it fully work for you when things go 100x or 10x in complexity is the real question. And that is, that is, you know, the kind of long-term thinking that you need to do as leaders. True, true, true. I totally agree. So I just wanted to now see, okay, we were fitting the bill of what you wanted, but now that it has been here and we have been running purple, a part of it in production, right? So how has been your experience and what has changed, you know, before and after FSS? Do you see some positive changes and is it in line with what you wanted? Oh, absolutely. I think so two parts to this answer, right? One is the primary goal with which we entered this partnership, right? And we started using the tool. The primary goal for us was to just add agility into our transformation process into microservices, right? And I think that definitely has happened for us. We, I mean, and you, you were a party to it, you have witnessed it. The pace at which our developers were then able to move services into microservices was just unparalleled or unthinkable, right, for us. From a process where team did something, asked the DevOps to deploy on Sandbox, create an in-front Sandbox, then validate and replicate again on production or pre-prod. All of that is now, you know, completely eliminated the need for that and the developers are empowered. So I think that definitely has added agility into, you know, us moving into microservices. And obviously, we, we started using facets at a place where, you know, we were a monolith going into microservices. So all the problems of people who were already on microservices were not there for us at that point of time. But that brings up to the second point that once we are on the platform and now we have also have an evolved architecture. Now we see that there are a bunch of byproducts, so to say, as benefits that we are getting, right. For example, to bring about a change across the org. For example, recently we upgraded the hardened image, you know, or if you wanted to use a certain kind of infrastructure unit, right. That, that, that was the instance that was, that maybe we have committed now. Whatever these kind of use cases, we, the application of that pan application is like supremely easy, right. So that is obviously one part of it. That enables you to ensure that there are no misses in terms of, you know, missing out on installing the agents of your observability tool or, you know, forgetting to add certain things to Grafana or things like that. So those things have completely been, been eliminated. So that is like, like the byproduct of that, that there are no manual misses now because of course everything is more declarative, more, more guardrail driven and so on and so forth. Apart from that, you know, obviously there are things like we get a bird's eye view of, you know, what is exactly happening in a very structure. There are things that, that are problems for us right now that we can work with, we have actually worked with you guys to solve for it. For example, things like service mesh or circuit breaking and all of these things which become a problem when you actually, you know, go into the microservices architecture. Those are the kind of things that you need to then incorporate into, into your, into your tool so that everybody is able to use it. So there are many byproducts as benefits, right? Obviously usage of spot instances out of the box, which ensures that you are able to control your costs. You know, ensuring that there is extensibility in the use cases that you are building for so that in future if you want to, for example, institutionalize a certain way of doing logging, you are able to do that. Or if you are able to institutionalize the presence of say observability tool, you are able to do that. I think those are just the byproducts of what we have seen. But I think the primary goal with which we entered, I think we have definitely achieved, which is a lot of agility in, in moving into the, moving ahead with the transformation. And now that we are a complicated architecture, so we have never seen a day where we are without this tool. So for us to appreciate how it would have been for us without this is slightly difficult, but I can, I can only imagine. Sure, sure. And there have been times when we also were amazed by the way your team was using it. Like I remember this spot rollout which you just mentioned, your central DevOps team too was able to roll it out without the developers even knowing about it, right? Like at least in the sandbox environment for the developer, the day to day life didn't change, only the garden is changed. So yeah, that was a good testament of, you know, the philosophy itself, not maybe the product needs more work, but then at least the philosophy is in the right direction, right? Absolutely. Yeah. So, so given this, I feel, do you see us fitting in your future as well, right? Like you are, you must be having like long-term roadmaps and, you know, do you see facets fitting well there and or do you see that we need to evolve a little bit more to be part of you when you evolve further big? Like what is the size till which you are comfortable using facets to be blunt, yeah. Sure. So actually like I mentioned earlier, right, I think even while evaluation because of just the fundamental construct of how the tool is made, right? I could see the complexity going 5x, 10x and the tool still working for us. And I stayed true to that evaluation even right now. If I think about, you know, purple in the future, we are obviously in the journey of ensuring that we achieve a properly distributed application architecture where, which is a good balance of, you know, domain-led services plus microservices, you know, don't want to overtly go into only microservices just for the heck of it, which means constant reevaluation of, you know, what should be clubbed as a one-service, one-service and so on and so forth, which obviously adds to that layer of complexity and definitely see the solution facets, the tool still working for us with 10x more complications with 10x more scale. So that is definitely takes the box there in terms of it staying true to the construct with which we started, which is empowering the developers, as well as the tools capability to handle that complexity as well as an orchestrate everything beautifully. The second part of it is obviously when we look at, say, developer experience or, you know, developer productivity or basically from an engineer's perspective, right? We would want to empower them even more. Even now there are certain use cases for which they are, you know, feeling slightly, you know, limited by certain things not being there or so on and so forth. And over a period of time that we have implemented, like, for example, our engineers mentioned that, you know, we need to have role-based access control for us to control every, every finer aspect of, you know, who can release what and, you know, what kind of applications, sub applications can be selectively released by whom and so on and so forth. So that was something which was very important for them to really get on board and that is something that we built together. So anyway, so coming to the second point, which is the first point definitely is that I can see the complexity and scale going up and the solution still working. Point number two, long story short is I definitely see this extensibility in the tool that no matter what our developer problems will be in the future, it can be incorporated. And I see, you know, Facet Steam also playing that role of keeping an open ear to our problems and being very proactively in solving our problems where, and that is extensibility that I see. So definitely I think on these two aspects, you know, that is, that would be my request to you as well that, you know, keep working with us to keep identifying what are the next level of problems that we can solve for the developers. Because at the end of the day, if you truly want to achieve aligned autonomy, they need to be autonomous in truly every sense, which needs a lot of tools and platforms to be institutionalized. True, true. It means a lot coming from you. So yes, and it's a great validation for us. And you rightly said, and our ears are open, we are working with, you know, purple and other partners to, you know, co build, because this is the place where we get the real insights, you know, we can build whatever product we want in our head. But when it actually gets used, it is a different kind of satisfaction and the kind of feedback which we get then is really relevant. So yeah, we're happy to keep collaborating. Thanks a lot for this insightful session, Suryash. Before we take questions, I will just like to walk through our audience through what exactly is changing in platform engineering and what we do. It's just a couple of slides and then we will open it for questions. Okay. Sure. Okay, let me just share my screen. One second. Sorry, it's a wrong presentation, which is okay. Okay, anyway, I will get started while this is opening. So basically, I just wanted to introduce our audience with, you know, what is happening in platform engineering and what exactly is it about. So I won't go into depth of it, but I just wanted to cover that how is ops evolving to platform engineering, you know, like because people are used to going the ops way and they call it DevOps, they call it, you know, system engineering and whatnot. But, but the main shift which is happening between ops and platform engineers, and these are the same guys, you know, who just shift the role which they're playing. In case of ops, they were mostly owner of the infrastructure, especially production. And it was like we talked about right it was about ticket ops. And it was very people oriented and things like tribal tribal knowledge and those things came into the picture because you know we were dependent on few set of people and a process to get through any changes. And, and challenges for their role were mostly like how to keep my, you know, uptime fine. And how do I maintain my infrastructure and and these these challenges were not at all shared with the developers right developers were just, you know, catering to creating business value. And they used to then only selectively support of steam in running of those things. Now as a platform engineer, the major shift happens is you don't be the owner of infrastructure, but you become enabler of these infrastructure. You know, so, like we said about the autonomy, so it will automatically drive developers to do it themselves. So you are saying you are the owner of what you develop, but I will enable you to do it in the best possible way. And I'll give you the right level of extraction so that you don't go and, you know, learn all the skills which I have. So it becomes very process oriented. And the challenges are now more like a product, you know, you are building a product for your team. So and so you are taking a request for them you are taking, you know, things which they want to do it faster and in this process you are also putting in standardizations and guardrails in place so that none of the changes which they do are going away. Right. So this is how ops is evolving going forward. Where do we fit in. So if you see now right now, the developers and platform engineers were stacked together before the infrastructure. Now imagine a self serve layer coming in between, which is owned by this platform engineering group and facets, right. And together they create this thing on this platform, which will enable their developers to directly manage their production infrastructure. So and in this process, we are enabling platform engineering because these people are able to shift, you know, to the role of enabler rather than, you know, being in between and doing all the automations. Right. And how so ever good your DevOps team is they will never invest in building a UI and and you know, make it intuitive for the developers they will always focus on the automation side. Even if you work with facets platform, you'll be able to focus on the right things which will definitely increase your developer productivity. The standardization will come in because the automation you write are centralized and are used by multiple people. So it's a truly collaborative platform and eventually it will lead to a lot of innovation. You know, and I like this quote a lot by charity mayors, who is the city of sunny come that it should be easy to do the right things and hard to do the wrong things. And this is the core philosophy which we follow while we are building facets. Yeah, so that's that's about it. Now, we are open to questions. So feel free to just post them on the Q&A channel. Okay, I have a question by Gaurav. There are organizations like that are quite dependent on people rather than tools. What are the baby steps they can take to move towards more automation. There is a cost to everything. Yeah. So, Suresh, would you like to chime in on that? Sure, sure. You know, so if you think about it, right, you can predominantly map everything out in the maturity curve, right. And if you if you think about, you know, even purple or other in other organizations as well. And if you look at, say, infrastructure management as a fundamental engineering tenant, now that will have a certain maturity curve, right. The maturity curve is everything is ad hoc at the lowest maturity, and everything is data driven and automated in the highest maturity, right. Now, constant strife should be towards moving in the positive direction always, right. So, if something everything is ad hoc and people dependent like you mentioned, right, can you start by creating a catalog of all your infrastructure into a central blueprint can you start by creating checklists of what are the steps to be done so that the things become repeatable, right. The next stage to a completely ad hoc people dependent thing is making it repeatable, right. Once you reach that stage, that is when you realize that, you know, now you're ready to take the next stage, right. Because even if you move to any developer platform, it will also need you to create your infrastructure blueprint which application is using God. You know, how, you know, what are the database connections required between which applications and so on and so forth, right. What are the crest like and so on and so forth, right. So, I think the first thing you should do, if you are in an organization which has a lot of people dependency is to start documenting everything and ensuring that it has a certain format target repeatability and consolidation of information as the first stage. Because even if you are going to the next stage, I think that will be something which will be required. I think today's day and age a lot of these things are available pay as you go. So, you might be surprised with, you know, what you're able to achieve, even if you are at a small scale with a minimal investment, you will be able to, you know, take yourself up the maturity curve by using certain tools, right. I think that is bang on point and, and like you said, I feel that, you know, the first step toward this is making your mind open, right. Sometimes that is the most difficult part, you know, because obviously there will be cost to things like whenever there is a change, whether it is towards the automation or bringing a new person in and training him or if that person leaves or maybe the process breaks or a new technology comes. So the cost is always going to be there. So having that long-term vision and investing towards the right future, which you did like right before even facets came along, right, at least that vision was there, you know, once that starts happening, I think things will fall in place. Yeah. So let's just wait a couple of minutes for any more questions. Just one more thing to add on to this because I feel a lot of these, a lot of people have these kind of questions and in many cases I've also, you know, offline interacted with the people who always, you know, ask me this question that how do I make a business case for this, right. What should be the rationale of, you know, how do I convince, because if you talk about purely the company dynamics, every company is a different dynamics. I was of course in a position where I could take the decision, but in many companies, people might not be in that position to make that decision. So what is that rationale? Because pure finance people or leaders will see it like an additional cost, right. I think the way about it is that slightly look into the future, maybe one year, one and a half year, think about where your infrastructure could be or, you know, what kind of scale you would be operating at and in fact, get your finance team only to give you this information and just tell those people that, you know, if you are targeting this in one year, if we go by the things the way the things currently are, I might meet two more people. So instead of us having those two more people, can we invest the same amount into something right now? Are we willing to make this investment today so that tomorrow we don't need to invest continuously, right. So that is something, you know, which is the right way to look about it that, you know, can I ensure that by doing certain things and by investing that amount right now, I am able to, you know, not have an investment and in fact, get a return on my investment right now because at the end of the day, it's all about the investment and the payback period, right. Any investment is going to be paid back in a certain amount of time depends on your company in terms of how much payback period is okay with them, but that is typically the way to convince people in my opinion. Right and your bang on and we have met many people who are trying to tie this down with the, you know, business ROAs and trying to figure out a case to put in front of business, but, you know, some things are intangible, you know, you can't put numbers to all of the things, for most of them you can, right. But that is really a good input like how to convince your finance team into, you know, and with this tools crawl which is out there like there are so many tools, which people don't even think about before buying because it's just in line with their thinking. Once a tool comes which is more disruptive and will require more investment that is when problem starts happening, yeah. Okay, I'll just wait a couple of more minutes if any questions are coming, otherwise I think we can end this. But it was great, Suyash, like it's always great talking with you, you know, I always get new ideas and this one was specially helpful, which you just said, yeah. Sure. No, no, I think my pleasure to answer. Thanks for having me always invigorates me to have these kind of conversations. I just hope I'm able to influence even one person to take this approach of empowering the developers and, you know, operating in aligned autonomy. I think it would be time worth, you know, worth spending. Sure. Right, then I think people are shy or they're not asking any questions, we were too clear. So I think we can end this and thanks a lot everyone for your time and especially Suyash for your time and see you again. Yeah, we'll do it sometime. Absolutely, thanks for having me. Thank you.