In this episode of Leaders of Code, Ben Matthews, Senior Director of Engineering at Stack Overflow, sits down with Abhinav Asthana, co-founder and CEO of the API platform Postman. Abhinav shares Postman’s journey, turning a simple side project built to solve personal API development frustrations into a foundational tool for millions of technologists. The conversation touches on the scaling challenges of a hyper-growth engineering team and the critical role of APIs in the age of AI.
The discussion also:
- Focuses on how Postman scaled its engineering team from just three founders to over 400 people.
- Details how Postman uses AI agents to aggregate and summarize developer feedback, providing clarity to the organization.
- Explores how APIs are the key to enabling LLMs to function as true agents by connecting them to live data and workflows. This connection transforms AI from a purely conversational tool into an action-oriented system capable of executing real-world tasks.
Notes
- Connect with Abhinav Asthana.
TRANSCRIPT
Eira May:
Hi, everyone. Welcome to The Stack Overflow Podcast. Today, we have another episode of Leaders of Code, where we chat with tech leaders about the work they're doing, their challenges, their customers, their teams, so much more. My name is Eira May. I am the B2B editor here at Stack Overflow. And today, I'm joined by Ben Matthews, who is our senior director of engineering, as well as by Abhinav Asthana, who is the cofounder and CEO of the API platform Postman. How are you guys today?
Ben Matthews:
Doing great.
Abhinav Asthana:
I'm doing great.
Eira May:
Awesome. Ben, I'll turn it over to you. I know you have some good questions ready for our guest. I don't want to stand in the way of a good conversation. So I will just get out of your way.
Ben Matthews:
Thank you. Yeah. I've been looking forward to being able to pick your brain mostly around just the journey that Postman has taken. I think it's a foundational tool that most technologists know about, have interacted with, and has really helped in testing and understanding the development of APIs. I'd love to hear about how that idea started and how it's gone from the beginnings to where it is now.
Abhinav Asthana:
I would love to share the story, Ben. Thanks for having me here. Yeah. Postman actually started as a side project of mine. I was a developer, intern actually, at Yahoo back in 2009, 2010. My job was basically to build an application that relied on a bunch of APIs. Those APIs would often break. I would not find the right documentation, and we would just stress around wondering whether our build is going to work or not.
And that experience stayed with me in my mind, and then I founded my first company right after college, and we were basically building for multiple front ends, like an iOS app and an Android app and a web app at the same time. So it made sense to not do that thing three times. We built an API, and I saw the same problem again, which was, how do you share your APIs? Do they work or not? Are they well-documented? And is the team on the same page with respect to the API?
And I found myself that I would just basically end up writing code over and over again, which would also be error-prone. So learning from that experience, I built Postman as a side project. I kind of put it out there. At that time, the Chrome Web Store was up and coming, and I found that to be the simplest path, and developers just really loved the product.
They loved the experience. They started giving me feedback about all the things it could do, and I started with something very, very simple, very basic, because everything that I tried at that time was very complicated. It was very cluttered. It was built in a very enterprise-y way, and I wanted something that's really like a tool for developers like me, and that's how we got started.
Ben Matthews:
And I think that's one of the biggest features that you mentioned there that I think, at least for me, really got Postman to be rolling, because I wrote my own internal API testing tools far too often long before that, and they work fine and some were reusable, but what really set it apart was being able to share that between people in my department. So as a developer, how often we would get, "Well, it's working for me." "Well, I'm doing this, and it's not working for me," to eliminate that chatter and to bring people together. I think that feature was what really made it stand out.
Abhinav Asthana:
That's absolutely correct. We kind of had this insight that if you're building an API and you are the only one using it, then it's not going to survive for long. The reason you build an API is for actually someone else. So there is this inherent collaboration or sharing built in into the idea of an API. And I would say that I think developers at that time were not really... They were aware that they did this but was not common knowledge.
And we saw that the biggest productivity boost that people got was when they would share a collection with someone else. And then over time, their teams really standardized on Postman as the way to document and test. And even before they would start writing code, they would actually start in Postman and mock out something. And really, that actually gave us the beginnings of a business model when we started the company in 2014. We saw that this could really become a tool for teams, and we have a business here.
Ben Matthews:
Yeah. That actually is one of the questions I really wanted to know. I think a lot of developers have had good ideas or built things that worked. How did you go from that transition of, "Hey, I have a pretty cool tool," to "Wait. There's a business model here. I can actually widen this and help more people with it"? How did that thought process go?
Abhinav Asthana:
Yeah. So I would say that I tried a lot of things before we hit upon this idea of a collaborative tool as the main starting point. Of course, Postman does a lot more things in the broader platform that hopefully we get to, but I tried everything. I quit my company that I'd founded back in 2012, and I was like, "Let me try open-source donations."
Fun fact, not enough to pay your bills. I was really at the very edge of being thrown out of my house. I was like on the last three months of rent. So open source did not work. We tried then some open-source sponsorships, and that worked a little bit. We tried in-app purchases. That kind of worked a little bit. But really, what we were able to see was that if you sell a product to individual developers, well, they might be excited. But really, when you build a product for businesses, that's when they stay.
And when managers and businesses started asking for this capability, that's when we learned that, "Okay. There is a business model here. There is something that people are willing to pay for." We ran a program. We ran it in beta for a while, and we had about 600, 700 companies in the program, price-tested it, and people are willing to pay.
So that gave us that confidence that we are solving a real need for engineering teams. And actually, with that knowledge, we gave more and more of the product away for free. So we kept adding more stuff. We gave individual developers more free things, and then we were able to charge businesses for a recurring subscription.
Ben Matthews:
Now, that's wonderful. I think the staying power of Postman is something to be noted of. You make an investment into those collections. They're cherished. They're shared. They evolve. We had repositories around what our collections would be and how to reuse them. So I think it really showed, as you say, once you help a business, there is staying power there. There's investment and cultures that build around some of those tools like Postman.
Abhinav Asthana:
Yeah.
Ben Matthews:
But from what I could read, it just started with you, and I think one or two other people is how Postman really started. And now, the company has obviously grown hugely. I'd love to hear about what is that journey like from an engineering point of view, to start with just a couple people sharing code between each other to where it is now. What were some of those big inflection points?
Abhinav Asthana:
From an engineering standpoint, I think I will tell you what we did well and what we did not do so well. So what we did well was we kept things as simple as possible in terms of our architecture and the product, and really did not overcomplicate things. I learned when I was more, I guess, junior as a developer that I was excited about any new framework or any new technology I could get my hands on, and then I would be like, "Wow, I got to try this." And that does not make the product better.
Product's value comes from how people use it, and then it has to meet those criteria. It's performant, reliable, high-quality. And really, the best way for us to achieve it was to keep things simple. We ran things on a single server, not AWS, right at the outset. We kept architecture really tightly controlled. Of course, we did refactorings over time. So keeping things simple and adding features and capability only when necessary when there was huge demand for it was kind of like the North Star.
I would say a mistake that we did, and I guess we were a bit more optimistic about it, we were three founders. So I recruited my coworker from Yahoo as my cofounder, Ankit, and in my first company, Abhijit, who was my intern, joined me as well. So we were like all three developers. Yeah. So we were all coders. We had all worked with each other.
And we were actually working on different parts of the code base, because there was a client tab. There was a back-end server. There was another system. And interestingly, our architecture evolved from that, because I was the owner of the client tab. So there was this whole sub-team that grew which would just do that, and then there was a back-end team.
So there were these three subcultures evolved just because there were three founders who were coding in different aspects of the product then, and actually reconciling. And what I learned was that once a thing is set in motion, like new developers that you add, really just continue from where you left off. And I would say we refactored things to better, cleaner APIs later, but the journey was not really simple. And oftentimes, we would have challenges in scaling with huge demand or adding new capabilities for teams.
And when we definitely went to the enterprise, there was a lot of challenging work to be done in scalability and reliability, and we had to have dedicated focus there. So for a long time, we stayed simple. We probably had about 20, 30 people for about three, four years in, around Series B, which was a $50 million fundraise we did in 2019.
That's when we were about, I'd say, 50 people with the engineering, sales, and marketing in the U.S. Now, we are north of 850 people, which is a much larger company with lots of different functions. At each layer, we went through challenges like how we communicate, what is not working, what to rip out in the way we communicate.
We could fit in a room in an office in the early days, and I've gotten actually just slept at the office. We had one room where all the developers would work together, and then we were just sleeping and coding. That obviously did not scale. So then over time, we added more layers. But I think sometimes we got it right, sometimes not so well.
Ben Matthews:
Yeah. And I'm sure there was plenty of lessons learned, but I really love that you were kind of talking about how people needed to work differently and how they communicate differently. What were some of the big challenges, especially when I'm communicating between teams, of something that started with just three people working on their parts? And now, you have, I imagine, an engineering department of close to... Is it around 250 or so?
Abhinav Asthana:
Yeah. Probably close to 350, 350 to 400.
Ben Matthews:
350?
Abhinav Asthana:
Yeah.
Ben Matthews:
Yeah. That's amazing. So there's a huge difference in a relatively short amount of time of growing to a company this size. What were some of the techniques or styles or ways that you facilitated of saying, "Hey, all these people got to work together. How do I keep them in sync?"
Abhinav Asthana:
Yeah. We have had different iterations of it, and we have gotten better over time, initially making sure that people were focused on a singular goal. So if there was one thing that we wanted to achieve, there was just this one goal that we would try to hit, whether it's scaling on the number of customers we have or whether it's revenue retention, just making sure that we are consistently repeating that, and we tie all threads to that. It was very effective.
I think one thing we also liked and we still do a lot is, I've seen the best outcomes come when engineers understand actually your business model, and they know the customer well. And I guess we had the benefit here, because we are developers building for developers. But sometimes with more complex projects, we've had to get product managers involved. We have had to get designers involved, and making sure that we all stay together in one EPD-type unit and we have clarity of purpose and vision was very critical.
I would say actually one change that I'm very excited about lately is that with AI and APIs working together, we have now been able to get straight to prototyping and actually having product managers and designers just build in the product. Pre-AI, we had to write docs. We had to do Figma prototyping, and we are trying to get rid of as much of that as possible so that everyone is actually really seeing the same vision. And that's been a big post-AI change for us, and has gotten that clarity back and kept complexity in check.
Ben Matthews:
Yeah. The advent of AI has changed a whole lot of how people work, and I think there's still, at least from my experience, there's some areas where you're surprised at how well it speed things up and how many gaps it's bridged. And other times, you're like, "Wow, AI is perfect for this. Well, nope, I was wrong. Hold on, let me try to bring it back."
And I think it's a great kind of learning experience that we're going through. I think it's definitely going to be a big turning point in how we develop when we look back 10 years from now. And you talk about some of the capabilities for your designers. That's what I've observed too. I think how it really empowers people a lot, it's not even just engineers.
I have product managers and designers now that are like, "I was trying to tell you what this does. I just had AI help me actually create this so you can interact with it." And how many gaps in communications that's bridged. So how did you get your teams to be empowered by AI, whether engineering or outside? How did you sort of present that to them and have the value placed in front of them so they could really leverage it?
Abhinav Asthana:
Yeah. So this is something that I would say applies in the pre-AI and post-AI world as well and tied to my previous answer around, how do you keep people in sync? So having engineers have clarity on what people want is something that we reinforce either as a company through our public issue tracker, which is there on GitHub.
So we maintained that and we basically told developers that, "If you want feature requests or you have improvements, just file it here." Kind of like the way open source works, but really actually embracing it, like, "We have to do it." Right? We'd rank, "What are the hardest issues? What are the things we want to really get done?"
And every year, I thought as we got more engineers, the number of issues would come down. It's only gone up. We have now probably 2,000 open feature requests in Postman. And I would say, some days, people are like, "You have too many things." And some days, people are like, "You don't do enough," is like we kind of go through.
So where I think AI has been helpful was that when the scale of this has reached this level, you can't really go through this individually. Even onboarding an engineer, a new PM takes... And it started taking months. To build the right feature, especially for developers, requires clarity across all of these different dimensions of a developer product, and we found out that we were kind of struggling here.
But lately, what we've been able to do is actually build agents on our platform which can aggregate and summarize all this feedback, and we are putting more channels in it, like our support channel or our customer conversations channels, and I can actually ask now agents to say, "What is the problem? Find this across the 13,000 comments that are out there. What is the workaround someone tried to use in Postman or out of Postman, and what do you think is the best solution for them?"
And this has just given massive clarity to the organization, something that took a lot of work to just systematize and refine. Now, we can just really have every engineer be empowered to ask the agent what to do. And it's not like the answer is right, but it's like the process through which you explore these issues. And, of course, we link to wherever someone asks something from so you can go and check whether the agent is hallucinating or not.
So that has been a big unlock, where we can again go back to this as if we are talking to engineers on the other end, and we are able to understand hundreds of issues, hundreds of comments together. So I'm on this agent. We have this integrated in Slack. We have all our product managers, all our designers integrated. You can just chat with it like it's a Slack bot, and you can ask it questions, and you can trace this chain, and then you can go and prototype it also with AI tools. And really, then you find the right API and just go build it. So that's how we are doing it today.
Ben Matthews:
That's actually a really cool use case of using an agent to really go through stuff. I was trying to go through all of our open issues that we have for what we call our public platform. And obviously, over the years, that list has... As you've seen, you've dealt with it. It's gotten longer and longer and longer, and you can only go through them at such a pace, and we've used AI to say, "Tell me which ones are related. Which ones are most common?"
And like you said, sometimes it's not right. It has overloaded the term data way too much. That's not what data means in that case, but it's really helpful. I frame it to a lot of people, at least for us, AI isn't doing something we couldn't do before. It's just doing all that tedious stuff that we didn't want to do, that we can give and have our people focus on creative solutions on things and new ideas. It's freed up a whole lot of time for that point of view. So I'd love that.
And even if you don't mind me talking about something I see on Postman, I actually love the opening line right on your website that AI needs context. And I think that is such a very concise way of most of the time when I complain about, "Hey, I didn't quite get it right when I tried to use it for coding," is that it lacks context and nuance of what I'm trying to deal with. And I see Postman is trying to actually give that context through these APIs. Could you talk a little bit about how you productize that and what needs you saw in bringing that into Postman?
Abhinav Asthana:
Yeah. I mean, APIs are essential for useful, working AI. The idea is embedded in this notion of agents. LLMs can tell you a lot of things and generate a lot of things, but it's only when you actually connect them with APIs they become real agents. And even for those agents to work, they need the right information with them, whether it's real time or whether it's through aggregated data sources or a workflow that you're trying to execute.
Really through APIs is how AI meets the real world. So what I think we have been investing in and looking at is, what are all the areas where real-world businesses or engineering teams would be trying to make AI work for them? And the first step is just making sure you have the right APIs. I think MCP has been the most prominent example here where people are able to build some MCP tools and connect them to LLM-based agents.
We saw some traction in the early part of the year with MCP server generation that we launched on our public network. So you could take a public API and create an MCP server out of it and plug it into cloud or Cursor, and people love that experience, because for the first time, they could see, "Okay. The stuff that I have in my systems can be actually actioned upon by these agents." And now, we are bringing that to private APIs within Postman. So there's been a huge demand for that.
I think people are still... They're early. It probably mimic our journey. We started with simple tools, "Hey, we could do this, and this sounds pretty cool." But slowly, your needs grow with time where you want more data, more context to come in. I mean, still the fundamental limitation of LLMs lies around the context window and their ability to fit that much context in and still be coherent over time. So I think a lot of engineering work is going to be around, what are your APIs? What do you kind of systematize and put it into the power of the LLM and make it work? So that's broadly what we mean when we are talking about AI needs that context.
Ben Matthews:
I think that's a really accurate assessment from what we've seen, what I've experienced. Being able to provide that context, it just provides so much value. But how do you think the consumption or utilization of APIs might change with the new advent of AI? I mean, it's touching so many different parts. Do you think people might be creating them in new ways and consuming them in new ways with new paradigms, new signatures? How do you see that going?
Abhinav Asthana:
Yeah. All of the above. It goes back to our story. I was actually surprised how much adoption of Postman was there organically. I think I was mentioning to you before this call started, I actually had posted on Stack Overflow, like, "Hey, I'm building Postman." And developers grabbed that answer and went on it. But really one other theme around it was that the mobile era, the cloud era was also beginning, and people were basically going through this platform shift to make these devices that are constantly connected to the cloud work.
That's why you were building all these APIs in the first place, and that was the factor for, we believe, the downstream demand for tools like Postman. And I think in the era that we ran was that we have this new app form factor of agents, and every company is either going to be using agents or building agents, or you're going to be having new types of companies who are just agentic companies.
All these agents will have to talk to each other at some point, and all of these agents will be powered by the existing infrastructure that has been built in the form of APIs. So I see new interaction patterns emerging, some of that you already see. APIs have to be more conversational. They have to be more... Instead of dumping 1,000 lines of JSON, with MCP, you probably want to make the experience a bit more conversational, and the API has to be a bit different.
So I think we'll see new types of interaction patterns by users drive more and more demand for agents, and those agents will then have to just do APIs a bit differently. I would say we are still in the very early phases of people figuring this out. I think there are lots of fun challenges ahead. Over time, the demand for APIs will just grow and grow from here.
Ben Matthews:
Yeah. And I think you're right. We are still figuring this out. I think from almost month to month, it feels like the paradigms around it are shifting. New capabilities are presenting themselves. And even you talk about the advent of agents growing, which I think is obvious, and they're super powerful. Do you think there's going to be a time where it's just we're building agent-to-agent conversations at this point? Are humans going to be taken out of the loop?
Abhinav Asthana:
It's actually, what I was going to say next as well was we are in this phase like, I would say, the early days of the internet. People believed that if they just put a web server and did not have a login, all their data was secure, and then hackers found out five years later there are all these open servers lying around there for the taking.
Ben Matthews:
Yeah. The good old days.
Abhinav Asthana:
And we are kind of in this phase with agents. Right? Everybody is building agents. Yeah. Yeah. And they're back. It's like a developer's land. Everybody is building agents. On my way to work today, I learned there was a mom meetup somewhere where people are vibe coding apps, which is great. But I think when you go to serious, real-world applications which have data, which have workflows that deal with payments, money, or some form of secure transactions, this will need more form of control and will need better engineering practices that we are still trying to figure out what are the best practices here are.
I think they just need to keep up with those accelerating demands. I think many things still have to be figured out where it can be done easily. So we are in this interesting phase. Right? We are using AI for writing apps of the form factor of yesterday. We'll build web apps. We'll build mobile apps, but the apps of tomorrow still have technology that needs to be figured out. So we are kind of in this very, very interesting times in the world of engineering.
Ben Matthews:
Yeah. It's a great time to get into it too. I was talking with some students at a university I went to, and I realized that the aha moment I talk about sometimes has totally changed. For me, the first time I really got into coding was when I started writing a program and just making something on the screen move. I typed something in, it came back, and this was like "Hello, World!" stuff. But I was like, "Wow, I did that."
That aha moment is now shifting with the advent of vibe coding. No one's surprised I got it to say, "Hello, World!" now. People are like, their aha moment is, "I created a whole app just by talking to it." So I agree, the shift in how people are going to get into the industry, how they grow in the industry. It's a very interesting time to see what that path is going to look like.
Abhinav Asthana:
Yeah. Yeah. I would say they encountered the oops moment right now. They change something, and they're like, "Oops, what happened?" And then either you figure out you're going to debug it and go forward. Otherwise, the aha stays that way, but I know exactly what you're saying.
Ben Matthews:
That's true. Maybe that's when they get really interested into writing code, like, "My vibe coding failed. I actually had to fix it myself." And the oops leads to the aha. That's great. So Postman obviously has a big level of adoption. And as it grows, I'm curious, how do you monitor and see how people use it to guide it to whatever the next set of features or the next set of customers? What are some of the indications that you look for in the market or from your customers to see, "This is the next step I want to take in the application"?
Abhinav Asthana:
Yeah. So we are constantly listening from all forms of different sources. Developers, thankfully, are very vocal about their needs and what they want, what they don't want. As I mentioned, our public sources are a big source of feedback for us. We also are big users of our own product. So we call Postman engineering like our first customer. We have to prove that we will use the capabilities we built, and do our engineers love it? And if they love it, then it makes sense to bring that to market. So we definitely apply that filter.
A lot of stuff at this scale right now comes from large customers, or any customer for that matter. But typically, when we are entering bigger and bigger markets, that's where we like to make sure that customer needs are being considered and we are responding to. I'd say that with end user feedback, like support and those public trackers, are very meaningful as a source. And generally, those practices apply to end users in large enterprises as well.
But oftentimes, we also have to just go to the customer and find out exactly what they're trying to solve. And I meet customers every week, every day sometimes, and I try to actually just sit with them and see how they're using Postman, and that tells me a lot more than whatever they write. It's very educational for us. So we call this reverse demos where customers are like, "Yeah. I'm trying to tell you, but I'm just going to show you what I'm trying to do, and then you learn from it." So that's a big source.
And the best way to do this is actually just go to engineering teams directly wherever we are fortunate to and sit with them. I think the sum total of all of this gives us certain patterns that we can build into the product, and that's how we continue evolving. I think the other side of it is just the evolution of technology.
So like I mentioned with MCP, that is something we didn't even wait for. We got a team together, and we said, "MCP is going to be a thing. Developers are adopting it. Let's just go build the best MCP client out there," or with AI protocol capabilities. We knew that lots of developers are going to be trying out AI API. So let's go build that.
So sometimes you also see how these technology shifts are happening, and we design for that. And finally, I think the hardest problems are really around how teams and organizations work together. Oftentimes, the way people say they are doing engineering is not what it reflects in large organizations. There's a lot of legacy code. There's a lot of legacy infrastructure, and sometimes it takes a while to just understand what they're talking about, while in Silicon Valley, everybody is kind of like, "Oh, yeah. There's not going to be any engineers." When you go to companies that have hundreds of billions of dollars of revenue, they're running mainframes at times. So you have to go understand those nuances as well.
Ben Matthews:
So, Abhinav, in five years, if we were going to look back and see this big change, this big time, because I agree. I think there's a lot that's still forming, and I think MCP was one of them. I was talking on another podcast about how I think for AI to really be comfortable for us to really understand what it's going to do or not, it's going to take maybe two, three, maybe four more standardized things.
I think MCP became one of them. That's one of the things that's going to stick around. That was sort of a protocol, and you kind of had the foresight to try to bring that into your app. So if we were going to look back in five years or so, what areas do you think also needs to firm up for us to say, "I understand AI," and how I'm supposed to use it as an engineer? And that's a big question.
Abhinav Asthana:
Yeah. Yeah. It's very hard to predict. I think in the AI line, the way we look at it is, what's happening this week, and what things are going to change next week? A safe assumption for the next four years is going to be that code as a thing is pretty commoditized at this point. Even writing prettier code or... Well, people used to worry about tabs and spaces a while ago. That was a big debate. Right? And I think those things, people just don't talk about it anymore.
I think the broader reason is people really think about, "Okay. Am I..." They're shifting to evaluating code versus really thinking, "I'm the one writing it." And there are pros and cons for that. I don't know where we'll land. My belief always was that engineers specifically like their craft to be... They're proud of the code they write, and they're proud of the architectures they build, and maybe the former, the first one is not going to stay as much anymore. Depends on where the marketplace lands.
I think the third thing is going to be, we are definitely going to have less UI. I think we see that right now that we are eliminating a lot of extra UI. I think the core aspects of the UI will stay. But oftentimes, in more complex software, what we'll see is that the UI itself is adaptive. So you can just tell the software to go change my UI, and that would be, I think, the evolution or the way people are going to think about software design.
So UIs that cannot change when you tell them to will look like archaic. So I think that's one thing I can definitely bet on. And this might be a bigger assumption, or rather, I guess now this is already happening, but I think with the importance of data being so massive, that I just think we are not looking at the traditional web in four years at all.
AI has already changed these habits. So the people serving the web with applications will be very, very different, and that means that the way you look at data, the way you look at your APIs is going to be very different the way we have traditionally looked at it, which is all of this stuff is available for free or people will tap in and go start using it.
I think in that world, trust, authenticity actually becomes even more important. So there are these two sides of it. We'll see in four years where we land. Right now, we are in this place that we are just getting more and more AI stuff, and I think we're trying to draw the distinction between what's really authentic, what's human, what do we really like. In four years, I think it's going to be clearer, but I think the core bit of this will stay.
Ben Matthews:
I think that's really accurate, especially around the UI and interaction part. I think in four years, that's going to look totally different than what we're expecting now. So we'll chat again in four or five years, and we'll see how our predictions went.
Abhinav Asthana:
Well, I hope not that long away, but we'll see. We'll see.
Ben Matthews:
My name is Ben Matthews from Stack Overflow. You can find me, @BenMatthews, on Bluesky or Ben Matthews on LinkedIn.
Abhinav Asthana:
My name is Abhinav Asthana. I am on X as a85, and our website is postman.com.
Eira May:
Thank you for listening to this week's episode of Leaders of Code. If you have suggestions for topics you'd like us to cover or guests you want to hear from on future episodes, you can email podcast@stackoverflow.com. My name is Eira May, and I am the B2B editor at Stack Overflow. Thanks, and see you on the next episode of Leaders of Code.