Creating world-class API devX with Sagar Batchu from Speakeasy

[00:00:00] Mike: Hello and welcome back to APIs you won't Hate. My name is Mike Bifulco. I am your co-host of the APIs You Won't Hate podcast, flying Solo today. Phil and I, have been doing our usual thing where we dance around each other's schedules, and being an East Coast American, working with a middle of Europe and or middle of UK and or tree dwelling, co-founder is a little challenging. But, Today I am super, super happy to be able to sit down and chat with my new friend, Sagar Batchu from Speakeasy. Sagar, it's really nice to meet you. Thanks for joining today. How are you?

[00:00:33] Sagar: Doing well, thanks Mike. You know, I've been following your and Phil's work for a long time, and very much admire what you guys have been doing and with APIs You Won't Hate.

[00:00:42] So, really excited to talk today.

[00:00:45] Mike: Yeah. Thanks so much. I'm, I'm honestly, deeply flattered by that, and it's always really encouraging to hear, we, we love the community we've built and it's super cool to see us having real impact on people's lives and careers and things like that. We are of course, here to talk about your work and what you're [00:01:00] doing at Speakeasy.

[00:01:01] But before we get started doing that, I'm gonna surprise you with a question that I didn't tell you I was gonna ask you, but I went on your company page on speakeasyapi.dev, and I looked at your profile there. And the second thing it says under your name is you love chicory in your coffee.

[00:01:13] So, we need to start by talking about coffee because I'm a, a massive, massive coffee nerd. Tell me, tell me a bit about your favorite way to have coffee.

[00:01:21] Sagar: Yeah, thanks for checking that out. My favorite way to have coffee is traditional pour over. So if ideally I have beans at home, grind them up, a nice ritual in the morning before you get started to work to actually grind coffee, smell it, have a nice drink. That statement comes from my, my family actually has a background in growing coffee, so past couple of generations in one side of my family has been growing coffee in India for a while. So that means I have to be a coffee snug, there's no other way.

[00:01:53] Mike: Yeah. Got it. I think you just pulled credentials on me. So I am certainly outranked here, but I drank an awful lot of coffee and I'm, I'm a [00:02:00] big fan of the morning ritual too. I'm an Espresso drinker myself. I tend to do a shot of espresso first thing in the morning. But yeah. Good, good to know. I'm in good company and more than one way here.

[00:02:10] Alright, well let's start there. Why don't you tell me a little bit about yourself, your career, your story leading up to where you are today, and then let's talk a little bit about Speakeasy and, what you're building now.

[00:02:21] Sagar: Totally. So my journey probably starts, back in university and, In senior year of university, I had this existential crisis where I realized years of work sitting in a physics lab wasn't adding up to what I wanted to be doing.

[00:02:40] Unlike most of my friends, wasn't gonna go get a PhD. Didn't really want to continue being in a lab underground for a number of years. And so had a mild freak out, decided to take as many computer science classes as possible one year, or try to be this pseudo computer engineer. And from there, [00:03:00] very much realized that this is what I wanted to be doing.

[00:03:02] I wanted to be building infrastructure, building software that other companies get to build on top of. So that began, career in software engineering. And most recently before Speakeasy, I had the opportunity to work at a company called LiveRamp, which was a massive identity data platform powering a lot of advertising in the US as well as elsewhere in the world.

[00:03:26] And with any massive scale data product like that, you have huge, you know, internal data infrastructure and developer tooling needs internally. And this is, you know, for all of us who've been doing engineering, who do open source, who do developer work, A lot of the best projects out there start as projects internally at companies.

[00:03:46] So this was very much, you know, foundational experience for me. While I was at, LiveRamp, I moved out to the UK, and actually started to build out an engineering team for the company there. [00:04:00] And through that experience, really found that I loved this zero to one process of going from having no idea what you're doing to a couple drawings on a whiteboard to an early prototype to figuring out, you know, if people pay for a product. And that was an amazing experience because doing that with kind of a backing of a company and having a whole machine around you that supports decision making, is not something everyone gets to do.

[00:04:26] So very, very fortunate to have done that. A lot of what I did at LiveRamp was focused around scaling our internal developer tooling our infrastructure data infrastructure. And so, towards the end of that experience, very much realized what I wanted to do next was actually, commoditize some of the things I had been exposed to internally, to developers everywhere.

[00:04:49] And then also bring that to other enterprises where there's so much value locked up that, is waiting to be unlocked.

[00:04:56] Mike: Yeah, I think that's a fairly common feeling for folks who worked [00:05:00] at large companies with big engineering teams, that you have hundreds and thousands of man hours that can often get bottled behind decisions that were made long before, people who are still at the company.

[00:05:10] And, some of the value of things being built, lacks the capacity to scale because things can't always move as quickly at big companies as they can at, zero to one shops as, you might put it. Yeah. Okay. So I guess that brings us to where you are now with speakeasy. So what's the elevator pitch?

[00:05:27] What's the value proposition for speakeasy?

[00:05:30] Sagar: Totally. So, SPEAKEASY is a API developer experience platform. We make it really easy for API producers, so people who actually build APIs both internally, externally, to offer world-class develop experience for their users. And for any of us who, you know, worked at these API companies, we know that the mass amount of platforms during effort, that goes into actually building great API, scaling it, doing all the tool last mile tooling to ensure that you know your users are happy.[00:06:00]

[00:06:00] And so speakeasy is that API platform that lets you serve your users, make sure you're able to, you know, unlock new developer communities and double your API usage quarter on quarter. Today we've kind of coming at the problem actually in reverse and have started with the day zero problem that you know, API consumers face when they integrate with APIs, and that's integrating with an API is trial and error.

[00:06:26] You look at docs. You look at your id, you try out something doesn't really work. There's often no usage examples to go off of. There's very little guidance. And so you, you are either in Slack with, you know, an API team figuring out what to do, or you're hand rolling your own client and SDK to figure out, you know, to integrate something repeatable that maybe other people on your team or your friends can take advantage of.

[00:06:51] So that problem is something we've seen repeated over and over. And so we realized one of the best ways to kind of enter this problem space is provide a [00:07:00] managed SDK offering. And that what that means is, when you are an API producer, you just wanna build your api, but you also want to serve your developers in different communities.

[00:07:12] And to do that, you need great SDKs. These are kind of how, as API users, this is our primary way of interacting with APIs today. And so a great SDK makes our usage of an API loyal. It ensures that we have less hours. It's, it's honestly you know, creates this great experience around using API I and, and kind of this proof in the pudding here, in that the top 1% of API companies that drive traffic today all have great SDKs and, and kind of huge teams internally that maintain them.

[00:07:46] At LiveRamp as well, we had kind of an internal DSL for API building that we created and eventually worked towards this goal. And we've seen this pattern repeated many, at many other companies before. Palantir, Stripe, [00:08:00] Twilio, all have this kind of internal, experience around the end-to-end type safety and making sure the end users get ergonomic experiences.

[00:08:08] So that's where we're starting today as we move forward the managed SDKs we're starting to offer more components of API infrastructure that help you scale your API. So things like self-service authentication that works with any API gateway self-service, troubleshooting and visibility so your end users can actually understand how they're using your API.

[00:08:30] And then eventually going down, or going upstream I should say, into, so the server side, helping you maintain your API, create API specs, this is, you take out of all of those tough problems that API producers face.

[00:08:43] Mike: Yeah, there's a lot there. I think that you're tackling a problem space that is obviously quite diverse in what you need to be able to address, but also is one where people can really relate to the series of problems that you've just described.

[00:08:58] Especially I like that you [00:09:00] said something along the lines of, what you're doing is helping API engineering teams just build the API right? They're spending their time doing the thing that probably their company does best, which is have some super specific engineering know-how about building something, whatever.

[00:09:16] It's, you know, it can be anything from Phil's company building things to track trees being planted in the middle of the UK to you know, whatever it is up and down. But when those groups of engineers spend their time figuring out how to do SDKs in various languages correctly, they're essentially wasting man hours on unsolved problems to some extent.

[00:09:36] Is that roughly the gist of why having a managed SDK offering is something that you're interested in providing?

[00:09:45] Sagar: Exactly. It's, we want to take the burden of engineering teams looking to scale. So this is the bottom line for companies. At the same time, we, we think there's like a top line advantage as well.

[00:09:57] So companies bring into, you know, being [00:10:00] able to break into new developer communities means potentially more revenue as well. So we, we like this kind of dual approach of yeah, reduce your cost, but also scaling usage.

[00:10:09] Mike: Yeah. Okay. So, let's talk about the nuts and bolts of it then. So you, you offer managed, SDKs I'm sure in a variety of languages.

[00:10:17] What does that look like?

[00:10:19] Sagar: Yeah, Clear question. So for those of you who are familiar with like open API and open standards in the ecosystem, there are, you know, tons of open source generators today that will get you 50% of the way there. A lot of teams like hand roll SDKs as well, is a common pattern we've seen.

[00:10:37] But to have really a great SDKs, something that's truly ergonomic, to your point, Mike, you know, built out in a variety of languages hosted in GitHub published to package managers taking, you know, that whole life cycle of concerns is actually really difficult. And so our product, can be thought of like a zero touch experience where we connect directly to your GitHub, wherever your API [00:11:00] specs are hosted, and actually create a GitHub workflow that automatically validates, you know, checks, enriches your spec, and then creates SDKs and we do something like seven languages now and then takes care of publishing them as well to package managers and keeping them validated and up to date. So that whole, you know, box diagram that you people probably have internally of API spec to SDKs is something that we're taking care of today.

[00:11:28] Yeah. Okay. Okay. And so which spec formats do you work with?

[00:11:34] Yeah, so we, we work with Open API primarily today, but have started to support Postman collections. Want to expand to the kind of breadth of the whole JSON Schema eventually? We know that's like an ongoing internal discussion of how wide to go and eventually in the future, even look at other formats potentially put out something of our own.

[00:11:54] But today, open API has, you know, such amazing adoption, continue to be, you know, [00:12:00] evangelists of that ecosystem and, and see a really strong mutual existence there.

[00:12:05] Mike: Yeah, I think I can understand that, especially because Open API is so broadly adopted it's something that there's, there's often domain expertise for at least in the design process.

[00:12:15] And, you know, things, things can go all kinds of haywire depending on the way the engineering team is set up once the spec is created. And you know, we, we've talked about on the show all sorts of challenges that come up with that. Even at that too, the Open API spec is an evolving thing, right?

[00:12:31] Like it is, it has moved and continues to move in for good reason. As we learn more about building APIs and client libraries from scratch, we, we want more naturally out of what, we think the spec should be able to do. And for a long time, I think that's also where JSON Schema has been an interesting topic too.

[00:12:47] Talking about validation and automatic generation of UIs and stuff like that is really, actually kind of an interesting, problem set to think about. So, tell me a little bit about the, the, I guess the customers, that [00:13:00] are looking at Speakeasy or the engineering teams that are using Speakeasy. Do they have like a commonality?

[00:13:04] Is there a part of the engineering journey that they're typically at when they come to you?

[00:13:09] Sagar: Yeah, it's, it's a great question. We, have been working with a variety of companies across couple different verticals, e-commerce, FinTech, developer tooling, other infrastructure companies. And we see largely two modes of operation.

[00:13:25] We have teams that are very early in the journey. They're essentially doing the first API launch, they're launching the product, launching the business. And so these are, these are what I would call lighthouse teams who realize that, you know, from day one, they want great SDKs, great documentation, good authentication.

[00:13:43] They want everything that makes an API experience world class. And so we're able to help these kind of teams take work off the plate, ensure that great API launch happens for them. And then you have teams that, you know, are, most of them mature with the APIs usually, [00:14:00] you know, dozens of endpoints, hundreds of operations and their API spec, and have a sprawling API ecosystem internally.

[00:14:07] And so for them, the value proposition of speakeasy is not just helping the external developer experience, but also the internal developer experience. Often you get to that scale where you have teams with, you know, dozens of API specs. Each team has their own open API and suddenly there's a question of how do you manage all these interfaces?

[00:14:27] Are you going to have one massive monorepo with SDKs for all your APIs, or do you want separate ones? And there's all these questions that pop up, at that scale that, and that's where we come in. We actually help capture a lot of that decision making in our product.

[00:14:42] Mike: Yeah, that actually touches on a really interesting point that I feel like I've seen maybe rumblings of a lot lately.

[00:14:48] I feel like for particularly large engineering teams, maybe not even large, but ones that have existed for a while, there's this notion of almost for lack of a better term, I'll call it internal developer relations, where part of the [00:15:00] challenge becomes how do we make it better to be a developer working on this thing?

[00:15:04] And just knowing the breadth of tools available and like the, capacity to do better and make the engineering process better is actually kind of a big treasure trove of value for engineering companies. You know, engineers burn out because their product is hard to work on, or because the process of getting code from ideation to production becomes really challenging.

[00:15:24] And I think companies are really starting to get wise to that, where, being able to lift some of the weight off the shoulders of engineers makes life easier and makes them, you know, as close to making it joyful to write code as it can possibly be. You know, I don't think I would say that code writing code is always joyful, but, it makes it better.

[00:15:40] Right? And, and, having tool sets that do that is certainly something that will help with that kind of conversation. Really interesting to hear that you're, you're sort of larger and maybe more experienced customers are thinking about that too.

[00:15:53] Sagar: Absolutely, in a way, we almost treated as a way to onboard unto product where we recommend teams to use us for an internal [00:16:00] use case first before going external. And if you can prove to your own self and developer teams that there's a massive productivity as well as, you know, overall value proposition, then hopefully that is obvious to your end users eventually.

[00:16:14] Mike: Yeah, Ideally it's a toolset that speaks for itself, the value should become apparent. So speaking about adoption, then, what is the strategy for pricing? Is there an onboarding experience that allows people to test out Speakeasy without having to spin up a , you know, a new SaaS charge?

[00:16:33] Sagar: Yeah, so you can get onboard with us today. We have very generous free tier within the product. All it takes is an open API spec to get started. And you know, even if you don't have one, we actually will work with you to put one together. We've been doing some fun Hack week projects internally to use the latest, LLM and ChatGPT tech to actually trade specs for you if you don't have one. [00:17:00] Yeah. Fun stuff around that with, you know, fun stuff with that around the corner and hope to share more. But yeah, so that, that's all we need to get started. And then as you become a customer of Speakeasy, we basically charge in the number of operations you manage to us, so, Yeah, an operation is one rest word per endpoint.

[00:17:20] We're basically incentivized to help you grow your API and grow usage. So we grow as you grow pretty friendly with, with companies. You know, we're, we're pretty early ourself and so always iterating, trying to understand where the maximum value for teams.

[00:17:35] Mike: Yeah, sure. And it goes a long way to be able to let people just get in and try the thing and, and give you feedback, see what's gonna work for them.

[00:17:43] Sagar: That's totally true. One, one of the ways we we'd like to work with people is if we see that you have an API out there publicly hosted, we'll actually just create an SDK, send it to you and say, Hey, this is yours. Feel free to use it. You know, trying to leave a little gift on your [00:18:00] dose step and see what happens.

[00:18:02] Mike: Sure. Yeah. Wow, that's, that's a very pleasant surprise, I'm sure to wake up to. Well what an interesting idea. So you talked a lot about focusing on idiomatic SDK generation, which I think for folks who have used client libraries that are idiomatic versus not idiomatic, it's always apparent when you bump into something that's very thoughtfully made.

[00:18:22] I'm sure there's a lot of interesting decisions you have to make to generate client libraries in different languages that feel natural to, to both languages. What does your approach to that look like?

[00:18:33] Sagar: Yeah, it's, it's a great question. You, you're absolutely right. The devil's in the details when it comes to ergonomics.

[00:18:38] I, I think, think of it in two ways. First and foremost, there's some top level philosophies that we try to maintain. Type safety is number one. We want to make sure that end users get the type safe experience. This is particularly a problem in, in rest where, you know, server to client type safety is not always guaranteed.

[00:18:56] We wanna make sure they're human readable. So in the case [00:19:00] that the SDK fails or there's an, or there's some kind of error, you should be able to actually understand how the SDK is working. We want to give you batteries, include experience. So if you've come across a good SDK, you know it's batteries included when it has built in telemetry and retries and pagination, and it kind of takes care of the long tail of problems.

[00:19:20] You come you, you know, you bump into as you do API integration. And then finally be fault tolerant. What's worse than this? You know, not having an SDK is an SDK that's broken. That is something no developer likes. And so that's another top level concern for us. So those are kind of a high level philosophies, but as we get into each language, we found that people are extremely opinionated about what a good Go SDK versus a good C Sharp SDK looks like.

[00:19:49] You know, we try our best to maintain some stability and develop experience across them, but we also provide a set of extensions and hooks for people to actually customize the SDK [00:20:00] output. Because we know that, you know, we, we can be opinionated and prescribe what a good Go SDK looks like.

[00:20:05] However, each company and team sees an SDK as actually a representation of their ensuring philosophy. And so we need to ensure that we're customizable enough that people can feel like it's their own and we're taking off, you know, getting rid of all the heavy lifting of that repetitive coding they need to do, but at the same time, they can customize and have a branded expense when they use us. So as we get into more languages, we're, we're exposing more extensions and eventually would love to get to a place where we actually expose the underlying generator as well for people to extend and, you know, provide their own system of customizing the SDKs.

[00:20:45] Mike: Sure, yeah. That's the tacit dream of an idiomatic, SDK, is that not only should it feel good in that language, but it should maybe feel good and also feel like something that's flavored like your team, right, flavored like your company, and maybe uses your style guide or [00:21:00] your you know, language features that, that certain teams have adopted and prefer to use.

[00:21:05] Along those lines, I guess I'm interested in hearing a little bit about how documentation works then for the SDKs that you're generating.

[00:21:11] Sagar: Yeah. This is somewhere I would say we're still pretty early in. We do provide usage snippets and markdown for every SDK that's created. So we wanna make sure we're giving you the tools for you to be able to take that and embed it in your own docs site or your own app.

[00:21:28] Longer term we would actually love to ship react embeds around this so that you could, you know, one click get a SDK documentation in Docusaurus or any kind of open source Docs provider. So slowly stepping towards that. And you're right, this is, this is so critical because when you work with something like Open api, it's, there's so much breadth, right?

[00:21:47] You have, you know, types of serialization, you have ways of managing request and responses. You have all of these data types and things that really should just be captured in usage examples for people to just copy, paste [00:22:00] and get started. So today we have markdown documentation. Tomorrow we do wanna launch a SDK first docs product.

[00:22:09] There's lots of great API docs providers out there, but we haven't seen an SDK docs provider. And from our point of view, it's a, it's a completely different kind of user journey.

[00:22:18] Mike: Yeah, I think that's fair. So you and I haven't spoken about this, but I'm, I'm a former Stripe employee and, and having a fair bit of insight into what it looked like for Stripe to generate documentation for the broad variety of, of client libraries that Stripe produces.

[00:22:35] It's a pretty custom thing, like it, it takes a lot of work to make it. Not only look presentable, but also feel good and be informative for the people consuming it. So it's worth being thoughtful there. And I can understand the need to kind of take your time and get to a place where you're building something that not only is functional, but you're proud of and sort of ticks all the boxes for the people who want to consume your SDKs.

[00:22:57] What are you thinking about next? What's Speakeasy working on [00:23:00] now?

[00:23:01] Sagar: Yeah, so for us, SDKs has been this awesome wedge into this rich API ecosystem. Moving forward from there, there's. Many more ancillary concerns around the API that we're trying to address. Things like self-service auth. So to give you an example, you know, like companies like Stripe or GitHub have amazing self-service API auth experience.

[00:23:24] I can get a GitHub personal access token and I can provide scopes and get going completely by myself. But how many APIs out there have that kind of self-service experience? So powering all of those experiences is something that we are going after. And then as, as we progress from starting to grow up the value chain to the server side and support things like server side generation giving you middleware to embed various parts of the API lifecycle directly into your build.

[00:23:50] So really exciting path forward for speakeasy on, on the SDKs itself as well. I'll throw in a plug that, a lot of our early customers have been [00:24:00] amazing and pushed us to think about SDKs. It's not just languages, but also run times and, and novel surfaces. So, We started to invest in generating Terraform as another SDK type.

[00:24:12] A lot of infrastructure companies need Terraform providers and it's something that can be taken created directly from your open API spec. Eventually, you can think of things like command line tools, Zapier plugins, chat GPT plugins, these all s SDKs of an api. And should all you know, the moment you have an API spec should all become immediately available to you.

[00:24:33] Mike: Yeah, that makes a lot of sense. There's, a lot of ancillary value you can provide by just plugging, plugging into those little things. Having a, an API that works well with Zapier, for example, enables a lot of no-code and low-code experiences for people who may not be, happy in Postman or, you know, trying to, to send curl requests to figure out how something works but can certainly provide value you know, almost straight out of the, the gate there.

[00:24:59] Yeah, [00:25:00] there's, it sounds like you have a broad array of things to tackle and definitely like, have, have come a long way to provide value for your customers as is right now. That's it's a very interesting journey and I think one of the things that we're seeing in, in the world of APIs right now too, is a lot of companies are thinking about this as a more holistic view of it's not just write the spec and then hope someone builds the spec.

[00:25:21] It's write the spec and then generate value from that as much as possible. I'm personally enjoying being able to see all these things come into existence because it's making, the, the sort of middle developer experience really nice where you consume APIs and build things that are functional from that has suddenly become much easier and nicer across the board too.

[00:25:39] Sagar: Absolutely. I think especially to today as we see this new wave of AI companies pop up. At the end of the day, every AI company is an API company. It's really interesting to see, you know, ChatGPT adopt open API as the standard for plugins. So it's, this ecosystem is just seeing so many big tailwinds and [00:26:00] continues to grow and we want to be at the center of it and, and help this ecosystem continue to grow.

[00:26:06] Mike: Yeah, well that's, that's really encouraging to hear. I I'm one of those people that spends a lot of time thinking about ChatGPT and, and AI based products, and. Have dipped my toe in it a few times for sure. But I'm also a very happy end user of it and nice to see that, like the standards I'm already familiar with will be really helpful for that future.

[00:26:25] Tell me a bit about how speakeasy is working with Open Source. Are there, are you working with like open api to, to develop future specs? How's how's that side of the house work for you?

[00:26:38] Sagar: Totally. So the core product we have is closed Source today. It is an ongoing discussion internally on how we make more parts of our product open source.

[00:26:49] In the meantime, what we've done is we've adopted this philosophy of any tooling that we build that makes our lives easier. That is, you know, not, you know, our core code generation is [00:27:00] stuff that we open source. So I'm happy to provide some links to some interesting projects we work on, like open API validators.

[00:27:06] Open sourced new templating engine that allows us to work more flexibly with open api. So there's lots of ways we see we can add value to the open source community while still keeping our core product close source. We support, you know, the newest versions of Open api. I think as we grow we'll and we have dozens of companies working with us, we'll be in a really good place to help inform and provide feedback to the Open API Foundation on, on future iterations of the protocol.

[00:27:35] Mike: Yeah, I would love to see some of those open source projects. And I think the open api foundation and the spec itself gets better with more voices in, in the room. In particular, when you're thinking about expanding the tooling that comes from open API and the things that we're building based on it especially people in position you're in, right?

[00:27:55] Where your company is building tools that directly consume and build from open api, I think your feedback becomes [00:28:00] particularly valuable because you've got insight on both sides of that, consuming the spec, delivering things with the spec. And all the little holes that kind of develop as, as a result of that and the bumps along the way there.

[00:28:10] So tell me about I guess the future from here. You, you have a, a series of releases coming out. I actually really liked, I was browsing your site earlier. It looks like you have a public roadmap, which I think is really interesting. Where consumers or consumers, people are interested in speakeasy can go see what you're bringing, bringing next, but also vote on things and leave feedback on what's coming with the roadmap.

[00:28:34] Are there, are there things you're interested in getting around to building in the future? Like, are there releases coming that your team is kind of chomping at the bit to get out the door?

[00:28:42] Sagar: Yeah, totally. And we, we always welcome feedback and uploads downloads as well to our, to our roadmap. Always looking for people to, to be loud and opinionated.

[00:28:52] Yeah, so some really excited things coming up on the immediate front with SDKs. You know, this is, it's amazing once you get into s STKs, the [00:29:00] number of things, number of value you can start to capture and, you know, make lives easier for developers. So, I'm excited for support for mobile, STKs supports for OAuth Lins STKs, you know, never refreshing token again.

[00:29:14] Pagination, those kind of things that we see can all be embedded into the interface for developer. So all you have to do is integrate and you get all that stuff for free. As we think p beyond SDKs, we've started to get really excited and experiment with how we can give you embedded components for your infrastructure.

[00:29:36] So one of the things I mentioned, we've been developing self-service art with to various gateways. You know, everyone uses an API gateway, but, but struggles to actually figure out how to provide self-service keys. So that's an area that we've continued to develop and, and push forward. Some of the areas I'll highlight, we very much believe that, you know, open API is an amazing standard, but for a lot of [00:30:00] teams they just want to get all this stuff in place and not even worry about open API sometimes.

[00:30:04] Right? Sure. So we're trying to go really upstream here and we have a really exciting API release coming out, which, You can think of as a clippy for your open API spec that actually helps you walk through your spec, keep it up to date. Automat suggest changes, make automatically fix things for you.

[00:30:24] And we've talked a lot of engineering products, technical rider teams that really spend a lot of time just on spec maintenance. And it takes time away from kinda core product development. So I think we're very uniquely positioned in this. World of SDKs and API infrastructure to actually start capturing all of that value and start making their lives a lot easier.

[00:30:45] So really excited. When my API spec writes itself.

[00:30:50] Mike: I'll say, yeah, gosh, that's living the dream at that point. Exactly. So tell me a little bit about your team. How, how large [00:31:00] is the team building speakeasy and what sorts of engineers do you have on staff?

[00:31:04] Sagar: Yeah, so we're a team of eight right now split between the UK and the US.

[00:31:10] Mostly on kind of West coast and, and GMT. Really amazing team, super fortunate to be working with them. Most of the developers on the team are platform engineers who very familiar with APIs, AI infrastructure. Some of them have built a p i platforms before at at pretty large companies. I think one thing that makes our team super unique is the spirit of experimentation is really strong.

[00:31:35] We have, you know, every developer is a product manager. Everyone is driving on threads and driving on different angles themselves. Often will come to a standup and someone has worked on something completely new and completely fresh and. Based on customer feedback and, and ideas. So really excited to be working with them.

[00:31:55] We are growing and hiring, so we're looking to hire several more founding [00:32:00] engineers, founding developer marketing role as well as thinking about roles like for deployed engineer account executives and sales as a little bit further down the road as we scale.

[00:32:13] Mike: Got it. Yeah. Well, what an exciting place to be in. It sounds like there's lots of growth to be had there. And it sounds like a really interesting team. So I, I will make sure to put some links in the show description to make sure that your open roles are something we link to. Are you hiring just in on the West coast and in the UK? That's usually something that our audience is keen to hear about.

[00:32:31] Sagar: We are remote first, so we are hiring everywhere. We do like to hire folks between the West Coast and GMT just to keep our time zone spread limited. But look, we're, we're always open to talking to amazing people everywhere and. I think first and foremost, passion and interest in the space is what stands up.

[00:32:52] Mike: Without a doubt. I think that's probably a good way to characterize early, early hires at companies like yours. Makes a lot of sense. [00:33:00] Okay, so Saar from here which, what's the best place for folks to get in touch with you if they're interested in

[00:33:06] talking about APIs? Totally. So best place would be just joining us Slack community, having a chat with us.

[00:33:14] Sagar: If you go to our website at speakeasy api.dev, you can join us Slack community that way. You also drop us an email link through some of the information provided there. If you want to try out the product there's a button to join our beta. We'll immediately reach out to you and help you get started.

[00:33:33] We also, most of our teams serve around APIs. You own hate Slack as well, so you'll find us there. You can always bug us there directly as well. I was telling Mike it is the second most used Slack community. For us after our own. So happy to talk to them as well. Yeah, I'm gonna,

[00:33:49] Mike: I'm gonna get you to write that down on a piece of paper so I can frame it.

[00:33:53] That's, that's always very, very exciting for us to hear. Yeah, so Sagar and I were actually chatting on the APIs. You won't hate [00:34:00] Slack, so if you happen to be a member there, feel free to join. That is also free. We make lots of noise about lots of things in there and lots of people smarter than me to learn from in there, which is always really encouraging.

[00:34:11] Sagar, thank, thank you so much for joining me today. I really appreciate it. We'd be happy to have you come on and chat anytime in the future if you've got new releases and new features, new functionality to talk about. It's been a real privilege. Thanks so much.

[00:34:24] Sagar: Nice to meet you, Mike. And yeah, likewise.

[00:34:26] Mike: All right, take care.