The Changelog: Software Development, Open Source - Modern software is built on APIs (Interview)

Episode Date: September 6, 2019

Abhinav Asthana (founder of Postman) joined the show to talk about Postman, an ADE — API Development Environment — that began as open source and is now a full-fledged company that just announced a $50 million dollar Series B. We talk about why Postman has grown so successfully, APIs and their impact to core business factors, what it means to be an API Development Environment (ADE), and how they created one of the most popular API platforms and community.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by DigitalOcean. Guess what?

DigitalOcean recently added MySQL and Redis to their list of managed databases. Their full managed databases lineup now includes the three most popular databases out there for developers, Postgres, MySQL, and Redis. Eliminate the complexity involved in managing, scaling, and securing your database infrastructure. And instead, get back to focusing

on building value for your users. Learn more and get started for free with a $50 credit at do.co.changelog. Again, do.co.changelog. From Changelog Media, you're listening to The Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, we're talking with Abhinav Astana about Postman, an ADE, API development environment that began as open source

and is now a full-fledged company that just announced a $50 million Series B. We talk about why Postman has grown so successfully, APIs and their impact to core business factors, what it means to be an API development environment, and how they created one of the most popular API platforms and community. Let's start off with how you describe Postman as somebody who asks you about it today. Our listeners, they may not have heard of the thing. What do you describe it as?

An API client? What's your description? So it started out as an API client, but it's evolved to what we call an API development environment. And that gives you all the tools that you need to build and test and document APIs. And it has a special flavor to it. It's a collaborative development environment. So you can, you know, while you can always use it as an individual, but you can also work collaboratively with your team. So as it says on the homepage, the only complete ADE system. So we all know what IDE is, integrated development environment, I presume is a new term you all have put on Postman, the API development environment. Is that an

acronym you all made up? Yeah, yeah. You know, we're trying to kind of come up with something. So we would always say, you know, it's an API client and five other things, right? And it would be like, you know, every time you say it, it's like people always remember only the API client part. So for most of our history, we were just an API client for like three, four years while it was a side project. And then as we expanded the product, as people started asking us

for more and more things, we were like, okay, what are the other things that developers use and we can go off of that? And we were like, okay, you have integrated development environments

for your code and you have API dev environments for everything inside that goes into building an API. And these things integrate with each other. So our view was that you have your ID, and you have your AD, and they work seamlessly together. So I guess back when you guys started, when Postman was an API client, if somebody had told you that in 2019 you'd be raising $50 million in a Series B financing round around this API client. Do you think that was crazy to hear back then? Pretty crazy. I mean, the circumstances in which I started Postman was

kind of got out of what I was doing before with a rapidly shrinking bank balance with, I think, six months of rent left. Scary. Yeah, I was like, okay, that's the time when banks start charging fees when your balance goes below a certain amount. And I was like, that's, the postman's doing well. I mean, I was like, it's a good side project, but I wouldn't have imagined the journey at all

from that point onwards. It's been a pretty crazy ride. So did this start as a typical developer scratch-your-own-itch, or were you looking to serve other people from the start? It was primarily myself, typical scratch-your-own-itch project, and I was inspired by other scratch-your-own-itch projects. I was like, you know, I have this problem.

It's not the first time I tried this thing. I was like, you know, I have this problem. And, you know, it's not the first time I tried this thing. I was like, you know, I have a lot of itches. Generally, I actually listed a ton of itches. And I was like, let me try to build something which is my own unique itch. And at least there were like other, you know, clients back then. And I was like, you know, it's not really fitting the bill.

And I like this thing versus that thing. You know, you have to be a little picky too. I mean, developers are picky and I was like, no, it's not really fitting the bill and I like this thing versus that thing. You know, you have to be a little picky too. I mean, developers are picky and I was picky that I don't like this for this reason, that reason. And then I was like, okay, I would build this thing which became Postman. Yeah, I put it up on the Chrome web store and turned out that, you know, this was shared.

Like the pain was shared, the itch was shared by a lot of other developers. Well, I shared your pain and I used Postman back in probably version 1.0 when it was a Chrome extension. Was there a Chrome extension pre-Chrome Web Store or was there always the Web Store? My history is missing. Yeah, no, it was always on the Chrome Web Store. So it started out on the first version of the Chrome platform as a browser extension.

An interesting thing that actually Chrome did was it allowed you to launch a webpage with increased privilege levels inside the browser. So it kind of turned Chrome into like an application, you know, dev environment because you could, you know, access like certain APIs that normally a webpage won't have access to. And I realized that you can send, you know,

local host calls by building a web app and that could have access to. And I realized that you can send local host calls by building a web app, and that could be distributed to other people, while other clients, I think at that time, Hurlit or some other things were web-only clients, and you couldn't access things behind the firewall and stuff. So I found that kind of, I'd say, interesting thing. I mean, other REST clients on Chrome were doing that,

but it appeared on the Chrome web store and then it evolved into a packaged app that Chrome had. So that was the second version of the platform. I think that's when I jumped off the postman train personally because it started to solve problems that I didn't have anymore. I was like, I'm kind of a simple, just give me the REST client thing. Yeah, the Chrome app, was it with Chrome OS, and the Chrome apps became big, and Postman, big, big new version,

sign-ins, sharing, all these things that apparently millions of developers love, but I just didn't happen to be one of them. Yeah, I mean, you can ignore all of that and, you know, continue using it that way. And that way. And respecting everybody's opinion has been like a core philosophy, right? I mean, if you don't want to do something, you will just not be bothered about it. And in fact, there are huge, I mean, millions of developers who prefer things one way or the other. And we try to be, you know, like we try to find a path that they will go in so you can you know ignore all of it continue using it as a rest client but eventually we were surprised by how much value that you know people got from using postman uh you know in a collaborative way and having an account and stuff and uh you know we just as i said right like all of this has been

like a crazy ride we just didn't know ourselves people, everything that we've built in Postman has come from like, you know, when people are like, okay, I really want this. That's when we actually build it. So it's been an evolution. And, you know, of course, there are some things that people like, some things people don't like. It's been okay. Some people think that Postman has been in existence for, you know, more than 10 years. Like they've been using Postman forever. in existence for, you know, more than, say, 10 years. Like, they've been using Postman forever.

And we just sort of tell them, no, no, it was not Postman. I'm probably using something else. Let's go back a little further then to the itch then. What specifically is the itch or was the itch in the early days of Postman that you were solving for? What are the core problems set maybe now or even earlier for API developers? So, you know, I saw a very basic problem that, you know, when you're compiling and running code, all of that, you know, that whole loop can be done on your machine. And, you know, you're on a program, you know, if it has problems or not, you know, if it's

a website that you're developing, you load the website in the browser and if the page works, if it doesn't work, your browser console tells you. But with APIs, things become a little interesting because things are running on somebody else's machine. And I saw that basically to debug APIs and to work with either your own APIs or somebody else's APIs,

you had to send a lot of API calls, you had to tweak parameters, you had to work in places when you didn't have complete documentation. So whether you were figuring stuff out for yourself or for an application that you're supposed to build on somebody else's API, you're just working a lot with APIs and none of those existing tools. So people would write curl commands. You would have a bash history of curl commands. And the better developer would be who has a bigger bash history.

Because, oh, I sent those calls. I'm going to send you those calls. And I'm like, why is that happening? Or somebody had their own code base where they had documented some things in some way. So I saw these disparate ways in which people were working and I myself saw doing different things at different times but I really wanted to just debug and work with APIs

in a little bit more pleasant way. Just remembering the API calls that I had sent before. Nothing more than that. And I don't have to remember like, you know, parameter number 26 in a big API. And pretty printing the responses was big for me back then was like, just just auto format the JSON response or the XML, whatever it is, and make it easy for me to read. And then just save that and just rerun it whenever I want. Yeah, so you know, you have the terminal, and then you scan through the response. And then your eyes would start watering looking at what comes out. So then I saw what I was doing. So I would take the response, put it into an HTML file, load the JSON view extension in Chrome, and it would pretty print

the whole thing. And I'm like, oh, that's pretty cool. But that was like four steps. So I was like, okay, I want all of this in a nice little package. And these things seem to be something I'm doing a lot. And that was the first itch. I think a related problem which got us into building stuff on the collaborative side was when I was with Ankit, my co-founder and CTO at Yahoo. We were building this application together and we were consuming an API and there was no documentation. And we have to figure out what the API was. And we'd run over to our manager's desk. Like, what is the API?

What's the latest version of it? And he'd like do something and show us, okay, try this parameter or that parameter. And I was like, I don't want to run to somebody's desk to find out what things are. Right. So that communication problem and that working with APIs a little bit more pleasantly was kind of like the base problems I was looking to solve back then. You were using this as a solo developer, Jared, or were you using this in a collaborative environment where you needed to work with other devs to kind of fine tune the API? solo where I would use it to tinker, you know, to prod at an API and then, you know, get this certain response back and then save that particular request for later so I could try it again. Or when I'm developing my own APIs, of which I'm often the only consumer, so that I can

replay things and make sure that, you know, you can almost run test suites that way. So I was just by myself. And I think when the collaborative tools came in and the, you know, create an account kind of stuff, I was just like, well, it's a little bit more here than I wanted. And I started looking for other things, but a lot of large numbers, right? The more people you serve, you're going to have some people that just doesn't quite fit. And for me at that time, I just jumped off the wagon. I have looked at it recently and, well, boy, it's changed quite a bit since then, but yeah, I was using it completely in a solo context. And so the collaborative tools did not appeal to me

where I'm probably less than half of 1% of people who are like that. Most people are not like me. Most people are in teams more often than not. I don't want to harper that a little too much, but our hypothesis was that it's got to be a pretty sad API that's going to be used by one person, you know? Guilty. All right. The saddest little APIs there are. People who share, who upload a video on YouTube and there's one view, you know? So, I mean, again, I don't like zero in on that because we saw that generally when you're building an API, there's a split between backend and frontend. You know, the API is supposed to be consumed by

other people and a whole host of flows that kick in because APIs allow you to build bigger modular pieces of software which are generally built by teams. So that was our hypothesis and we wanted to kind of respect the individual developer's workflow. But yeah.

And a fair one. I mean, like I said, I'm abnormal in that way. A full stack developer working on small contracts. I am both the frontend and the backend. So I, like I said, I'm abnormal in that way. Full stack developer working on small contracts. I am both the front end and the back end. So I write the API and then I write the API client. And that's pretty rare, I think. So what I always wonder is you have this nice little side project. People are using it.

You're putting more and more into it. And your bank account is dwindling, dwindling. You got your day job and you're wondering, do I pull the trigger? Like, when do I dive into this and raise money or start charging money, build a team? Those are sometimes the hardest decisions it seems. What was the trigger point for you that you said, okay, it's time to make this real?

Yeah, you know, I didn't think of any of that. Because, you know, if you enumerate it that way, it's ridiculous to start a company. You know, why would anybody do it? It's just, you know, it's like you're laying on a bed that looks, you know, pretty neat. You know, the mattress is fluffy, but, you know, the mattress gets pulled out the second day. So I didn't actually, and, you know, there's a bed of nails there the second day. So I didn't actually, and you know, there's a bed of nails there generally. So I didn't think any of that. I think I really enjoyed that feedback loop that I had while working on Postman. And, you know, I loved

building something that, you know, I had had as a problem and I would give it to somebody and they would say that, Hey, you solved this problem for me. And that was the best feeling as such. Of course, you can't live on feelings alone. And I tried a lot of different ways to sustain the project. Like Postman had a donate button and I think less than 0.0001% of people ever donated. And I tried, you know, putting some sponsors in. At that time, there was Mashap, Restlet, and a bunch of other companies. Mashap became Kong, and then Restlet got acquired. So I tried a whole bunch of things. But primarily what I think got me into, you know, doing Postman, so I quit my job, what I had. And I just was like, okay, I don't know what I'm going to do. But I know I like working on Postman. And I don't like to work, I don't know what I'm going to do, but I know I like working on Postman and I don't like to work.

I wouldn't want to work for a big company or any company for a while. So I picked up a consulting gig, which interestingly I had to design a smartphone app. So I always played like both hats in the previous company I was at. Like I was a UX designer, UI designer, as well as a programmer. So for making money on the side, I was like, okay, I can pay rent and I can, you know, sustain myself. So I'm going to do this for two days a week. And for five days a week, I'm going to work on Postman and let's see where it goes. And Ankit at that time was working in Mumbai in India and I was in Bangalore.

So I booked a bus ticket and I was like, I can't afford a plane ride because, you know, bank balance is going to go down. So I'm just going to go to Bombay and I'm going to get my head straight and stay with Ankit and see where it goes. So there were no plans of building a company. It was just, you know, I want to work with somebody I like. That was my hope that Ankit would eventually join. And I want to work on something that people love. And we'll see where that goes.

Ankit being one of your co-founders. Yeah. So you were on the road to your very first co-founder. What was that like? When did you feel like the next step was your next co-founder, which is a name I can't pronounce? Abhijit, right? Abhijit. Yeah. So Ankit, Abhijit and I have this interesting or had this interesting relationship. So I was an

intern at Yahoo working with Ankit and Abhijit was an intern working with me at my first company. So we knew each other through this intern-employee relationship. And Abhijit, so Ankit and I started working together during this time when I quit my previous startup. I got a call from Google saying they want to feature Postman on the Chrome Web Store as one of the featured apps on the new platform. So that was kind of a very encouraging sign. And I think that's when Ankit and I decided to, you know, look at things a little bit more seriously, much more than a side project. And we started looking at people who might be excited about working on it, maybe on the side. And we had a bunch of things like, you know, we had this Newman test runner, we had

this interceptor plugin, which, you know, we like the two of us just couldn't maintain on our own. And we found out that Abhijit was in Bangalore and Abhijit and I had worked in Delhi then. So we kind of picked him out. He was at Walmart Labs and we found he was in the city. And I sent him a note saying that, hey, we're doing this thing. Do you want to work with us? And he's like, yes. And that's it.

Just like that. Just like, yes. Yes. Yes. That's the response you want when you ask me a question like that. want to work with us yes yes i do yeah next next thing was a pull request i think so the very first iterations of postman was an open source project it was a chrome app and because of the notoriety of it being so used and then obviously the call from google sort of perked your ears up and others too to say, we should probably get serious about this.

And so at that point, you weren't really making any money. It was just an open source tool. Is that right? Yep. Then we tried a lot of different ways. So we tried to bootstrap the project. And at that time, I think Postman transitioned. So we tried a whole bunch of ways.

So we tried donations, sponsorships, and looking at it, I was like, okay, I mean, one thing's very painful. And I don't want to do that. So I was just looking for ways to sustain ourselves. And, you know, the donation bit didn't work out as well. The sponsorship thing didn't work out. So we introduced this in-app purchase called Jetpacks, you know, at that time. And the idea was that you buy this $10 in-app purchase, and it'll give you access to automation capabilities that Postman has. And I mean, the funny thing in our heads was that, you know, you have a Postman going on a bicycle from door to door delivering mail, and then you get this cool new version of Postman with jetpacks and he's flying around your town delivering mail. So that was the imagery we had, which gave, you know, which gave Postman its logo that was there today.

So that made a bit of money. And our grand plan was that we're going to be maximum five people working on this thing. And let's figure out what are the most important problems we can solve. And it was enough if you translated dollars to rupees in India, you can pay rent and eat. Like being ramen profitable, that's the term now, which I learned a little later. So we were ramen profitable then. And that's when we had investors reach out saying that, hey, you guys have a lot of traction. And we hear about you from a lot of folks. Have you thought of starting a company?

And by at this time, we were not really incorporated. You know, we were just like three of us working together. What's interesting I hear here is that is I heard donations, which is interesting. And then, Jared, you mentioned earlier the recent announcement of a $50 million Series B. So from donations to $50 million in a Series B, it's an interesting story to consider donations being a monetization strategy to bootstrap to where you're at now. It's really gigantically different. Yeah, I mean, and I wouldn't recommend it.

You wouldn't recommend the, you know, like. You wouldn't recommend the Series B or the donations button? Actually, either, you know, depending on which spectrum you're at. Both of them have their pros and cons, you know. You know, money always comes with. Strings attached. Strings, always. So as long as you're aware.

It's wise of you to wait a little bit too, because I'm sure that you were in a position where you probably could have, you know, for lack of better terms, sold this prototype or at least this big idea. But what you did was you built in some worth. You know, you kind of self-vested your own long-term worth

and you probably retained a good portion of the ownership because of that. I think it was a good decision. You know, I had offers to have me as an employee in other companies, you know, or do postman on the side or acquire postman as a portfolio of another suite of API products. And there were offers to come to the U.S., you know,

and stay in the Bay Area. I think one of the things I learned, so I've been, you know, coding since or used to code from like kind of sixth grade till 2016 and I was the you know CTO right so the CTO title at early stage companies is the guy who does all the work generally and because there's nobody else who can be hired at that point and then there is a person who does the you know sales and marketing side so I was you know I was the person who would be in the background. And I was happy doing that. I loved coding, loved programming.

And what I saw was somebody else could be the creator of an idea. But if it's your idea and you have a particular vision of the idea, you can't give it to somebody else and expect them to execute like the way you are thinking about it. And I was not taking ownership of that idea. And I was like, OK, somebody else will do the talking. Somebody else will do the marketing. So that had been with me since like school days. You know, I would have a friend of mine, all of them are still friends and great people.

But I was like, you know, I just want to code. So with Postman, I was like, you know, I think I've seen this go south in so many different ways that I'm not sure whether I'm going to be great at it, but I'm pretty sure that I'm going to be better than everybody else I've worked with. And I just decided to stick with it. Was that hard for you, stepping outside of your comfort zone to accomplish that? A lot. I mean, you know, when you're spending like 16 hours in front of a computer and then you have to spend 16 hours in front of people, it's a very big change. But I'd say it helped a lot. And I started seeing the value in, you know, kind of starting to empathize better with who's using the product.

Like the first thing I did when we eventually raised our seed round was I came, I bought a ticket to the Bay Area, visited people who were using the product. Like the first thing I did when we eventually raised our seed round was I came, I bought a ticket to the Bay Area, visited people who were using the product, like people I had corresponded with. And they were like, oh, we are using the product this way and that way. So I literally saw Postman running on their screens. And then I heard their stories about how they're using Postman. And it just blew me away.

I was like, that is the bit that I was kind of missing. And then I started getting more into, you know, being open to, you know, talking and listening. And, you know, eventually, of course, you have to learn to lead and stuff. But it was a journey. I didn't learn it in a day. And I don't think I've still gotten any of it figured out. But it's a journey and it's been good for us.

It's interesting how sitting down with a user of a product you're building or have built and how motivating that is to you because you see them using it. And not only do you get that feedback loop going, but you kind of like, you kind of have this, like we're all in this in some way, shape or form to be in relationship with other people. Like in that way, you're able to actually reach out and help other people solve their problems with your tooling. And I can't even imagine how motivating that was for you to actually see people face to

face using Postman. Yeah, it totally changed. I think, you know, kind of like my perspective on what Postman was like, of course, you know, I liked it as a site project and it was fun to work on it and I knew it had value. Once you see how passionate people are about the thing that you've built, actually feel more responsible for it. It's not like you can think of anything. We are very conscious of breaking changes.

So even for you, Gerard, I can say that, okay, you can go and use Postman that way still. And you want to respect that. And when people have invested a part of their life in learning a product that you've built, they've built workflows around it, you know, there are mission critical things

that are happening. I think once you meet them and you see that there are real people, you know, using the product, I mean, we have more than 7 million users that we cite on the website, but what is still important is that, you know, the stories and, you know, use cases of each one of them. And it makes you more responsible. It made

me more responsible. And I did the same thing with every single employee at Postman since then. We fly them out and, you know, we hold meetups. And of course, we tell people this is what Postman can do. But a lot of it is for us to just know, you know, what they're doing with the product. This episode is brought to you by GitPrime. GitPrime helps software teams accelerate their velocity and release products faster by turning historical Git data into easy-to-understand insights and reports. Because past performance predicts future performance, GitPrime can examine your Git data to identify bottlenecks, compare sprints and releases over time,

and enable data-driven discussions about engineering and product development. Shift faster because you know more, not because you're rushing. Thank you. so i'll be now you mentioned the seven million plus developers right there on the home page 300 000 plus companies using this 130 million plus apis a lot of us build things similar to postman or we have tools we have open source projects we got our hobbies and we'd love to have more people using them you don't want to build that one little api for one right no one wants to build that except apparently me but how did you get here because this is a seven million people it's just a large amount and you've had a lot of success over the 2012-2019 seven years. So there had to be some tipping point or some sort of like hockey stick.

There were maybe some features you added early on. Tell us some of the insights that you've learned maybe in retrospect or maybe you knew how to get so many people using and loving this tool. Absolutely, yeah. You know, it's been something, again, I'll be analyzing, looking back, and we have some observations that we then projected kind of forward.

And I think over the last four years, a lot of them have, you know, just turned out right. You know, mentioned that the first thing that we, like our first insight was that, you know, building APIs means groups of people working together. And now you would say, of course, you know, building software means groups of people working together. And now you would say, of course, building software means groups of people working together. But we saw that APIs are a different way to combine larger pieces of software. So you can take open source libraries and you can mash them in and do includes and requires and say that, okay, my software is

more capable because it has these libraries. And what we saw was that, you know, this proliferation of this way of working, you know, through APIs, and that's how fundamentally software was, you know, getting built. So in 2012, 2013, I think Programmable Web listed out a few thousand APIs, but the number of APIs kind of looking at from my experience at Yahoo or at other startups or from the people that we were talking to, it seemed a lot. You know, everybody was building APIs internally for their partners, for, you know, public platforms and stuff. And we saw that as building APIs required groups of people to come together, how do they share what they're working on and how do they make their workflow a little bit better?

So we invented this concept of a postman collection where you could basically put together API calls, could be any set of API calls. It could be like your calls that you debugged and the five calls that don't work for an API. Or these are the 50 API endpoints that my API has. Or this is a definite use case of my API working with Slack's API or Stripe's API. So we said that, okay, the way developers work or the way we work is you're kind, you're kind of in this mode of work, debugging, testing, combining, and you want to share that with somebody else. And the way to do that, you know, is you don't want to build formal documentation for it, right? You're not going to share a repository for it all the time. You don't want to write documentation for it because, you know, forget

use cases, you don't even have documentation for the API that you have built so far. So collections kind of became a very lightweight way for people to share what they were doing. And that established a workflow between, you know, groups of people. So you could create a collection in Postman, you could download it as a JSON file, or upload it as a link, or create a run in Postman button and share it with others. And what created was this inherent viral loop in the product that if you want to recommend using Postman to somebody, not only you are telling them to use Postman, but you're also adding value to what they are doing. So if, again, taking the example of a backend developer, you tested your API in the Postman API client, and you want to give it to a front-end developer that, okay, here's a set of calls that you can use. Put a collection and share it with them, and now they are a little bit ahead.

They don't have to rediscover all the things that you have discovered. not just with internal developer workflows, but also companies like Box and Microsoft and even back then, totally unprompted, started sharing collections publicly and they started talking about it. So I think good developer tools have always had word of mouth traction, but this also added this layer where essentially this network of people

that was coming together to build or work with APIs was using Postman. So we saw that grow pretty fast. And then we have just kept iterating on the product to enable more and more collaborative activities. Like in 2016, I think, we launched this concept of a team library where you could share collections that you're working with all in one page. So it kind of becomes a shared API repository for your team. And then it eventually evolved into this concept of a workspace where you can invite people and work with them in real time, like the way you work on Google Docs or Slack or something for all the things that you're kind of doing together. So we feel that was one very strong thread that ran through, you know, to help

Postman grow. And along with that, I think, you know, just adding more tools to enrich everybody's workflow, right? So now Postman can test for, you know, I mean, hundreds of different kinds of APIs, it already supports, you know, so many different kinds of APIs. It already supports so many different kinds of protocols and so many different ways of working with request bodies and stuff. So we continued all of that. We added more tools to cover more of the workflow. So you can create mock servers in Postman. You can build documentation in Postman.

And I think the only other thing I'd mention is that we knew this nature of developers to kind of try to tinker with the tool to, you know, do things a little bit more efficiently. So we built this JavaScript-based runtime in the product, which gave rise to other use cases like automation testing and chaining, eventually leading up to integrations with CICD systems and whatnot. So we always kept the tool extensible. It was collaborative, so people could share things. And that has helped us grow. And at this point, actually, we have to discover use cases now from, you know, people like, okay, what are you using Postman for? And we know a little bit better. And I think the collaborative stuff is on point. I want to come back to that, because I'm not sure I understand what you mean by there's a JavaScript runtime inside of the tool. Can you tell me how that plays out?

Yeah. So, you know, imagine that you have an API that you want to test across, like, let's say 50 different, across 50 different variations of input parameters, right? So in an API client, you can create 50 different requests, or what you can do is you can create a collection and you can have the request be dynamically created for those parameters and you can loop through it. So Postman has this concept of a pre-request script that can run before you send a request and a post response script, which we call a test script. And these two things are pieces of code that you write, JavaScript code. So it can automate any single thing that you do manually. You can automate it, right?

So you want to send a bunch of API calls. You want to write test automation. You want to chain together API calls, like take the data from one API, put that into another API. You know, if you want to get a CSV dump and then be like, okay, I want to run this API for 10,000 iterations for just data transfer jobs. So we built all of these automation capabilities on top of that runtime. And it gives you access to certain abstractions within Postman. So you can get access to variables. You have a bunch of APIs available for collections. So it

gives you a lot of that ability to mold the tool. Yeah, that sounds really powerful. Thanks for explaining that because it wasn't connecting, but now I totally understand what you're saying. And that sounds like, especially with power tools, they need to be malleable. If you can dream it, you should be able to do it, right? Especially for developers.

So that's really cool. Back to the collaborative bit. I mean, I guess it kind of seems obvious, but I don't think about these things so explicitly all the time collaborative tools are inherently viral because you have to share them with the person that you're collaborating with and they haven't learned of the tool yet then they're being exposed to it right like here here's a postman collection oh what's postman oh it's this thing you know like they have to basically spread it in order to do what they need to do for

their job right to collaborate unless they're like me and they work in a silo so i guess the takeaway there is if you're building collaborative tools and the sharing side or the collaborative side is hard then you're not doing yourself any favors whatsoever did you mention the collections was that a thing you formalized around and made it really easy to just share a link and and pass it on is was there anything that you did around like the landing page for the person who's like not a postman user who gets a collection passed to them share some insights on how you guys really smooth that out and made it shareable yeah yeah i mean you, these were all observations,

right? So we, I mean, as I said, everything that we have built comes from observations or generally what people want. And it's a little bit different than what people say what they want, right? So we noticed that people would download these JSON files, put it into a repository, and then they would have, I mean, people still do that. They're kind of doing that over and over again. And a repository kind of works, but generally when you are working across different teams, you don't have access to the same repository. When you are sharing a public API, you're not, you know, Microsoft is not going to give you access to their code-based repository. So kind of there was this notion of, you know, sharing of a collection and people would describe a sequence of steps that they would do. And we just thought of making that set of steps simple. So the first iteration was you can upload a collection as a link, like the way you share a Google Doc.

You get a link and then you can open that link and now you can use Google Docs with that thing loaded. So you could do that with Postman through the share a link and then import flows we did. And once we did that, then we saw documentation pages appearing where people would list out, go and download Postman, click on this link, click on this button, et cetera, et cetera. And we said that, how can we simplify that? So we built this run in Postman button, which you click the button, a page opens up and you click a button on that page. Or sometimes if it's a JavaScript enabled button, then it just, it's one click to click that button and then you open Postman and the collection gets preloaded for you, right? So a comparative experience there against developer documentation was, if you see most API documentation, it has these curl commands,

right? So you will copy that curl command, put it inside a terminal for one API. Now, if the API has like 200 endpoints, you need to do that 200 times multiplied by the number of times you have variations on that API. So we just simplified kind of all of that. And people saw a lot of value in there. And, you know, just spread more. And we have continuously started, you know, I mean, we've always seen more forms of collaboration kind of coming up. So for internal teams, this itself is not sufficient. They want that, okay, if somebody else updates a collection, then I should get an update right away. If somebody's endpoint changes, if somebody makes an update to documentation, then I should just know right away. And we were like,

okay, we imagine people working in these real-time workspaces. You know, it's what you see is what you get. And the system should automatically store revisions for everybody. And you can diff and merge and fork, all of that. So we try to simplify what the software does for you to help you enable just, you know, collaborate more and more in different settings. And it's still an ongoing process. You know, there are social rules that come into play. There are some companies that are very transparent and we'll invite you to your workspace.

You don't need access control, but there are some companies who are like, okay, no, we want these rules. We don't want people to see all workspaces or all collections. So we want different repository for this set of people and different edit access for that set of people. So now we have been studying these, you know, social groups that have their inside companies and how that intersects with like software development workflows. And yeah,

the first instances of that, which we found out were through, you know, collaboration around like public APIs. Yeah, once you get into private apis especially with access tokens and you know responses there's probably lots of stuff that is sensitive and you at least want good access controls around who sees what but then also have you had any pushback i i don't know does postman store those collections on your guys' infrastructure. And so now you have, you know, some burden of holding on to other people's sensitive API data as well. Yeah, yeah. And, you know, I mean, that's just, you know, one of some of the risks that, I mean, come

with any SaaS cloud-based service. We have certain best practices. We have tried to bake, like, certain defaults in the product. Now that, you know that there's some stuff that will just not be stored on our servers, by definition, you can store API keys and passwords locally, it will not be synced up. So there are lots of these different safeguards that we have had to put in. And people weigh those against the value that they get in terms of better workflow. Many SaaS companies who are providing similar services that you are with regard to sensitive data have tried the on-premise model.

GitHub Enterprise, NPM famously or maybe infamously now have had their two separate products, the public and private package repositories. Is on-premise something that you've thought about? Do you offer it or have you tried that route? We don't have an on-prem version for the cloud based or the syncing stuff that we have, but all of our tools run on-prem technically because Postman is a desktop app that you run in your infrastructure.

We have a command line tool called Newman that can run or integrate with your CICD build. And that is an open source Newman tool that you can integrate within your firewall and it runs on your servers. So it's kind of like a hybrid model, if I may say, where like the tools themselves run mostly on your systems. But for a full scale on-prem solution, like, you know, that's something that we think about. But it's not been, I'd say, a high priority so far. Because of the effort put in, because your customers aren't asking for it. I just wonder how seriously you thought about it.

Yeah, I mean, customers haven't really asked for it. I think generally there are more concerns around, you know, like, how do you access those APIs? And we don't access those APIs. We don't get anything kind of flared from, you know, the client to somebody's APIs. Like, it totally runs on, you know, your infrastructure. So they have more concerns there. Like like how are you accessing our APIs? And we're like, we don't have access to your APIs, you have access to your APIs. So you store the collections, but the bits inside the collections that say,

hit this server on this IP address or whatever it is, is internal to their network. And the result of that never comes back to your cloud sync. Yeah, I mean, by default, it's turned off. You can turn it on if you want to keep it open for a bit. So all these controls are there. Yeah. So it's been something that we talk about with people, and they weigh the pros and cons

of what they're getting. So this CLI, you said its name is Newman. Please tell me this is a Seinfeld reference. Yeah. Newman was the postman in Seinfeld. Yes. Hello, Newman. I'm all over that reference. Newman had a line in, so I'll maybe share just like a bit on why it was called Newman. So Newman had this, I think, line, what he was telling Jerry Senfeld was that, you know, Jerry, do you know like this mail, it always kind of keeps on coming. It just never stops. So he had this whole notion that Newman is running in the background,

you know, running these automations nonstop coupled with your CICD bit. And, you know, it was just like this reference to the postman always having to work in the background. I think Cliff Clavin was also a postman, but he spent all of his time at the bar, so that would have been a bad name. Interesting.

And people like Newman, you know, generally. Well, Jerry hated Newman, but everybody else likes him. Jerry really did hate him, didn't he? Yeah, Jerry hated him a lot.

Despised him. Yeah. If your automation breaks. Like if it's running tests, you know, imagine that your test fails, right?

You're going to hit that thing, right? Which tells you that five things are not working this episode is brought to you by team city team city is a continuous integration and delivery server developed by jet brains that helps you build test and release your software faster it supports all popular build, test, and release your software faster. It supports all popular build tools, test frameworks, version control systems, issue trackers, and cloud platforms out of the box with no plugins required.

TeamCity visualizes your build, test, deploy pipelines, collects statistics on each step, pinpoints the root cause of failures, and suggests which commits might have caused a build failure. The professional version of TeamCity is free, even for commercial use, and lets you set up up to 100 builds and run up to three builds in parallel. For large organizations out there, JetBrains offers TeamCity Enterprise, and right now they're extending a special offer to our listeners. Get additional build agents and new licenses of certain enterprise versions with a 50% discount.

Head to TeamCity.com slash changelog to learn more. Again, to teamcity.com slash changelog to learn more. Again, teamcity.com slash changelog. So we've talked about where Postman came from, what it was, what it's turning into. Maybe we can talk a little bit about your vision for the future. But right now you do pitch it as the most complete ADE. Maybe it's the only ADE because you guys made up the acronym. Maybe not. That being said, there's some competitors out there.

You're now saying use Postman to build your APIs as a full integrated shareable environment. Tell us more about what it looks like today, what features you're adding, and what people can expect if they check it out. So, you know, as I was talking about collections before, right, and as we started understanding a bit more on those collaborative activities that people do when they're building APIs, we saw that people take a lot of different paths. Postman, of course, prescribes one particular workflow, but it's not the workflow that they have or they want to have.

There are lots of variations in how people build APIs. The other thing we saw was when Postman always was about testing APIs or building APIs or an API dev environment, the word API itself was never in the interface. always was about testing APIs or building APIs or an API dev environment. The word API itself was never in the interface for a while. Oh, yeah? Because we always had requests, history. It was like REST client.

Was that what it used to be called, like a REST client? Yeah, I mean, it was called a REST client, but it was implied that when you are sending a request, it's an API request. So we saw that people would take that leap from seeing a collection as a group of things to, okay, it's representing API documentation or it's representing an API test suite. So you're like, okay, what is an, like, what is an API generally, right? Like, do we know how is this abstraction represented in the minds of, you know, our users? And we said that, okay, you know, we should see APIs as a combination of these three things, which we

eventually, you know, found out being recently talked about in this book called Continuous API Management as API is having an interface, an instance, and an implementation, right? So an API has a running instance. So that's the thing that shows you, you know, it runs that code. And then it has an interface, which are the endpoints that are described.

And then there is the implementation, which is the code base, right, which is executing, you know, all of that thing. So we looked at this particular definition, and we saw that essentially, this whole process of building APIs is, you know, going through the cycle of, you know, design, developing, testing and deploying. And people essentially need some direction on how to go about it. So we looked at all of these different activities and said that, okay, Postman is going to define a notion of an API. And it's going to help people go through this workflow. And along this workflow, you will connect all of these different tools and techniques that you use in building that API. So now you have this API tab inside Postman

and you can create a new API. You can give it a name. You can give it a version. You can define the API through a schema. We support OpenAPI, GraphQL, Rammel, and a bunch of other things. And you can generate Postman collections out of that schema.

And those collections could then in turn be turned into mock servers, automation test suites, documentation, monitoring. And it gives you like this place in which you can really see, you know, all those things that an API is and connect to other things where an API is, you know, being represented. So it kind of brings together a lot of these other disparate workflows that existed outside of Postman into Postman, streamlines a lot of those bits that people are already doing. And, you know, people just feel more comfortable that, okay, all these things are kind of in one

place. So that was our first iteration of it. And, you know, of course, you can talk about how it has evolved into, you know, more things. So when did you guys add SOAP support? Because I'm sure that's pretty popular. SOAP, actually we want to support it as a schema as well. Oh really? I was mostly joking. No, actually the launch plan was to support SOAP and GraphQL at the same time.

How was it? Because so many APIs are still in SOAP. People don't know it. So the interesting thing about APIs is that it's very hard to get rid of an API. You have to deprecate an API over a very long period of time unless you're Google, which is you find out on Acid News that the API you're using is not good. They just turn it off the same day, right? Yeah.

But otherwise, you need to transition clients off, and you need to really work through a deprecation plan. So a lot of mission-critical APIs are all SOAP APIs. In fact, a lot of REST APIs are built on top of SOAP APIs, and a lot of GraphQL APIs are built on top of REST APIs. And it's like turtles all the way down. All the way down. Sounds inefficient, but what do I know?

You know, a lot of software development is basically working around the constraints of an organization that built software before you. So it's layers, you know, like all those layers represent, you know, it's like looking at a tree trunk, right? Like you look at the first ring and you're like, okay, this is what happened in the first iteration. Then I'm going to like build a ring around it, build a ring around it.

And every new technology adds a ring around it, doesn't replace anything underlying. Right. You're only ever adding on top. And it's kind of like scar tissue. The more you add, it becomes thicker, harder, more rigid, more difficult to deal with. So yeah, that's just kind of a fact of the world at this point. And our view is that all those APIs are valuable, all those layers are valuable. And we want to enable developers to work with all kinds of APIs across all sorts of different

constructs. So if you have a legacy API, if you want to transition out of that legacy SOAP API to a GraphQL API, you should have SOAP and GraphQL collections testing both APIs in the same place, right? If they're in different places, then it's just harder to, you know, do those things. Or you can build a mock server for the older API and, you know, then, you know, document that and get it tested. And then you transition into, you know, a new thing.

So I think, I mean, all those cases are valuable. In fact, billions of dollars are spent in digital transformations every year, which is basically everybody just trying to figure out what was done 10 years ago. Yeah. So in addition to your JavaScript runtime, you could add a Fortran runtime or a COBOL runtime. Come on now.

Come on, support everything. Fortran. That's the line. I think if there's one advice i had to give to open source developers i'm like just talk to your real users you know yeah so you have this funding you have postman as it is surely when you talk to those investors they weren't interested in postman as it is they were interested in some future for Postman that isn't here yet, but their money will help you get it there. So what does that look like if it comes to fruition and does everything that you hope it will

do? What does the future of Postman look like? So Postman, you know, aims to be the collaborative platform for all APIs, which an organization builds. So within the enterprise or within a company that's building APIs or consuming APIs, that's the place that you go to. And you can branch out and do other things like use other tools, but that's the place where you essentially work with APIs. So we want Postman to be synonymous with anything API related. And an extension of that is as APIs also help businesses or businesses and developers collaborate in building software together. Postman is something that we expect to be the network of all APIs published on Earth, effectively.

And that's how we kind of built the Postman API network for public APIs, and we have Postman Pro and Postman Enterprise for essentially internal APIs. While you're on your way, you also have the second, I guess, annual Postman user conference coming up.

So a lot moving and shaking there. Tell us about this conference. Postman enthusiasts around the world, what's the deal here? So we, as I said in the beginning of our conversation, we love meeting people and

that's when you kind of realize how the product is being used. And hopefully, we can share a few things that we have learned. So the Postman User Conference is a way for some of the best practitioners within the Postman ecosystem to share their practices and knowledge with other members of the Postman community. We had a great first conference last year, and now we're holding a second iteration of that. We expect it's going to continue expanding. And we host meetups and events across the globe now. In fact, a lot of our events are held by people in the community themselves. So it's a way to kind of bring them together, you know, share best practices,

share what we are building for the coming year. And hopefully, you know, everybody has a good time. Yeah, conferences are pretty interesting for brands like this. We see a lot of that happening quite a bit now. And it's certainly a good place to obviously meet up, as you said earlier, face-to-face with some users, which is super motivating, but at the same time, very rewarding in the process to just bake in

deeper relationships. Maybe now that we're kind of like closer to having a full understanding of Postman, its inception to its history to how you've grown to where you are, maybe paint a picture for the future. Where is API development going? What are some of the tooling happening that you're seeing? It's like on the forefront of enabling teams to better collaborate, to better manage, to better version, et cetera. Sure, yeah.

And, you know, we, I mean, first of all, we believe that APIs are essentially the building blocks of modern software. It's just now you kind of get this massive power of functionality and storage with cloud-based tools available to infinitely scale up anything that you want to use. So I think APIs as a general trend will continue to be those building blocks for modern software. Another related trend that we see is everything is kind of API-fied in a way. Businesses are APIs, governments have APIs.

There is a lot of data that is exposed through APIs that's useful in context, in social context, or other things that we can't even hypothesize. If you look at all the data dumps that governments all across the world expose, you know, once a year, those are all becoming APIs where you have real-time information coming from, you know, things on the ground. So that's the other bit we see. I think consumers will have more power due to APIs. That's something that is not talked about as often by

companies because they want to, of course, give you applications to work with. But if we go back to that hacker mindset that you could go into an application, tweak it to your own needs, now things have become much more kind of like, it's like your iPhone, right? It's a MacBook. You can't really do anything with it. You can't tweak it and stuff. And I think APIs give that ability to consumers to, you know, tweak things to their advantage. I think that hopefully pressures companies to, you know, build more and better APIs. I think privacy and the debate around data is a big thing. I mean, all the debates that we have around data these days

are all essentially about APIs. You know, APIs are available for you to put in data, but it's very hard for you to know all the ways in which, you know, a company is kind of tracking you. So I think that's conversation about this debate between applications and consumers and what role APIs is going to play is going to be important.

So that's the context. We feel APIs are very fundamentally important to the software world going forward. I think in terms of tooling, I would divide it into two parts. There are tools for building APIs and tools for consuming APIs or using APIs. Postman plays a role in both sides. And I think that's where one of the advantages of Postman also comes in. And I missed one point that we'll probably talk about in a bit. I think for building APIs, cloud-based tools, development environments have done a lot recently. But really thinking in terms of APIs is still, I'd say, lagging behind.

It's very hard to kind of model an infrastructure. It's very hard to reason about the conceptual architecture of something. And no tools have been built. It's more like a spaghetti that is in your principal architect's head. And we're still trying to reason, OK, we went to microservices, but we really didn't. If you visualize a whole bunch of microservices, it looks like a mess, right? So I think tools there in terms of reasoning conceptually about APIs need a lot more work. We default to using schemas, I think, and text editors, which I'm not that excited about. In terms of using APIs, I think we see a lot there

happening that we didn't anticipate. Like out of that millions of developers that we feel use Postman, a lot of them are first time developers, or first time users of APIs. You know, these are people in marketing, sales, success, people who's, you know, I saw, I think, an article on a conference about how journalists can use data APIs to write better stories, right? And describe how to use Postman for that. So I think anything that makes APIs accessible and more usable, I think Zapier comes to mind,

you know, how you can connect things. IFTTT comes to mind. I think they're still in those early stages of really just connecting things, but not really applying APIs to build like powerful applications. And I would like to see, you know, more things there. And I think more generally, how, you know, the general, you know, non developer who's not invested like five years or 10 years of their life in understanding code, you know, how can they break down applications or this way of working when you're working with code. I think that needs a lot of work.

And I see that kind of class emerging. There are developers who just know what's going on and they know how to fix things, how to build things. And the rest of the people who just know how to turn their machines on and off again. So I think something needs to be done there. You mentioned using APIs is a big thing for you. I would imagine that's probably where your network,

your API directory comes into play is one part is understanding that an API exists and potentially an extension to that would be ways people are using these APIs. So this network, this directory you have, is it APIs that only use Postman? Or is this sort of like agnostic in terms of like it's APIs at large

that people are brands or sharing and consuming? So it could be any API. You know, they just have to publish on the Postman platform. We try to verify them. So we want to make sure that the company that has built the API is publishing on the platform, unlike a moderated list. Because, you know, with using

APIs, you also want to get the latest version of the API as it's secure and things like that. So if you're a company, you can have a Postman account and then publish a bunch of collections with and then we don't really care whether you build the API you know using Postman or if your team uses Postman you just want the API to be there in a form that can be consumed by other Postman users and it's a free service. And you also say on top of that it's the most authentic collection so I would imagine there's some sort of vetting process in there to ensure that the API is, you know, latest version, you know, usable, etc. Yeah, we have a DevRel team that is, you know, it actually builds relationships with the teams who are publishing on Postman.

As I said, one of the criteria is that you need to, if you're publishing, if you're PayPal, right, and you want to publish on the Postman platform, we'll only let PayPal kind of do that. We're not going to have somebody else represent PayPal. And we look at that as a vetting process. In terms of the collections themselves, after you publish your first one, then you can update and add more. That's really up to the publisher. We don't go to that level of granularity. It'll be too much of a vetting, I'd say. But over time, we want to build, we are actually in the process of building more social tools for the community to be able to rate APIs, be able to fork them, be able to submit use cases back to the publisher

and really come together to say, okay, this is a good API versus this is a bad API. Yeah. I mean, right now it seems all you're doing really is just linking out to their developer docs potentially. It doesn't seem like most of the pages are actually on the Postman website. You're just sort of like a link directory for APIs essentially.

Yeah, the website version is a little bit behind. So the app version, if you go to Postman, click on the new button, and see the API network in there. So that's the one you publish to. And we have a new version coming up pretty soon, that will be updated dynamic portal effectively, where you will be able to search for publishers and they will all be listed on the Postman, you know, portal, you would not be directed to search for publishers and they will all be listed on the Postman portal. You would not be directed to other things. We started with that to just see who is publishing with the Run in Postman button.

And those are the first entrance into the official network. And the web version will go some to find meant to better build the user experience out. As of today, the Postman app gives you a ready way to consume these APIs within the app itself. Gotcha. Very cool. Well, hey, congrats on the $50 million. I mean, from donations to $50 million in Series B, that's huge.

Thank you. Got to pinch myself, as always. It's still real. You're not sleeping. You're awake. It's still real. You're not sleeping. You're awake. You're not dreaming. You're awake. Yeah.

I mean, I'd only say, I think, you know, we never really went for a funding milestone as like, you know, marker for success. And I think we have a long way to go. It's a milestone, though. Yeah. And, you know, Postman still has some, I think a thousand feature requests open on our public tracker. And we're like, I don't know what timeline we'll get to it. Either we'll close it or we'll refine it. There's so much to do that I think we're excited

about the journey. So there's lots more to do. But yeah, at this point, it feels awesome. Well, it was fun here in the journey, especially just the early days of, you know, Ron and profitable to where you're at now. It's interesting to see the path that people take in scratching their own itch and actually seeing success. And I would say even also to that, changing the way something like this actually operates you know you're making a big dent in the dev world so we appreciate that thank you so much it's it's been great and it's uh it's been amazing you know i think going from like that first version to seeing uh people you know use it and share like their stories with us uh feels great and the credit goes to the team you know i've been i think on this call but there is a big team out there now.

We are about 150 people strong across San Francisco and Bangalore. We have people across the globe now. So in UK, Portugal, Nigeria. How many engineers? About 75 engineers now. And yeah, an interesting fact I'd mention is that, you know, almost all of our sales are self-serve sales. So people buy the product through the product. We don't do outbound sales.

Sweet. Yeah. So, you know, keep developers happy without annoying emails. That's the good thing. Except on the enterprise side, of course. Yeah. You know, enterprise, so the interesting thing with our motion has been that people reach out

saying that we want the enterprise product because we see so many people using it and what do you have? So, yeah, it's, I mean, it's something that, you know, we're

learning from other companies, I'd say Atlassian and Slack and I think we're still focused on building a valuable product. You know, it might change in the future.

I'm sure there will be a CEO or a CTO who is not day-to-day using Postman, and we'll have to email them. Thank you so much for sharing your time and your story with us. We appreciate it. Thank you so much. Thank you for having me here. All right. Thank you for tuning into this episode of

the changelog. Hey, guess what? We have discussions on every single episode now. So head to changelog.com and discuss this episode.

And if you want to help us grow this show, reach more listeners and influence more developers, do us a favor and give us a rating or review in

iTunes or Apple podcasts. If you use Overcast, give us a star. If you tweet, tweet Podcasts. If you use Overcast, give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it. Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service,

and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo, and our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master or go into your podcast app and search for Changelog Master. You'll find it. Thank you for tuning in this week.

We'll see you again soon.