Transcript: Building a Scalable No-Code Backend with Xano

Nataraj: Nataraj is the host of startup project podcast. He is an investor at incisive VC, an angel investor and a product manager. All opinions expressed by Nataraj and podcast guests are solely their own opinions and do not reflect the opinion of the firms they work with. This podcast is informational purposes only, and should not be relied upon for investment decisions. Nataraj and guests may maintain positions in the companies or securities discussed on this podcast. To learn more, visit the startup project.io. Hey Prakash, thanks for coming on to the show. Prakash: It is a pleasure to be here. Thank you so much for having me. Nataraj: Uh, so in startup project, I like to feature, you know, interesting products, you know, that are solving interesting uh problems. Uh, and as I explored Zano more and more, uh, you know, it is at the intersection of a couple of very interesting trends, uh in terms of how we are developing and scaling applications in general. So, I thought it would be really useful for our audience to have this conversation about, you know, what Zano is doing, uh, and what you're building at Zano. Uh, but before we get into that, uh, can you give a little bit uh, introduction about yourself and uh your career till now before starting Zeno? Prakash: Absolutely. Yeah, so um, you know, pretty much outside of school uh or after I graduated uh college. I went to Cal Poly Pomona. That's the Cal Poly that most people don't know about. Um, I actually joined a small startup called Picasa. And uh Google actually ended up buying Picasa um, and it became Google photos. So um, a lot of my my co-workers back then called me very lucky because I had no idea. I just joined and then that happened. And I spent uh the next uh eight and a half years at Google. Uh, I had the privilege of, you know, leading the design on Google calendar for a bit. I led the design and research team for Google Enterprise, which was G Suite and Google workspace. Um, so I really just had an amazing career there learning a lot, working with brilliant people. Um, after Google, I left and I uh went into the startup world. Uh, after a short break, I I I basically did a startup and I call it three and a half years of me getting the crap kicked out of myself. Um, and then I went into consulting as one does after a failed startup. Uh, I consulted for a couple of years before starting Zeno. So that's kind of been the trajectory of the career. Uh, I by the way, at Google, I was like UX. I kind of uh evolved from a UX person into a product person and then obviously after uh doing a startup, you're just kind of like more horizontal across the business. Nataraj: Yeah, I I think especially, you know, I I have this thesis about software products, like cracking the right software product is about, you know, finding the right abstraction layer at which people want to work at. Um, and I think exploring Zano and where it works, I think your background sort of makes sense on someone like you will be starting Zano actually makes sense. Uh, I think someone should have an eye on at what level this product should be actually designed. Uh Yeah, I think that's like that's a keen observation. with that, explain what Zano is. Prakash: Yeah, so that's first of all, that's a really good observation because I think one of the main pains that I felt when I was doing my startup was my lack of control as a design product person over the engineering process. You know, you have to pay for an expensive engineer. They're kind of like a car mechanic. If they tell you something is going to take, you know, a month to make and tens of thousands of dollars, you just kind of have to believe them and and hope that it works out. Um, so I always knew that that was a painful process. And then I came to learn that, you know, 80% of the time and resource in software development is spent on the back end side of of software creation. And so um, so Zeno, uh what we are as a tool, uh we're a scalable no code back end. And for those of you that don't know the no code space, it's kind of what it sounds like. It's uh helping people create software without having to know how to code. No code has been around for a very long time, right? They like a tool like Squarespace is even considered no code but just as a website builder. Um, it's gone through a couple different iterations and generations. We're part of a new part of no code where you can really do anything. You can build anything, you can scale without limits and we 100% focus on the back end, which is the server, the database, the API layer, and we connect to any front end that you want. Nataraj: So, um, what kind of applications does Zeno enable to build? Prakash: So Zano is uh really actually meant to be a visual programming language. It's touring complete. Anything you can articulate in a software application or a software programming language, you can do in Zano without code. So in terms of the types of applications that we see built, I mean, we see everything from a dog walking application, um, all the way up to like a customer advocacy uh platform like at a big company like Qualtrics. So, um, you know, it's really just it's kind of like asking, you know, what you uh what you can build with a JavaScript, right? It's like the use cases are endless and and in that same way we see our customers building many types of things on Zeno. Nataraj: So you know, one of the problems or one of the assumptions people often have when they listen to, you know, when we categorize a product as no code is that, hey, you know, this might be good for experimentation, but can I run my production applications on this? Can I really go from uh a demo or um a hobby project to actually running something that actually makes money or I can build in my own company on top of it. Like right? That is actually where I where you can sort of separate out like, you know, players which are, you know, creating sustainable companies and will continue to be, you know, sustainable companies versus, you know, platforms which, you know, sort of didn't break out. Um, how how do you see Zano and where where does it fit in that sense? Prakash: Yeah, I I always say that no code low code has some baggage associated with it. Um, and that is because uh the no code vendors and tools of the past have had all of these limitations, right? Like and they are generally limitations around scalability, security, reliability, compliance. Those are the major categories. And so um, I think that the hesitation is that no code really is something that you should just prototype and tinker with and not anything to take uh seriously at scale. Um, but as I mentioned earlier, these next generation tools are architected fundamentally differently. So, for example, us as a no code back end, we are architected fundamentally different than some of our predecessors that might look like a spreadsheet on steroids and then, you know, scalability and compliance and security things are layered in as an afterthought. We were architected from the very beginning, right? To be enterprise grade, uh to where it was portable. You can uh move it to your own infrastructure, control the resources yourself. And then uh that nuance in terms of the flexibility, in terms of what you can build was also addressed very, very early on. And so I think that uh the concern is definitely valid. uh but one of the things that we hope to do as a vendor in this community is to um, you know, kind of break that stereotype and show that you can start with uh no code low code tools like Zano and scale without limits. Nataraj: So uh I mean to me, uh while I was exploring Zano, it almost felt like, you know, it's sort of like almost like because I was a back end and a front end engineer and I've like played around with different stacks of building back end and one of the problems I see is like building a small application is getting really complicated. Um even if, you know, even for developers who are seasoned because things are so rapidly changing and modern it's it's only it's becoming more and more complex even to get started and you know, add things. On one side it's you feel like everything is getting simpler, but when you start to write an application that is full stack, you know, you have so many things to take care of to even write a smaller application. Um, I feel like all my career I've seen that in the name of distributed systems and in the name of like scaling to hundreds of million users, we've come made this incredibly complicated back end stack to actually get started. What what is your thought process on this? Is am just am I just a bad developer who's experiencing this or is this something really happening? Prakash: Uh no, not at all. I think you call out something that's um that's pretty important. I think as we've introduced new technologies to handle different use cases, certainly like on the DevOps side of things or site reliability side of things, um, it just gives the consumer more choices, which then leads to confusion around what to start with, especially if you have sustainability in mind when you're building an application. Really when you're building any sort of software that's meant to be a business, the most important thing is validating it in the market, right? So you want to get it out the door. Um, and we believe that we should, the vendors should be responsible for making a good decision, a long-term decision in terms of an infrastructure and the DevOps and all of that piece so you can focus on the business logic and um, your relationship with your customers in validating it. The more quickly you can do that, um, the better it's going to be. It's you're either going to fail and learn uh and then iterate. Um, or you're going to get it right and you're going to be able to scale your business on something that you can trust. And so I think there's just a lot of decisions to be made when you're building software and I think that people like to over complicate or it can be over complicated if you really wanted to. But I think a general rule of thumb that we pretty much tell everyone is you're always going to rebuild. Once you're starting, you're just get used to the fact that no matter what stack you build on, you're going to rebuild it at some point. So, the stack that you can use where you can iterate the quick the quickest, um is probably going to be the best one and we wanted to basically really um have that true to our spirit in terms of the way we engineered Zeno, but on a trusted infrastructure to where if they did hit it and if they did start seeing that usage and product market fit, they could rely on it to scale with them. Nataraj: Yeah, you know, I mean, whenever I talk to like very early stage founders or founders who sort of had some sort of product market fit. What they start out in general and where they end up is slightly different. Uh, talk to me a little bit of, you know, how did the process of pro, you know, finding the product market fit, assuming that you found it, uh sort of looked like for Zano in, you know, last five years. Prakash: So, I think like the way that we went about um creating Zano is we generally knew that this no code low code space was growing. More and more people were turning to no code low code despite uh the perception of its limitation because there just frankly is more demand than there are engineers, whether it be in a big company or in the world of software that needs to be created. So we saw this, but we saw this limitation in terms of the back end, right? And building sustainably uh with security and and that scalability in mind. So we kind of made two decisions. One, is we decided to 100% focus just on the back end, right? And not do the full stack. This was the non obvious thing number one that everyone was like, that's probably not a good idea. Um, the second piece is we decided not to um abstract away the core principles and concepts of what the software development language should be. So for example, we chose to call it an API instead of like a workflow or a Zapier type thing, right? Or a zap. We chose to call it a webhook, right? Like we we we we believe you should teach um the next generation of software developers that have the eagerness to learn by just abstracting uh abstracting away the code but just making those concepts more accessible, right? So those two decisions were non obvious and getting product market fit around that was first just started with a landing page as we were building the project. Like, hey, this is like a no code back end. Uh, if you're interested in something like this, uh, sign up for early access and uh, if you do an interview with me, you'll get in sooner, right? That's where it starts. And then once you start like having people uh use the product, you kind of see how quickly they or at least we saw how quickly they came to start relying on it. Um, then the next step is will they pay for it? And then over time you just see how that word of mouth grows and how sticky it became. So I think for us, we got lucky in the sense that we kind of had this non obvious approach and despite what people were telling us, we thought that it was like kind of a need in the market, probably because we've had a lot of failure in our past on things that didn't work. Um, and then we were able to kind of see some of that traction and usage. Um, and you know, you're even if we have some product market fit, it's always the strength of the product market fit and product market fit changes as your uh your company uh shifts and starts to grow, right? Um, so anyways, that's probably the story of how we thought about it and how we got um the modicum of success that we do have. Nataraj: So I mean, because you know, back end has so many components, right? Like was there a specific customer use case or use case that said, okay, which you cracked and when you got confidence that, okay, we've really found something here? Like was there a specific example of a customer or a use case where you realized, oh, okay, I think we are in the right direction. Prakash: It wasn't a specific customer or use case, but um Zano was actually born out of an agency, a development agency. Uh, it started as a command line tool to basically just make back end creation easier without having to grow the team. So when you see hundreds of different use cases, you kind of realize most software is the same, right? They uh they have the same kind of infrastructure setup, same database. Like there's the same motions that you're doing over and over. To your point, that's hard for a lot of people to like think about doing, but after a while it becomes pretty repetitive. Um, so we're I think for us, it was less about the specific use case and more about that procedure and those steps that you had to go through even just to start validating and testing your idea, right? And sure you could do this on some of the other tools that were in the market, but then you couldn't rely on it once you started to have that modicum of product market fit and usage and scale or if security uh was a uh prerequisite for you to even build. So, that was the approach that we took and um, and we found that, you know, being pretty horizontal at least for us has worked so far. Nataraj: Oh, so you uh mentioned that it came out of a studio. Is it from your consulting or were your co-founders running a studio which sort of gave that that this insight? Prakash: My my co-founders were running the development agency. I had done some consulting work as an individual for that agency. and it was in that doing some of that work, that joint client work where I I had seen the evolution of Zano from the very beginning as a command line tool to a decade later having served so many, you know, hundreds of use cases. and you know, I told um my two co-founders at the time. I was like, if we took this and we productized this, I think we could serve a pretty big need in the market and I think we might have something special. So that's kind of how it came about. Nataraj: Yeah, you know, when you said uh that example of seeing, you know, hundreds of examples of how to scale back in, I had this idea of, you know, we've evolved products or like the way we development, develop applications based on cloud, right? Everyone uses cloud to abstract away things and this and we are moving above higher in that abstraction level. So every we had infrastructure as a service, then platform as a service and now probably with AI like intelligence as a service, right? We're sort of abstracting the layer away. And I was thinking, um, at some point someone has to abstract away, like, you know, why does everyone has to do a scalable website? At some point we have to abstract away that, hey, I want a scalable retail website like amazon.com and that has to be abstracted away at some point. And you can say that Shopify is a little bit of that, but it's not truly scalable, right? As a merchant, I don't have full control like uh you know, I I don't control back end, I don't control front end. I just can control pieces of it on the UI. Uh, so I was at some point thinking that at some point there will be a company which will give me an amazon.com and I'll scale linearly whenever my usage grows. I can have the option of, you know, scaling up my database, scaling down my database and I can configure it how I want to scale, which geographies I want to be. Like, so everything a well understood engineer will not be coding it but just deciding it. right? Um, so you are sort of like an evolution of in abstracting away that complexity from back end perspective. Prakash: 100% and I I actually think that we actually could serve that use case pretty well in the sense that you know, I think a lot of uh companies uh and vendors in the no code space, they're very good at building building blocks, right? Like these connectors that connect one service to the other, where we kind of took the other approach and built the engine and the foundation. This uh visual development layer that is on top of an engine that abstracts away the DevOps component, the infrastructure, Kubernetes, Docker, um, postgress, like you don't have to worry about those things. Those are there and they're orchestrated in such a way to where as you scale, you don't have to worry about it. So, if you're building for example, if someone wants to build, which you can do in Zano today, an amazon.com template, right? With the right database schema and you want to be in multiple uh geographic regions, well, you can start with that business logic layer in the database. and then from the infra side, we're able to deploy in whatever region you want or in multiple regions. And so I think it's really just building the foundation that people all align and agree like this is the right layer of abstraction in terms of the business logic and the back end. Um, and then from the infra side, they're able to move it as they start to grow that linear growth that you were talking about. Nataraj: So, uh, the in I mean, not to use uh no code or low code, but uh who is the ideal user today for Zano? I mean there is like the hobbyist developer, there is then the pro developer, there is just you know, an experimentation uh user. So who's who's the main user today of Zano? Prakash: Yeah, so we um we service primarily the citizen developer. And if you haven't heard of that persona before, it's a Gartner defined persona. You can think of them as a product owner type. They're a systems thinker, they don't know how to code, but they need to build software leveraging, you know, tools like the no code in low code industry has. Um, there are also developers that uh are on on Zano as well, but primarily we serve the citizen developer. Now, the citizen developer, there's a wide spectrum of experience, right? People that are more on the citizen side will use tools like airtable, Google sheets because it's very easy to pick up and start using. That serves certain use cases, simple use cases very well. We serve an advanced citizen developer where they need to graduate out of tools like an airtable or a Google sheet, um, when their needs are those that require this scalability, security, reliability, that's who we serve. So an advanced citizen developer who is uh is who Zano serves today and we're constantly working to make ourselves more accessible to the more um citizen side of the citizen developer. Nataraj: So let's slightly shift gears and um talk about like how you're doing in terms of um, you know, as a company. like I think you raised, you know, your series A uh and you have a split between I think enterprise and consumer. Like what is your, you know, revenue split? Yeah, you know, how you're doing enterprise versus uh maybe SMB or citizen developer like uh give me a picture of, you know, how how how you're doing on that side. Prakash: Yeah, so we launched in January of uh 2021. So just a couple years ago and since then we've luckily seen some pretty exponential growth, largely due to word of mouth, right? We are uh just a back end so we're front end agnostic and in all the different front end forums whether it be uh a JavaScript uh forum or a no code front end forum uh we're mentioned. And so I think uh we can attribute our growth to that. We have today over 70,000 back ends that we've deployed. Um, and like you said, we've raised our our series A. and in terms of the enterprise versus uh the self serve split. It's about 20% enterprise revenue, a little more than that and then the 80% is that self serve. We're obviously working right now to develop our muscle in the enterprise that go to market uh sales assist or PLG sales assist motion. Um, but for right now, I think we are mostly known in kind of small medium size business and then uh in the enterprise, I think no code is still very early in the adoption and we're trying to prove ourselves there right now. Nataraj: How how how is the ecosystem or like the competition in the space that you are operating and I'm not talking about like low code or no code per se, but like in specifically like at the abstraction layer that you are operating it primarily focused on back end. Like who who's your primary competition if there is one? Prakash: Yeah, um, so I would say that the spectrum, there's a spectrum between citizen and developer, and then there's a spectrum between developer to engineer. Like, you know, junior developers, I think you said a hobbyist developer is very different than an architect, right? So we service kind of that upper end of the citizen developer into kind of the midway to becoming an engineer and in that space, there are a number of different tools. When you think about back end specifically, if I'm going to pick like the number one competitor, I think we serve different markets, but we we definitely see them is Superbase, right? And Superbase is basically like postgress in the cloud. They've done an amazing job. Um, great founders, they execute very well. Um, but I think that there are tools that believe that making a developers's life easier is kind of the future and then there are tools like us that believe that the next generation of software creators are going to look more like citizen developers. So we serve these two markets, so because we serve the upper end, we we tend to see each other there. Nataraj: Got it. You mentioned uh in one of the answers, um, you know, you almost thought of Zano as a design language. Uh, and that's that gave me a thought that, you know, hey, I think it is also for AI to use this design language and make things happen on Zano. Like are you guys thinking about AI? Like what is your take on how AI will impact your product trajectory or you know, use cases or how how are you thinking about AI intersecting with Zano? Prakash: Yeah, so I mentioned visual development because we are very much we even though, you know, we we use all core foundational software engineering principles. So variables, loops, conditionals, things that every programmer knows and is used to and is kind of language agnostic, right? And we visualize that. When it comes to AI, AI obviously understands these concepts uh as you train the model and it obviously is trained on different languages. And AI is has been such a beautiful thing because I think it has opened up um so much more opportunity and and has built so much awareness around creating software and uh making creating software so much more accessible, right? Some people just ask AI to generate simple applications for them. They'll copy and paste the code uh and if they have the technical competence, they will deploy it on their own. So, I love AI for that reason. That being said, I think that something else is needed after or to pick up where AI leaves off. So what do I mean by this? Um, if I say that I want to build for example, an Uber type application and you give the same prompt, right? Number one, we're probably going to receive two different code sets, right? That's the first thing. But even if we don't. Let's say we receive the exact same thing. What I mean in my mind with an Uber application with wait times, uh vehicle types, etc, is very different than what you mean. So in that case, if we mean different things, well, what are we going to do? We're going to keep reprompting until it like keeps spitting out obfuscated code that we may or may not know how to read. What's better is you need to pick up from that scaffolding and take a visual canvas where you can infuse your intention into. So we believe Zano will be the visual canvas where that can pick up where AI leaves off, right? And so I think it's not uh I think a lot of people make the mistake of saying, it's AI is going to replace coders or replace no code. I don't think that's going to be the case at all. I think they're going to work very well together and we believe um that we can pick up where uh AI built does like, you know, 50 to 60% of the work for you. Nataraj: Yeah, I think that's a very good point. I mean even when you use chat GPT or any of those tools to even rewrite or write something, you often sort of take what uh you get and sort of modify it slightly because it's not still there in terms of what you want. And we see at least I see it almost every day that what you ask and what you expect is not yet there. So you still have to, so you get up to almost maybe 60, 70% of what you want, but then you have to still modify and add your own flavor and correct it or Absolutely. And and it's going to take I think you are right on that point. Prakash: Yeah, and I also think that it's going to take a while for it to get there wherever there is because even I always joke like sometimes for example, if I message my own wife and I forgot, I forget to put an exclamation point or an emoji, she misunderstands maybe that I'm in some sort of mood and then maybe that's like a fight for later and I'm like, hey, I didn't I didn't actually mean that. So, the point is, we as humans even miscommunicate with each other. So then to like think that an AI can build an application that just understands all of the nuances of what you mean, it's going to take a very, very long time to personalize that for each individual and just or to rather than to assume a model can get everything for every single person correct. So it's very important to obviously leverage the power of AI, but to then use tools um that can kind of like I mentioned make those edits. Like right now you you know how to program. So you can make those edits yourself and you can make those corrections, but a lot of people can't do that. So we have to figure out a way to extend the power of AI and pick up where it left off. Nataraj: Yeah, I I think that's a great point. Um, so uh one of the things that I'm trying to, you know, sort of add uh in all our conversations is the aspect of acquiring new customers uh especially at the early stage. Um, so I'm curious like at Zano, you know, whether from the start or whether now after, you know, yeah, five years for four years into this, um, what are some of the techniques that you guys use to acquire new customers? Prakash: I think that one thing that we've done very well, um, especially as a development tool is to create lots of valuable YouTube content. If you go to our YouTube channel, which is youtube.com/nocodebackend, you will see that we have videos starting from like how is software made? What is a back end? What is a front end? How does an API work? All the way to how do you merge two JSON arrays? I think it is very important to do this and to continually put out content because this is how people consume content, content these days. And while it feels like non obvious for a development tool to be consumed in this way, it's probably our largest source of high quality traffic, right? And it's the beautiful thing about the content is it just keeps it keeps giving. Like some of this content is just evergreen. And so I think that we have done a really good job at from the very beginning creating content and having every opportunity to create content, um, be in our DNA. We also uh started running office hours, which was pretty unique at the time when we started. Every user, even a non-paid user has the opportunity every single week to come and meet with a team and get their questions answered. And guess what? If they ask something that we think is unique and we think can help other people, we clip that, right? And we put that on YouTube to then be discovered. I think the final thing as a development tool is having a community tool that can be indexed, right? on the questions that are answered and search for in the future because the chances are the problems that your customers are having today is a problem that a customer is going to have three months from now, right? So I think it's a mistake right now until they fix this to have a community for example, on like a discord or a slack, while like even though that immediate communication might feel really good, well, guess what happens? Like hundreds of questions could be answered and then all of that knowledge evaporates and dissipate, right? So I think it's really important for customer acquisition, natural customer acquisition to have that live on, right? And so uh I think those are some of the decisions that we've made that I'm very happy with and that keep paying dividends today. Nataraj: Yeah, I think I mean the point about YouTube is very right. YouTube, I think a lot of people don't realize is the second largest search engine. So, if they're searching on Google, they're probably also searching on YouTube for the same thing. Um, and I think it's interesting to know the part about community. I'm wondering, do you have any plans of because I've seen this in sort of other tools which sort of became ecosystems of their own where you have marketplaces of, you know, people who can sort of develop things. Like I think we see this in WordPress and Shopify. Uh, are you seeing um, you know, a marketplace sort of a thing evolving in Zano? Prakash: Absolutely. Yeah, we have a uh we already have a marketplace of developers, agencies, and coaches. And then uh we're currently working on a marketplace where people will be able to release capability and soon be able to sell capability, um all using the Zano platform. I think the ecosystem and this marketplace partner ecosystem is extraordinarily important and it is something that we have active work streams on. We're even working on a certification process because we've heard feedback from our agency partners that say, hey, look, I need to separate myself from everyone else that says that they build on Zano, how can I prove that I am um, you know, an expert Zano builder, an expert Zano architect? And so we have uh certification programs that we're actively working on as well. Nataraj: I mean after talking to you and I've seen those YouTube videos by the way because I wanted to understand the product and it looks like you you should almost rebrand yourself to calling as you know, backend cloud uh instead of a no code backend because I think uh it feels a lot like uh you know, some some of the cloud products essentially. Um, so yeah, I think that that would be interesting. Marketing stunt you should try out cloud and see how it goes. Um, but we're almost at the end of our conversation. So I want to ask a couple of questions that I ask all my guests. Um, so the first one is, uh what are you uh consuming right now? Uh, so like what's influencing your thinking? It can be books, movies, Netflix, whatever. Prakash: I listen to a lot of podcasts. I'm sure a lot of your guests do. Um, but uh I, you know, I subscribe to podcasts like, you know, the all Lin podcast, revenue builders, uh the Logan Bartlett, Invest like the best with Patrick O'shaughnessy. Um, and I learn something uh every single week. I'm constant like some people will work out to music. I when I do work out, I'm working out to podcasts. I'm listening to podcast on my commute. Um, I'm more I I tend I'm one of those types that kind of listen at 2X and skip around. Um, if because you know, I think I'm at I'm at the point where I kind of know maybe the nuggets of wisdom I'm looking for. Um, but I'm just so grateful uh for the community of podcasters that have amazing guests, right? Um, that I can learn from on about management style or about growing a business, customer acquisition, go to market. So I would say that that's where I get all of my knowledge from. Nataraj: Um, who are your mentors that helped your career? Prakash: Well, I have, I mean related to the podcast stuff, you know, I think that there are moments or nuggets of wisdom that you pull out from all of these podcasts, from all of these different individuals that um, that influence you. And you know, one uh I would say like, you know, two people that uh I've never met but that have really influenced my way of thinking is Chamath Palihapitiya, um, and uh I think he has like a a wonderful framework of just intellectually hon, intellectual honesty, um, and just, you know, always seeking the truth and what you're doing. Uh, certainly David Chacharia who is uh Mongo DB, uh great management and philosophy around um, or sorry philosophy around management and and growing a company. Uh, and then in terms of like in person uh people, you know, I used to work with uh Adrian Graham and Carl uh Shogren. Um, they were at Google with me. They ended up having a Facebook career. Uh they sold their company to Facebook and then they ended up creating Seesaw and working with them directly. They're just, you know, brilliant individuals, they work really hard. Uh they always have this like healthy dose of like skeptical skeptical um, optimism that I think has just taught me I I've like learned from them to basically, you know, build in a very measured way where you have your head in the clouds but your your feet on the ground. Nataraj: Um, one final question. Uh, what do you know about being a founder that you wish you know before starting Zano? Prakash: I think I'm very happy with uh all of the mistakes that I've made. obviously it's shaped kind of all the decisions and where we are today. But I think if there was one thing, um, and I've said this on a couple different interviews, but um, it's that it's that that things that matter take time. I think when we're younger, we're always in a hurry. Uh, we always think that there might be a silver bullet shortcut and we're always looking for it. But when you're when you're trying to do something that