Accidentally Building a Y Combinator-backed Startup with Sachin Jain

Speaker A: Hey, everyone, I'm Andrea, uh, content marketer here at BareMetrics. And welcome to another episode of, uh, Founder Chats where our CEO Luke Marshall sits down with founders who are actively building the future of B2B SaaS. Today's guest completely breaks the startup playbook. Sachin Jain built Requestly with no landing page, no marketing budget, not even a domain name. He kept it open source while competitors copied his code. And in just three years he went from Adobe Engineer to Y Combinator founder to successful exit with browser Stack. The numbers are insane. He beat 17,000 YC applicants without a name brand degree or previous exits, grew to 300,000 developers using only Stack Overflow and GitHub. And when acquisition offers came in, he turned down, um, higher offers to choose the right buyer. This all started when Sachin spent eight hours debugging a Black Friday crisis, then built the solution in 30 minutes. That weekend hack became requesty. If you're tired of growth, hacking advice and wondering if building great products still works, this episode is your answer. Here's Luke Marshall with Satchin Jane, founder of Requestly.

Speaker B: Thank you, Sachin, for making some time today to come join us here from Requestly. For our founders out there, I have Sachin from Requestly joining the Bare Metrics founders chat podcast today. And Sachin has had quite a journey, uh, from his time in early software development at intern at intern at Google, I should say all the way through Adobe and then moving into building Requestly with which has now gone through an acquisition, is still a very successful tool available to you through as a Chrome extension on the web. So Sachin, thanks for joining us.

Speaker C: Yeah, thank you, Luke. Very excited to be here, mate.

Speaker B: Can you give us just a bit of background about how you came from being a software developer at Google as an intern and then sort of how you worked up to the point where you started to have this problem that made you want to found, uh, Requestly and move into that.

Speaker C: Yeah, I think, uh, as a part of my daily job, one day I was troubleshooting a tricky JavaScript error which was FOUC. So FOUC is flash of unstyled content. And I was troubleshooting an A B test campaign. The issue was the actual content was being rendered on the website and then the A B test campaign was applied, which was not expected, and customer had to go live with the A B test campaign the next day. It was a Black Friday sale and it had already been roughly seven to eight hours. Uh, since I was troubleshooting this issue and the problem was the JavaScript that was running in production was minified and I had no control over it. So it was hard for me to put logs, it was hard for me to put breakpoints. So that was a lot of uh, stress situation. It was a P0 issue and I had some prior Chrome Extension development experience. So I just got this idea that if I can spin up a Chrome extension that can help me Swap this production JavaScript with the JavaScript that's running on my local machine, that would provide me control back and then can help me troubleshoot this issue. So I took that risk and within the next 30 minutes I built a very hard coded Chrome extension with no UI, nothing, just two simple URLs and swap them using Chrome extension APIs. And it worked like magic. I got control over the JavaScript and now the JavaScript that is being served on the website was running from my local machine. So I was able to add logs, I was able to profile my code and I was able to add breakpoints. And believe me, within the next 30 minutes I was able to pinpoint what was happening. And then over the weekend I built the ui. I made this, uh, all the source, open Source, pushed on GitHub and launched on Chrome Store. So that was the v0 version of.

Speaker B: So this is, this is years before the current sort of AI accelerated development. And you went from pain idea to implementation in a, uh, weekend?

Speaker C: I guess, yes.

Speaker B: Was it easy? Because you had that very clear idea of sort of what the problem was like, that frustration you had and that time pressure you had, did it make it really clear exactly what you needed to build? It wasn't as if you were building this overinflated product. You had like a very specific pain you needed to solve at that time, right?

Speaker C: Yeah, I think that's a very fair point because I had this pain that I need control on top of this JavaScript. How can I do it? So that was the problem statement and I had Chrome Extension experience, so I just thought that can a Chrome extension help me solve this problem? So I quickly, uh, went to the Chrome extension documentation, figured out if there is an API to do this or not, to intercept the network request and modify them. And then I found the Chrome Web Request API, which was able to do it, took the sample code from the documentation page, uh, converted into a Chrome extension, and minded that it was not the first thing that came to my mind. I had already spent seven to eight hours troubleshooting this P0 issue. After that I thought about what are the other ways I can use uh, to solve this because the problem statement was very clear and that's why the solution was to the point, let's just swap the JavaScript.

Speaker B: Yeah, it makes sense. Yeah, I think that's sometimes a good thing for founders to consider. Right. Is that if you are very focused on solving a particular part of the problem with a skill set. Like you mentioned you had experience with uh, Chrome extensions. Being able to get something up as an MVP or in your case a production level app, uh, uh, quickly is actually pretty achievable. You went from so Requestly in its current form, you know, free open source and alternative to Postman. That's how we've marketed out there, the all in one platform, uh, to test and mock and intercept APIs. At what point firstly did you say that hey, there's other people that have this same problem Once you've launched it on GitHub or once you've made it open source, when did you sort of figure out that other people needed this as well?

Speaker C: So Requestly has its own journey or sort of series of pivots or series of messaging and positioning on the product. Initially I called it JavaScript redirector. Like very focused to the problem statement and uh, organically from uh, couple of answers on stack overflow and GitHub. And I saw the motion within my team as well within Adobe and uh, outside web developers, they discovered it organically. There was no promotion on YouTube and you will not believe that there was no landing page at all. There was no domain at all, nothing. Just a plain simple GitHub project published on GroomStore. And uh, people discovered it organically. So that was one sort of a happy moment that people need this problem. And second is people started asking for feature requests on GitHub. For example when you redirect JavaScript, uh, you get into a couple of issues like uh, course issues sometimes and sometimes you also get into this X Frame options issues because if it is happening uh, within the iframe and iframe. So people asked for a feature to modify headers as well. And then again over the weekend I quickly went to the Chrome extension documentation and figured out that which API can be used. Unfortunately the same API could be used which was Web Request API, which is like intercepting the network request in Chrome. And it was much faster than intercepting requests using a desktop application or using Proxy. Uh, so that became a very differentiation point in the initial uh, few days of Requestly because uh, you could have done this using bulky tools like bulbsuite or Charles Proxy as well. But having this within Chrome makes the entire web development fast. Uh, and you don't have to switch between multiple applications and it also writes context switching. And on top of it I made the interface like, very simple. You call it like rules. You configure a rule to redirect a JavaScript, you configure a rule to modify headers, and when your work is done you can just disable. So that was, I think those two to three points made Requestly stand out as a product initially. And then what happened was over time people also uh, like demanded features like I also want to override my API response. And then we build feature called uh, API mock or mocking API responses, which essentially uh, lets web developers build their front end. When Backend is not ready, you can just test different API responses against your front end. So again it provides a lot of control and it uh, sort of encapsulates your backend away. So as a front end developer you can think of it as like your application. Plus Requestly keeps your backend dependencies and backend complications away. Whatever you need from backend, you can just complete it from the requestly. So that at that point we started calling Requestly as sort of interception and mocking service.

Speaker B: Sure, got it. Yeah, I guess. Um, just back to the start of this piece. You mentioned no landing page, no domain, simple web extension. You had some organic interest straight away and you started to see downloads. This is the, this is kind of the story that founders want, right? You said you had a really good feeling moment where we saw people downloading it and asking on GitHub for additional requests. What made you stick with open source versus monetizing? You've got this amazing organic demand. Now you see a funnel starting to appear. What made you choose to keep it open source and free?

Speaker C: So when Requestly was published on GitHub, um, I did not have any sort of expectations or ambitions to make it huge. I just loved building the product. So I kept it open source. I also got few contributions from other developers and my um, initial instinct was to make it open source. And I kept it open source because a lot of developers were raising or using GitHub to raise their feature requests, sometimes contributing, sometimes not. So it became a platform where developers can go and ask for new features from me. Very cool. There came a point where I closed source Requestly for about a year. And the reason was I saw that in Chrome Store people were duplicating the products. Like for example, uh, people had like adblock, adblock ad blocker, which were pretty Much same source code, just a different skin on top of the uh, core of the product. So that one of my friends suggested that it could happen with requestly. People can just source code, copy the source code and publish it, uh, with a new name and new skin easily. And with that thought I made it uh, closed source for a brief time. But then I realized that if people do it, let them do it, uh, I want to go back to the open source again. So then uh, at some point again I made request to open source again.

Speaker B: Very good. Yeah, I know I've worked with companies in the past that have had a split between their open source and their commercial version that might have a few additional features or connectors, etc. And I've also known companies that have pulled back a lot of the open source features into the commercial. And you do get that feedback from the community. Right. And uh, I think you can go one of two ways. You can either have active contributions in that community that want to continue to see the product evolve through again, open source contribution, or those that just saw it as free. Right. And as soon as you put a price tag on it it's like, well, it's not free anymore. They might not have been contributing to the code, but now that they're, now that you're asking for monetization, it's tough to justify for them.

Speaker C: That's a fair point. In fact, we have also followed an open cool model in Requestly. And uh, we have studied the open source model from giants like GitLab, um, Posthub, Supabase. I believe each of these companies is a very good company and they're also making money. So one thing that we realized is we want to keep a uh, gate where we provide all the features to individuals in free, but as soon as they need a feature like team collaboration where basically team gets involved, or enterprise features like SSO or audit logs, those we kept in the enterprise layer or the sort of uh, behind the gates.

Speaker B: Yeah. And that makes a lot of sense. Right. And that's, that's probably great advice for founders out there that are struggling to figure out do I give my, give away my product for open source, uh, or do I monetize it? What component of it? Like you say a lot of the time open source platforms that scale with usage come to a point where they need support of the founding team and you can monetize, monetize your services or custom builds for the post that point in time. Right. So um, that's a really great point and that's A question we've had, I've had often from founders where they're trying to gain early traction in product adoption and product market fit and they think that open source is the way to go and they're happy with that. Uh, but then it comes to the point, well, hey, we've got to pay our bills, we've got to make money here. So I think that's a really, really intelligent, uh, way to do it is to, to get to the point where enterprise feature requests or enterprise deployments require additional service support and builds. Right. Moving back to the start of your journey again, uh, you went through, uh, YC in 2022, I believe, um, 17,000 applications, only 414 were accepted. One of those applications was yours that was accepted. Uh, you've mentioned before in your application discovered the problem space and the market size while it was still your side project. Do you have any advice for founders that are looking to go through somewhere like a Y Combinator and how you actually built that application to be, um, so impactful and get that application through?

Speaker C: Yeah, I think that's a very good question. And there's a lot of public advice available on like, how to build a good Y combinator application. But I can tell you, like, what we did differently or what our application had that maybe, uh, stood out. So I think YC is also an investor and every investor looks for some signals before investing. Like signals like it should be a big market. Signals like maybe a good founding team signals like strong product or signals like strong traction. Something has to be there in your application. And you can see a lot of applications, uh, get accepted when you have, and you don't have any product when you're pre revenue. These applications are accepted based on the strong founding day, like graduates from Stanford, Harvard, or maybe they have done something in the past that repeat founders. In our application, uh, one thing which I think was crucial was we had the product and we had thousands of developers using the product. We had very good ratings on Chrome Store. And when we applied to yc, we also had some revenue, like a little bit revenue, um, because that was the thing, that was the time when we just started. And one more thing which was that we had this insight because we solved this problem for ourselves. So we understood what problem that we are solving. Otherwise sometimes what happens is that a lot of people start building products, uh, without having the deep insight into what they are building. Yeah, in our case, because we solved the problem for ourselves first and then we were scaling so we had this really good understanding of the problem statement in the market space and how to promote it because we already had got uh, thousands of developers using the product without any, uh, sort of dollar spent. So those things, I think those signals were good signals for YC to consider our application.

Speaker B: Yeah, that makes a lot of sense. I really like how you differentiate. So you didn't necessarily have a well known founders team or someone who'd done it in the past, but what you did have was early traction, uh, uh, an emerging user base or a growing user base and a growing user base of very valid users. Right. Being developers. Uh, and you had what I would think of as a constant feedback cycle. Right. Those developers that are using it are building it, are giving you feedback on how to build it better and they're taking it back to their enterprise teams which then gives you the keys to monetize. So I imagine all of those combined attributes for a YC, uh, application is certainly very strong. So yeah, yeah, really great, really great to hear. And that's an amazing and well done on going through that process. I know a lot of founders get discouraged at the start of that process or they feel like they're, you know, don't have what it's worth. But um, you guys obviously nailed that as well. And the piece about, you know, you knew your problem and your market size as well, you knew that this problem was out there that people hadn't had a good solution for and you were building for that. So that's great. Um, how do you manage that developer community? So you know, like you mentioned, you've got, I think it's like 1200 reviews on your Chrome store. You're at a 4.3 rating, like excellent for any sort of Chrome extension tool out there. How do you develop that, commute that developer community to continue to build such a good product? Uh, continually.

Speaker C: I think if you analyze about Chrome Store use, a couple of things stand out. One is, in fact we did this analysis recently. One is the product feels really simple to use, like simple and easy to use. Second is excellent customer support. Right. And when we did this analysis I think a few years back and when we did this analysis recently, both of these things still stood out in almost all the reviews. So we also translated these values into our company culture values. Be simple when we say things simple, be simple is whenever we are trying to solve a problem or build a feature, it should be very intuitive to understand. It should be very intuitive to use. We don't need to explain through documentation, although we still have documentation. We still have YouTube videos, but within the product, it should feel simple to use. We cut corners wherever things get complex. Even though, like people might come and say, no, I need this additional feature, etc. So we think about how can we keep things simple. Like that's a constant, uh, feedback that goes within my team and to me as well. Like, how can we still say simple? That we are simple. Right. Second is best customer support. So we don't differentiate between whether a user, uh, is paying user, free user, or it's from a like high, uh, maybe, you know, good paying company. We provide the best customer support to all the people and also have been the cases that when I directly go to the people to solve their problems, sometimes they have configured requestly incorrectly. Sometimes it's a very niche use case that potentially could not be solved with requestly. So there are so many cases that we come across, but we try to provide our best foot forward to support the developers within the, to solve their problems. I think considering these two things, uh, that people really consider us. And then the third thing is we talk about brand. So within the team, we believe that we want to build a brand where people not only love our product, but they also love us. They would like to stand behind us whenever we make a big decision or whenever maybe things go a little bit south. So considering this, when we think about, you know, building such kind of brand, customer support, uh, becomes the first step that you take to build such a brand. Yeah.

Speaker B: So a couple of really good points there. And I think this is the one I love, I love first thing that you said that the fundamentals of your product are built into the cultural tenets of your company as well. I think that's really important. Um, and that whole idea of simplicity and what you've done, something that stands out to me there is when, when, when we do as SAS companies, we might do customer interviews or uh, you know, quarterly business reviews with our clients. And we often ask them, you know, uh, what, what can I do better? Right? What, what don't I have in the platform so you can build your roadmap, sometimes it's just as valuable to say, you know, what are we doing good? And if they say to you, I, um, love how simple it is and your customer support is awesome. So you do more of the good, right? You don't try and build, maybe you don't try and build out what you don't have, you actually look at it and say, well, of those 1200 reviews, 80% of them called out our great, um, customer support and the simple use. So let's use that as the foundation for everything we do moving forward. I'm a big fan of that and I think that's something that founders could definitely take away. We often get wrapped up in the idea of building a product roadmap for these future feature requests, but sometimes what we're doing well is just that's what we need to be doing more of. So ask your clients, what is it that we're doing well? How can we continue to do more of that? Um, really great to hear. Yeah, I really love that idea there. And obviously taking on that feedback and continually working with them. I think you raised a really good point too. You said before how a lot of people were pulling your open source out and building competitors or building clones and doing other things like that. If you have a defendable point of difference like your support, then that's, that's your competitive advantage, right?

Speaker C: Yes.

Speaker B: Those people may be spinning up something really quickly as a skeleton product, but if they're not putting the time and effort into support, which is what your users want based on the reviews, they're not going to last. Right. They're not going to stick around. So, um, I think that's also part of that reason why you may still be comfortable being open source is because the two components of your differentiation, great customer support, simple design and use is what sets you apart. Would you agree?

Speaker C: Yes.

Speaker B: Yeah, I think that's, I think that's really evident from what we've talked about there. For sure. Um, moving on mate, I'd love to talk about the move through the acquisition. So you've had a great startup journey. You've done the effort of finding a problem, solving it, you've launched, gain momentum, you've gone through Y Combinator, you now have this potential acquisition from Browser Stack. Um, how did that come about and how did you go through that process with them?

Speaker C: So I think first of all acquisition is very contextual and you have to evaluate a lot of variables when to consider acquisition or not. And it is a double edged sword. One is uh, like you could always be thinking that we can make it ourselves big versus you can also think about uh, maybe a win, win situation for everyone. And in our case, uh, I had already connected to one of the browser stack founders and he reached out to me to maybe just have a chat and uh, it was a very informal conversation. Uh, and he basically wanted to understand what we offer in the product. And back then we only offered API mocking basically. There's a whole lot of journey on how we went from Interception and mocking to just API mocking and then evolved to API mocking and testing and eventually became a postman competitor. And browserstack offers testing infrastructure basically, uh, like manual testing, automation testing for web applications, mobile applications and requesty offered API marking. So there was very good fit because mocking is also required in development and testing. Testing as well. And we had plans to go into the testing space as well. API testing as well, which was interesting for browser Stack and it was interesting for us because the partnership made sense. Browser stack is a leader in the browser space and mobile space and requestly being the very good product as an in browser API, uh, mocking and testing solution. And considering the basically win win situation for the investors, employees and eventually founders, the acquisition made sense. One thing that I maybe would like to put across is a lot of people consider acquisition in a very structured manner. Basically they shop, they talk to different potential buyers, they get multiple offers on the table and then they evaluate the best often which is good, which is great. The only thing uh, I would like to add on top of it is make sure that the buyer that you choose is optimized towards your uh, product and company as well. And just don't optimize on the price. What I mean to say is that if you just optimize on the price, you could see potential alignment issues in the future. So rather align on the, optimize on the right buyer than the right price.

Speaker B: Yeah, I think, I think. And that's particularly important when you're going to stay on. Right. When you're staying on with that acquisition team and you're moving into a bigger organization, then if your interests aren't aligned, then you'll fall apart quite quickly. Uh, yes, and I, I give that advice to founders when they're asking me about either raising capital or moving into a majority. If they, if they're being a majority acquisition, you either need to be comfortable that the acquirers will come in and change things because they're trying to get you to that next level of growth that you haven't got experience with, um, they will have networks and methods that you haven't been exposed to, which might be uncomfortable. So you need to be comfortable with that. But if you have that sense of ownership and that sense of strategic direction and conviction that how we're traveling at the moment is the way we need to continue to travel, then you're absolutely right. The buyer, you need to have a bot, you need to have a say in that buyer's, you know, direction, um, and how you continue to run the company. So I think that's a really interesting point and great to hear you were able to find the right buyer. Um, I can imagine that you weren't necessarily. Like you said, it was a casual conversation to start with. You sort of started to look under the hood. You came to a mutually agreeable sort of future for the company and it turned out great for you guys. Now I know it's only, I think it was May this year correct that you went through that process. So still early days. But how have you found it post acquisition? Do you still feel like you've got, you know, good control and um, direction over the company?

Speaker C: Yes, I think Browser Stack is a very good organization and both the founders are still deeply involved in uh, basically learning different functions. And this has helped us a lot because when founders are deeply involved it's easier to build alignment on how you want to run the product and the product vision because they're able to understand how you want to run this. And they were pretty excited when they made the acquisition. We were pretty excited to join the organization. Uh, so we basically uh, aligned on how we want to run Requestly, what should be the vision. So our entire team moved and became a part of Browser Stack. Uh, Requestly is running fairly independently within Browser Stack and growing independently. And uh, eventually we want to uh, basically get into a lot of developer market share and help BrowserStack move from or captured develop our market as well with the help of Requestly. So that's the vision with uh, Requestly and uh, and they are letting me run this independently because they believe that uh, I have taken requestly from 0 to 300k developers so far. So maybe we can take it to 2 million as well.

Speaker B: You've got the runs on the board for sure. Yeah, you've absolutely got that traction there and that momentum. That's great to hear. Uh, Sachin, for our founders out there, like I said, you've essentially had the, the typical golden journey from SAS or I'd say SaaS. But browser extension or not, it's still software, it still works as a SaaS. Uh, SaaS founder, uh, experiencing the problem, building the product Y combinator through to acquisition throughout that journey. What are some things that maybe surprised you or stood out to you as you were going through that? Like not, not all of it was deliberate. Right. Some of it was just through hard work and perspiration. But um, what are some things that stood out to you over the last few years?

Speaker C: I think one of the things is uh, that you realize that in a startup journey is very important. And as your company grows, you also grow together. Your network grows, your social capital grows. And it is very important to learn different skills that you have not learned before, like, for example, uh, like raising funds. So it is a very different skill set that you learn as part of your company building journey. You learn about building connections. Maybe as a founder, you are shy, you don't talk to a lot of people, you are quite nerdy engineer who is very good at building products. But then as a part of the company building, you'll have to learn these things. You'll have to learn to manage people. You have to learn time because there are so many things going on. Uh, you have to prioritize, so you learn prioritization. So as an individual, you learn a lot when you build a company. That's one thing that like really surprised me, how much I have learned over the last three, four years, which probably I haven't learned over the last, uh, eight, ten years before that. Second thing is how different founders operate their company, uh, their leadership styles. You also observe that and how important is to build a company M culture. Uh, for example, when we went into Y Combinator, we had an orientation session and in the orientation session, uh, we got the YC values. And one of the YC cultural values that stood out is, uh, helping each other. Helping each other, which is essentially pay, uh, it forward. And that has really, uh, stuck with me. So whenever a founder reaches out to me for some help, and if that help is in my capacity, I definitely do that. Similarly, uh, from the acquisition experience, I think one thing that has learned that I've also spoken recently is optimize for the right buyer than the price. And honestly, we are pretty happy with that decision.

Speaker B: Yeah, that's awesome. They're really good points there. Yeah, I think the learning piece is a really big part of it. Uh, a lot of my content I've spoken about recently is when does a founder become a CEO or when does a founder become an executive? And it's like, maybe you don't necessarily have a point in time where your label changes and you become the CEO, but that course of development where you figure out, okay, now I've hired a team, so therefore I need to figure out how to manage them. Um, I'm no longer the only developer, so I need to know how to manage my time effectively to manage the developers. And then you're right, those strategic level discussions around acquisition, buyers, network, etc. That YC cultural tenant really stands out to me as well. I, I was fortunate enough to attend, uh, a course at Harvard Business School. And I went over there for, uh, a couple of months, uh, as an intensive executive training program. And at the end of it, in the very last couple of days, we had a, a brief by one of the heads and they said, do you think an education at Harvard Business School is an asset or a liability? And we're kind of all like, you know, where's this going? And they said, well, in accounting terms, it becomes a liability because it's something to be paid forward, uh, in the future. Right. And it really, it's the same thing. It struck me that I, I have had this opportunity to be a part of this, this, uh, this, this institution, and I've got all this knowledge now to go forward. Um, it is now my liability to go out there and help others that may not have access to that same experience, the same education, et cetera. Um, so I really appreciate that, Satch, and I agree with that sentiment completely. And I really love having the opportunity to talk to other founders, uh, to, uh, emerging CEOs, executives in this space and just, you know, collaborate on things and share ideas. Um, and like you say, you pick up things from other founders, other leaders that you might want to do more of and you might see things that you don't want to do, um, way they're running their companies as well. So, yeah, really, really resonant points there. Um, Sachin, absolutely appreciate that, for sure. Um, mate, we're about on time here and I, I. All of your answers today have been really, really great, really detailed, really on song. And I think you've offered a lot of value to other founders and particularly the, the short period of time you've been able to achieve this. Like you said, the transformation you've gone through since, you know, y combinator was 22. We're ending at the end of 2025 now. Um, that's quite a, quite an intense period to go from, um, simple web tool through to acquisition. So great to hear how you've been able to develop and handle that over time. Mate, do you have any questions for me, um, that you'd want to talk on in particular?

Speaker C: I think I'm good. Thank, uh, you, Luke. I'm really excited to be here and I hope that this conversation helps a lot of founders who watch your podcast.

Speaker B: Yeah, absolutely, I think it will. Um, we'll pull some of the snippets out of here that you've given us there, and m. I'll talk about a bit more on LinkedIn, but I think you've had some great points and I really appreciate your journey and uh, really respect, respect your growth as an individual from developing an open source tool through to acquisition. Like I said, there's a lot of things that have gone on in the last few years and I imagine it's been a bit of a whirlwind. But, um, great to hear your advice and thank you so much for taking the time to join us today. Um, we'll be in touch soon and hopefully, uh, we can talk again.

Speaker C: Yeah. Thank you, Luke. And thank you for building Bare Metrics. It has helped us a lot.

Speaker B: No worries. Thank you, Sachin. Cheers.