[00:00:00] P: Hi, Sagar. Welcome to Software Engineering Daily. 

[00:00:02] SB: Hey, Pavel. It's great to be here. 

[00:00:05] P: So let's start with the first question. What is Speakeasy and what do you guys do? 

[00:00:10] SB: Absolutely. Speakeasy is an API developer experience platform. We exist to ensure that API producers can create and consume APIs extremely easily. Our goal is to realize a vision where creation and consumption of REST API is much easier than it is today. And we've started with one part of that very, very big vision and continuously working towards realizing that vision for our customers. 

[00:00:39] P: How did you get into programming? What were the first steps in the world of software that you have taken to get to this point? 

[00:00:48] SB: Absolutely. Actually, my background was completely different. I started and studied in physics for a number of years and realized before I was going to get a PhD that I didn't want to be spending many, many weeknights and weekends down in the lab. And the part of my physics degree I enjoyed the most was actually programming. When I was taking the data and turning it into something actionable that we could work with. 

And so, my last year of college I had a mild freak out and decided that I was going to try to cram in as much computer science as possible so that my degree was something that I could immediately go start building. And the idea of starting to build every day was very exciting for me.

[00:01:38] P: And from your background in physics, did you find any things that you have learned within the physics degree that helped you a lot with your experience in programming and with the path that you have taken? 

[00:01:51] SB: Absolutely. Physics is all about approximations and patterns. And that kind of thinking translates very well to computer science and programming and in building, right? A lot of times as developers, we very much rely on our past experiences. In many ways I would say, the code you read is more important than the code you write because you start to develop all this intuition about how systems are built. What are good patterns for development? 

And so, physics is a lot of the same. When you're investigating a phenomena, even as a lab student in an undergraduate degree, you're not discovering anything new but you actually going through dozens of experiments. And as you do, you develop an intuition for how to run an experiment and also an appreciation for the scientific process which, at the end of the day, not just for programming but for company building and startups, is super important. Always thinking first principles about the data you see and how to make decisions. 

[00:02:54] P: And from the degree in green physics to learning to programming, cramming all the computing science courses, how did you end up working on Speakeasy? And where did the idea come from? 

[00:03:04] SB: Yeah. I worked, after my degree, in a number of startups. Enterprise software for the last decade. And my most recent company, LiveRamp, I spent a bunch of time there working on building out the engineering team in London for the company. And to that, a lot of developer tooling, data infrastructure. Really thinking about the internal developer productivity at companies and the impact that has on the end customer as well. 

I think there's a saying that great internal developer productivity means great external developer proactively. Maybe we just made that up. But I'll just say that that's – I very firmly believe in that. 

And so, I ended up working a lot of intel tooling at LiveRamp. One of the really amazing tools that we had built internally, kind of led-born by a chief architect, was an internal API development stack. And the basic idea there was if you want to provide consistent clean API interfaces for your end users to use. 

The best way to do that is internally ensure that every team and every developer is developing the same way. We all kind of, as developers, know Conway's Law, which says that, "In short, you end up shipping the organization that you have internally to your customer." Right? 

And so, if we know that to be true, then you have to always ensure how you develop internally is the way you want to reflect externally. That's often what happens with products. So DevStack, focused on make it very easy for internal developers to define an API and then not have to worry about all the last-mile tooling that it actually takes to get the API live. And talking about ensuring end-to-end type safety. Really well-documented APIs and SDKs that stay in sync. Great and consistent authentication across all your APIs. And making sure that all the access patterns that your customers have are consistent across all of your products. 

I think we did this at LiveRamp. But a number of other companies have achieved this like Stripe, and Twilio and GitHub. But they only do it. So, it's really, really intense platform engineering, right? We at LiveRamp had any engineers focus just on this. 

At companies like Stripe and Twilio, we know that there's massive platform teams whose sole purpose is to ensure that the APIs are consistent in the way they're delivered to their customers. That's the inspiration for Speakeasy, is that building an API is hard. But when you actually think about distribution of the API to developers, it's about 10x size of problem. 

[00:05:48] P: Could you give me a real-world example of a company that uses Speakeasy? Is there any company that you could maybe – and describe how the users – well, how they use it? And what was the main benefit for them? 

[00:06:01] SB: Absolutely. One of the companies that we've been very fortunate to work with from early days is a company called Airbyte. They are a very popular open source developer – piece of development infrastructure. They focus on making it really easy to move data and kind of become this kind of core part of the modern data stack. 

They start as open source and then have launched an API as part of an enterprise offering. And when you launch an API, it can become a key monetization channel for a company. And so, investing in the developer experience and the time to 200 as we call it. How quickly you can get a developer to onboard and actually use the product is critical to adoption and as well as long-term use and maintenance. 

And they realize that when they launched this API to actually achieve that vision of great time to 200, they would have to spend several quarters, several engineers. Have a whole API platform team. And that's all time away from actually core product development. That's what we were very lucky to work with them from early on and help them essentially accelerate that vision. 

And I say accelerate because a lot of companies do have this vision, right? They want a great API. They want a very well-adopted API that essentially is integrated everywhere. But achieving that vision is the difficult part. And so, we helped accelerate that. 

The way we work with Airbyte is twofold. We launched um a set of what we call managed SDKs and a telephone provider for them. They use OpenAPI spec, which is a common API standard. We're able to plug directly into that and host these production-quality interfaces for them in GitHub. Automatically manage them. Create pull requests. As the API changes, keep them up to date. Publish them. 

Essentially, take over this whole pipeline that needs to run outside of actually developing the API. And so, we were able to do that for them in just a quarter, go from launching the API to actually having fully supported interfaces as well as tooling around it. Like basic logging, security, telemetry, things to actually ensure the maintenance of those interfaces is also strong. 

Yeah. Really excited to be working with them. Also as an open source company, excited to watch them continue to grow and monetize as well. And very happy to be a partner with them. 

[00:08:37] P: And since it was your first customer, was there anything specific or surprising that you have learned from Airbyte while you started developing Speakeasy? 

[00:08:45] SB: Absolutely. A product like this is meant to accelerate development. But it's also really interesting because it can help unlock new revenue as well. There's both a bottom line and a top line argumentation for using a product like us, which is, as I mentioned, we help you achieve the vision with a lot fewer engineers spending time on this. And at the same time, help you reach new markets for your API that you previously may not have touched. 

Terraform is a good example. As a company, if you want to launch a Terraform provider, you need several Go engineers learning a very complex development framework. I need to understand Terraform now as an ecosystem. And so, we go to companies. And I think for a lot of folks, realize that working with us means they could actually maybe unlock new developers that they otherwise won't have even talked to. It's time expansion. And I think that that's like an exciting pitch, especially for startups. 

[00:09:52] P: And what is your current price? In your current pricing model, how do you make money? How do you charge the companies that use your software? 

[00:09:59] SB: Yeah. Our current pricing model is based on API operations. An API operation is a single verb in your REST API. Get, post, put, call are all the operations. If you're familiar with schemas like OpenAPI or Postman Collections, a single operation ID is how we charge. And we charge on a per month basis. We don't discriminate between the languages. 

If you're using an API spec with 10 operations and three languages, that's 30 operations. And we also don't charge per generation. You can continuously change your API every day and we'll always keep it up to date. Keep these SDKs up to date for you and all the tooling around it. 

[00:10:44] P: You only charge per the actual usage and you cut a scale – your pricing will scale with the company that grows. 

[00:10:50] SB: That's right. We don't want to penalize you for e-trading on your API. That's that's something we actually want to encourage. Instead, we we only scale as your API grows and as your business grows. 

[00:11:02] P: And do you also have any kind of free quota for developers that just want to try it out? 

[00:11:06] SB: Yeah, we actually have a very liberal free usage plan. You can actually come to Speakeasy and, at this moment, use everything in the platform for free. The only restriction is that it will all be in our GitHub. The moment you want to actually productionize this, bring it into your GitHub and put in your package manager. That's when you start working with us commercially. But you can actually come and use the product – use all the features with zero paywalls. 

[00:11:34] P: And speaking a little bit more just about APIs in general. I was wondering, what are the most common mistakes that you see that developer make when implementing APIs? 

[00:11:45] SB: Oh, man. That is a can of worms. Where to start? I think even before getting into the problems, I will say that designing an API is something that is almost taken for granted, right? Like all of us learn how to design APIS when we start programming. But designing a truly intuitive API that's easy to use and kind of groc, right? 

As developers, we use that word whenever something just makes sense. Like you start using it and it kind of flows. That's really tough. And so, the kind of problems we see is everything from the design side. How does the API actually reflect the resources that your company is exposing? 

Company to company is very different. There's product philosophy that's involved on do you want to expose the resources? You think about internally, externally. Or do you want to have a completely different layer? I'm not saying those resources in the domain model is usually where a lot of the problem this lie. 

I think the second thing we see is, in terms of API design, it sounds kind of silly. But actually just the naming, right? How do you actually ergonomically structure the API so that when you think about API design, I think you actually have to think about the delivery and how developers use it. If I'm in an IDE and I'm importing in an SDK to work with the API, I really just want to type the company's name, right? I just want to type Acme. Or type in Acme and everything should just flow from there, right? The type-in should essentially guide me through that. 

And so, a lot of people I think, when designing the APIs, don't realize that the API itself is documentation. And the API isn't separate from the docs. A well-designed API can be the documentation that a developer uses. 

Outside of that, a lot of other issues we see. Often, authentication is a common one. These days, schemes like OAuth and OIDC are becoming popular. Those are difficult workflows for the developer to manage. And so, we've spent a lot of time in our SDKs ensuring our SDKs can actually handle those kind of security schemes. Give you automatic token refresh workflows. Reducing the burden on the API consumer. 

A couple of other places we see issues. Just in the way APIs manage different content types is a common problem. Also, polymorphism and inheritance, also a difficult one. That one maybe is a little bit more to do with how open API is designed. And I think that's a whole different conversation. But generally, these are all kind of concepts we see that teams struggle with. 

[00:14:39] P: And what tech did you use to build Speakeasy? And are there any interesting open source technologies that you're leveraging that you think are great?

[00:14:48] SB: Yeah. We built Speakeasy with Go and TypeScript as kind of a core components that our code generation works off of. We use Go lang for actually understanding the APIs to parsing the specifications. Plugging it into people's APIs to middleware. That's all to Go. And then we use TypeScript for actually doing the serialization of the SDKs themselves. Trying to get best of both worlds. 

We've actually open sourced a small repo called Easy Template on our GitHub that is a unique way of using Go's templating system, but with TypeScript actually to do the serialization. We've built a little project that people can check out. If you're a power user of Go templates, you might find this interesting. 

[00:15:37] P: And which cloud provider do you use to run Speakeasy? And why did you make that choice? 

[00:15:43] SB: Yeah. So we are on GCP and Google Cloud. I've worked with Google Cloud extensively when I was at LiveRamp. I think it's a great cloud provider. We chose it specifically because they prioritize developer experience. And as a developer experience company, the vendors we use as well end up reflecting how our technology is shipped. And so, if we prioritize our own developer experience, then it goes a long way towards ensuring our customers have a good DevX as well. 

[00:16:10] P: And while buildings Speakeasy, what was the most challenging technical aspect of building this entire great system that you built? 

[00:16:18] SB: Yeah. I would say that building something like this is a continuous journey. I like to say with the team that every day is day zero. There's always more to be done than they need to iterate. We're still definitely early in the journey. But so far, one of the things we've come to appreciate is, building a product like this, you have immense amount of product surface area to consider. 

We already had seven, eight languages in terms of that we support in multiple stacks indicating with different APIs. APIs are so diverse when you look at them in customer stacks. The way they're designed. The way they're implemented. The frameworks they use. 

And so, we're exposed to essentially the full universe of REST APIs. And dealing with that level of complexity has taught us to prioritize and really start with the things that matter the most to people and then expand over time. I think just learning how to manage that spread while also delivering a high-quality product has been the thing that we have really grown into. 

[00:17:22] P: Because you said that you support at the moment how many languages from the point of view of the SDKs that you generate? 

[00:17:27] SB: Yeah. So we support eight languages. And we're also adding novel generation targets like Terraform, which is not just a new language but also in your runtime as well. 

[00:17:37] P: And does your team or their expert – are they experts in each single of those eight languages? Or do you ever like seek outside help to make sure that the code that you generate is to the best quality? 

[00:17:48] SB: Yeah. A team of all polyglots. We appreciate language design. Think about economics for developers. Same time we understand that languages have communities of their own. We always try to work with at least one or several developer influences every language we go to. 

We just launched Swift. So, iOS. We're working with a developer who's well-known in the Swift ecosystem and kind of specializes there as a consultant to ensure that we are making the right language choices as well. If you're someone who works in a particular language and has really strong opinions and how to do idiomatic design in that language, definitely come talk to us. We're always looking for new influencers to work with. 

[00:18:36] P: And was there any specific environment or language that just gave you a big headache and took a lot of your time to try to figure out how to generate the SDK?

[00:18:46] SB: Yeah. Well. It's a tough question. You're putting me in the spot to throw a particular language under the bus. But no. I think every language is unique. And I would say no particular language is giving us more or less trouble. I would say all of them are equally easy and challenging. They all have things they do well and things that they don't do well. Yeah, no particular language is harder than the other. Yeah. 

[00:19:14] P: And from the point of view of just the general architecture of the Speakeasy, what were the most interesting architectural decisions that you made? And how did they cooperate with your tech stack? 

[00:19:28] SB: Yeah. In terms of architectural decisions that we've made, I think we have worked really hard internally to ensure that we can actually ship our products through a distribution mechanism that customers understand. 

We're a GitHub native product. We work directly in your own environment for GitHub projects. You can almost think of us as an embedded product. And so, making that decision early meant the way we work is different, right? We are a company and a product that works with our customers to serve their end customers. And so, we do this extra hop in our product every time we ship a new feature. 

Yeah. I would say the other thing that we decided really, really early on is that we would, as we scale out to different languages, try very hard to provide kind of consistent DevX across all of them. That's also been something that's driven a kind of core decision-making from the get-go, is that we want to optimize every language idiomatics. But at the same time, we want to provide consistency as well. It's a very fine balance to work. 

And then finally, the last thing I'll add is we want to meet developers where they are. We work with open standards today like OpenAPI, Postman. And in the future, other specs as well. 

And we may want to propose to the REST ecosystem a new design standard. But I think starting from there is a challenge, right? You have more than 50,000 companies adopting OpenAPI. And so, for us, it's important to help that community drive it forward to the extent that we've even found itself a position on the design board for OpenAPI before known as Moonwalk. I very much believe that you have to help an ecosystem evolve before trying to rip and replace and come up with something new. We work with your API frameworks, your standards as they are today. 

[00:21:34] P: And from the point of view of the security and the reliability of the service, how do you ensure that? And do you ever have the data that – the user data or the data that would normally go to the server of the company that has built the API? Does it ever flow through your services or do they connect – those SDKs, do they connect directly with the APIs? Or do you ever act kind of as a middleman of that data? 

[00:22:02] SB: Yeah. We do have the ability to collect telemetry and usage and the logs from SDKs. But we don't do that by default. That's something we're very careful to be very transparent with our customers and say, "We don't collect that unless you strictly enable that with us." By default, we don't collect any logs or any telemetry. 

In terms of SDKs, because they deliver directly to your own version control, we're not a middleman essentially at that point providing an embedded service that runs completely local to your environment. There's no code that's generated that's sent outside. There's no API information that's sent outside. Really the only thing that connects with us is authentication. Just to say, you're using Speakeasy and who you are. Yeah, I pretty much believe that we want to respect the boundaries that you already have with you. 

[00:22:57] P: And could you talk a little bit more about the team and how do you work together? 

[00:23:01] SB: Yeah. We're a remote-first team but have centers of gravity in San Francisco/the West Coast of the US and London. In the UK. I spent a number of years out in London. And then my co-founder, Simon, he grew up in London. And so, we have a little bit of synergy there and have started building out an awesome team. Mostly developer focused-team out there. 

We have two local hubs but always looking for engineers anywhere in the world. I truly believe talent – a great talent can be fun anywhere and can be a differentiation for a company early on. 

That being said, nothing beats in-person iteration and the discussion and time spent together. We very regularly meet up as a team or sub-teams in localized areas and have travel budget around it. If you're going to meet another member of the team and work with them, we kind of have a no questions asked budget to travel. 

[00:24:03] P: And do the two different hubs – both the one in San Francisco and the one in London, do they differ from the perspective of type of work that is being done over there? For example, more engineering work in London or in San Francisco? Or are they kind of more equally the same? 

[00:24:19] SB: Yeah. We do have teams kind of focused on different areas. We do come together, have a collaborative period early in the morning every day. That is good overlap between US and UK. And then time on either side of that is focus time for teams. Mornings and early afternoons in the UK is focus time. And then late morning and afternoons in the US is focus time. 

I think it's really important to build these mod rituals early on. Trying to work the way you work in an office environmental [inaudible 00:24:52] is I think very challenging. There's a saying amongst managers that you either have a fully remote team or a fully in-person team. 

And so, when you're a hybrid team, you have to be fully remote. You can't sit in the middle and end up with this really mixed process. It ends up always disadvantaging the one person who might not be in the same time zone as everyone else. 

[00:25:19] P: And were there anything, any processes or any ideas that you tried to do with your remote team to kind of work remotely better that specifically didn't work and you abandoned them? 

[00:25:32] SB: That's really an interesting question. I think something that we did really early on that I'm very happy that we did is everyone we hired, the first four or five people who joined the team, started with Speakeasy doing contracting. And essentially, contracted for several weeks. Got great signal on us as a company. We got a great signal on them as developers and just builders. And they ended up joining the team naturally after that. 

Obviously, that doesn't scale. There's a point where it's very difficult for every interview to be an extended contract. But early on, that was something that we did and I think has just created an early team but great fit and great camaraderie. 

[00:26:18] P: And now when you hire new engineers, do you continue that process of just getting them on the contract first? And how do you select them? What kind of features and characteristics do you look for in engineer that join Speakeasy?

[00:26:31] SB: Absolutely. I think first and foremost, company at this stage, the thing that matters the most to me is ability and speed of iteration. You're essentially doing this random – semi-random walk as a company to find truth, right? You're searching for PMF and trying to figure out what people want. 

In that kind of scenario, the most important thing is that the developers stay really close to the customers. You trade on essentially a daily basis. And not life doesn't move in weeks or months. It's moving daily. And so, the decision-making has to be fluid, which means that developers have to be okay with the ambiguity that comes with that, which is a tough thing, right? A lot of us start our careers in bigger corporate, bigger ecosystems where we end up getting comfortable with fixed roadmaps that have a horizon for many months. But in a company at our stage at the horizon for any decision, it's days, if not a week. And so, being okay with that constant iteration is to me one of the highest, most important things when working with a developer. 

[00:27:40] P: And are you hiring now for any specific positions? 

[00:27:43] SB: Yeah. We are hiring for more developers in the UK, in the US as well. We're still looking for early team members who want to work across the stack from working with CodeGen, LLM APIs. I'm also working with frontend. Great developments experience in US as well. Essentially, all the way through. 

[00:28:05] P: And since I used to – because you just said that your team is split both between London, UK. Now a bit more remote and San Francisco. And I lived in London. I worked in London for a while. And since you have worked and lived in both of the spots of the tech hubs, how do you think personally? How different is the mindset in San Francisco than it is in London? And kind of how do those markets differ? 

[00:28:29] SB: Yeah. London, of course, is a very – I would say it's an earlier market than San Francisco in terms of tech. But it's quickly growing. I think the talent is amazing. You have lots of developers coming from more traditional backgrounds like banking, finance. And when you put them in a high-equity, high-ownership environment, they really excel. 

And then, of course, SF brings the true Silicon Valley spirit of entrepreneurship and building quickly. And so, I think it's a really nice balance to be working with both. And they both have the strengths and weaknesses, of course. 

[00:29:08] P: As we might be getting by being emerged in both at the same time, you might be getting the best of both. 

[00:29:14] SB: We'd like to help. Yeah. And I do hope one day we have HQs in both places and we have developers going between them. But very lucky to be working with amazing teams in both locations. 

[00:29:26] P: And what would be your advice to founders starting tech companies in 2023? 

[00:29:33] SB: Yeah. I mean, the world has changed so much in the last two years and even in the last year since we started. I would say focus on customer value. Focus on something people want to use, want to pay for. I think it can be – it has been quite distracting for the last few years in the world of cheap capital, which is awesome for some startups. But I think there's a lot of distraction away from the kind of core problem that you're trying to solve as an entrepreneur, which is finding what customers want and delivering something that's highly valuable and sticky for them. 

Just kind of relentlessly staying focused and that is important. There can be a lot of hype and a lot of tactics in startup land. And I think it's fantastic to deploy those towards that end goal. But remember, it's all about PMF, right? Everything else is either improves or decreases – 

[00:30:30] P: And the PMF, to kind of extract the acronym. Would that be the product market fit? 

[00:30:36] SB: Exactly. Yeah. Product market fit, number one. Everything else is in service by accelerating it or decelerating it. If you focus on that, I think all the other decisions you're making will either compound that or take away from that. 

[00:30:52] P: And you guys have recently emerged from beta that you have been working on for a while. But actually, you've done the work very, very quickly. And I was wondering, as a developer that want to use your servers, how do I start? 

[00:31:04] SB: Really easy. You can go to our website, hit the try now button and immediately be able to log into our platform to GitHub or Gmail. And yeah, in just a few easy clicks, you can connect your API with us. Start understanding your API, creating SDKs, publishing them. And over time, do more and more to the platform. It's really easy. 

We also have support for many different options like a local development mode where you can use everything to a CLI locally as well. We're very flexible as a company in terms of how we work with our customers. So please do reach out. Love to set up demos, trials, in addition to actually just trying it out yourself. 

[00:31:45] P: And what is the next milestone for Speakeasy? And what are you currently working on? 

[00:31:48] SB: Yeah. We've been really lucky to work with a lot of early customers on this core problem of building high-quality developer surfaces like SDKs. But as we expand from there, we're kind of going up the value chain and thinking more and more about the overall API build process. How companies actually building the APIs, iterating, evolving them and shipping them? 

And so, we're trying to introduce more features around the actual API development. Understanding API schema, evolving, versioning it. The governance side. We'd love to get to a place where, the moment you start building an API, we actually – you consider using Speakeasy to make that API build process a lot easier. 

And from there, there's a very rich road around all of the infrastructure to actually run the API as well. Things like OAuth and rate limiting and caching. There are tons of products to be built and I think a whole ecosystem to evolve here. We're super excited to go out for that broader vision. 

[00:32:48] P: Awesome. Thank you so much for your time. It was great talking with you. 

[00:32:52] SB: Thank you, Pavel. Super excited to be here. 

[00:32:54] P: Thank you so much.

[END]