Sagar Batchu was born in Sacramento, but moved to Bangalore after a decade. He has always been interested in how things work, and majored in Physic at his University. Towards the end of his studies, he crammed in a ton of CS classes and fell in love with the craft. He's worked on firmware, enterprise software, and eventually went to LiveRamp, building new experiences for them. Outside of tech, he loves pickleball, enjoys growing coffee and loves readying about historical events.In his past, Sagar and his team took on API initiative to invest in internal API experience. Through this project, he spent a lot of time thinking about how to make this happen. He immediately saw the need across the industry, with the absence of time and money to fill the need. He decided to take it on and start a company.This is the creation story of Speakeasy.SponsorsSpeakeasyLinkshttps://www.speakeasy.com/https://www.linkedin.com/in/sagar-batchu-981b3738/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
A lot of our customers were spending a lot of time, a lot of support time onboarding users onto the API. Like the table stakes for what they were providing the users was just the classic three pane documentation site. Now this is the classic left-hand view, middle view, right-hand view you've probably seen for a lot of API docs. And that just wasn't enough.
That, to me, felt like the lazy thing to do, throw up a Swagger doc site and send it to your customers. We actually started to innovate around a set of React and developer portal components that would allow you to stitch together a really interactive and guided onboarding experience. My name's Sagar. I'm CEO and co-founder of Speakeasy.
This is CodeStory. A podcast bringing you interviews with tech visionaries. Six months moonlighting. Who share what it takes to change an industry. Who built the teams that have their back. Keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as a group. Total waste of time. The stories you don't read in the headlines. It's not an easy thing to achieve.
Took it off the shelf and dusted it off and tried to begin. To ride the ups and downs of the startup life. You need to really want it. It's not just about technology. All this and more on CodeStory. I'm your host, Noah Labhart, and today, how Sagar Bhatiu is making crafting API experiences a cinch, where every API is up-to-date, making integration easy. This episode is sponsored by Speakeasy.
Grow your API user adoption and improve engineering velocity with friction-free integration experiences. With Speakeasy's platform, you can now automatically generate SDKs in 10 languages and Terraform providers in minutes. Visit speakeasy.com slash codestory and generate your first SDK for free. This message is sponsored by QA Wolf.
QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes. With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Grotta, and Autotrader, you're in good hands. Join the Wolfpack at QAwolf.com. Sagar Bachu was born in Sacramento, but moved to Bangalore after a decade.
He has always been interested in how things work and majored in physics at his university. Towards the end of his studies, he crammed in a ton of computer science classes and fell in love with the craft. He's worked on firmware, enterprise software, and eventually went to LiveRamp, building new experiences for them.
But outside of tech, he loves pickleball, enjoys growing coffee, and loves reading about historical events. In the past, Sagar and his team took on an API initiative to invest in internal API development experience. Through this project, he spent a lot of time thinking about how to make this happen.
He immediately saw the need across the industry with the absence of time and money to fill the need. He decided to take it on and start a company. This is the creation story of Speakeasy.
Speakeasy is a platform that really helps you take your API to market. It helps you distribute your API to your customers, give them all of the tools they need to have an amazing onboarding experience and also long-term usage. So I really got into this when I was working at LiveRAM.
We were a really big ETL product, and transforming from an ETL product into an API product was this big initiative that happened. And doing that's really hard, like running APIs at scale for a company that had many hundreds of millions of ARR running through it, many dozens of high-value customers, billions of requests a second.
It was a really gargantuan task that the engineering team at the company undertook. And as part of that, we built this fantastic API platform initiative. And at its core, the purpose of this initiative was to provide all developers of the company a consistent way to develop and ship APIs.
So investing in our internal developer experience was the way that we decided we were going to make sure our customers had a great developer experience. Through that whole initiative, I ended up spending a lot of time on it, thinking about all the tools and building the tools that we needed to actually make that happen.
So this was everything from a DSL that we use internally to define and build APIs, infrastructure components like sidecars for authentication, a lot of tools to actually make the development and deployment of the APIs easy for every developer at the company.
When I left LiveRamp, I realized that this was a pattern that was happening across the industry at any company of scale, and even small startups. But the truth is not every company has the enduring time, talent, the kind of willpower to actually invest in great APIs. But not investing in great APIs means that you're really restricting your customers from getting the best of you.
I started to dabble in that. and really talk to users, work with developers in the space, it all started to revolve around OpenAPI, which is this kind of core description language for REST APIs. So that's where Speakeasy started. And through that process of iteration, we've now gotten to where we are, which is this growing platform of tools that help companies build and ship great APIs.
Tell me about the MVP. And this will be interesting to know where you start. Maybe it's a little bit, you know, in when you were spending that time and thought prior to starting Speakeasy or it could be started at the Speakeasy point. You tell me about the MVP, that first version of the product you built, how long it took to build and what sort of tools were you using to bring it to life?
You're absolutely right. When we started, one of the core problems that we were working with was this idea that a lot of our customers were spending a lot of time, a lot of support time onboarding users onto the API. Like the table stakes for what they were providing the users was just the classic three pane documentation site.
Now, this is the classic left hand view, middle view, right hand view you've probably seen for a lot of API docs. And that just wasn't enough. That, to me, felt like the lazy thing to do, throw up a Swagger doc site and send it to your customer.
We actually started to innovate around a set of React and developer portal components that would allow you to stitch together a really interactive and guided onboarding experience.
So you can, if any of you have used like the Stripe API or GitHub's API or some of the other great APIs out there, you'll see that as part of that first step of onboarding you to the API, they have a beautiful portal where you can immediately get your API key. You can understand your usage. You can basically walk through all the elements of the API in a very guided and beautiful UX.
So that was our first product. That was really, we really focused on that API onboarding story. We ended up actually pivoting away from that because we realized to really scale that product, you had to catch companies at the right time. Literally, you had to catch them that week that they were going to launch the API, which is a really tough kind of go-to-market problem to work with.
So I don't think it was the wrong product, but I think it was the wrong phasing. And so we decided to focus on something that every API out there could benefit from today. And we landed on SDKs as this really important part of the developer journey that most APIs miss.
Let's stay on that for a minute. And you're kind of touching on some of these at a high level, but tell me about some of the decisions and trade-offs you had to make in those early days with that MVP. And it could be technical debt or feature approach, things like that. Dive into some of those and specifically how you coped with them.
The trade-offs we made were twofold. One of the biggest trade-offs is early on, you're trying to get momentum and velocity for yourself in any way possible. You need to find ways to just have a lot of really activity around your product every day. So you start learning about what users are doing.
So early on, we decided that we were actually going to build it in such a way that the product was self-hostable. In retrospect, that was actually a mistake. I think it wasn't the best decision at the time. Doing that, we incurred a lot more technical debt and we incurred a lot more really just things to do to make the product self-hostable from day one.
I don't think we really optimized for getting it out to as many customers as possible. And so I think that was a pretty hard learning for us was that early on, we really had to optimize for getting it out into the hands of as many customers as quickly as possible. And that's one thing I think most founders will tell you that early on, you're just optimizing for user growth, velocity and feedback.
So I think that was one trade-off and another one for us. I think another really important learning was that when you're shipping something to your customers, that their end users are going to actually use, you need to really focus on design and design engineering. And this is, again, something that I think we didn't spend enough time on at the time was,
Even though we were making portal components that you could theme yourself, it's really important to give users the right hooks into these JS components so they can actually theme it. And we didn't actually spend enough time figuring that out. We ended up, again, having to spend a lot of time with each customer, helping them theme and build these portals for their APIs.
So those are two learnings that we had. I think the takeaway for me there was really optimizing for tech stack internally that allows for onboarding as many customers as possible with as little support. And then the second one, making sure we identified like which features were the kind of killer features for a customer.
When you're going to put out a UI to your customers, like you really care about design and quality.
This episode is sponsored by Speakeasy. Whether you're growing the user adoption of your public API or streamlining internal development, SDKs can turn the chore of API integration into effortless implementation. Unburden your API users from guessing their way around your API while keeping your team focused on your product.
Shorten the time to live integration and provide a delightful experience for your customers. With Speakeasy's platform, you can now automatically generate up-to-date, robust, idiomatic SDKs in 10 languages and Terraform providers in just a matter of minutes. SDKs are feature-rich with type safety, auto-retries, and pagination.
Everything you need to give your API the developer experience it deserves. Deliver a premium API experience without the premium price tag. Visit speakeasy.com slash codestory to get started and generate your first SDK for free. This message is sponsored by SnapTrade. Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API.
With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices. Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators.
Get started for free today by visiting snaptrade.com slash codestory. Okay. So you've got the MVP and it's working. You're getting some traction. I'm curious about how you progress the product from there and matured it. I think to wrap that question in a box a little bit, what I'm looking for is how did you build your roadmap?
How do you, how did you go about building a roadmap and how do you do that today? And what sort of criteria are you using to decide, okay, this is the next most important thing to build or to address with speakeasy.
After that kind of experience, when we pivoted into SDKs, I think one of the things that happened was that we started getting into the hands of so many users. A lot of that feedback came naturally.
One of the things that we invested in on the own was like a kind of support process that allowed us to get unadulterated feedback from our customers directly to us and everyone developing on the product. We didn't buffer that with support or any kind of function like that. So we literally had Slack channels with every customer as they ran into questions and issues, iterated directly.
And we very much built a kind of culture around forgiveness or ask for forgiveness, not permission. And so everyone developing the product had full autonomy to make the design decisions and fly forward. really take customer feedback, implement directly, and ship again.
So we got into this really iterative process early on with a dozen or so customers in SDK product, where every week, every day really, we were doing multiple releases, having them use it. And I think what was really key was identifying customers that were willing to make it.
This only works if you have engineers at the customer who are in Slack with you, going back and forth, really diving deep into things like, How do you want an SDK to represent union types? That's like a tough type safety problem. Or how should file streaming be handled for different encodings in an SDK?
So these are the kind of things that we really dug deep on and helped us get, I think, some true insight and edge in the developer experience. The other thing we did was we also recognized this was a product that had a significant community angle or ecosystem angle. So we invested time sponsoring a lot of open source contributors in and around the open API space.
And through that, got time with them to get their learnings of what they were seeing from users of their open source libraries. And so that was also super useful for us in terms of making sure we weren't over-indexing on the service that our customers were working with.
So I'm curious about team. How do you go about building your team? How did you go about building your team? And what do you look for in those people to indicate that they are the winning horses to join you?
The early days of a startup, I think team is everything. I think without a great team, you're basically dead in the water. So hiring was something invested in very early on. Hiring was challenging when we started. It was 2022, coming out of COVID. There was a lot of remote work going on. People weren't back in the office yet. People were also staying in their jobs.
The industry wasn't where it is now, and people weren't switching jobs as often. And so we definitely struggled to actually hire in-network. A lot of the folks, engineers I had worked at LightRamp had gone to work at other startups that had come out of LightRamp. So I was also facing that problem of my own network had been somewhat exhausted by other startups.
What we did was we ended up working with a fair number of contractors early on, but implemented this policy of like contract to hire. So every contractor we work with, we had them work with us for four to six weeks. And then depending on how it went, we use that contract work as an interview to come on full time. I think the first five or six engineers on the team all went through that process.
And that was honestly, I think, such an amazing experience.
leverage point for us because everyone we hired early on was a great fit on the team they had already spent many weeks building and training with us so that was i think one of the things that worked really well for us on hiring the other thing that has worked really well we really think about our engineering as marketing so all the stuff all the design decisions and a lot of the early tug of wars we had internally around how to build we externalize into blog posts
That helped give, I think, folks out there, candidates, prospects, to get an insight into how we design and develop and how we collaborate. Any kind of brand building, I think, always helps hiring. In terms of what's, I think, really working for us now is that core philosophy of ask for forgiveness, not permission, really is quite pervasive at our company.
I think everyone is really empowered to make roadmap decisions, design decisions, work with customers. run sport, make some pretty impactful decisions. And sometimes we get it wrong because of that high autonomy, but I think that's okay. I think you have to think about it as, in the medium term, those sometimes wrong decisions, do they go towards building the right culture?
And over time, it normalizes, and the end result is an organization that's very effective at making decisions because it's happening grassroots, autonomously, and not getting gated on top-down heavy processes.
This message is sponsored by SnapTrade. Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. This message is sponsored by QA Wolf. If slow QA processes bottleneck your software engineering team and you're releasing slower because of it, you need a solution. You need QA Wolf.
QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes. With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Drada, Autotrader, and many more, you're in good hands. Ready to ship faster with fewer bugs?
Join the Wolfpack at QAwolf.com to see if they can help you squash the QA bottleneck. Let's flip to scalability, and this will be interesting given who you're serving and how opinionated they are. I'm curious about scale. Did you build this to scale efficiently from day one, or have there been interesting areas where you've had to fight it as you've grown? It's definitely been a challenge.
And to your point, the SDK product is so opinionated, right? Kind of the shape and quality of a great SDK can really differ company to company, like TypeScript idioms that are agreed on, Python idioms that are agreed on. But even in those, you often get into debates with the customer that really come down to a handful of characters. And that can have a serious impact on developer experience.
So where we've gotten to at this point to scale this is it really comes down to providing the users with great out-of-the-box defaults. So a combination of deterministic config as well as a little bit of LLM powered magic on the OpenAPI spec means that we can make a lot of great decisions for the customer to get them to like a 90% and 95% great SDK out-of-the-box.
But then it's really important to invert control at that point and give the customer a number of really nice knobs and configs to decide how to take that great SDK and make it absolutely the best for their end user. We take the customers 95% of the way in that build process and then give them the config and utilities to make those final last mile decisions.
And I think in the SDK product is super important because an SDK at the end of the day is a representation of your product and your engineering brand. A great SDK looks great to customers. A bad SDK looks like you're not investing in maintenance and engineering.
Okay, Sagar. So as you step out on the balcony and you look across all that you've built thus far, what are you most proud of?
It's only been a little under two years and it's already a pretty long journey. I think one thing that stands out, I think to me that Speakeasy has done really well is building our customer relationships. I think a lot of developer products have great products. At the end of the day, these teams are all like great builders and the ideas are amazing.
But I think building a kind of company, culture and organization that really prides itself with respect to how it handles its customers, I think is somewhat underrated in developer tooling. I think what I'm most proud of is just the customer relationships, the level of support kind of care that we're able to give our customers.
I think our median response time is something like 2.4 minutes or something, even as we scale. And it's just, for me, to every person developing actively on the product, to those doing sales, product marketing, I think we really care about making our customers successful. It goes hand in hand with our product, right?
We're this kind of embedded product that, you know, when we launch with a customer, they're often like doing an SDK API launch. And so we're part of that launch and we're part of helping them boost their end users.
So there's a lot of craft and care that goes on the product, but there's also a lot of craft and care that goes into learning support and just being there for our customers, making sure they're successful with their end users.
Let's flip the script a little bit, Sagar. Tell me about a mistake you made and how you and your team responded to it.
I think one interesting mistake that stands out is a lot of startups that are going through this kind of PMF journey often end up going down a path on products that they decide later that was actually the wrong path. That has happened to us several times. I think with the kind of high autonomy and high sense of experimentation that we have, we will often go down that path.
But I think it's always what's telling about a company is how you recover and how you take the learnings from that. So earlier last year, we actually ended up building kind of addition to our SDK product, which was a Docs product. And Docs is like an important part of any API, right? Every great API is going to have great Docs. But for us at the time, I think it was the wrong place of investment.
And we had actually committed a bunch of our customers to launching a Docs product for them. Obviously, when we realized we couldn't make that happen, that was worrying for us. Obviously, the time spent and all of that, but also we had committed to help a number of customers.
What we decided at that point was we were going to partner with a company, another company in the space, other companies in the space. And we ended up taking on a bunch of support work to help those customers of ours we had committed to. And we ended up even committing to building an integration with that partner company.
So our customers would not be left hanging in terms of seeing that vision of an integrated SDK and docs product. So I think we've had several experiences like that, but I think what's... It goes back to our culture on customer centricity. And even in that moment, I think the way we covered was important. I think we haven't left our customers hanging without documentation stories.
So I think that's one thing that stands out to me.
Okay, this will be super fun. Tell me what the future looks like for the product, for the Speakeasy product and product suites and for your team.
So we're at that interesting turning point as a company coming out of being a seed company and growing. I think for the product, I think about everything that we've done today is about building APIs. It's about working with your API spec, launching an SDK, distributing to your customers. It's all about build.
But when you think about an API and the journey a development team goes on, I think it's really more than that. It's build, it's test, and it's run. Those are three big phases that I see in the API lifecycle today that aren't really serviced by great products. I think there's point solutions and there's... kind of things at the end of the lifecycle and before the lifecycle.
But in the code, when it comes down to actually building, testing, and running the API, most teams are reinventing this wheel every day or every time they launch. And so for Speakeasy, we've done the build side. There's still plenty more there. We've at least made, I think, a pretty big inroad into helping you build and distribute your API. Next comes test.
So it's about how do you ensure as your API grows and scales, you can maintain great consistency, reliability, and empower your dev team to move faster. And then finally, there's run. Run is really exciting because I think APIs haven't seen that revolution towards fast iteration and edge development. the way UI has.
Like, teams like Vercel and Netlify have brought that, like, amazing get previews on every GitHub commit kind of experience. And that's changed UX development. APIs haven't had that. And so we're exploring with our customers what it means to, like, instantaneously have APIs deployed on the edge, have a backend for frontend on every GitHub commit.
I think there's something really exciting there in terms of helping our customers go all the way from an API spec to a deployed API back as quickly as possible and becoming this core infrastructure loop for our customers every day. I'm excited the way the team is shaped up. We're half based in San Francisco, half in London. A couple of remote folks, but those are two centers of gravity.
I feel super lucky to be working with these great talent pools in both locations. Core team members still here at the company. We're growing the team. So yeah, I think Speakeasy is interesting. It's a platform of products. It's not a single product. And so there's scaling challenges, but there's also a bunch of new product that needs to be built.
And so I think I'm really excited for us because it feels like we're just coming from phase zero to phase one, but there's still phase two, three, four on the road to being a big kind of foundational infrastructure product. So yeah, I think this is going to be an exciting rest of the year, but I think there's so much more to be built. There's so many more problems in the world of APIs to be solved.
Let's switch to you, Sagar. Who influences the way that you work? Name a person or many persons or something you look up to and why.
I'm definitely lucky to be sounded by, I think, when sounded by lots of other great founders. The company that I worked at previously, Libram, had a number of startups come out of it.
All of those founders of all the startups have been incredible kind of mentors to me and created this ecosystem through which, you know, being able to flourish and take risks and feel like I've had support during that process. So I would want to thank that ecosystem of founders that have come out of Librem. I think they're all really fantastic. My co-founder Simon has been absolutely amazing.
I think he's brought a side of thinking that I just don't have. He's been in investment before, he's done product at a variety of different companies. I think as he describes it, he's done a lot of different things, whereas I think I've always done engineering. I think definitely very grateful for him for having someone who is able to see all the decisions we may take at this stage of the company.
They seem like product decisions, but they're really product, team, marketing, sales all rolled up into one. And so being able to clearly articulate and disambiguate these decisions is really important. So I'm definitely super grateful for being able to work with him.
Sagar, last question. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world and can't wait to show it to you right there on the plane. What advice do you give that person having gone down this road a bit?
As engineers, we can get really kind of rabbit holes into the building side and the product and crafting an amazing product. And don't get me wrong, that is absolutely important. That's like core of what all these companies are. But I think it's super important to spend as much time actually talking to your users, understanding their problems. and what they need.
I think that's somewhat undervalued in the developer tooling world because a lot of us come from having faced the problems ourselves. So we sometimes feel we have the intuition and empathy for the developer problems. But at the end of the day, as you build, you're going to discover new things and you really want to invest in those customer relationships that will take you forward.
So yeah, talk to users, try to build relationships with them, meet them in person, spend time with them, go to meals with them. Speakeasy wouldn't have been here today if it wasn't for those early customers who have pushed us forward, vouched for us, have taken the risk and bets on us.
Because at the end of the day, that's what kind of changes, takes that cool, awesome project you're showing me on the airplane into a product and a business is having those real customers and companies pushing you forward. So I'd say, yeah, invest in the relationships. It's a lot about product, but it's also a lot about business. the people who are going to use your product.
That's fantastic advice. Well, Sagar, thank you for being on the show today. Thank you for telling the creation story of Speakeasy.
Thank you so much, Noah. It's been great to be here.
And this concludes another chapter of CodeStory. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.