 Thank you everyone for joining in. So I just want to quickly set a bit of context about what today's talk is about So I'm the VP of products at a startup called Cloud Cherry recently, you know, we accepted Cisco's intent to acquire us and Zainabar actually reached out to me saying hey, why don't you guys come forward and share your journey with us to talk about how Various engineering decisions have had an impact on our growth, right? So Really here today, what I'm hoping to do is take you through the journey From some of the early days of where our product was and how it evolved and talk about key decision points that we went through So here's what you can expect, right? So we will cover off at a high level decisions that we had to make around Component design, right? How do how do teams moving really really fast in a fast-paced environment? Look at component design trade-offs Mistakes that we made things that we improvised on second architecture Things that we did around state management as well as areas where we likely even over engineered a few things Third design systems and I know everyone talks today about a design system and I think in at our end We'd like to believe we did a decent job of going beyond just having a UI toolkit To a set of principles and a framework that we have tried to apply so we'll share a little bit about this Next performance, I think we are still on our journey here There's more that we need to do but we'll share a little bit about things we've done in performance and finally about other things about engineering decisions that have implications on ongoing maintenance and We'll spend a bit of time on hiring and career-parting, right? I think that's a topic I sort of wish there were more discussions about around what are the career paths for front-end engineers? what implications does it have and Lastly soon after the session, we're planning a birds of feather where we'll get together You know, you know sort of a smaller group to deep dive into a couple of these topics because each of them has a lot of Context and we want to make sure we can go a little bit deeper into some of them So here's the broad what to expect in this context, right now I don't spend a whole lot of time showing you sort of then and now But I have a couple of screenshots of what our product used to look like earlier and what it looks like now Right, so this is what you see on the left is what our product used to look like about three odd years back And you could see sort of where it is now It's been through a significant journey, right? And it's been possible by an incredible team of people we've had and you know The reason I wanted to set this context is to give you a sense of challenge as we had now We were a very small team, right? So literally a team of less than 10 in a startup as part of the core engineering team going up against competitors who were 10 to 100 times our size and It is literally a David versus Goliath. It's a type of situation and We were able to go in and win in various opportunities against competition that was one more funded had larger teams ladder brand reach and so on and so this is part of the framing that I wanted to share with you is We've had our tough times getting to this point teams that have been stretched work hard We have made various decisions along the way, but you can see sort of then and now, right? Screenshots don't do entire justice, but you can see how much our product progressed, right? At least a certain extent just looking at the screenshots. So keep this in mind, right? Our journey is not done, but we have come a long way in three years with what we've built out So these are different screenshots of the product then and now with respect to the shift, right? here's You know our sort of journey that we went through right starting from where we initially moved over to angular To where we started and evolve an early design system the little smiley is that indicate our high points and low points Now after putting this together when I looked at it, you know to be perfectly honest as a startup that went through the journey It seems like this is nice, right? But the reality is I can tell you every day every week They were likely very high points and very low points where things would either go wrong and things were going well, right? And it is it was quite an emotional roller coaster So I'll now spend a bit of time diving into each of the stages that you see here in this journey, right? so This is really the first point where the the first version of our product that screenshots that you saw earlier was really build out using angular JS and You know literally we had an internal joke about it We you know and part of a startup's growth is in early stages. You had a lot of technical debt that accrued You're going to market. You're trying to find out where this product market fit and quickly iterating So our front end had a file called app.js back at that point Which had tens of thousands of lines, which could even make certain text editors crash You know, so from there we went through the re-flat forming exercise and moving over to angular now I personally am not I'm quite framework agnostic, right? We had choices at that time. We could have gone down react, right? It's not about which framework it is I'm not a big fan of any of the framework was because ultimately some of these choices are tools that enable you, right? I'm not we're not strongly attached to one versus the other It's a question of choosing the right tool for the job you have at hand But we chose angular, right and it came with various trade-offs, but Netnet if I was to look at it and say I think it worked very well for us Right now I will talk about the hiring implications that it had a little further downstream But at the point that we went with angular here Now in the communities when you went out and looked online There were enough people in the angular community who were actually switching to react Right because the whole migration path is very very painful Also at that point when we picked up the early angular beta and RC it was a ton of work for us It was really a moving target things were just not stable there just weren't enough component libraries in place and it felt like we were Solving very fundamental problems as we went along So a very painful path now a key decision we made here though was to stick with angular And thinking of look if you're trying to build a serious application at scale Right where multiple concurrent developers are looking to work with a somewhat opinionated system Which may have a higher learning curve early on But it really pays off over time because of the opinionated approach that it takes And I would say we made a fair choice here This isn't to say that we've chosen something else that this would not have happened But we were happy with the choice we made right, so here We were also a C sharp shop right we ran on Microsoft Azure So the fact that you could run C sharp in the cloud at the back end Right and also use type script was definitely a strong motivating factor and nothing like going down the strongly typed path Where it builds comes to building a more robust front-end application so with this You know we we had a ton of other issues because as we made the switchover from the older version of angular Right everything from we had One of the developers in the team earlier who was just doing css Now with the ship over shipped over to angular 2 and components this radically changed even how the team worked Right versus one person who would work on css now the whole workflow of how you would look at it With respect to someone building out a component Had to change so certain roles themselves had to evolve and Initially things were not smooth We we still had a lot of accrued debt which it took us some while to sort of work through There were still things that were using bootstrap and it took us a little while to get this off the ground So this was a Pretty painful phase right working through it because there was no visibility to dates Right when would rc stabilize It was hard right and I think there were times where I think I would lose sleep at night thinking did we make the right decision Right, but it it passed right now We were still a tiny team right there were only like two front-end developers at that time two back-end developers We I hired our first head of design who came on board And we started to get into thinking about look. What are the fundamental principles behind putting together a design system? Now we were early in our thinking here of thinking look a design system is not just a ui toolkit And putting together a set of components and saying here's what you use But really thinking a more long-term patterns that would emerge that you could start to use Now this is a journey, right? I don't think we're done there yet But we developed an initial set of guiding principles And we attempted an effort that we called initially lego blocks Right trying to build out very reusable components that would take various inputs Have different outputs and that could be reused in various different ways Right with angular and components at that point Literally the way you would think of cars and how you have brakes that could be used either in an omni or it could be used in a gypsy Now it was ambitious and it didn't work out as well as we had hoped Right, so it led to more complexity than we had hoped And we realized that look while you could look at some of the smaller components and plan for it this way The nature of how components come together get aggregated and composed It's so different that it has hardly established these patterns early on We also had challenges just with repo structures Right and today you have choices of going with a mono repo versus things split out with different repos We went back and forth a little bit here initially all the components were in a separate repo We were trying to pull them in we had our share of Challenges that we had to work through here Now on the design system and the reason I'm just spending a minute on it is I think Versus getting into the UI toolkit. I think we established a set of broader Principles based on which we would make decisions Because the key part here is really front end engineers engaging closely with design with a shared set of principles around What do your users care about? How are they going to use your product? What are the guiding principles that will help you with various decisions you make about how these components come together? And once this shared language is in place, it actually makes a lot of decisions easier So this is very contextual to us, but just as an example so that you could see it We established key principles at a very very broad level like things like enable action Don't overwhelm users and so on which then translated into the thought process further downstream So as we built out the design system, we had a sticker sheet. We had components behaviors that were documented So it got a lot easier later To work through this where engineers who are aware of the principles could even without design being in the loop Move forward very quickly to make key decisions So the point I'm trying to emphasize here is how this helped us to accelerate things Versus being stuck in a very traditional Dev cycle process which slows things down It enabled us to empower developers and designers to make certain decisions a little faster I won't say it always worked. You know, we had our share of mistakes, but I'll say that it helped This is roughly how we went about building product, right? I mean this I think familiar to most people the agile side for sure, right? But we also had a customer development cycle where product management design and a few key engineers Would quickly iterate with customers to ensure that the problem was known sufficiently enough Working these key tight loops Now this is incredibly key Because getting this structure in place helped ensure that engineers were close enough to the customers and every line of code that we were writing Was written keeping this in mind This then obviously expedited things because when you get into the agile cycle There is significantly more clarity and you can also respond with enough agility truly agile Without having to necessarily document everything capture everything and it brings people together with a better shared vision so Simple as this is I think it's a key factor which I think enabled us to move fast despite having a very small team While going up against competitors that were like hundred times our size, right? Now As we grew and matured right we really got to sort of the next stage where There were more problems new problems right as a startup You always have different problems You solve those problems and you go to a new stage and you have a new set of problems to deal with So one part of this now was around architectural decisions with respect to the component architecture state management We had technical debt that were accrued there, right? So for instance usage of local storage worked until a certain point But we started to have customers dealing with much more large data sets So in the space that we're in right it it If you can think of us as an analytics platform right without getting into too much detail about what we do So performance was often linked to The number of attributes of data that would come in and each attribute may have sort of sub attributes as well And this could lead anywhere into hundreds or thousands So there were many different scenarios in which the product could be used And we got to the point where we had a better understanding of the market and what these needs were So this meant coming back from an engineering standpoint to look at it to say how should we be thinking about it Right. So we went through a long exercise of revisiting our state management We will deep dive into this into the birds of feather a lot more but what I'll say is we went with ngrx and It helped with a ton of things But I will also tell you that we Likely over engineered a bunch of things too because the sheer amount of boilerplate and amount of complexity that this brought in Was way more than I think it likely needed Now the reason I'm sharing this is as a startup as you're evolving You really want to plan for the long term Now it's still a very delicate balance You don't want to over engineer too much for the future either Since that means a lot of wasted effort where your company strategy could otherwise moved on a different direction And you've solved for a problem that no longer exists So there's a balance here I think we erred on the right side But the key learning and takeaway here is look think about where this stands. How is it going to play out in the next two years? Some decisions are reversible Some are irreversible Irreversible decisions need a little bit more of careful thought and consideration If it's a reversible decision Empower your teams to make decisions quickly and just move forward because ultimately that isn't the best interest and The key thing about software today more than any time in the past is look Think of just rewriting everything that you have every few years It's much faster to do that than to have to have to worry about legacy So we constantly rebuild everything that we have a rebuild refactor The whole the whole systems keep evolving I think that has been a key factor because it has helped us to keep evolving without worrying too much about the death that at a cruise This is just an example I can go through some of this a bit more. I wanted to just share this now The interaction of product management design and engineering is incredibly vital here, right now Versus getting into a complex cycle where someone is creating epics breaking those down Separately engineering looks at it tries to understand it the qa team works at it separately Instead all of us just worked off Gherkin based syntax To capture each feature with the broad user stories as well as the scenarios So it provided a shared business language Which enabled product managers engaging with the market to come through with broad ass But design and engineering to put down behavioral specifications of how things should work So this is very important right because one designers actually versus just coming up with mocks actually sat down with engineers to write behavior aspects Second engineers as well empowered to understand the broader use cases would contribute directly to this Quality assurance teams would be able to use this as a starting point to then extend it to look at boundary value cases Right other test cases that they need add coverage for so all of it got written out as feature files in gherkin Now did we end up automating all of this end to end? We didn't right So some developers built out unit test cases for their components, right, which was important on e2v We started some efforts, but quite honestly the startup with things moving so fast We differed some parts of e2v, but longer term we will likely look at leveraging this This brought a lot of power to it because of joint collaboration and everyone contributing to One source of truth with respect to what do customers need and what are we building? And breaking it down all the way so that qa is linked into this and it also becomes a system of record for documentation Now I also wanted to share a bit about how we measured ourselves Now we're a company that's you know in the business of listening to customers Helping brands listen to customers understand what customers say and using that to make better decisions So Instead of trying to look at our engineering productivity in terms of look how quickly did we complete these story points, right? Or trying to look at burn charts We instead looked at it outside and starting with customers So it came down to uh, so g2 crowd is a website where for more sass software You see online reviews today. So customers can go out and write reviews of your sass products there So We turned g2 to crowd the primary internal reference point of saying look our customer is happy with what we're shipping And looked at various criteria around g2 crowd kpis things like did your product meet their requirements? Was your product easy to use was it intuitive? Was it easy to learn? What is the quality of support? So this became a key setup overall umbrella metrics The reason i'm sharing this is I think this is a more meaningful set of metrics to have the team align around Then looking at things like what is the productivity of this engineer versus that and trying to optimize for it So we instead took the approach of look Empower your teams and give them a sense of the bigger picture context and then let them make decisions on how they want to do things The other thing we did is we ran this thing. We you know every month we ran an internal survey So that's the second part of this course that you see here And we asked the team. How did we do in terms of delivering value to customers? How did we do in terms of speed with respect to what we put out? quality and did we have fun working together as a team and Just a simple way of having the team itself get their barometer of how this is And then this fed into the retrospective discussions where they would get together to talk about look What are things we need to do to improve it? So I think we did this well It brought people together as a team and opened out conversations around is what we're doing not delivering value Right, what do we need to do about it is is could we be moving faster are some decisions happening too slow? And I think this worked well for us So I just wanted to share that with you and of course we also track our glass door reviews and you know employee experience as well Now as we move forward, right? I would say the Part of the rapid evolution from here, you know the decisions we made earlier helped us really accelerate what we built out And we were up now working with global customers across global markets, which large brands Right, and we were still a tiny startup who was not known around the world And you know, we would we would go into opportunities against much larger competitors And when once they would see a product they would love it Right, but we were still a small team having to accelerate and more quickly against engineering teams of competition There was 10 to 100 times the size I would say the decisions we made earlier and how we went about this let us move really really fast I'll come back to this slide to talk about this in a bit, but I want to just tell you to give you a sense of it Right, this is mid 2018 This is the size of our team, right? We had one product manager one designer one architect Just three front-end engineers at this time three back-end engineers and one data scientist compared to competition much much larger And I want to talk about a couple of things here right one in the context of hiring and other in the context of career parts So one thing we did on hiring which I think worked well for us is We did away with you know interviewing people So, uh, literally, you know, we told our HR team look we want to stop spending time having many Phone interviews and face-to-face discussions with people and we just ran a system entirely off of our website So this is literally hacked together by an architect and he put it together using our own apis and put it on our website Where anyone could just come in they could sign up off of a website receive an otp Pick the task that they want to if you're interested in c-sharp product management design anything, right? There would be a task randomly assigned to them They would have 24 hours to actually show us what they do Right, so versus talk where you get into an interview and you spend like half an hour on Theoretical questions just getting people to actually show you what they do And then to submit it and then within 24 hours what we would do is you know what if we like the task and someone was great We would just fly them down no questions asked Right next day we would fly them down if they whenever they were ready We would run a quick check to make sure that they were the original author And pretty much if all is good we would make a spot offer on the same day so I would recommend this I think it really worked well for us because it took away a ton of time from things where Otherwise we would have been interviewing people and spending a lot of time now the other thing I want to share Is around career paths? so Through this journey right we were fortunate and literally having zero attrition in the core team right of engineering But finally there's one engineer who left us last year So it was a front-end engineer who joined us and in about three months down He said that you know what I want to work on the back end and he didn't actually have the skills right? You know to work on our back end And so it was a interesting conversation I had with him because he said that look I don't know if front-end is right for me And he said that look most of the architects I know Today are all back-end architects So I don't want to work in front-end anymore. I want to be a back-end engineer Because I see that as the only possible career path for me long term So this was sort of very interesting for me right so I mean I And I want to thank him for sort of bringing this up because after this I had conversations a lot of other people in the team And I want to open this up too for this audience because I think this is very important Right. What is the career path for front-end engineers? Now if I went off what he told me right saying that most people most architects I know of today are back-end architects right at the point at which I started my career if I was to look at it that way Most of the architects back then were likely working on you know had experience with mainframes and You know systems which are irrelevant today Right. So the key thing is Are likely most of the architects around today back-end architects? Yes But is this the future? It's not This is not the future Right. So all of you in this room have a very key part to play because I think conversations that we want to have And I want to dive a little bit. This will be one of the topics in birds of feather Is what are the career paths here for someone who's in front-end? Right today more than ever Front-end applications have way more complexity than in the past The overlap of front-end engineering collaborating with design has become incredibly important So this is one dimension where one of one of the key engineers in our team in the front-end has been engaged much more with design in the recent past so Once you have a great design system in place those front-end engineers engage some problem solving solving a higher order problems Using the design system becomes incredibly powerful Whether it's system architecture and design at the front-end Where to use web workers where to use service workers, right? What do you need to do to look at performance and optimization? What do you need to do for larger applications at the context of localization and accessibility? So these are important conversations for us to have because I truly believe that as we look at the future The path here for various front-end architects to emerge Whose roles may look similar in some ways to back-end architects, but also likely being very different Is a very very very real possibility so I want to open this up for discussion and I would love to get more thoughts on what others are doing here and how you Looked at career pathing But this is a key part where we step back and say hey guys look we need to have this conversation Outline paths for you to discuss. What does this look like? Right, what would you be doing? I spoke earlier about the shift from the earlier version of angular someone earlier who was just a css Primarily css developer Found it hard to make the transition to angular And he tried for a while, but instead we moved him out of a very different role in the team where he's doing great But these changes are going to happen only more and more Right with web assembly starting to be a key part of likely what might be a big shift in how front-end is built That may also start to have significant implications so This is an important topic that goes back to the team, right? We have a tiny team But as we looked at this it start to give us some Thought on how we want to shape roles How it aligns to design how to align some more systems and performance and how this starts to get built out so Look Some of you may be aware of this. There's an article that came out in the can Uh, I think about a few weeks back and there's an announcement too in public, right? So, you know cloud cherry is in a space which is incredibly hot, right? So, uh, you know, uh, two of our large competitors one went, uh, public went IPO another Large competitor was acquired by sap last year now We in incidentally, you know had conversations with a number of other key strategic Uh, um, strategic in the ecosystem and, um Just late last month We were very happy to announce that Cisco Has expressed their intent acquire cloud cherry, right? So we're in the process at this point of closing this transaction So This is a key stage of our journey, right? We were a startup that grew from a tiny team going up against huge competition And the challenge we always had is we never had a brand in the us, right? We didn't have that kind of market access And now to be a part of Cisco this opens up incredible opportunities for us to go out its scale and to have market access and reach now The reason I wanted to share this journey with you is I wanted to share how For a small Indian startup a bunch of people with dreams And a lot of hard work and toil that went into it. This has been incredible for us Now every startup usually is likely six to nine months away from dying at any point in time, right? And this isn't to say that look we succeeded because of this but these were key factors and these were key engineering driven decisions that really played out into this Because for a small team To be able to do this is not easy The choice of going on to move on with angler C sharp and type script How the team was set up and how people collaborated How we ensured that the team was empowered to make decisions to move forward fast Balancing engineering debt at various points that kept accruing But sort of the right point of where do we start to look at? Okay state management, right at what point do we need to go back and say look These components are not consistent in various parts of the product. It's fine. We'll get back to this at this time right these were not easy decisions and I think we're fortunate at this point to be where we are And I'm proud to be here. I'm representing really an incredible team that's helped us get this far Sharing some of the learnings we've had so far. We haven't gotten everything right, right? Like I shared earlier. We had many slips along the way I think our decision to pick up move over to angler may have been a little early and we went through a fair amount of pain While we did it While we attempted to get our design system in place with lego blocks We ended up having to discard that whole thing and redo it later Along the way as we move forward fast We maybe should have given more thought to career path for front-end engineers. How do we think about it? How do we ensure they're supported and mentored someone who wants to go deeper into application performance on the front end? Are we make making sure that that's being planned out right so some of this Some of these are key learnings we've had This isn't to say it will necessarily work for you, but we wanted to share it as a part of this journey And we're now at a point where we're actually moving over to angular seven This has been a relatively smooth update so far touch wood. I think we'll know more soon We're still at a point where we're having performance issues that we're working through Just because of the sheer scale of the amount of data on the front end that we're handling So we have gone through and made a number of improvements here using web workers in certain places Now we've also relied very heavily on the material components Right by sticking as closely as we could with angular material components. It's actually given us a lot of things for free So for instance accessibility and other things just come literally with it But sometimes if you modify the styles that are involved Then upgrade ability starts to get broken, which has still been a bit of a sore point The last part too is increasingly we're also using vue.js in some parts of our product, right? and likely We are also exploring other ways to use angular elements to permit more seamless use of web components across different frameworks We're not at a point yet where I can say that this is completely worked well, right? but By and large, I think this has been good for us now Broadly if I was to recap it right, I would say that We took an early call on moving to some of the latest technologies that were available Some of that came with a certain amount of pain, but some of it worked well I think we made slightly forward-looking decisions on the component design and on the design system um I think the way we set up our teams and how people collaborated and the culture around it was key with respect to how the org worked And um, I think we're at a point today where we are still working through performance issues during the birds of feather We would love to trade notes with some of you to see what you're doing and see if we have learnings that we could share so This mostly wraps some of the key things that I wanted to cover off with that We all wanted to open it out to questions to see if any of you have anything that you'd like to ask We have a mic here that will get passed around And join us later as well for birds of feather session. I think I may need help Where would the birds of feather be on the outside on the left side, right? Yeah, great Also in the left we will break out into sort of three groups there, right? We will sort of talk a little bit more about state management. We want to share our lessons on what we over engineered Right and what worked well Talk a little bit about component design our approaches And would love to learn from you and based on what you've done and third You know also a discussion and just career path thing in front end How your organizations are thinking about it and what your thoughts are I forgot to mention this earlier, but on the front end career path too We are slightly opinionated on full stack versus front end Our leaning is less towards full stack and more towards specialization in front end But doesn't limit people from necessarily exposure to all of it end to end But would love your thoughts on how all of you are looking at it Yeah, I have a question regarding web components. So you are mentioning that Angular elements and web components. So have you used this in production or you are trying to explore this Angular? Yeah, no, great question. We're actually just trying to explore it. We have prototyped a couple of examples at this point But we're not used it in production yet. Okay. The only reason we're partly exploring this too I should give you a bit more context is in anticipation of Cisco stack for instance uses a mix of you know other platforms, right? So keeping that in mind, we wanted to make sure that is interop between what we have In case for instance certain widgets may get plugged in together and so on We didn't have the need until now, but we're exploring it a little bit now looking at the future saying hey in case Some parts of a product get integrated in together where it's react plus angular coming together. How would we want to see it? It's still at an early stage of exploration. I'm happy to share what we have done, but would love to know what you're doing One more question Just in case people are probably hearing that question. It was really around Using usage of angular elements. Is it something we're doing in production or not? One more question regarding view js. So This angular and view are you are you using both together or yeah in a different projects you are using? Yeah, great question too at this point. We're using it as a separate project Okay, so where we're using view js for a more administrative view Of certain functions But not for the primary product at this point. So is that view are you combining with typescript or directly? TypeScript With typescript. Absolutely. Okay. Thanks. Yeah, and I didn't talk about this enough But you know, I think we have gotten better at using the typescript capabilities But I think we have more work likely to do there to fully leverage it, right? To have a strongly type system brings a lot of power I think I think in the last year We have really looked at it and started started to define types better in the context of all the apis and what we do But there's more that we will look to do there Okay, thanks Yeah, hi, I have a question regarding the career paths and The way you decided Between the features you are going to release for example, let's say for a start of its very small team It's very very difficult to decide whether you are going to do customer facing features Or something you want to do with the stability and you know performance based, right? So how what factors made you? Make make those decisions and the second one to answer your question is for Fronted career paths. I think product management is one of the very keen way to move in because You know the product and it's you know, uh, you know the How how customer is going to engage with it with it? You'll understand other competitors and so I think Moving into products can be a good career path for a front-end engineer as Just to answer your question Could you clarify the first question a little bit more? I had a bit of trouble Yeah, so yeah, the question is let's say You have two features which will one will be your customer facing Which customer ask you to do it for you for them? And then you have a feature that will make sure that your product is more stable You have more scalability. You have will have more performance So what would be the factors because being a start of it is very difficult, right? You have very less time. You have to be fast-paced. So what factors make, uh, you know take take that decision Great question. Uh, there's two parts to it. So I've split it into two parts One is how do we prioritize? Right, so we prioritize by looking at a matrix of four things We call it density Intensity frequency and urgency right density is really what percentage of the users or customers Have have this need Intensity is how intense is the need? Is it something that they have pain? Which is incredibly high and they've already like found some work around to do it because the pain is so high Right, it's very experiential The third is frequency. Is it a daily pain that they have or weekly or monthly? And the fourth is urgency urgency may be driven by something that's more strategic, right? That's these four are sort of drivers that help you help us decide look, um Customer facing feature with respect to something very visible Was there something under the hood? Which still lies in it and keep in mind even engineering tech debt Feeds in as well to the same system of prioritization right now This is a system of prioritization now with respect to who takes it up My larger developers have freedom Right, they have the freedom to look at it and align with their sort of career path of look Here's what I want to be better at now You know in a startup where everyone look is an owner in the company and wants to enable the success People are also aware look today. This is the more urgent need that the market has So we try to find the balance by lining between the two Right, so focused on the long-term career path Right, which may be someone who for wants to more focus more on system and performance While still balancing that a little bit with more short-term more pragmatic needs No easy answer on that one. Unfortunately, right because market needs a ball. We have tried to balance it out Not always getting it right Hello I'm audible Outside. Yeah. Yeah, please. Really nice to talk with So I want to know like uh, you're using angular and which is very type safe and really good support for Why did you pick view along with angular and what was your experience in terms of type safety and View API Yeah, so just to clarify we have not moved into using view as heavily Right, it's only one part of an administrative piece But it wouldn't surprise me. We start to use it a whole lot more Right. Uh, so but bulk of it is still primarily on angular Uh, we've been very happy with type script, right given that the overlap between c sharp and type script Uh, a couple of the developers in the team for instance also go in and work on the back end as well Right. So the the extent of familiarity allows some of that to be a little bit more seamless Uh, it may be worth my mentioning to why c sharp You know the our primary architect achieved after architect of the company was one of the early open source people out of here in banglore You know and at the point at which he chose c sharp It was just a purity of the language itself Right and just that azure pass Enabled us to get to significant scale and you would have noticed in the team. We had zero devops Right, so I would blindly recommend this to anyone today Look at look at running on a pass system if you're a startup today You don't need to have a devops engineer or any of that to get to significant scale and auto scale And versus any other stack you're running python anything else you've still got headaches of thinking of The virtual environment all that it took all of that away Plus gave us this seamlessness of look c sharp type script Right that help people move between the two. You just likely we will likely do more in the future