Turning Frustration into Inspiration to Create Tech Success with Tanmai Gopal

Many of us techies dream of launching a mobile app, a software as a service, or a similar solution that is used by millions. Our guest today is no different. He's building, he's hustling, he's trying to launch a food delivery app for the Indian market. Frustrated by the complexity, complexity of API workflows, and suddenly a light bulb goes off. What if, what if the real problem is not the app itself, but the way the data and API calls are managed? Fast forward, and that realization sparks the birth of Hasura, now a billion-dollar tech company transforming the way developers build applications globally. Welcome back to Mastering Tech Growth, where we interview industry leaders to bring you actionable insights and inspiring stories. I'm your host, Mike, and today we're diving into an incredible story of resilience, innovation, and bold pivots. This episode is about finding opportunity in frustration and turning it into a platform trusted by tech giants like Airbus and Walmart. Joining us today is Tanmay Gopal, co-founder and CEO of Hasura. Tanmay is a visionary software engineer who turned his frustrations into a revolutionary solution for developers. From his humble beginnings building a food delivery app to creating one of the fastest growing open source platforms, Tommy's story is a masterclass in perseverance and innovation. Welcome to the show, Tommy.

Thank you for having me, Mike. Hi, everybody.

So we tried to do this a couple of times, Tommy, isn't it? First time you got sick, second time I got sick. So I'm really excited we're actually finally doing this. It's going to be incredible conversation for me. Myself personally, and I'm sure our listeners. So as we like to start the show, tell me, we have this spirit question. When I say mastering tech growth, what comes to mind?

I think, I think for me, it's like the art of kind of product development and kind of just thinking about like the understanding and how how to build products, how to get to kind of PMF, how to iterate with an early set of users and stuff like that. To me, that balance of how much effort to put into kind of engineering and product development and growth and things that are kind of more user-facing, right, like that entire art and science to me feels like to me is kind of the core of when you say mastering tech growth, that's the first thing I think of.

Okay, so we are effectively saying there's no really one thing that you would single out, like product-market fit, sales, leadership. Effectively, we're saying it's in the middle between choosing the right amount of energy and time for the product and for the sales and for the development and for everything. The mastery element is actually that all of these needs to get some attention, but you don't need, you don't want to go in one or another direction too much.

Is that good or something? And it's right. And I think it's like different things at different points of time, right? So it's like the, it's always kind of this trifecta of sales, marketing, and product development. And which one you choose to do, spend 100% of your time on it, which stage, right? Or 80/20, because it's not possible to do one-third, one-third, one-third, like you can't spend your time on all of it equally. But at different points of time, you'd want to lean on different pieces. And I feel like once you yourself or your organization starts to kind of master that piece, that unlocks kind of that growth.

Okay. So there's definitely then a timing element in play, we're saying. As in choose in, in different times of your organization or even your self-mastery, you want to choose different priorities. Is that what you're saying? Yeah, exactly. I love that. So before founding Asura, you were developing a food delivery app for the Indian market. So what inspired you to start this project or venture in the first place?

Yeah, I think it was just that I wanted to kind of get my hands dirty and build a, build a simple product. That I kind of felt like needed to exist. And I just wanted to kind of get a sense of what it would be like to create a product that has, you know, multiple stakeholders, solve an important problem where there's an existing market and stuff like that. And really kind of get my hands dirty with that. And so me and my co-founder and some of the early folks in the team who are still with us today, we we kind of got together and we're like, okay, let's do this, let's do this. Uh, it's kind of like a— it was, it was this home, uh, food, uh, delivery kind of thing. So the idea was that you have people who make kind of a few extra portions of the meals that they regularly make, and then we'd go and they can go and kind of publish their menus, and then we go in and pick up some of those items, and then we deliver that to people who want kind of, you know, like home-cooked meals, where somebody just made like, you know, you're making lunch for yourself, but you make an extra 5 portions. And then we take those 5 portions and we deliver it, right. It's a bad idea for several reasons. And it's really hard to get right. I think in the Bay Area now there's something called Shef, S-H-E-F, which is very, very similar, which is great. But it's really hard to kind of execute and build on as a business. But we never got to that stage, because we were thinking about just the product development of it. And And we started kind of building the product around it. It was interesting in just kind of getting so frustrated with the time it was taking to build some of those things that we realized that, wait, like, let's just first fix this piece. Because this problem seems like— this problem seems like a real problem that everybody's having for sure. And so we kind of just moved into that. So I think we spent about 6 months trying to build our food delivery application. And then we started kind of thinking about, no, we want to build tools and technologies to speed up the development process. And that's kind of what we started working on. We started a consulting firm where we started helping other people build their applications using some of these ideas that we wanted to experiment with that would speed up development. We had certain ideas around CI/CD workflows. I remember kind of we were the first Git-based CI/CD deployment for Kubernetes in the entire world when it came out very early. We had one of the things was a data API that then turned into Hasura, the company. We had we had a file storage layer, we had a bunch of things that we were kind of experimenting with. And we started a consulting firm, we started helping other clients develop their applications with these technologies and techniques. And after a few years, we felt like the data API access layer felt like the piece that could become a product and a business by itself. And that's kind of when we shut down our consulting firm and we started Hospira's VC. And we started Hasura around data access as kind of a core product and platform capability that we wanted to build the company around. So that was kind of the gradual process of discovery, right, from kind of like the food delivery build an application to building lots of applications for I think about 80 customers or so. As a consulting business we scaled that and we grew a business there that was entirely bootstrapped. And then from there to raising VC and starting Hasura as it kind of exists today.

Okay. So that's a very nice domino. So you kicked off as a small team and I wanted to ask how many people were in that very first stage, those first 6 months of that food delivery app?

Like 3, 4 of us.

And was it like close friends? You all came together?

Yeah.

It was like that, isn't it?

Yeah, from like university, my, some folks that I know from university, my co-founder who was in the same city who had gone to study in another university that I got connected to through an alumni and stuff like that. So that's kind of how it all came together.

And it's all—

initially it was a small network of people. Yeah.

And it's all unpaid, no salaries, we're just gonna come together. Here's the vision.

We all had, we had a little bit of savings that that we could have gone on for maybe about a year or so. Yeah. And so we just kind of survived off of that. Okay.

That's such a common picture though. And so that's why I asked, you know, it's very often a handful of friends, 2, maybe 4, you know, maximum probably like 6-ish, which comes together. Someone has a vision and, you know, the vision is not something, you know, fleshed out where it's based on market research and some, you know, customer interviews. It's like, hey, let's just build this because it's fun. And then everybody just chips in because everyone has these dreams of owning, you know, a business, being a co-founder and, you know, all the unicorn stories. And people come together and a lot, of course, a lot of them, of course, don't really go anywhere. So your story is unique. And I want to find this moment where, where, where that, you know, real decision or that correct decision was made. So So you're doing the mobile app and at some point you go like, you know, whatever, you know, let's forget this app. Everyone is struggling with this API situation. So was this GraphQL particularly because it was new technology?

No, it wasn't.

It wasn't, is it?

No, it wasn't. It wasn't. Yeah. No, we actually had— and so from the food delivery app, we went to the consulting business, right? And then from the consulting business, we took out the data access API kind of component that we've been building, that we've been thinking about. And we took that and we started a company around that. We added GraphQL support to that because we were like, that's going to be the easiest way for developers to use the API. We had to make a choice of what API should our data access solution provide. And GraphQL was just kind of getting started at the time. It was a great fit for our use case for data APIs. And so that's kind of when we added GraphQL to the piece. But GraphQL has been and is going forward as well. Kind of more of an implementation detail of— it happens to be a nice API for the data access kind of business value that we provide. Right. And that's kind of also the evolution that it's happening. The next evolution that's happening for our business now, which is the next API that we're kind of adding is what we call PromptQL, which is actually an API for it's actually, it's an agent API. So from a data API, we are kind of now have this evolution to a data agent, right? That's kind of with AI, that's kind of the next step that's happening. So GraphQL was this, you know, it was kind of us being at the right place at the right time and really understanding. And we got that feedback from our first set of kind of users that we were previewing our technology with as well, who said, hey, this kind of just feels like it'd be perfect with GraphQL. And we heard that from like 2 or 3 people. We added GraphQL support. We open sourced it. And that's kind of when it went viral, right? That moment was when in like I think just a few months it started to go viral with developers. They just absolutely loved the technology. After about a year of that open source project, we started getting a lot of enterprise traction from people who had deployed this already in pretty serious kind of environments, right? I remember getting a call from Cisco saying, hey, so we kind of run our infrastructure on this. We have a whole bunch of internal infrastructure that we've built out that uses this. Who are you people? Like, is this real? Can we pay you? Will this technology exist? Like, tomorrow if this goes down, nobody can make any deployments for the next 2 weeks. 'What is this?' And we're like, 'Yeah, of course we're a real business.' Right? At that time we were like maybe 7, 8 people. And that's kind of when we started getting those early signals about a year in after it was open source that the bet is really playing out. Right? Like we thought this is mission critical and serious, but now we're kind of organically seeing that other developers and technology teams are also able to deploy it in an— especially in a mission-critical enterprise environment, right? That's a tough environment, right? They have legacy data, they have like— it's a complicated process to introduce new technology. That's kind of where you can add real business value, right? As opposed to just a greenfield kind of application where somebody's building something new for themselves, which is very nice, but it's not something that you can build a business on. Building a business, we have to make sure that our technology kind of gets used by people who can use that to add a lot, like hundreds of millions of dollars of business value. And if they do hundreds of millions of dollars of business value, we'll get millions of dollars of revenue, right? It has to go into enterprise. And I think about a year or so after it was open source, we kind of started getting that signal. And that's kind of when we did our Series A fundraise. And we started thinking about monetization, right? Till then we weren't even thinking about monetization, we were just thinking about building the best product and good distribution.

I love that. Concentrate on things, you know, you can do very well. It does feel like you got— you made that pivot, right? So that food delivery just went through the window, right? You just launched a consultancy firm. You started— at which point after launching consultancy firm, you actually started working on the core of Hasura as an offering, as a one sort of service offering, like Was that the year you mentioned where you just sort of compounding, were using the, you know, Hasura Core as a, you know, with your consultancy firm or was it always like, hey, this is gonna be the main offering, we stop in consultancy? Like who made that call and, you know, like how you were thinking about it?

Yeah, it's a very good question. So we had, so we were running the consulting business, we had 4 or 5 pieces of technology that we had developed that our team was using. I think at the time we had grown to about maybe 60-65 people in our consulting organization.

60 to 65 or 65? 60.

No, 60.

Yeah, 60. That's a huge operation by itself already.

Yeah, and we were making a lot of money. Like we were making a lot of money. We were, we had clients that were like the world's largest banks in the world. We had a really good client list. We were doing really well. And internally we had like a 5-member platform team that was building these components. And the rest of the team was essentially kind of providing those kind of technology consulting, product development services to other customers, right? To other people. and that was kind of that business that we were running. We were kind of, we always had this dream, it was naive and stupid in hindsight, that we would be able to also build a great product while getting consulting revenue. That's not, that's just not possible.

Why is it not possible? Tell me why it's not possible.

It's a problem of focus. To focus on building a product and taking that product to market is different from focusing on providing services to customers to help them do whatever they need to do. Look, eventually in a large business, they kind of start to converge a little bit, But in those early days, so let's say, you know, pre-IPO, right, and going from like $0 to $500 million, $1 billion in revenue, and that's kind of like that pre-IPO stage, it's really important to choose one of the two. Are you building an amazing services business and scaling that up? And it's totally possible to do that. Are you building an amazing product and scaling that? And the kind of company that we have to build, the kind of product that you have to build, is very different in, in one of those two scenarios. Um, we realized in our consulting business that we were not able to focus on product development, and all of our time was going in helping and working with customers and customer relationships. Um, which is very different.

Wouldn't the customers help you to make your product better? Just, just—

but only 10%, only 10% of the interactions would help us make the customer better. Okay, 90% is just 90% of the interactions were learning about their business. Yeah, right. Okay, helping them organize or helping them navigate the complexity of rolling out their internal product development inside their business, right? Helping them make choices about what cloud vendor to use, what what technology to use, how to do product design, roping in, you know, other partners, right, on design maybe or whatever. Right. So a lot of that work is spent with the customer doing something which is very good work that you can charge a lot of money for, but it again results in you getting a different kind of customer, right? It's not, it's not, it's very different from taking a product and giving it to people who can now do something on top of that product. And so I remember my co-founder actually made the decision and she said, hey, this is not like possible. We can't do this. We have to stop. We have to take this tough call. Despite the fact that, you know, it was, it was a struggle to build a consulting business to go from zero to millions of dollars in revenue with very high margins. And at that point to take that call and say, man, we're making this money, but like we need to stop because because if we don't stop, then the kind of business that we have to scale is going to be very different from what we want to do. Okay.

Did you have any investors at that point in time? Tell me, like a board?

No, it was bootstrapped. It was entirely bootstrapped.

Okay. So that was easy call, at least from a stakeholders management perspective. Okay.

We just had to get like the founding team aligned. It was still very tough because we had to help 65 people in our company move on, get absorbed with our customers, right. And stuff like that. So it was a tough transition to make from a people point of view. Some of us came out and started Hasura and I'm happy to say that everybody who worked with us then also found really good jobs and is now doing very— they're all doing really well in their careers. But at that time it was like a tough decision to make, right. And transition to go through.

Um, how did you know it's a good decision? Tell me. Like, um, that was a big goal, right? So it's like, it's kind of what we wanted to do.

Again, it's like, okay, it's like the— we realized that like we wouldn't be able to scale, um, we wouldn't be able to kind of like impact at the scale that we wanted to have impact. The number of people that we wanted to be successful in building their own applications, the number of people that we wanted to we wanted kind of like millions of developers to, all the organizations in the world to be able to say, I'm using this product and I'm accelerating and I'm building world-class products. I'm able to build things faster. I'm able to do better.

So there was a vision.

Exactly.

So there was a vision.

Okay. Exactly that. We wouldn't be able to serve that vision, that vision of saying development has to be easier and better. For the world, that vision would not be met through a services model, right? Like it would take us 30-40 years to build a business that could do that.

Do you have a vision right now? Like, do you have a vision statement of Hasura?

Exactly, right, which is basically saying that for— and then when we started Hasura from that time to now, that vision has always been to say that We believe that for people to be the most productive, to build, to have the experience of the best kind of products, they need high-quality, instant, secure data access. That needs to be a commodity that just exists, right? The world needs to have— the world needs to be in a place where if you want to access data that exists, it's private data, enterprise data, personal data, right? You should be able to kind of securely access it and use it to do whatever you want to do. That needs to be commoditized, right? Let's say for example, like you want to access your email data, your bank data, you use a variety of SaaS products, right? Today you are in a place where you do not actually have instant access to that data, right? It's very painful. If I said like, you know, hey, Mike, can you like, you know, look at your emails and tell me like how much you spend on Uber, right? Or you just, you went on PTO, you know, what are kind of the important emails that you want to get back to, right? You can't like, Theoretically you can, you can build software and you can use AI and you can do things to answer that question. But can you actually build a product that does that for you? You can't, right? Like it's not easy. It's very painful, right? There are 10 kinds of APIs to go through. Uh, there's like authorization and security is really hard. And this is hard for you as an individual. Can you imagine it's 10 to 20 times harder for somebody inside an enterprise? Right? If I'm in a bank and I'm working with a customer and I want to get information about the customer, about the money markets, about the bank itself, and then provide some value to the customer, right? It's super hard to get access to data that is all over the place to build a product around it and then deliver something to that customer. It's just extremely painful. I guess if that And that was kind of the insight that we had, that if that was a thing that just existed in the world, people would be able to do so much more. And that has always been the vision. That's kind of what we realized in our consulting business. We realized that, man, we're solving this problem again and again across these 80 customers and 80 products that we have built. The problem, the core problem technically that we have solved ourselves that wasn't already solved. Cloud was existing, frontend frameworks were getting better and better. Like everything was— like databases were getting better. Like these pieces all existed. But the part that we always had to manually solve was this part of securely getting access, securely getting data from the database and from a variety of databases into the frontend application. That's the piece that we were manually building. We were building these APIs, we were setting up the authorization logic and and we were doing that work. This work ought to exist for free. This work ought to be like click a button and this access and this API is instantly available. This should not be work that we have to spend months and years doing. This should just exist, right? That was the core kind of like frustration and insight and observation that we had that this is where we're spending time. This is the part that needs to be automated. And that's kind of when we said we have a way to automate this. Let's open source this and see what developers think about it. And then when we gave it to developers, developers were like, shit, this is amazing. This is exactly what I wanted. I want to build my cool frontend applications and I need instant access to data. That's the part that takes me like, you know, weeks and months to build and maintain and scale. If you're telling me that all I need is a Postgres database and I put your tech on top of it and I get an API that's secure and like I can access data securely and right users can access data and whatever, I can just focus on building my app and my product. That's amazing.

Is there a reason—

that's what we saw.

Tell me, is Postgres like the only database which is—

We just started with Postgres. We just had to make a choice again, that kind of choice of like what we focus on initially, right? And so we just started with Postgres. Over time we started expanding to other databases. And so now when we work with enterprise, we have like all kinds of databases, right? So Postgres, SQL Server, Oracle, MySQL, Mongo, ClickHouse.

So when you launched that to the open source communities, like what was like the biggest or, you know, the one initial challenge which sort of hindered the adoption a little bit? Like, I'm sure there was something where, you know, you launched and people took it and they were like, this is amazing, but what about that?

Right, so the way that I think about a lot of these kinds of products is when you kind of build that product and you give it to people, right? If you reach 100 people, only 10 of them try it out, right? And if 100 people try it out, only 10 of them are going to talk about it. You use so many products, you don't keep talking about all the products, right? But some of us do, right? And so there's kind of like a, you know, 0.1% conversion rate on word of mouth and people talking about your product. Right, for you to be a popular open source project, etc., it takes time. You need to reach a lot of people. And then once you reach a lot of people, you need to make sure that enough people try it out so that those people who are vocal and who talk about technology, who blog about it, who share it with people, they feel like sharing it, right? And that initial activation, getting to as many people who you can reach, and as many people that you can activate, right, as many people as you can kind of get sucked into the product to start using it, just like a consumer product, right? Imagine if like you're using Instagram, but the onboarding on Instagram was very hard, right? You wouldn't use it. And if enough people didn't use Instagram or talk about it, then it wouldn't go viral, right? So in that activation phase, which is critical, the part that we noticed that was challenging was we had always decided and even now we kind of stick to this idea that we do not want to kind of host a database. So we're giving you APIs and access to different data sources, but we don't actually run a Postgres database, right? Because we believe that in enterprise and in complex environments, people already have existing databases and people have a complicated database technology stack. So we do not want to go and own and run the database itself. So our biggest challenge was how do we provide an instant experience for a developer to see how powerful and nice this API is, which is essentially an API, a data API, which obviously needs a database to have the data. How do they experience this value when we don't even provide the database? Right. It's like, you know, I'm giving you this amazing iPhone screen and experience, but there's no storage. For the thing that you're using, right? So how can I show you that my API is amazing without giving you the database? And that was kind of a big initial challenge that we had to address, where giving people kind of an instant one-click free Postgres database was really important. And I remember at the time what worked really well was Heroku. And Heroku used to offer developers instant free Postgres databases that they needed to. So you signed up on Heroku, you got a free Postgres database, and then you could just run Hustlr on top of it. And I remember we became the number one thing deployed to Heroku, and we stayed there for like 2 years. We were the topmost thing deployed to Heroku because people would just— because we needed Heroku, right? So you would take our open source project, you would deploy it on Heroku, and Heroku would give you the database, which was limited, of course, right? You only had I think like 10,000 or 100,000 rows or something like that, you had a limitation. It was a great experience. And that is what really helped, right? Like without that would have been impossible for the project to take off.

So when you started pushing out, was there a plan? Like, you know, I'm sure there was a plan, you know, let's get this influencer talking about the product or, you know, let's put it here, let's send some traffic towards it. I'm just trying to understand like that initial traction which was very successful by just simply by the word of mouth where developers tried it, they got amazed because the product was good and they offered their friends and it just sort of kicked off. But that initial push is always like that go-to-market exercise. Is there any tips or how you guys did it so it was so successful?

Yeah, yeah, I think, I think it always depends on the nature, the kind of product that, that is being that is being built, right? So is it for developers? Is it for enterprise infrastructure? Is it for consumers, right? So it depends, but I think what's really important is to, one, be aligned to how people think about a particular problem in what is what is hot for them or what is top of mind for them, right? So, at the time when we were doing data access, if you had said instant data access and APIs on Postgres, that wouldn't have worked because that was not top of mind for developers. Although that is the value that you're getting, that's not what is top of mind for people, right? What was top of mind at that time was GraphQL, right? And that was kind of emerging. So it was really important to kind of align with something that your consumer base and customer base is kind of thinking about and is top of mind for them, because you have to penetrate through the noise. How do you get their attention?

How do you source that? I mean, like, is that purely just based on the fact that, you know, the product—

that's the market research. That's the market research and the work that you have to do. Okay, so you have to find out, yeah, you have to find out for your audience, whatever it is, whether it's a totally boring topic or a totally hot trending topic, right? Whatever it is for any audience, there'll be something that is top of mind for them. There's something that is, that defines, that, that, that is the way that they see the world, right? Yeah. Like for example, you're launching a new keyboard, for example, right? There is something today that is top of mind for the keyboard audience today, right? It's different every year. It's different every few years. It's different, right? But there's something today, right? Maybe it's split keyboard. Yeah, right. Maybe it's, uh, the buttons that you have, right? Like whether they're clicky buttons or not. So it's something that is going to be top of mind for them that will help you reach the people who are going to be your initial audience, who are going to be your initial potential fans, right? Your initial potential champions. So you have to find a way of reaching those initial potential champions, uh, by really deeply understanding the market and what is top of mind for them so that that helps you define your vector for this is how I'm going to reach them. Once you reach them, you have to deliver a stellar activation experience. Right? You have to shave off every single step, every single minute, every single second that gets in the way of activation. Right? So that your user who you connected with, like you're building a new keyboard, and you told them that, hey, like the next, like the thing that you're all thinking about right now is like how good the buttons feel. That's the next like innovation in keyboards. And that's what's really important. And so now you know that there's a bunch of keyboard enthusiasts who talk about buttons and like the feel, the button feel. So, so you've decided that you're going to talk about button feel, button feel is your vector. That's what's top of mind for people. So any content that you do, any forum that you go to, any event that you do, button feel is going to get people in. Yeah, but once people come in, does your button feel product experience deliver? Right, right. Is there a way for them to come to your booth and to try it out instantly, right, to get activated on your product? That part is the second piece that's really important, right? Because the more activations you get, the more you can start to seed the— you can start to plant the seeds of virality and word of mouth and growth. Right.

Yeah.

That's, those are the kind of two initial pieces that feel magical, right? That's kind of where magic comes from, where it's like, man, I was just thinking about this and in 30 seconds I could do it. I felt magic. And then when somebody feels that emotion of magic, that's when, that's when that kind of word of mouth and growth happens. Yeah. Right. That, that, that like creating that magic, which is that intersection of top of mind with amazing activation experience. These two things create magic. And then as soon as you've created magic, you can start taking your product to market. It's still just the beginning. Like it's nowhere near enough. Just creating magic is, it means nothing for your business, but it means that you can start your business.

I love that. That's a solid advice, Tanmay. It's, yeah, it's very easy to overlook that and neglect some of these things, which ultimately sets you in a poor position from the get-go. So you want to concentrate and get that magic. And I love how you put it, magic, just get the magic. I think you said magic like 9 times. That's a good word to describe it. So I want to dig into a little bit into enterprises. So convincing enterprises to adopt emerging technologies requires demonstration of value. Often proof of concept or return of investment or something like that. How did you approach enterprises to make sure that your product sticks with them?

Yeah, it's, it's, for us, our journey was, was what you kind of see pretty typically with open source infrastructure projects, which is that a developer or a practitioner or a champion who liked the magic of your product brought you in. So they start using it. And then once they start using it, in our case, we had to make a decision of, are we going to monetize by developer seat? Or are we going to monetize— like, is the unit of value the number of developers that become productive? Or is the unit of value the core IP of the technology itself? So to give you an example, are we a GitHub or a Postman or are we like cloud infrastructure, right? Are you— do you price like a database which doesn't price by seat, it prices by usage, right? Or do you price like GitHub which is you price by seats, the number of developers in your org. And those are two kinds of very different businesses and they have very different kind of ROIs and how you grow and how you communicate your business value to enterprise and how they justify how much they're paying for you, how much their willingness to pay, right, it kind of is very different for these different kinds of businesses. So we decided to be on the infrastructure route and so for us it was essentially kind of once you're in kind of mission critical part of once their entire application, the API kind of depends on you, right? What then the business value, kind of the ROI justification ends up essentially being how much kind of the cost of development and maintenance of that component would have been if we weren't there. Right.

It's very hard to measure these things. I call them intangibles.

Exactly. Exactly. And that's kind of where a little bit of like that art of pricing needs to happen, where you price it in a way and you price certain features in different ways to map that to your customers. So for example, for developers, they're saving a lot of time in the building and the maintenance of this API. But the applications that they're building and their willingness to pay is at a very different level from somebody who is running tens of millions of dollars of revenue and transactions through the system. Right? Their willingness to pay for the same amount of time and the value of the development and maintenance of the API is very different for them. Right? So we kind of went through this journey where we had to build the right kind of features and feature gates that would help us connect to the business value of the mission criticality, the business criticality of the product. Right. And then price around that. Right. So then it makes sense to you so that when you're an enterprise and you're deploying it at scale, you're like, oh yeah, I pay like $1 million a year for us. So that totally makes sense. Okay. But you're a developer and you're like, yeah, I pay $50 a month for Hasura, that makes sense. Right? So making— like that's very hard to do. Right? Like that's very hard to like— it takes a lot of like working with customers and spending time with them to understand what those gates are, what are those feature value propositions, what are the product value propositions, what are the company value propositions that allow you to partner with your customers to extract the right level of business value. But ultimately for everybody, it kind of boils down to how business critical is what I have built with this infrastructure, how business critical is it, and how much am I willing to pay for that being a thing to be taken care of, right? That's how you think about the price, right? It depends on like the alternative, like pricing is based on— pricing is not based necessarily on how many development man hours I would have spent building this API myself, right? Pricing is more dependent on saying, how much do I pay to not care about this problem? Like, how much do you pay AWS to not care about the fact that your compute runs?

Yeah, I love that.

It's not actually based on what is the cost of a CPU that runs in the cloud on a data center, right? That's not what you pay for. You don't, you don't actually work the math out, right? And like, oh, if I bought my own machine, maybe that would have been like $1,000. And then I pay for electricity, maybe that's like $20. And so I should not be paying more than like, you know, $1,500 a year on AWS. And then you get slapped with a bill that's like $500,000. Right. But that it's totally not connected to the cost of goods. It's connected to how much do you pay AWS to not worry about the fact that there is a CPU and electricity and data centers and availability. I do not care. I do not want to care about this problem. I'm going to pay AWS to not care about this problem.

Okay, I get you. Do you go after enterprises now based on like sales approach where you reach out, or do you allow actually the developers who work for enterprises to bring your product in and then you sort of like land and expand on it? I'm just interested to see how you sell right now the product.

Yeah, I think we've gone through a transition and we've transitioned from being exclusively sponsored inside organizations by developers to what we have learned gradually now with our customers to go kind of more directly to enterprises with the value prop more directly to go kind of almost mid-down to top-down. Mid-down to top-down. Okay.

Yeah.

So that's what we're going through right now. And I think especially now with the— with AI, for essentially kind of like, you know, you have data that you have to access over an API if you're building a product like an app. But if you're building an AI-based solution, you need an agent to access that data, right? Like, it needs to become more flexible. With an API, it's like, hey, this is the data I want, or this is the data I want to write. Very specific. But with AI, it's going to be a lot more generic, right? It is also, you're like, do this for me, and then do that for me, and then change this for me. And it's like, very free-flowing. So especially with that, we're noticing kind of, it's early days, but just phenomenal response from the market on directly kind of going mid-down and top-down, right? Because that's just the nature of the need for like kind of this kind of solution. So now we're kind of transitioning as we've grown as a business to being more kind of mid-down and top-down by going to enterprise directly, you know, having events, having thought leadership content that gets us in front of the people who are directly willing to buy and purchase technology to solve problems.

So do you have your community sort of advocates or Someone who's been with you from the beginning as open source participant knows all your tech and they effectively just sort of, you know, spread the word, run workshops and things like that, or is it actually baked into your business as a function?

Combination.

Combination of two, okay.

It's a combination of the two, yeah. Again, depends on kind of like the, like at different stages, the amount that you invest in these things are different. Um, but, but, uh, but the short answer is it's a combination of them.

Yeah. So if people would want to find the Hasura community, is that all in like GitHub, or do you have like Discord? It's all in GitHub, isn't it? Well, so I'm very intrigued by this AI situation which, which you mentioned. I mean, the whole market is, isn't it? And, uh, not sure if you were part of the current, um tech show which ended in Las Vegas, it was just all about AI. Not surprising. I mean, it's, it's so easy to see how AI will just swallow the planet. I mean, it already is, but it's so easy to see how it's going to be a lot bigger. So based on that and the fact you mentioned that, you know, the market is responding very, very, very positively, can you really talk through that PromptQL a little bit. I'm very intrigued, like, how you guys building and why you're building it as you are building it.

Yeah, yeah. So, so, um, kind of again, kind of going back to our vision, right? And really kind of thinking about, well, um, if I have AI, um, to, to do work for me, um, what does it mean for what unlocks AI, right? Like when you are thinking about you yourself as a person, user, or inside an enterprise, you're a person that uses an internal application, you use a customer-facing application like DoorDash or Amazon or whatever, right? If all of these things were to gradually become AI-enabled or have almost AI-native experiences, what would it— what do you need, right? And the simple thing that we realized about a year and a half ago when we spun up our AI research lab was the dream that is— that should be possible, but it isn't, is why is your ChatGPT or Claude or whatever not connected to all of your business systems in a way that you can just tell it to do stuff that just works with high confidence, right? Like, why doesn't it just work? It doesn't, right? It feels like AI is cool and this and that, but it doesn't— like, something's wrong in that it doesn't actually do the thing that you want to do, right? Like, it's okay when you bring in a lot of data and you say, help me write an email or help me brainstorm and stuff like that. But, but it's not become a part of our day-to-day life because to become a part of our day-to-day life, it needs to become a part of our processes and our workflows. Yeah. Right. Why is it not a part of our day-to-day processes and workflows? Why, why do I have to ask my team, uh, you know, uh, what are the kinds of tickets that we're getting from our customers? What are people complaining about? What is kind of the most important thing right now for the community? What sort of version are they on? When we're selling deals to enterprises, like what database is coming up most often, right? What deals are expanding really well? Where's the kind of sales velocity high or low? How does it correlate? How's like product usage correlating to this, right? Help me fill up this form. Like I did an interview with a user and now I need to fill up the Salesforce form. Like help me fill up the form correctly and do work for me. Me, right? You go onto a website and you're like, man, I don't want to fill up all this data, like, let me fill up this data based on, you know, my information and information that's already available, right? Why are these things like not there? And, and, and what we realized was that the core bit of it that's hard is very similar to what is hard for apps also, is that your AI assistants or agents that you're building are not kind of integrated with data in a way that they don't have access, real-time access to data.

Exactly.

So they can actually do stuff. And even when they do have access to data, they hallucinate and it's not reliable, right? You ask the AI to do something that's business critical, not cute, not a cute demo, but like serious work, right? Like you're going to a customer meeting and you're like, man, what are the recent support issues that they've had? Right? You don't want to miss out on support issues. Right? Like you can't imagine that you use your AI to access the recent support issues and you turn up for this customer meeting. And you have no idea that they had like a recent downtime or a critical issue.

Yeah, that's a great point.

Last week. Terrible look. You'll stop using this AI thing at all at work.

Yeah.

Right? You're like, no, I'm going to use it for like generating images and memes, but I'm not going to use it for actual work, right? Are you going to use it to review a contract? You're not going to use it to review a contract, right? Because you just feel like even when I do connect my data to it, it makes stuff up, right? It doesn't do it accurately, it doesn't do it reliably, it misses out on information, right? It's, it's, um, and it's so weird when you use AI, sometimes it works very well even on a complex task, but as soon as you make it work on a larger amount of data, that technically fits, its performance becomes worse.

Yeah. 100%. Yeah.

Like, these kinds of things just happen. So we kind of attack that problem from that point of view, just saying, if I want to use AI for business-critical workflows and operations, and I want data to be integrated with AI for critical stuff, what needs to exist? And, and we came up with PromptQL, which is essentially a way of which is a new way of connecting kind of AI to data. And we're publishing our paper and our benchmarks are insane. It's like any RAG benchmark, we can hit 100% accuracy on that RAG benchmark by applying kind of this prompt-to-QRL technique. And the prompt-to-QRL technique is a very simple idea. What we do is we say, whenever you're using the AI to do a piece of work with data, we actually tell the AI to first plan what it wants to do with data, then write a program. First it will write a program itself, figure out what to do with data itself.

AI will write a program itself.

AI won't do the work directly.

Okay.

So AI won't talk to your Gmail and fetch the emails and then tell you which emails are important to respond to because, you know, you were out for one week, you were sick.

Okay.

Right.

Yeah.

Let's not do that because we know that if we do that, AI will miss out on stuff. Right. It will, it will pick up two of the important emails, but the third one where somebody was asking you to sign a contract, you would have forgotten. It would forget. That happens today. If you go to your Gmail Assistant today or any email assistant today, and you ask it that question, I was sick for a week. Tell me what emails I need to respond to. It won't figure out last week. It can't do a filter by last week. It just can't, it can't do last 7 days. It'll tell you some important email from 2 months ago. It will miss out on some important emails that you had even in the last few days. It just won't work accurately. You'll get one good look, one answer, but you won't actually use it in a critical way. You'll say, screw it, I don't want to use this AI stuff. Let me go through my email and literally look at each email, right? That's what you'll end up doing. You just won't use AI for doing this. You'll end up doing— whereas AI would have been hypothetically perfect for doing this, right? Um, and so what we do is we say, AI first write a program. So AI first writes a program to say, go to the emails, fetch emails for last week. For each email, use AI to classify each email as whether it's important or not. So the AI writes a program and the program itself uses AI, right? And this system is kind of complicated to build and run, and it's hard to get it to work well. There's implementation complexity, but the idea is very simple. Instead of AI making the work for business-critical operations, we make the AI write a program to do the business-critical operation, and the program itself can use AI. So it's not like the program can only do, you know, structured computation. The program can also classify things for you or extract data for you. The program— you can, you can tell the program to go to all of your contracts and for all of the contracts, figure out how many people signed on for an annual contract versus a monthly contract. That's a great AI task.

Okay.

But instead of us trying to load everything into ChatGPT, we make O1 write a program to do this, to go to all the PDFs and to extract the right data, to aggregate that information, and then present it to you. And this API is what we call PromptQL. And this results in an amazing amount of accuracy and repeatability. Now you get the exact same answers all the time.

Yeah.

And the accuracy just goes through the roof, right? Because I mean, you can imagine executing a program is so much more accurate than executing like an AI task, right? Where it's a hope. And that's been a game changer, right? Like when we show that to our enterprise customers and we show that to our users, they're just like, 'Oh my God, it actually works.' Yeah, right? Like the magic that was promised is—

exists—

happening. It exists. It exists. It makes sense. So, uh, so, so that's kind of what we're saying. Does that, does that make sense?

It does.

It—

when you were giving that picture, I was thinking about my use cases. So how I use AI, I have agents which I can talk with, and behind it there's actually automation flows which which is made with Make.com or Zapier, you know, things like that. So you can sort of, you know, force AI to make API calls and get JSON back and understand that JSON and feed it back to you. But the fact that the business logic itself is in Zapier or, you know, or Make.com, which means you basically taking that business logic, which is always the same, It doesn't matter how many times you're running, it doesn't matter what data comes in or comes out, the business logic is always the same. So the program, as you have, you know, you put it, is something I do manually myself to set up my workflows. But I do have AI agent in front of it, so which allows me to, you know, query these workflows in a human way. For example, let's say I'm booking a, you know, a guest for the show. I'm offering 3 dates. I would open a chat and I would go like, you know, put these 3 dates, copy paste from an email and, you know, into my calendar and it does its thing and it comes back, hey Mike, it's all done and it's in my calendar. But the business logic was actual automation flow. So you, exactly from your perspective, you're just generating the program for that business logic. So it's always the same, it's always, you know, accurate and accurate. Yeah, that makes perfect sense.

And it's always explainable right now. You're not, because otherwise when AI does its work, it's not— you don't understand why it screwed up, right? Like suppose for example, yeah, exactly, connect ChatGPT into your calendar and to your guests' emails, right? And you said, hey, tell— get the information about the guests from the emails and create the right calendar events with the right descriptions, right? Like just do that work for me. It'll work. Sometimes it won't work. And when it doesn't work, you don't know what went wrong. Yeah, right. But, but, but when you write a program to go over each email, from the email extract the content, and then from the content go insert it into Calendar, you can see every step. And, and then you can ask the AI if it screws up. It's like, hey, why won't— why is this calendar event wrong? Like, why is— I can see that you created this event, but it's wrong. Why is it wrong? And then it'll tell you, I wasn't able to extract data from the third email.

Yeah.

Because that's the line that went wrong. And then you're like, okay, cool. Can you fix this line and add a check that in case the information is available in a different format and a different language, you do this, etc. So you update it. And now it gets better. Right? This ability of like creating a plan and following the plan and introspecting the plan, you don't get with AI today. It's a black box. Yeah. Which makes it really hard to trust in a business application, right? It's still okay for doing cute things, but like in an actual business application, if you don't have explainability and understanding, you, you can't make it work. And so, so, so I think that's the unlock. And I think like over the next few years, it's going to be super exciting as like, that's what I'm waiting for. I'm waiting for AI to become a regular part of our lives in everything that we do. Yeah, in actual workflows. That's what I want, right? And not just for doing my search and research, but it'd be amazing, right?

Like, it's like, it's going to be awesome. And I mean, it's going to be a proper sci-fi movie. And I think people underestimate how quickly that's going to happen. It's like if you're playing with the technologies and you use to enable yourself, enable your workflows and processes, you know, you already, you know, like 20 steps ahead of people who don't use it because it's just such a huge time saving. And then you have this gap. We just discussed where it's really difficult to, you know, apply it to all your business workflows because of that unpredictability and the fact that it just decides to do different things when you rerun it and you have the same prompt, the same data, and you just run it twice, 3 times, and you see totally different results. Well, not totally, but there's a, you know, there's this margin of error which happens all the time. So the moment we get that in shape, shape where it's predictably safe and it does the same thing as you expected, it's gonna be insane.

Yeah, it's gonna be mind-blowing. Yeah, it's gonna be mind-blowing. Like, that, that is like— and, and, and for me, like, to, to have the opportunity to personally, and for, uh, for, for the people that I work with, for all of us to be involved in helping make that future is too exciting. Right. It's amazing. It's like, yeah, let's make this happen. It can happen. There is a, there is a possibility that it happens. Of course, there's, of course, we can see that it's not happening. But, but everybody who's used AI knows that, man, if a few things got fixed, it would just work, right?

Like, I get you.

That would be, that'd be amazing.

So I'm sure you guys are going to be successful by the time, I mean, The PromptQL sounds excellent. You know, you definitely got your two fingers on the pulse. I'm sure you're going to iron out whatever the challenges you guys have, and it's just going to be an awesome product. Can I ask this? And just sort of going maybe into the fields of entrepreneurship. And so it's, we see it online all the time, you know, be your own boss, you know, escape the 7 to 5, you know, launch your own business. So it's very often, you know, romanticized, romanticized where it's, you know, it's romantic movie almost like everyone wants to do that, right? But what's the, what's the harsh reality from your perspective? Because you went from 3 people food delivery app to a billion dollar valuation company. It's like, what is the harsh reality over here?

Yeah, yeah. I think like, I think it's everything, everything is, everything is hard. Like everything in life is hard. And what makes entrepreneurship harder than other things is that we've not had practice at it. We've, we've, we've all grown up in, in, in systems and environments where the system and the environment was defined for us. So, so in that case, what, you know, finding a job and getting a promotion and working with other people, like the system is defined well, and we just have to navigate the system. You follow traffic rules and you drive and you follow the system. And then you're able to build that into muscle memory. And so something like driving, which is theoretically very hard, is now not actually really hard. Because you just, you're, you're, it's muscle memory, right? You follow the rules and you stop. Imagine if you didn't have any rules on the road, it'd be so hard to drive. Right. Um, and I think what makes entrepreneurship hard is that there are no rules. There is no system. There is, there is, there is no right. There is no wrong. Everything has to be figured out all the time again and again. Right. Um, and I think And I think that's what makes it hard. Um, then other things like it's kind of in similar ways to PhD, right? Like a PhD is hard. Not, not because, not because it's like, oh, the math is hard. The science is hard. Or what you're doing is hard. It's hard because you have to figure out a problem and a solution yourself. So it takes 5, 6, 7 years to figure out what's the problem I should solve. And and of the 50 different ways to solve it, which one is going to work? Right. It's this, it's kind of in a similar way, hard with entrepreneurship because there's no guide on people and fundraising and product development and hiring and scaling. And you know, when to call it quits and when to double down, right. And when to replace yourself and when to augment yourself and when to, have tough conversations with people and when to encourage them. Right. Like it's just, there's no rules. So, so I feel like my advice to people always is to say, if you're tempted by it, just try it.

Yeah.

Just try it. And within a year or two years, you will know whether it's for you, because some people really like the challenge of figuring it out on the fly. Um, but the things that you optimize for in life change, right? Like you cannot optimize for saying, uh, for having a lot of control on your schedule in a very different way. You cannot optimize for saying, I'm going to have good work-life balance separation. I'm going to have good, uh, I'm going to have these many holidays. I'm going to have these kinds of vacations. And I imagine that in some time I'm going to go live out of this place for some time. right? Like, uh, these, these are no longer kind of like the ways that you prioritize, right? That matrix changes. Like that kind of like lifestyle that you want to live is very easy to do and feasible, um, in kind of a 9-to-5 system, but it becomes harder as an entrepreneur because the variables are very different. Of course there's work-life balance, but the way that you think about work-life balance changes. Right? So yes, you are your own boss, you can take an off whenever you want, but like emotionally you won't be in a position to take that time off in a way. I get it, right? Like you will be putting in 16 hours a day because that's what you need to do sometimes, right?

Not all the time, but hopefully not all the time.

No, hopefully not all the time, right? And sometimes you have to do that in your 9-to-5 work too, right? Sometimes you just have tough days at work where you just need to work with your team and power through it. Um, but it's the ways that you prioritize. There's no system, there's no rules. Okay. Right. And that I think creates a challenge that is both fun, but also like a very harsh reality. Like you are responsible for a lot more, both to yourself and to the people around you. Um, and it takes a certain kind of mental, uh, framework to enjoy that. Right? That's, I think, the reality of it, right? And so my recommendation always is, if you're tempted, just do it. Like, just figure out a way to do it. And one way or the other, you'll know whether it's for you or not. Right? And you'll figure out maybe it's a timing thing, maybe I need more savings to do it. Maybe I want to be more of an expert, you'll figure it out. But give it a shot. Yeah. Don't, don't overthink it. Like, just do it and you know. Yeah. And then don't be afraid of what you find out, right? Like, it's okay. Maybe you find out that I love this, I want to spend more time. Maybe you find out, ah, not for me. Not for me.

I love that. That's definitely the harsh reality. I feel like, um, all of— a lot of techies, you know, they want to launch something, and when they start building, it's always like, you know, unicorns, you know, next Teslas or whatever. It's always like these, these big dreams. And in real terms, you know, it's going to take years. You're going to fail at least, you know, a couple, if not multiple times. Maybe you're never going to be something huge like billion valuation, but maybe you're going to create something which sustains your life and you're going to, you know, have 10 employees or whatnot. Really different journeys, but It definitely takes time. I think the harsh reality is that it's very, very unlikely that it's going to be anything less than 5 years before you have something really tangible.

Oh, for sure. At least, like, if you're thinking about, like, an outcome, like a, like an outcome, then, like, before 10, don't even think of anything less than 10 years. Yeah, like, like, uh, yeah. And, and, and, and I've been talking to people and it seems like in many different ways, especially with AI and whatnot, the horizon of the outcome is becoming— it's changing from pre-AI world to post-AI world, especially the change seems to become— it is already happening, but I think it's becoming more bimodal in the sense that it's becoming faster to build something that can scale pretty quickly in a short period of time. And so you kind of get to like, you you can get a pretty successful product that has good revenue, very healthy product, healthy business, but a smaller business, like, you know, maybe, maybe $100 to $500 million kind of valued business, meaning like $50 million revenue kind of business that you can scale up to, it kind of stops there. But, but building that kind of like $1 million to $50 million revenue business is kind of like, that's one side of it. and then it's a much longer time. And that period of time is actually increasing to get to a place where you're a billion-dollar revenue business, right? Where you're like, you're looking at like the, you're looking at like a $20, $30, $50 billion kind of valuation, right? Like those are becoming, that timeframe is actually increasing, right? You look at kind of a lot of successful products that you use and see today. Businesses that are doing well, they've actually taken a long time to build to get there. It's not happening, it's not like a quick thing. You can build a cool fun SaaS product that goes live and then you'll actually get a lot of revenue pretty quickly. Especially for example recently, a lot of tools that help you build software and applications quickly from AI, right? Like you can give it a prompt and it builds an app for you, you can give it a prompt and it builds like it writes some code for you, etc. Everything from IDEs to v0 and Bolt and stuff like that, they're doing really well. And it's awesome. And so, but those businesses laying the foundation for becoming $100, $500 million revenue businesses, that's a whole other journey. That journey is very hard, right? So exactly to your point, the outcome that you're thinking about that you want, you— I completely agree with you. I think it's not good to think about that outcome. I think it's not good to think about that outcome as like, oh, I'll, I'll, I'll, I'll be rich and I'll famous in like 3 years or something. Right. Like 10 years to any kind of outcome. And along the way you will figure out, I think, what kind of business is really emerging and is becoming, but, but you'll have to be honest to that business. It's really that market, that product. You have to be honest to that to see where it's going to go. Yeah, right.

So it is a journey. Like, you, you, you want to take your backpack and, and just be like, I'm going to be in this journey for a long time. I will enjoy it.

I'm going to enjoy this journey. I'm going to love doing this. I'm going to love the challenge. I'm going to love the people that I meet along the way. Yep. I'm going to love the challenge of building something. I'm going to love the challenge of growing something. Thing, right? And the day you get your first 100K in revenue to the day you get your first million in revenue to the day you get your first 10 million, 100 million revenue, they're all such amazing milestones. But every time you reach that milestone, it just feels like, oh yeah, it's done. What's next?

Yeah, exactly.

Because you're just enjoying the journey. You're like, there's no end, right? Like, yeah, sure. What's the billion-dollar value? It doesn't matter. Let's like, what's the $10 billion value? How do we get there? Right? Like, are we on track for that? Right? Like, that becomes the next thing. And if you enjoy that, then, then you love the entire journey. Right. But like, you should stay honest and true to that journey. It's not nothing in life is like a quick turnaround, right? Unless you hit the lottery, which is like, then you hit the lottery, right? Then you built something, you were at the right place at the right time in such a way that it was an instant exit. Maybe you get it, maybe you don't, but don't, don't try for that as the only thing. And you'll just be sad.

Yeah, I would say don't start thinking about the glorified end result of entrepreneurship, which is basically money and freedom. That's not a good thinking.

That you can get in a thousand other ways, right? In a thousand other ways that are more healthy for you, right? Like mentally, like you can get like a lot of financial freedom and personal freedom by doing a lot of things. You don't need to do this for doing that.

Exactly.

Right.

You mentioned timing to me, which sort of struck a chord for me because we had a couple of guests who actually chose timing as the one, the most important, and you can only choose sort of like one factor when it comes to tech growth, which was the timing. From your perspective, do you think, with Hasura and the successful pivots you guys made, was it timing? Like you were in the right place at the right time? Which had a big influence in your success, or you think it's actually not?

No, it's huge. It is the only factor. Like, timing is the only factor. And, but when we phrase it as timing, it sounds like luck, right? It sounds like something outside our control.

A little bit, yeah.

Right. So I find like the better way of phrasing it is to seek that timing.

Okay.

Right? Like, if you're continuously doing your market research, and that's what I meant by like the knowing how much to invest time in what, right? Do I invest more time in product development or sales or marketing? The answer to that question is a timing question.

Okay.

What is the market ready for right now? Right? To put yourself in a place where you can exploit timing. Right. So to be aware that there is a right time where things happen is very important. But there are ways to now absorb that into your planning and work process, right? So that you're not like beholden to that, right? It doesn't feel like a lottery ticket where, oh, they were at the right place at the right time. That's not— that's true. Obviously that's true. But that doesn't mean that they were not working hard to be at the right place at the right time. They did a lot of work to be at the right place at the right time. and then they knew enough about the market to discover that it's the right time, right? That's the critical part. It's like, how will you spot that the timing is right? You will only spot that the timing is right if you know enough about your market and your product to say, oh, this is the right timing to do this, which requires a lot of hard work to know that it's the right timing. So that— so I completely agree with folks, and I deeply believe in timing, right? Like, for example, right now, for us, right, with PromptQL, the timing is right for the mid-down motion, where people who are AI change agents and champions are thinking about rolling out AI inside their organizations. But the timing is wrong to build a business, I believe, on an AI on a framework to build AI software. The reason why the timing is wrong to build a framework and monetize a framework for AI software, building AI software, is because developers have— we don't know what the best AI products look like. Right. That hasn't existed yet. Like how in, in, when the internet came out, e-commerce existed and then everybody was like, oh dude, we need to be building e-commerce stuff. That's insane. So then we started building frameworks and infrastructure to support e-commerce. So the timing was right for that, right? iPhone came out, app stores were a hit, apps were a hit. The timing was right to build product analytics and app development stuff for that. Front-end software and TypeScript and browser-based thing was becoming rich. The timing was right for building front-end frameworks that you could build a business around. And that's always been hard. Everybody's always wanted to do it. And Vercel and business— some other businesses have cracked that finally. It's taken time, but man, that team is such a stellar team that spent so much time figuring out that this is the right time to monetize it this way. But they couldn't have done that 10, 20 years ago, right? Similarly, like today, I think like the first AI software don't exist yet, right? Like the the killer AI app beyond the ChatGPT and Claude doesn't actually exist, right? Yeah, it's not, it's not there yet. But once it's there, then the timing is suddenly right to say, we need to have like AI development frameworks that make that process easy. And then you can start to monetize that to roll that out to developers. Okay, right. So that's, that's what I mean by, that's what I mean by like, timing is important, but like, you need to be, understand your market and your product to exploit the timing.

Exactly. So you create the perfect timing by effectively doing proper market research and just understanding the common problem space or the biggest problem spaces. And then effectively you create a product when people are ready for the product. So the adoption is just simply there.

Exactly right. And the way that you do GTM for the product is different. Sometimes it's the same product, but it's a totally different motion. Right? Like, but you understand that by understanding your market, your users, the nature of your product, the impact that your product can have. If you understand that well, and you— and the only way of understanding that is not sitting down and doing research, right? It's like trying it out. You have to try a thousand things. You take your developers, and when you take it to developers, you realize, okay, this is why it's not working. Or you take it to the CIO, and then you're like, okay, this is why it's not working. I get it.

So we go back to the Facebook attitude of failing fast.

Exactly. That's why failing fast is such an important mantra because failing fast is the fastest way to get to right timing.

Yeah, that's true.

Because if you keep failing fast, failing fast, failing fast, eventually you get to a place where the timing is right.

Yeah.

That's why failing fast is the right, is like a really good mantra for products.

All right, excellent. So as Tamir has shown us today, success often comes from embracing challenges and pivoting when it matters most. His journey from a food delivery app to leading Hasura demonstrated the power of focusing on real problems, building innovative solutions, and staying community-driven. Talking about community, if people want to learn Hasura, try, you know, your magic formula, see how everything goes, where they can find you, Tamney, or more information about Hasura.

Yep. Head over to hasura.io. In particular, if you're exploring AI things, we'd love for you to head over to promptql.hasura.io or just Google for PromptQL. Hang out with us and experience kind of the magic that we're still in the process of building together. But if you're in the AI space and you take a look at PromptQL, your mind is gonna get blown. So check it out, join our community on Discord and just search for Hasura Discord. The right links will pop up and and we'll see you there. And that's the best place to learn from us and we learn from you.

Excellent. Or scroll down to the show notes. The links will be there for your easier find. And as well, I just realized that it would be so cool if you would make some type of button, you know, in that initial journey, which would be titled Make Magic.

Yep.

Just when you, you know, want to launch everything, you would just One button says make magic and everything happens.

Make magic.

Just a side note, if you guys enjoyed today's episode, as always, please leave us a review. We love that. Until the next time, stay safe and see you online.