Sagar Batchu
Appearances
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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?
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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?
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, 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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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,
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
When you're going to put out a UI to your customers, like you really care about design and quality.
Code Story
S10 E1: Sagar Batchu, 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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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?
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.
Code Story
S10 E1: Sagar Batchu, Speakeasy
And that was honestly, I think, such an amazing experience.
Code Story
S10 E1: Sagar Batchu, Speakeasy
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
Code Story
S10 E1: Sagar Batchu, Speakeasy
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.