Made in India: The Founders Behind the API Tools | apidays India 2026

All right, it is 5:45 on my clock. So, we will get started. I know it's pretty late, so I really appreciate all of you for staying back in spite of the wonderful Bangalore traffic. Right? But, I I feel like if you stay here, then you'll avoid the traffic. So, it's it's a win in that sense. Okay. This is one of the panels that I've been looking forward to host for many, many years because we've had such wonderful products built out of India, but not a lot globally talked about it. Maybe some companies, but not everyone. So, this is a great opportunity to not only celebrate what we've been able to do from India, but also kind of hear the backdrop story behind how did they go about? And if you know, any of you are planning to build your own product, then maybe you'll get some insights or some tidbits from the founders who have walked the path, so you don't make the same mistakes we did, right? So, with that, I would like to please invite all our panelists on the stage. Please welcome with the big round of applause. I'm not doing an intro right now, but we will do the intro. Yeah, just grab. All right. Some of them are also meeting for the first time. That's So, because I've not slept for two nights, so it's easier to put a slide and remember what what to ask so that I don't make a fool of myself. So what I would like to do is maybe starting with Neha in one quick sentence, if you can help us understand what annoyed you enough that you decided that you have to build a company to solve this problem. >> Sure. Am I audible? Yeah. Am I audible now? >> Yeah. >> Okay, perfect. Hi everybody. Thanks for your time today. Okay, very interesting question. You know, I have been working as an engineer as a product manager before Keploy. And you know, we saw a standard cycle that if even if you are shipping a small feature, you still have to go through a two weeks of test life cycle like give it to QA and it this is pre AI era time. And you know, if it is a back end change and you have to prepare the test environment and everything. It was similar for my team and we were really frustrated and even after spending those two weeks, we were shipping and deploying at 2:00 a.m. so that you know, there's low traffic and we were scared that something might broke. And you know, that was the frustration eventually when we thought of starting you know, new ideas of how do we test it, how do we bring the production like behavior locally and things like that and that's what eventually started. >> Cool. Awesome. How many can relate to this story? Surprising, very few people. You're not shipping software at all? If you're shipping software, this is a very common thing. You're up in 2:00 in the morning, 3:00 in the morning making sure you have minimum impact. Right? Uh Okay, we'll move to Anoop. >> Um hey everyone. Um so, I'm Anoop. I'm the uh founder and CEO of Bruno. Uh for me, this was in 2021. Uh I was looking for um an API client, which uh was just fairly very simple and straightforward. I just wanted something minimal. Um and the tools at the time, uh including Postman, uh Insomnia, and others, uh which did too much to my liking, and I just wanted something fairly straightforward, very simple. Uh that was one. And the other thing was um all of the tools at the time uh forced you to um kind of the model of collaboration was on cloud. The need for API collections, which is examples of how to use your API, if you wanted access to that, uh it you had to you it was a different paradigm. Uh my need was that if I come to your company, I clone your code base, I shouldn't ask someone where my API collections are. It should be in the code base. Uh that was a very uh personal thing that annoyed me a lot. And uh I built a product and a paradigm around it, and and that's how I started building Bruno. >> So, your collections belong to you locally in Git. >> Yeah, in Git, Git native. So, we pioneered that 4 years back. Today, everybody does it, but back then it was novel and unheard of. >> Cool. Ankit. >> Uh hey Naresh. Thank you very much for inviting, and hello everyone. So, uh my journey started in 2017, 2018 around. I was an engineering manager there uh for an email campaign builder, and then the deliverability things. And one of the new QA there ended up sending 10,000 emails. and then he being more creative also put a CEO's photo in that. So, that was a little disaster. Uh half of the emails were wrong. But some were valid. So, that time it make made me think that we need to control our dependencies. Can we actually simulate those dependencies and then have a end-to-end verification still at the contract level. Uh that's where the API virtualization thing that I started. >> So, no more emails to customers about like what you didn't intend unintended emails. But of course you guys do a lot more so we'll come to that in a minute. >> Yeah, that was the moment where uh being a engineering manager and responsibility that we need to contain this. How do we contain this? So, that's where the thought started and we actually built I myself built it uh very rudimentary in a Node.js uh simple email API which does a contract mocking exactly as it is. >> All of us have built our products over the weekend. One quick hack. How hard can this problem be? And then 5 years later, 10 years later. Abhijit? >> Yeah, wonderful to be here. I think for Postman around the 2012 time frame what we started observing was that APIs were a very prominent part of the language that developers were using, right? And all large companies agnostic of domain, industry, vertical, geography APIs were becoming the primary ingredient of development. Uh but we saw this big gap between tooling for other things versus tooling for APIs, right? We had tooling for code version control, you had like Confluence, Jira issue tracking, you had code review tools. But even though APIs were such a primary component tooling for that was essentially non-existent, right? Even in the largest software shops, you had people pasting codes into a Google Doc and sharing access, right? And we said there has to be a better way of doing this. Uh built on this assumption that APIs were going to become increasingly important, and I think that bedrock has carried forward until today. >> Absolutely, and I think you guys have kind of uh started that whole movement, I would say, to start with. So, thank you for that. >> No wonder. >> Cool. Um great to hear the stories like this live. I'm Peter. So, my story with Karate is starts in 2016. Um and the I'm a platform architect at Intuit, and my team was writing API tests. And they called me to investigate some problems that they were facing. In fact, the tests were flaky. They were sometimes passing, sometimes not passing, and all that. I think we've all been there. But there were many things I didn't like about what I saw in the tests. There were two things which I'll call out. One, um the whole logic was scattered across multiple files. This was like an in-house Java framework, you know, that teams tend to evolve over time, and then, you know, land into tech debt. And the other thing was um yeah, it was it was not readable. Okay? So, my ideal test is it should be like in one page, and then if you look at it, you should at least be able to see what the customer use case is. So, that was the origin. >> Cool. >> Uh thanks again, everyone, for sharing the interesting story of what annoyed you to start a company. Always interesting to hear the backdrop or the behind-the-curve story. Let's move to the next question, uh which as a founder, I think all of us have uh the sweet memory of the first paying customer. I think it's always special. I don't know if you guys believe that, but for me, having a first paying customer is uh such a confidence booster. Also kind of a reinforcement that yes, someone's actually willing to care what I'm doing. So, I would love to hear what is your first customer story, first paying customer. If you're not commercializing, that's fine, but what was your first customer story? And yeah, just give us a quick backdrop. I'll take that. So, >> This is also a good example of what open source does, right? You you put something out there and then it lands in some enterprise and you know, you get a invite. I basically got invited to SAP to give a tech talk and then you know, as Karate became you know, somewhat popular. But then once we I left my corporate day job and decided to go to the dark side of open source full-time. You know, we we reached out to all the users of Karate and this was one of the teams and they said, "Hey, we want to actually onboard 200 developers onto Karate and they specifically like the fact that Karate had a combination of both API testing and API performance testing including UI testing at that point. So yeah, very short story, but yes, very much a fond memory because of the very interesting connections I made that I never expected would happen. >> So, SAP was your first kind of a customer who invited you to come in. Okay, pretty cool. I didn't know that. >> So, I think for us small funny story. So, we monetized in late 2015. That's when we first launched our subscription product. But Postman as a product had been around since sometime in 2012. So, we actually had a user use Postman for like a year and a half and then they were like, "You don't have a paid product, so I'm just going to mail you a check." Out of the blue, you know, we hadn't spoken to them earlier. Uh, so I don't know whether you did call them a paying customer, but uh, that was a surprising moment for us. Um, but then I think we had around 400,000 users on our Chrome Web Store platform. Uh, and we said that we want to, you know, get into this API collaboration piece as like the core value prop of Postman. Uh, we ran a beta for about 6 months, took a lot of those users who were interested into that. Um, and I still remember I think October 2015 is when we had a small team of like three or four developers from somewhere in Spain. Uh, they were the first customers to to buy when we formally launched. So, uh, still remember that moment. >> So, you first had a customer who wanted to pay you a check, send you a check? >> Yeah. I mean, they they didn't know what they were paying for. They were just like, "We've been using Postman for a year, super useful. Here's a check." Right? And we were more than happy to accept that. Um, but yeah, I think uh, while I was preparing for this I think one happy memory is also that, you know, the first paying customer is still active. >> Wow. >> So, it's uh, I think it's obviously been a very exciting journey since then. >> Cool. Pretty nice. Ankit? >> So, uh, Be Scepter has been a side project kind of thing. That's how it has started. Uh, just a hobby project for me. And when I was solving this for one of my QA team member, I took three, four months to productize. I would not say productize MVP and put it on the website as a SaaS service with some limitations. Okay? Been there for a 6 months, a year. And then after that with a contact form. Okay? So, and someday after that, someone messaged on the contact form, "I want to use a higher limits. How can?" So, I said I thought of and then sent him a PayPal payment link of $10. That's it. And then unlocked him an the thing. And that was the first thing that that's how in 2019 it started. >> Cool. A $10 PayPal link. Nice. >> And and and I kept that $10 plan still today. No increase, no decrease, that is still staying there. >> Awesome. >> Uh I have two sweet memories uh from 2021. So I built up started building the project in 2021. Uh put it on Hacker News. Uh zero reactions, nothing, nobody cares. Continued building it for 2 years. Uh then one fine day in 2023 for some weird it just blew off. Uh like like vertical. Just just vertically blew off. >> Hockey stick growth. >> Uh yeah, just crazy. Hockey stick growth. Uh and uh so then I was like, "Okay, I'm going to quit my job." and I started a just incorporated a company formally. Uh we had three people. And uh then there was a Hacker News post after 2 years that went viral. And I had uh a small subscription plan and it was like 10 11 p.m. in India. And uh uh we had a PayPal integrated and my phone was buzzing with payments. Just just a stream of payments. Uh that's a very fond memory I carry. Um the second fond memory is Tesco. Uh they wanted to adopt Bruno and uh again in 2023 when the company was three people they wanted to do it for a thousand 2,000 people in their org and they wanted to use Bruno. And the director uh called me to Tesco. And he was like, "Uh we want to uh you know, pay you and use your product." Uh and I was like, "Uh sure." And one of their worry was we were just three people and we were going to just disappear or like would they didn't have any confidence. And that was very worrying and I went back and I was like, "Okay, guys, we are going to go to an office. We have to put a face that we are a big company. Uh so we did that. Um so yeah, Tesco was a big customer of very first big customer. And I a year back recently I asked them like, "Why did you guys trust us? Wasn't that not risky for you to trust three people?" And his response was uh yeah, it was risky. And I was like, "Okay, what was your backup plan? What if I had stopped the project?" And his plan was that he will hire me personally to the company to work on that project. That was the backup plan. >> That was his original plan. Talent acquisition. >> Perfect. Uh very nice. So our first paid customer was you know, somebody who actually pulled us back to the track of what we started for. Um so you know, we started in pre-GenAI era that, "Hey, let's capture real traffic and you know, help uh with the regression testing locally." And after two, three years uh of driving that open source and suddenly LLMs came in, started generating code. We were like, "How can we miss this? Maybe LLMs uh generating test cases and people believing in that is a future." And we started uh you know, building a product in parallel which was generating unit test cases, end-to-end test cases, mocks, and everything. And we were like so sure of let's let's go ahead. We were bullish on that. And we kind of paused what we begin began with. Um and then there is this one customer who came in via the open source route. And he was like, "Hey, you don't have a gRPC support. Um can I um you know, can can we partner? Do you sell this as an enterprise solution?" Until then we didn't. Um and we were like we don't really want to focus there uh because we picked up something else and we internally discussed and we were like, "Let's quote him something that, you know, he would not even pay for SmartBear or Tricentis or a big company." And we quoted him you know, a good amount um for for an yearly contract, we'll take up front and all that. And and we were like, "He will not definitely pay this and, you know, we can focus." But he he did and and you know, he said yes and um you know, we were like, "Okay, let's let's parallelly build this as well because uh somebody is kind of giving us revenue and is believing in this product." And I asked him uh later on why he did that. So, he was like "AI is generating code and everything is becoming non-deterministic. I wanted the you know, this is what I saw as a deterministic solution to uh replay and give me confidence. And and that pulled us back to that track eventually um and and saved the company." Yeah. >> I would say having a paying customer, like to your story, a lot of times actually helps you focus, sharpen your focus. Without that, you seem to kind of wander around a little bit. But like having a paying customer really gets you focused on what people are willing what they value, right? So, I think that's a very important thing. I also think to your story uh pricing is a perception game. Uh so, sometimes, you know, when you quote really high, they think it's high quality or high, you know, whatever great it must be great. So, I would not deny that. I think we've all experienced that pricing is a perception game in my opinion. >> true. That's true. I agree. >> Uh did uh so so, I know some of you started fully open source and are still open source at core, uh right? So, is Specmatic. And one of the challenges we had is when we were fully open source, we didn't have any commercialization. We would get a lot of emails saying, "Love your product, but what's your business model? Are you going to be around?" Uh, and if you say, "No, no, we we just open source." They wouldn't come. Uh, but the moment you have some kind of a pricing plan, even if it's GPT generated, you actually start seeing people paying, right? So, that's that that was for me like a very interesting uh, aha moment. I don't know if any of you had something similar. Yeah? So, people want some kind of, uh, you know, business or commercial angle to it, then they believe in your open source. Otherwise, it's difficult for them to believe. I don't know. Uh, curious to see, Peter, what was your experience? >> Yeah, that's that's No, that's right. We initially did experiment a little bit, but you're right. Um, I'm more of the tech side of the business. My co-founder actually handles a lot of the I know, decisions on that. And I was surprised by exactly this phenomenon. I had this very interesting perception of what pricing does for developer software. I'm a developer. I tend to write my own dev tools. I can't imagine paying for tools, you know, that kind of thing. >> Correct. >> it was a great learning for me. That's that's that's what I would say. Yeah. >> Absolutely. So, I want to add to that pricing thing because, uh, I moved from a contact form reach out to get an invoice and price to a dedicated pricing page with a subscribe right now. And that day changed everything. >> Yeah. >> That that removed the friction and then instant activation changed everything. Pricing page. >> Cool. Anup, do you want to add to that? >> Yeah. Uh, for me, uh, it it's one of the drastic changes that has happened in the last 5 years. Uh, being from India, we don't pay for dev tools. We just don't. And that sets our mind in a certain way that nobody's is to pay for it. Because you're an employee in a company as an engineer and you think that this won't work. Uh I had that delusion or like naivety. Um so asking for money for an open source project or building a business around it, you there's some sort of a guilt or something that's kind of like uh you go through uh where the counterintuitive reality is that anybody who wants to use your product uh would value it much much more if you are going to be around for the next 10 20 years. If you have a uh I'm going to adopt your tool, open source, free, whatever, but are you going to be around uh for 10 20 years? How are you going to be around if you're not going to build a you have a whatever model it is. But you need to have a monetization model and uh we also have this thing because in India we don't pay for it, uh we kind of have this perception. In Pruno's revenue, if I have to talk about it, uh any guesses how much revenue comes from India? I would say zero. Uh we have a very few customers coming from India. A lot of uh revenue comes from outside India that people pay for. Uh that's a bias that I would say people should be aware of in India. That people do pay for dev tools. We just don't, but people do and it's important to have that model so that you can continue to build what you want to build. >> But I think the important lesson there at least for me was business continuity, right? For customers is very important. They put lot more uh because so much effort goes in in terms of adoption of a tool, right? It's not like I simply plug and play. There's there's training the users, like getting the adoption, convincing people. So there's so much investment that goes in in consideration to that, the amount they actually pay you is very fractional. Like that's my experience. So to your point, you shouldn't have that guilt for asking. Yeah. Cool. I hope this is making sense for folks here. Yes? Cool. Let's move to the next question then. Which is uh I I find developers being a bit of unusual, highly demanding uh kind of persona, right? If there's even a little friction in doing something, they kind of tend to abandon your product, at least in my experience. In some cases, they may not, but there's that likelihood and the fear of developers kind of uh you know moving away from your product. Unlike a business product, where you know, generally even with friction, people continue, right? So, developers are highly opinionated, also highly capable. These days, especially with LLMs, everyone feels you know, I can build this in a in you know, overnight or whatever. So, my question is what is one counterintuitive lesson you have learned while designing a product for developers, right? Which kind of changed your perception or you know, whatever, lesson learned, basically. >> Um yeah, so uh with Bruno, we had two examples. Um so, um Bruno is an API client. You make an OAuth call. You have a call which uses OAuth 2 authentication. And uh there is, as you know, in OAuth 2, it's a multi-layered. There are number of calls that you have to do. So, in the initial product when I built it, uh I actually made that steps very uh detailed. Like, you have to do this API call, then this API call, then this API call. Uh whereas, it could have actually been done into a single API call. As a developer, I prefer to understand what those calls are, but I failed to realize that the customer does not care. They just want the call to work. They want to put their OAuth 2 credentials and you to do the magic. That was counterintuitive, and there was another feature in the product very similar where uh I was planning to remove a uh kind of a no-code utility. Instead of scripting, we had built a sort of a easy form to do it, and as a developer, I thought that well, I would just write a script for it. Who Why would I put it into a UI component? And the feedback on GitHub is that no, we really want that. Please don't take that feature away. And I was like, okay, like just calibrating that um sometimes people you want to design products keeping people in mind, and counterintuitive uh that a developer So, this is the opposite. I'm not answering your question the right way, but that's what I'm saying. >> great because as founders, sometimes you think all your users are like you, right? >> Yeah. >> But, they are not. >> You have to go through that journey. Yeah. That's quite Actually, it's quite uh hard because one of the things that makes founders special is you you go against the norm, uh against what the world tells you. They're all like you have to uh starting a company, starting a project, every time you have to go against it. So, you you have this feeling that you are always right, and that is what got you here in the first place. Now, the challenge is now you have to really open up, and uh let go of that ego. Uh that's a hard learning journey. >> Yeah. And a bit of lonely journey because sometimes not everyone is agreeing to what you're saying. >> Um so, for for us, um I and my co-founder Shubham, so both of us have been fairly technical, and have been hands-on uh even today when we're building features. Uh so, from from a developer perspective, we haven't really found instances where we've got a pushback on hey, not like this, but like this. Um but, where we have got a lot of feedback is um asking for new features and new different use cases in certain ways. Um, yeah, that has helped shape the product in certain ways where we could not even think that could be possible. Um, and counter-intuitive things that we have faced is being developers, we did not know how to sell. Um, and developers and engineering teams have told us, uh, you know, I've shown or I've come across um, certain ways that, you know, how how much security is important if you want to roll out, um, you know, if you are an open-source project, you might get into production as well, uh, without much hassle. Uh, things like that. So, there are certain jacks that people apply. Uh, yeah, things things around that. Moreover, towards sales and GTM and, you know, reaching out, uh, to enterprise buyers, uh, has been counter-intuitive for us from what we thought. >> Okay. Cool. >> Um, so, I think two related pieces that I can talk about, not sure how counter-intuitive they are, but um, I think one thing that we realized maybe a first few years into our journey is that, especially with developers, I think transparency matters a lot. Um, pre-commercialization, you know, since we had some Postman product out there, we had a GitHub issue tracker. And, uh, what we realized was the more transparent we are there, right, where we treat people who are reporting issues not as customers or users, but as partners who are trying to build towards the same shared common goal, uh, I think the more impact that we had, right. Uh, so much so that even to this day, we encourage all PMs, engineers, and all teams to be active on GitHub, uh, which is which is very different from the sort of conversation that you'll have on your incoming support tickets, right? So, there the conversation is business commercials. But, here it is developer to developer. This is the problem I have. Um, and people have also been very receptive to our arguments if we make our case well. Right? If we try to sort of explain our constraints, why we took certain product decisions. Uh, yes, I mean, as your user base grows, there'll always be a certain section which is not completely aligned. But, by and large we found that I think transparency really helps. Um, and I think as a uh, as an addition to that, um, feedback is often something that we tend to undervalue. Right? Like someone who's giving you detailed feedback, that is somebody who has tried out your product. They have an incentive to help you improve. Right? I mean, it's so much easier to just say, you know, this isn't working for me. I'll go somewhere else. But, for for whatever reason they're invested and they want to help you improve. So, I think uh, lack of engagement is is much much worse. Um, even even today, you know, any signs of churn that we have, right? It's almost always the case that there was lack of engagement as opposed to people who are highly engaged giving feedback. And in in most cases, if we are able to explain our reasoning for doing what we're doing, uh, that works out very very differently. Okay. Cool. >> Peter? >> Okay, yeah. This is a hard one, but I think you you talked about this, right? You kind of start out creating a tool thinking this is the best tool in the world, and everyone is going to see that it is the best tool in the world. That doesn't happen. And, um, like every developer has their own favorite language. Uh, you can't make something that solves like that fits everyone. You're not going to make something that everyone every developer is just going to like no matter what. That was the learning for me because in my kind of initial days of being so overly enthusiastic about an open source project, I thought, "Wow, everyone's going to be able to understand the greatness of this tool and how logical it is, and it's like a no-brainer to take." But no, the world doesn't work like that. There are so many reasons that people can use to, you know, say, "Hey, I'm not going to use this tool for my team." I And And there are so many interesting reasons, political You know, it's like developers have invested 3 years of their life learning some testing framework, and then how can I switch? Um so, yeah. I think all of you know this, but yeah, for me is some of these were very interesting lessons I had to learn along the way and adapt. And hopefully now I'm a little more older and wiser and so on. >> I think that when I remember trying to push Karate in a company, and I thought it's a no-brainer because, you know, you don't have to sit and write every time this code. Uh but there was a massive pushback because I've built this entire framework in Rest Assured, and that's my call you know, claim to fame, and now you're suddenly taking that away by giving this thing that does all of this without all the complexity that I've built. And so, that's a hard one to bite sometimes because you're like, "This is completely illogical." But so is the world sometimes. Ankit? >> Yeah. So, uh the friction is uh very real. Developers don't like friction at all. They don't like onboarding. They are They were in the problem space. That's where they look out for a solution, and they are now looking for a success, basically. Okay. So, for example, in B Sector, uh we have a zero friction policy kind of thing. I would not call it policy, it's our own thought process where the user or anyone comes to the website does not need to sign up. He He up for an endpoint, which his internal team is not able to provide him or he's not able to get an outside. So, that's where he came on the website and he gets it there without signing up. Okay, and then he triggers a call, one call, two call, three call, 50 calls. The moment uh we we push friction, but at a little later stage where he is becoming a regular customer or regular user. So, that's the thing. So, I think friction is they they love success immediately uh because they they are the I think higher intelligence order kind of uh we all are. So, uh that's where uh they they are looking forward to a success. One another example I have, which is slightly different where uh uh we try to be over I try to be over smart and then try to push one of the our product feature when someone was routing traffic to Engine X engine uh Engine X the local tunnel thing and then we try to push that why not use our own local tunnel. And the day we released it, the next day we got a message that you can't do this. We have our own reasons to use B Zepter to route traffic via Engine X to somewhere else and then we have to roll back that. So, so me pushing that my mindset does not work there. They have their own controlled reasons where they want to uh use it that way. >> Cool. Did any of you have experience where your customers complained that you're releasing too fast? Like that was to to me very counterintuitive. Like you would expect that, you know, I'm going to give you the latest greatest hot out of the oven straight and customers push back saying, "No, no, no. Slow down. Release once in a year, maybe once in 6 months, not you know, three times a day. That's just insane." And we were like, "You can pick whatever you like, right? You don't have to pick the latest greatest every time." But they're like, "No, no, it's too much cognitive overload to deal with what all has changed over the time." So, I don't know if any of you have experienced that like >> I don't know. My experience has been some customers just don't upgrade if it's working for them. So, I've had that experience a little more. In fact, it shocks me sometimes I'm they're using Karate version one or you know, some zero point something version. So, that's just my experience. Wanted to share. >> So, so as long as things are working because I worked in a customer success domain before this. Uh and uh one time one customer told me directly that whatever you release keep things should keep working. You go and upgrade, ensure that it's backward compatible. My workflows are not broken. So, as long as that is satisfied, I think customer should be okay. >> Uh that was the counterintuitive thing, right? Everything's fine, but we just don't want to upgrade. To to your point, right? Like sometimes someone's happy with the version, they just don't want anything more, right? I don't I don't want deal with anything more. Sorry, you wanted to jump. >> Yeah, I mean, this is happening majorly when we are dealing with enterprises um because they themselves are on code freeze and even if they want a feature or a fix, they cannot roll out. Um and and especially when uh you know, they are satisfied with a feature, and they're like I mean, I have had a chance where a customer was expecting a fix within the certain version that they were on. And I'm I'm like, "How how is that even possible?" >> Just log into SSH into their server, fix it. Simple, right? >> Yeah, so >> All right, let's uh move on. No panel is complete these days without AI. So, AI has to be everywhere. Right? Every uh is it fair to say every developer tool uh like all of you guys are being pushed to embrace AI and show that you are AI ready and you know everything about AI and it's going to solve world hunger, climate change, everything together. Uh so, I want to skip the optimistic pitch because I believe all of us are optimistic that AI uh has a lot of potential. We already seeing it in our own products. Uh but, what I want to look at uh in this next question is uh maybe share one aspect about AI that concerns you as a as a product builder, right? As someone who's envisioned and built something. Is there something about AI that concerns you? Right? There are a lot of positive things we can spend the rest of the evening talking about it, but I would love to hear is something concerning you about the way AI is happening and the way you are getting pushed to incorporate AI in your product. >> Uh >> Yes, uh so there are I think all of you know there are many of our users who are reaching out and they're very proud of the fact they have used cloud code or codex to write karate tests. It's kind of it works. Karate has been around for 10 years, so it's in the training data and all that, which is great for us. And um so, they're happily writing the test, but I think I if I just take this up one level, the big problem I think as I think a lot of you know already if you're just generating tests from your code, I I that's actually a big problem. You should be generating your tests from your intent. You know, not like cloud looking at your code and trying to, you know, create unit test kind of to code. By the way, you know, I'm I'm pretty much uh black box. Karate is all about testing your end-to-end functionality. It's not at a unit testing level. So, unit testing, it may work, you know, if you're doing uh you know, just self-creating tests. And I think um that aspect of AI nowadays starting to create tests, and they all run, and they are all green, that to me is dangerous, and I'm seeing a lot of enterprises kind of sliding, you know, without knowing it into that situation. >> Okay, interesting. Um I think one of the harder parts about this is that um we're at the intersection of multiple exponential curves, right? So, AI technology is obviously increasing or changing faster than what we've seen prior to that. But what that also means is that the number of people who are developers is changing fast. What they their expectations are changing fast as well because of all the AI tools that they're the they're using, both consumer and professional. Um and what that means is that, you know, it's hard to figure out what level to build for, right? Like you're you're assuming, you know, everyone has, "Okay, this is how AI is going to be in 6 months. This is what LLMs are going to improve to." But the space is so exponential that that's really hard to anticipate. And, you know, 1 year later, 2 might 2 years later, you might be really off. So, I think understanding what level you're building for, I think is the hard part. Um I think the the other area of uncertainty is that like every one of us has grown up largely in a non-AI world. So, all of your intuitions about the world and what software, what computing are based on that inherent paradigm, right? And LLMs change that fundamentally. Um so, what what we're seeing is that a lot of products, I'm sure, Postman included, in a lot of ways we are just, you know, building AI flows that make use of those faster, right? Like doing the same things, but doing them faster, which is not necessarily going to be what is sustainable long term. So, I think the amount of like fundamental unlearning that is required both from our side, our user side, I think that is the piece that is like very very new to all of us. >> But I think you touched upon a very interesting point is that with AI, the user persona is expanding quite significantly and I don't think we fully understand the user persona now. So, at least from my perspective as a product builder, we struggle a little bit because now there are I would say personas that we've actually never thought about or imagined and suddenly now you need to cater to them. So, that becomes quite challenging in my opinion. >> Yeah. I think one thing that will that this will also lead to is an increase in the um spectrum of users that that you need to cater to, right? You want to cater to users who will never see code in their lives, right? Who want to sort of build software because they can. You'd also cater to users who have been like working with code for 30 years. So, that spectrum of users that, you know, a product like Postman needs to solve for, that is, you know, vastly larger than what we've seen before. >> And agents, of course. >> Humans and agents. Ankit. >> So, so things have been moving a lot faster and since I become a founder and I started this journey, I started learning few new terms, which is like product market fit, okay? And then I'll I'll try to answer Abhijit I'll pick your point also and you're also product market fit is that when you have a 10 strangers or 50 strangers or 100 strangers, you decide a number who starts seeing the value and then paying for for the product. Now, what is happening with the AI is it's very easy to build. So, in my opinion, the half-life of PMF is reducing faster. So, if if I build a feature today in my product, and can it be copied easily? Yes. Can the copied by the competitor is the one thing. Uh uh self-developed because it's a dev tool, right? The the developers are we are selling to builders or building for builders, and they will build it themselves. So, any feature that I build today, uh I think in a 1 year down the line, it will have a lesser value because on one side, the models are becoming faster. The other side, everyone is building by themselves. So, there is a uh I I I at one moment, the cost to build is smaller uh near zero, but the shelf life of that feature is also reducing. Yeah? >> Uh for us at Bruno, uh we take a more pragmatic stance. Uh if you go to any website today, any company, you will see AI prefixed AI native automatically. Uh if you go to Bruno's website, you'll not see AI in the homepage. Not very very rarely. So, we very pragmatic when it comes to it. And we have a problem with AI at Bruno in the company. We give everybody cloud subscriptions, 15,000 20,000 rupees per month. We give it to them. But the slope and the uh the pace at which people can develop code is just like all in every team you have five developers, there is four engineers and one lead. These four engineers ship features. This lead is responsible for reviewing them. We still take the stance that you have to read and understand every line of code. Uh it's very counterintuitive. Uh it's a anti not a it's a different stance. But I believe that it's a slippery slope to a black box, where you just become prompt engineers and we are building a dev tool for and we want to maintain this dev tool for the next 5 10 years and more. And if you're writing code, it doesn't matter whether you pick it up from Stack Overflow, AI wrote it, we don't care. But if you open up pull requests and ask you to explain that line, you should be able to do that, explain what that line is. If not, you should not be working at the company. It's a very counterintuitive stance and that's our stance and we stand by that stance. >> I I I recently remember you fighting with someone, not fighting but responding to someone on LinkedIn about like, "Oh, no, I don't want Bruno to also have this AI thing." And you were trying to justify that. No, no, you can use it without AI or something like that. So, I think there's there's that pressure as well, I'm guessing, right? >> Okay, I have a completely different stance because we believe that none can stop exponential generation of code eventually and we should just push for it. You know, where we should focus more is verification of the behavior. But if I talk about you know, AI generating code, I have two stances there. One is um basically we are kind of coming to a plateau where all of the models are trained on decades of written code, human-written code, which was eventually world. And now the public code generated is majorly via AI and the future models are going to be trained on that. And eventually I believe we are going to be on a plateau and there are not going to be many technological significances um or improvements as per how people are not going deeply technical. And the second stance is around monoculture because let's take an example of a rubber tree. Almost every plant um on on Earth is the same species and which is efficiently great, but uh if I talk about a plug uh every every rubber tree is going to go down uh with the same plug. And I believe it's the same with AI code generation. Uh so much AI code is generated and it has the same similar blind spot not just in one repository, but across all repositories. Um and if there is a vulnerability uh discovered you know, uh eventually and people are going to improve that, but it's going to take that all down together. Um which I believe is another way to think about it. >> Okay, pretty cool. Um I I I wanted to add something, but I I just realized we are uh kind of running out of time. So, I'm going to skip the couple of questions and kind of jump to uh the last question to so we can just summarize. Uh I want each of you to basically complete the sentence for me. If you are building a developer tool from India, don't underestimate >> Okay, I'll go first. Uh so, one is definitely don't underestimate the uh power of community uh be it open source or otherwise if you can build that. Uh and being an Indian developer, I was very shy about uh reaching out to people you know, GTM and sales and all of that. So, uh yeah, I mean uh don't underestimate the power of how you can sell a simple product uh you know, to the heights of it. So, >> Okay. >> two things. Pretty cool. >> I'll go last. you. >> Skip. >> So, I would say go build it because uh >> Sorry, you don't >> Go build it. Why are you waiting? If you if if you if if you want to build it, go build it and then show it. Because traditionally we have been using someone else's software. Be it a curl or be it anyone else. We have not or and we are building software for someone else. So, developer tools are like like let me invest in my own productivity first. Okay. So, go and build it, solve that problem, and then work I mean invest in your productivity. This is the best time you can invest in your productivity. Whatever thought you have, go and ask LLM agents and build it and solve it. And then find the like-minded people who also wants to solve in the same way that you have solved it and that's where it will go popular and become successful. >> So, don't under-underestimate your desire to itch. >> Absolutely. >> Scratch your itch. >> Scratch your personal itch. >> I think I'd say don't underestimate the importance of the local developer community because I think the world is getting flatter than ever in terms of spread of tools, spread of spread of practices, how fast they spread, etc. So, uh when we started for example, there were some schools of thought that said, "Okay, dev practices start in in the valley, they move out from there." But I think now and especially with AI that is starting to change very very quickly, right? So, uh you get quality signals, quality feedback, quality usage all across the world. >> Cool. >> Yeah, so I was going to say that a startup in Bangalore, you don't need to be in HSR Road. You can do it from anywhere. You know, we are remote. Uh Uh but yeah, don't underestimate the value of the long game. It's a grind. Open source is very much thankless sometimes. You know, so yeah, it it takes time if you're expecting magical results like overnight. That's not going to happen and that's my advice. >> Cool. >> For me I'd say that don't underestimate the chance of luck. Every time somebody asks me how do I become successful? How do I build a successful open source project? The answer is I don't know. It just I just built it two years. It just went like so and don't underestimate the pain that you're going to be in for if you want to build a company. It's extremely painful. It's extremely chaotic. You cannot engineer viral moments. You cannot engineer success. You cannot. You just can try. And the only counter to that is your passion, your perseverance, your desire to build, your intensity to create. And hopefully that balances out and you come out successful. That would be my message. >> Okay, pretty cool. All right, I think we're out of time. So I want to thank everyone for joining us and especially I want to thank the panelists for sharing some of the backdrop, some of the interesting lessons they have learned and I think lot of pearls of wisdom here for other folks who are looking to build products, build your own company. So go get it, right? Thank you.