a16z Podcast - a16z Podcast: The API Economy -- The Why, What, and How

Episode Date: March 13, 2018

with Cristina Cordova (@cjc), Augusto Marietti (@sonicaghi), Laura Behrens Wu (@laurabehrenswu), and Sonal Chokshi (@smc90) APIs (application programming interfaces), observe the guests in this episode of the a16z Podcast, can be described as everything from Lego building blocks to Tetris to front doors to even veins in the human body. Because the defining property of APIs is that they're ways to send and receive information between different parts, that is, communicate between software applications (which often map onto different organizational functions/services in a company too). APIs therefore give companies access to data and competencies they wouldn't otherwise have -- or better yet, that they no longer need -- by letting even non-tech and small companies combine these building blocks to get exactly what they want. Which means companies today -- including non-tech companies and small companies -- can focus on their core competency instead, access bigger data, and get superpowers to scale and compete with the Amazons of the world. But what does all this mean for design -- after all, APIs are interfaces between software, not people -- and for other stakeholders (finance, ops, etc.) beyond developers? Who do you sell to? How are APIs changing not only the (inter)face of business today, but how entire companies are being formed from -- or around -- them? This conversation considers all this and more, featuring: Cristina Cordova, who leads partnerships for Stripe, which builds infrastructure for the movement of money including payments processing; Augusto Marietti, CEO and co-founder of Kong, which helps companies manage secure APIs and microservices; Laura Behrens Wu, CEO and co-founder of Shippo, which powers multi-carrier shipping for all kinds of commerce; in conversation with Sonal Chokshi.

The content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security and is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. Hi, everyone. Welcome to the A6 and Z podcast. I'm Sonal. We've been talking a lot about the theme of the API economy lately, from presentations to videos. But in this podcast episode, we wanted to dive into the trend more practical. hearing from those building API first companies and their insights about what people, not only developers and technology businesses, are doing with these application programming interfaces. But before pondering the existential question of what is an API, we began discussing why the API economy matters, to what it means for things like UI design and sales, and overall what APIs mean both practically and philosophically for innovation. Joining us to have this conversation, we have Christina Cordova, who leads partnerships at Stripe, which builds

infrastructure for online commerce, basically any movement of money. You'll hear her voice in the first answer. We have Augusto Marriotti, who's a CEO and co-founder of Kong, which helps manage secure microservice APIs. And then we have Laura Barron's Wu, who is the CEO and co-founder of Shippo, which powers shipping for all kinds of commerce. Sounds like a motley crew of a cast for an episode of the A6 and Z podcast, but we're here to talk about the API economy. We're just really interested in it because it's sort of the evolution of what's happening next in software. And so just to launch things off, how would we define or think of the API economy from each of your perspectives? So maybe 10, 15 years ago

used to need to have someone who knew how to do bookkeeping or accounting and payments and shipping and all of these different services to get up and running. And now you can purely focus on your core competency and like building your really great product and thinking about how you can find these other services, whether it's via API, open source, et cetera, to really make up for the fact that you don't have to be great at all those different things. So APIs kind of give you that leverage as an online business. Well, I was going to say you don't actually necessarily even have to be an online business because one of the most fascinating things that I've seen in the growth of this so-called API economy

is that it's oftentimes a lot of, quote, old-school businesses that aren't even software native or internet native that are using APIs. A lot of retailers who weren't built as e-commerce companies are now moving online as well with bricks and mortar store declining. For example, soap brand ASU started out as a traditional retailer with their little stores everywhere. They now want to expand on their e-commerce presence. The interesting part about e-commerce is that it requires like shipping from the retailer or the warehouse to the end customer and the end customer can be wherever. So like the customers aren't

coming to your store anymore. You need to make sure that the item gets to the customer and the customer is satisfied with that delivery experience. So with that change like traditional retailers are actually very open-minded to figure out what kinds of new technologies can help them get online because it's not their core competency. That's not how they were set up at the very beginning. Right. They're not like necessarily internet native. Exactly. I guess so from your perspective, how would you define this idea of the API economy? Because you're not vested to any one particular type of API. Like you're actually thinking about this as the collective of APIs, for lack of a better phrase. Yeah. We've been around seven, eight years in the API space

from various angles. So I grew up in Italy and either you don't study much mathematics. You start a lot of history though. Yeah. So every time I need answer for the future, I go back in history to find those answers also I'm passionate about history and all over the places I hope we all do that not just everyone who's Italian it's funny

I once heard Mark Newson speak before he went to Apple he was just famous industrial designer and I heard him speak at Art Basel Miami in 2006 because he was the designer of the year for Design Miami and one of the things that he said on stage

and there was like a musly crowd of like 20 people he said that because he hadn't grown up in a place like Italy he grew up in Australia he didn't have the legacy of having history so for him he felt like

it was actually freeing to him not to have history as a thing. Anyway, it was a sidebar. Well, I think we have just so much history. So if you go back in 1901, that's where the assembly line started, but it was not a commercial success. So Airy-four made a commercial success with the Model T in 1906. But what happened there was basically an innovation in speed and efficiency, right? And so what they were doing, basically electricity became this meteorid energy

that you can turn on and off and was powering the assembly line. And the assembly lines were combining peas on components that were not built by you. Okay, so just to break down that analogy, you have the assembly line, but the novelty and the assembly line wasn't just that it was making things speedier and more efficient, but that it was combining things that were not all in-house. Well, it's like the iPhone, you know, it's like all these parts are coming from all over the world, and you know, you're sourcing chips from Qualcomm and putting that into a brand new device, and that's in the physical world, and I think there's a very strong analogy to the software world. And that can be like APIs and open source software

combining together. At least in the assembly line case, when I see something, when I can picture something physical, I can see, oh, all these components, whether it's for a car or an iPhone, they come together into this object that I use. When I look at APIs kind of coming together in that way, I don't actually, it's very abstract. Like, what is the thing? What's the outcome? What's the output at the end of that? Yeah, time and cost. So in the assembly line of every four, you know, you were cutting down time by producing a lot of Model T, but also cost because you were standardizing the process. And then in the cloud computing and the API is a economy era, the electricity is basically cloud computing. You turn it on and off.

Yeah, that's like the utility base, right? And then the assembly line is APIs, open source. They don't give you mass consumption, like in the Model T, but they definitely give you mass distribution that you can play software everywhere in an iPhone, in a car, in a fridge, on the website. And that's all mainly powered through APIs. That's actually the other idea that is interesting about that analogy, because when I think of what Henry Ford did, he wasn't like the first inventor of the car, but the person who made mass manufactured cars, it is his idea around democratizing access to that technology, which is, I think, how I think of APIs in the context of small and medium size, actually any size business. If we take it to like a larger, like a more

modern example, so we're moving from, let's say, physical, building a physical car, right, all the way to, like, let's say a business like Lyft, which is ride sharing service. They don't make any cars, but in the case of Lyft, they're utilizing multiple different API technologies in order to build their product, right? So rather than having to build like mapping and logistic services, they're integrating with Google Maps. Rather than building out like a push notification or phone verification system, they're using Twilio. Rather than having to build their own payment service, they're utilizing Stripe. So that way, they get to bring a service like Lyft to market to, you know, hundreds of thousands of customers without having to build it intent. And I think

the other interesting aspect is like access to data at scale. I really like Stripe Radar where people who are able to just plug into Stripe Radar and prevent fraud in a way. because you've seen fraud across all other customers already, and you're able to use that data and make it accessible to a company just getting started. So it's basically aggregating the insight, which is a classic premise of big data, but not every company has access to that. So while you're having the API, working with an API, you're essentially accessing that power, superpower, without having to have all that in-house.

I have a question here, sort of a cash-22, because one of the things that we've talked a lot about is full-stack companies, and the advantage to them being that you control the user experience end-to-end. And one of the risks of this world and this approach and this mindset is you no longer control that end-to-end. So on one hand, the argument could be that you specialize and it can really let you focus on what you focus. The flip side of that is what happens when you don't have that shipping in-house anymore. How do companies sort of manage and navigate their decision-making around we're going to rely on this company for my API 4X? I'll give you an interesting example.

We work with a company called Shopify, who I'm sure you work with on the shipping side, right? So they power e-commerce, like an e-commerce platform for online businesses. So especially if you are a non-technical business and you want to sell a really great product, but you don't have to worry about managing a store and getting your website up. They manage that for you. And similarly, a key part in an online e-commerce store is payments, right? And so Shopify, rather than building their own payments infrastructure from end to end, said rather than building it ourselves, we'd rather go down the path of working with Stripe

and building on top all of the technology that we have to offer. So how do you get to some point in the path where you say, hey, well, maybe we should just bring this in-house, right? In many ways because you're maybe losing that core competency. If they were to then, you know, a year from now decide, well, why don't we just kind of go and do this ourselves? You know, their CEO said it on like an earnings call fairly recently, that getting to a point where you say, like, we want to bring this in house, like, sure, we could do that

definitely something that Shopify could do but it would effectively require them to get all the way down to the basic rails and start completely from scratch and that would put them so far behind on their real value which actually makes the thing of what you were saying earlier about cloud computing now becoming

the utility because there was a time when people thought that way about the cloud and now it's like a given for not everyone but for a lot of people what's your take on sort of the evolution of how people have embraced the mindset around APIs? Yeah if you go back in electricity everyone had the own electricity power center next to their factories, right?

And then eventually became centralized and then distribute electricity across the world. And that's what cloud computing is, right? Everyone started to build their own data centers. And now eventually, like, going back to the IBM funder vision, where there only be three or five giant computer in the world. So East Street repeats itself. So you just go back and just put the knowledge in there. So it's happening for various reasons.

But at the infrastructure level, you know, there's three different kind of APIs. There's the public APIs, which they're basically API companies, but they're public API accessible. There is partner APIs which are kind of semi-public and you only open it up to mission-critical partners but are not open to everybody and then you have the internal APIs. So you have companies where their main product is the API,

companies like Shippo, Stripe, Twilio, et cetera. And then you have partner APIs where they're open up to a limited set of sub-partners. In fact, on a recent podcast, we had Rigetti and they're actually trying to offer quantum computing through an API, essentially. And then you have this third category, which is... The internal.

So team-to-te-team employees only within the organization. Is that only in big companies? I would say, you know, startup usually start monolithic by building quickly vertically and then has their product market field and they scale to thousand and hundreds of engineer. Then they break down the monolating and they start to have a lot of internal microservice APIs and don't talk to each other internally. Yeah. It's funny you say that because when you talk about the evolution of a company going from monolithic

to breaking out of microservices as sort of this evolution of the company. It reminds me what happened at Netflix, which is where a lot of microservices really originated. And in that sense, the most eye-opening thing for me, we did a podcast with Adrian Cockcroft, is that you think of each microservice with its own API as its own little mini-business unit that a developer literally owns soup to nuts without having to worry about this big organizational Tetris game

of where you fit organizationally. Like you can essentially modularize your business and do more interesting things, specialize or whatever it is, in different ways as a result of having that. Well, it's like breaking down Legos, right? And for example, a company like Stride, they have obviously public APIs, but internally, too, every business, every service is kind of like isolated running. They own microservices, right?

At an enterprise level, you know, 99.9, they're still monolithic, so it's more a 10-year transition that we will see. And what Netflix did, it will happen to Coca-Cola, to McDonald's. So there's a lot of value to be unlocked and to help companies doing this transition from a little-to-microservices. We'd help, obviously, of open-source infrastructure like Docker, Service Discovery, Kubernetes, and you name it. So those will help that transitions,

and what happens is you're going to have a lot of internal APIs stocking to each other. I think in many cases, we very much look at it as API first. You're starting out the company and you're building an API from the get-go. So this is the first category of APIs,

the ones that are, the business is the API? That's what you're calling an API-first business? Correct. Yes. In many ways that you are building the API because you are selling that API to customers. So you are API-first or API-only in some cases. I like API-only,

better. And the reason is because when I think of API first or any blank first, like internet first, web first, I think of it being as more native to the way you think about a company philosophically. So when I think of internet native commerce, I think of Amazon, which never had a brick and mortar legacy. In a similar way where you have like a social media company that starts out that's like mobile only and then it's really like mobile first. And then ideally if they're successful, then they have a web presence and then they have a presence in like so many other places, right? I think, you know, first is how you interact with the service. What's the first thing to interact with the server? You interact first with an API and then with a GUI.

So the first thing you interact with in Stripe, it's an endpoint. That's why API first, because the first thing you interact with. Mobile first will be mobile app, first thing you interact with. That's actually a really good way of putting it. It's also the interface. That's the front door of the business. Like, when you think of a brick and mortar store, now take that as in you're entering through the API. The primary way to access is through the API. But we also have a dashboard built on top of the API. So everyone who's not a developer, because there are other stakeholders at the company that are important as well that need access to shipping data, to payments data, they'll able to

make use of our services as well through the dashboard. And those are for analytics, for one-off transactions, whatever it is, it's just important to keep in mind that while it's API first, there are also other stakeholders in the company that are important in the decision-making process or buying process that need to be involved. And not everyone knows how to integrate an API. So we have this dance between the other stakeholders and the developers. I do want to focus on this other stakeholders and then also where the developers come in. I just realized we never actually stopped to ask like, what is an API?

And I don't mean this in like a, you know, I know an API stands for an application programming interface, the definition. But philosophically, existentially, what is an API from each of your perspectives? How would you define it? Funny because the shipping providers sometimes ask me that question. They're like, what is an API? What do you say? Do you have a different answer for everybody? For me, I mostly say it's a way for our customers to automate their shipping processes.

It's a shipping back end. But they don't want to know any of the technical details because they're not. Yes, exactly. So you don't necessarily have to go deep into this philosophical late night drinks, wine, cigarettes. Oh, yeah. Here's what an API is. I would say that it's a way that you can send us your most critical business and payment information and we'll store that information.

and you can then pull non-sensitive data back into whatever systems that you want to integrate Stripe with. So if you want to send the data that you sent to us like a week ago into your accounting system, you can do that. It's just the way that you interact with Stripe services to process data and then read that data back. Okay? Yeah, I mean, my mom asked me this all the time

to understand what I do. I used to work at Wired, and my mom told people I worked at Wireless. I try a different way. I mean, I tried the puzzle thing. I try the Lego, you know, when you have those four dots on top. Those four dots are the APIs. I tried the door of a house.

So I try kind of different ways, trying to visualize her what an API is. None of those analogies are working? No, I think the door of the house was enough. The soft is the house. And then, you know, you have this door. And that can be the place where you can access to the house. I have to say, out of the ones you just listed, though, My favorite was the Lego with the four little buttons on the top.

That's actually an interesting idea to think about this extrusion that sort of plugs into another thing. I like that, actually. Something about it's very evocative. Well, it's very evocative to microservice. You're building a castle, right? And then the whole little piece with different color, different shapes. Those are the different microservices. And then how they actually connect each other is through four dots or whatever.

Those would be the actual handpoints. Okay, so there is some communication interfacing happening. In your case, you put a dashboard on top of things so other people can. and get information that they need who aren't developers. So when a developer is in an API, what are they looking at? Is it just like a stream of data, code? Like, what is it? What's the it?

So in a lot of cases, it's can you look at the source documentation and get a sense for like what data do I send this interface, this application programming interface? And then once that data is there, how can I pull that data back out? Yeah. Right. And I think a really great API first, API-only company

build a combination of really great, like, source documentation, in addition to almost like a manual, but in the online world, for that documentation. Yeah. So if you are non-technical, then you can read that manual and get a sense for what information can I send and receive. And that manual, you're supposed to be able to read it, even if you're not a payments expert, a shipping expert, like it's supposed to be intuitive for everyone to understand and to know what to send and to know what to receive. I think Stripe did a great job back five, six years ago on documentations because they were I think the first one to innovate

in such a simple thing but it looks simple but actually very complex to make it easy to digest by having a three column structure so you have the resource then you have the endpoint and you have example of the response and so this three column structure now became a mainstream. Back in 2011

it was not clear. All the docs were messy that really brought a lot of innovation in the market because of how simple was to read the docs. So all the person on the receiving end who doesn't necessarily have to be a technical consumer has to know is here's what I can send here's what I can receive and what was the third column on it it was so the endpoints then the resource then you have the actual endpoint with the description and you have I think their response examples with different library so you have PHP ruby Python so it depends what you need you

can switch different library you have code examples of what could you need to to write on top of the endpoint to call the request and then you can even have a console so you can try it out right But that's still the part that is aimed towards developers. And then you're saying that you build dashboards on top of that for everybody else in a business who needs to get what they need. So talk to me about that. Because I'm actually very interested in the design and UI aspects of APIs and everything around it. Yeah. So we've built a dashboard that just reflects everything that happens through the API in the dashboard as well.

It's not meant as the primary way to access Shippo, but you're able to see whatever is going on through the API. And it's for operations people to access to shipping data, for finance people to, to access the shipping costs and all that stuff. And then also for customer support people to know what's going on with the packages where they are. Because when people start writing in about my package is lost, it's damaged, whatever, customer support people need to be able to go into the dashboard

and figure out the tracking information. So that's very Shippo-specific. On a high level, I'd say, it's just important to figure out what are the other stakeholders in the company that need to interact with the data and how can we make it available to them without the developers having to build

custom dashboards for that company. And how do you guys tackle this? If you're solely serving developers, query the API if you need something, right? But the reality is that if you're non-technical, you cannot query the API. And then that requires you to go, like, ask an engineer to do something, which is generally frowned upon. In a number of ways, we've both built a dashboard that enables you to see all the information that you're sending to the API.

And then, more importantly, we actually started getting a number of requests from our customers who came to us and said, I want to see. this data on like a month by month basis. Or I want to see this data split out by country of where my customers are from, right? And so we eventually built a product called Sigma, which actually enables you to effectively query from the Stripe dashboard using SQL. So we built all of these kind of queries as examples. And then you could take them and then you could completely tweak them to make them give you what you want out of the Stripe API. And we built that specifically because we had a lot of finance people, business people, product managers who were not

super technical, who wanted to know more about their business, but weren't able to query the API. For us, the GUI is more an enterprise feature. Devops downloaded and use it, engineers use it. Then when you go in an enterprise relationship, usually you have higher to stick older than ones, obviously, a management console or dashboard. And that one is part of the enterprise package. So you only get this feature and many other, only behind enterprise subscriptions. But really, the GUI is just to show you that the thing is working. But it's built on top of the API. Just, okay, actually, we're processing payment. Actually, we're shipping things. Like, an API is really hard to explain to someone who is

non-technical. So people are having a hard time understanding what's actually going on. It's super abstract. So when you are able to bring something in where you can show them, well, this is the shipping label. These are the buttons you click, and then you get a shipping label. And it's going to happen in an automated way once you've integrated the API, like management gets it. We're really essentially talking about information moving between places, data, transferring, in different ways. You know, I think of the analogy of shipping today. The most transparency you have into a FedEx package is each physical stop it makes.

But because this stuff starts off already machine readable and codified as data, you essentially contract things in the physical world as well as non-physical in ways that you've never been able to before because it is data all throughout. And I was thinking about the analogy and I'm like, yeah, my shoes ended up at my brother's house because I accidentally used that shipping address. But I only know like the first and second stop. I don't actually know every single. bit along the way.

Totally. And it's just fascinating that we have eyes on that. So you're making API calls, but actually, like something is happening in the real world. Like a package is being shipped. Yeah.

It's being transferred. Your phone rings if you use the Twilio API. Yeah, exactly. I love this blending of digital and physical. It's one of my favorite themes. I think the great thing about it as well

is that you have all of this data and all these different places. And now that all of that data is online and in APIs, all the different services that you use can also connect with each other. Yes, exactly. just you as a business or an individual connecting with a bunch of different APIs, but like,

you know, if I want to take this data and like push it into my payroll service or my accounting service or my shipping service, I can do that because everyone is using the same interface for how to communicate. We as an API first company, we also use other APIs like we use Stripe for our payments. We use Twilio to send out tracking notifications. So even like API companies use other APIs to get that. Oh, that's interesting. Actually, another way I discovered to my mom is veins.

Software is a body. APIs are the veins moving the information around. Ooh, I love that. And they take all the information from different organs of the body, which can be payments, shipping, but they move all the information around. So let's actually talk then about when you have this organism, this company. What does it mean for people who are building companies

because you now can build a company that is entirely a set of APIs. So what happens? What changes? So it's easier than ever to become a merchant. You don't need a physical storefront anymore. It's less like upfront cost. You have all of these different Lego pieces to put together and then you have your online store. So you have Shopify that you can use as one piece for Shopify. You don't even have to be a developer. You can use Stripe for payments. You can use shipover shipments. You can use Flexi for warehousing, all that stuff. You just put it together. And then you have your online store and you can focus on what to sell on that online store and how to market it in the best way possible. And you're now able to sell something online easier than ever. You're also competing with the retail giants, like Amazon, Walmart, Target. And then the other benefit, like access to data at scale, becomes important because with getting access to data around whether or not this customer could be fraudulent,

like, that's another benefit you can tap into without having to lose focus on what you're building. And then at a certain point, you get to a level where you want to start thinking about how you can compete with the Amazons of the world? The question that's type of mind for everybody. Right? So you go from like, okay, it's really great to like start a business, but how do you actually scale a business? So in a number of ways, how can you ensure that the services that you're using are actually giving you access to services that you as an individual, even if you tried to build it on your own, wouldn't be able to do? And so it's about giving that power to a business that is so small that like they wouldn't otherwise get that from anywhere else. Even at Apple,

10% of all the pieces are built by Apple actually 90% it comes from outside so what Apple did they build an amazing supply chain right amazing team

and so every software modern software we'll have to build their own kind of supply chain management managing all these dependencies in their software and it's definitely a more complex

work by take out all the operability of actually doing things you're not good at right yeah that's another tradeoff so what I'm hearing so far is this

allows you to specialize it allows you the super scaling access and then you're bringing up the reality that it also has a complexity that it introduces as well in some cases, depending on the type of business you are. There's tradeoffs depending on who you are. So one question I have is like sort of the practical logistics of getting these companies to become more API first or to think, you know, more about what they can do with APIs.

And one of the questions I had is that who you sell to. It really depends. If the company is still small enough, the developers, for sure, the decision maker. But in bigger companies, developers become the influencers. So they do look at different APIs. It's important to have a very good API documentation and client libraries. But the decision of whether or not to switch out their shipping back end that comes from the product manager, that comes from the ops person, it's not necessarily the developer anymore. So we have to make sure that all the needs of the developers are being met, but we also have to convince another person in the company that it's actually the right time or that there is a good reason for them to switch out their shipping component. You're always up against NIH, not invented here syndrome.

But in this case, you're not only up against this introduction of a new idea, you're actually telling them to remove something that's very familiar and safe to them in their company. Because every company has like a shipping dock or, you know, even if it's on a big shipping dock, it's like a little teeny patio with like a little bit of those pallets that people put on Pinterest. Anyway, how do you kind of go up against it? Yeah, so we have customers who are just getting started and then it's to like capture them from the very beginning. But then we have customers, as you mentioned, who already have their shipping operations set up. And then if it's a non-technical decision-maker making the, like looking at different shipping options, they don't really care about if the API is restful, like if we have different client libraries, they just assume we're scalable and reliable.

These are all given for the non-technical person. They care about conversion rates. So shipping affects the buyer decision at checkout. It decreases card abandonment rate. It increases conversion rates. It, like, increases user engagement if you use tracking data in a smart way. So all the main decision makers at e-commerce stores, They want their e-commerce stores to grow.

You're basically selling the benefits, not the features. Exactly. What you get out of it, essentially. And that's, like, another thing that Amazon has introduced. Shipping is no longer a means to an end to get your item from A to B. The buyer at checkout looks at whether shipping is free, whether it meets their expectation around transit times. And if it doesn't, they close the window and they go to Amazon and buy it there. I would say for, especially in the payment space, you could very easily walk into a situation where you're trying to sell payments to payments people within a company.

Why is that bad? In a lot of ways, it's not bad at all. it's just that if you already have this, like, why do I need this? The reason why we're having a conversation is likely something's not going right, ideally. In a case where you're having a conversation with a customer, that customer comes to you and says, hey, we want to launch this brand new product, but our existing payments infrastructure doesn't support it. So we've talked to a lot of companies that, let's say, do like one-time payments because they do, you know, kind of one-time e-commerce transactions. And now they want to launch the equivalent of like a birch box, which is a recurring revenue business. And so the payments infrastructure that you need, is going to be completely different in an example like that. And then another case that's extremely popular for marketplaces, right? You were moving from just accepting this one-time payment to also needing to pay out to all these different constituents. So then you're not just kind of selling the payments person on payments.

You're selling them on payments infrastructure and the ability to move money in a way that they weren't able to before. For us, it's a little bit different because we're an open source company and business. You have a free thing and you need to convince them on how to pay. So 50% of our competition is ourselves. So in open source, what you gain in marketing, you lose it in sales. Ah, that's so true. We talk about this on this podcast, actually.

And so if you go back to Amazon AWS, it became AWS in 2006 with Amazon S3, right? But it was first, they were in internal need, and they built the API internally, and then they open it up. In our case, we're infrastructure, with open source. So developers and DevOps download and use it. But then once we go into, you know, productions and higher-level security, role-based access control, Avability, multi-classer, multi-de-C, then we're going to enterprise conversation. And usually that happens at one or two step above the actual developer engineer, which is software architect, tech lead, or even just VP engineering.

So this is where we sell it to, even though the users are usually DevOps or system engineers of the open source software. Okay, so any parting thoughts now for people who are thinking about entering the API economy, becoming an API company, API first, in whatever forms or flavors, any takeaways? It's thinking about the API in a way that is not too descriptive. So what does it actually do for the business? What's the benefit? And that's especially important if you're talking to stakeholders that are non-technical. So making sure that people understand API as a means to an end.

I would say focus on building an API that really speaks to what you do best. For example, if you look at Dropbox, not an API first or API-only company, but very much a lot of their really great and most successful APIs were focused on sync. which was something that they're particularly great at. So how can you build a product around something that you as an individual company do better than anybody else? It should never be an afterthought. We see a lot of time where, yeah, we have the thing and then let's think later and then we do it like after

and that doesn't really sync well with actually your core purpose. So he has to be not only API first, but you think about 10 years, 20 years, not just let's build this developer portal there with some endpoint and see how it goes. Most of that will fail and you have a giant Fortune 500 that thought their way and just because that they go of the brand but they never went anywhere and nobody used their APIs just because they think like an aftertong

or a satellite thing rather than the future. So making it really core to your business. So build around your core offering and also out of there you can public some of those and make it a business itself as well and that's really what Amazon and AWS did. So trying to replicate that motion.

I think Netflix did that phenomenally in a couple of years but you can really calm them on the fingers. There is not a mainstream of execution like Netflix. More companies should be thinking long term first and in a native not an add-on afterthought way that's great well you guys thank you for joining the a6 and c podcast thank you thanks thanks thanks