Subscribe
Share
Share
Embed
In our latest podcast episode, we spoke with T Antonio, Senior API Sales Manager at Mapbox. Previously, T's had experience as an API partnerships director and as an Enterprise Accounts & Partnerships Manager at Postman. In a change of pace for this podcast, we discussed advice on where early API companies should start when building brand recognition and developer affinity. The conversation came down to two ways to get started: partnerships and freemium models.
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/
Building a successful API requires more than just coding.
It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.
In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.
Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.
They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.
They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.
Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.
Thanks for listening again to the API Intersection podcast.
I got a little something different today, so we tend to talk a lot about how to stand up your API program, API design topics, stuff like that.
So we have a different kind of guests today, and I'm pretty excited to get into it.
We've got T Antonio from Map Box, and T is the name here.
I didn't get it wrong.
So it will yell me his name's, not T Antonio.
It's just T to just T.
It's T Antonio.
Yeah, I got it.
And a little bit different co host today with Anna Dorty coming back again.
So Anna, tell us a little bit about yourself and then to walk us through what your role Map box looks like.
Sure.
Sure.
I am the product marketing manager at Stoplight.
And last time I was here, I had been at Stop Light for about a month, so it's been a while now, so I'm really excited to hear from our customers about what they're looking for in our product.
Yeah.
My name is T.
And originally I worked in API partnerships in hospitality, been in APS for eight years.
I was also the first sale tire at Postman, and I currently now work at an API product company called Map Box, which I guess if anyone needs maps in their app or website, hit me up.
Nice.
Well, there's the plug.
Cool.
So I guess you say you've kind of been in APIs, but I thought it was worth noting here that you're working kind of partnerships.
And I think over the last ten years we've seen things shift kind of out of this wide open public API world into more kind of bespoke partnerships.
Yeah.
Sort of a nebulous word right now.
It doesn't have, like, a a true definition or a single definition in APIs APIs, just by the nature of what they are, their integration tech like partnerships.
It just lends itself to any type of partnership.
Originally, I worked in the type of partnership that you want to have where everyone's begging to use your API.
So if you have a huge funnel of people coming in and you're disqualifying which companies you want to work with and take their business, that's the best kind of partnership.
And I did that for several years.
But that's not necessarily like the real like ground truth for most companies, right? Partnerships often are just either more mutual, or you're the one chasing other folks down.
What I see mostly now is with young API companies.
They're really looking at platform partnerships, bi companies that have app stores.
For example, they want to partner with them to become an app in their app store so as to open up a new market, essentially for their customers or to gain customers.
Yeah.
I've heard this approach referred to as like integration marketing, right.
The idea that if you can be listed in kind of the different marketplaces and kind of be more connected with other platforms in the the shared set of customers eyes that that's the best way for people to find out about you because they're coming in the door connected.
Right.
So I guess I'm curious.
We're deciding how to do that right now.
Actually, in my own mind, I still kind of frame everything somewhat around sales just because it's kind of the bottom dollar, like I'm chasing down air for the company, and that's regardless of what company I'm working for.
And so I still think of it as sales, even if we're both mutually getting something super beneficial from it.
I mean, that's really like, even if you're selling something, it should be that way anyway.
But like, the actual commercials of it are kind of confusing or can be confusing.
When does the company know they should start looking for partnerships? At what stage? So.
early.
So I was working with a company recently.
They are twelve employees, so very small API startup, and they are already integrated with, I believe, eight platform partners.
So when it comes to like, should we or shouldn't we take this Avenue to open up a market? My attitude is yes to all of them.
And form partnerships is one of them is like the freemium model.
So is, like all the marketing building a community, having a discord, if you can or Reddit or whatever wherever your people are, do all of it.
Don't pick one because you don't know which one's going to pop off.
Yeah.
So for me, platform partnership is again, app Store sort of functionality where there's a platform that I'm building something on top of, like Shopify Store, for example, is another good place to think about.
You know, like you're in shipping and logistics, for example, you might want to go into all the e commerce platforms and partner with them versus like a direct partnership where there's maybe some sort of true, like, native, like alignment that happens if we're going to use maps.
ahead.
For an example.
I work for mapping API company.
I may have an alignment with a cellular wireless company where we share just a ton of customers.
And there's just a ton of overlap that keeps coming up over and over and over.
So we just decide to build something together, some sort of plan that makes sense for those mutual customers.
Or it's literally just like a handshake agreement of I'll send you some mind.
You send me some of yours and we both gain customers.
Got it.
Versus for Map box.
I guess the customer would be.
I want to put Maps into my product and I'm going to pay you on some basis to use that.
Yeah.
I mean, that's the basis of it.
We have map Box has more than just base maps.
We have geocoding navigation, a lot of other sort of deep rooted tech automotive.
But yes, in short, if you want to place maps, like, if you're the next Strava, for example, and you've got some great outdoor app that you're building, for example, you're going to want to have maps is probably one of the first screen in the app.
You're probably going to come across that box and your research on how to do that.
Got it.
So you mentioned earlier that your advice is to do all of it.
If you're talking to a small startup, right? Who is primarily a couple of devs and maybe an application architect, if they're lucky, they invest their time.
Yeah.
Or how would you recommend that they approach that that idea of doing it all.
That's a great question.
And I don't know that I've cracked the code on that.
Aside from just working a lot, maybe contracting some work out, and then it comes down to funding and finding employees that can do it, begging for community help wherever you can.
That's like the plight of, like, gritty founders.
But on the point of saying that isn't to say, like, if you have to do every single thing, it's just sort of the attitude of no one thing is going to get you there.
So you got to try every single option that you have available to you.
Even if you truly believe in your product and the business value of your product, you don't know who's going to latch on to it or find it unless you really do the work.
Yeah.
Hey.
I've heard a rumor that if you build it, they will come.
But I just haven't seen that happen ever in my life.
So I heard that that can happen.
And maybe it does.
For some companies, like Google is a good example.
I guess if that happening in Facebook, where it's just like the NPS must have just been outrageous.
But majority of the time, I see people having to chase down their customers, you might be able to relate to that.
Well, yeah.
I don't know.
I don't know.
We're in a weird meta space within API.
Yeah.
I understand that.
I worked a postman, so yeah, I get it.
Yeah, but it is true that there's a whole life cycle of tools and products that have to think about how we connect with them.
That sort of thing, which I think goes back to something you mentioned earlier when you were going on the kind of theoretical situation of a cell phone provider got a lot of overlap.
yeah.
The only thing I would say just to shift maybe a little bit of that mindset is even though that's true.
Like if I'm selling a product to you and you're my customer that you've bought it for me, if I have the mentality of like, you're not just a customer, you're sort of like this partner where I'm going to do things for you that maybe don't directly contribute to me earning money that I had a lot of success with that.
So I try to like, still, even though it is direct sales, I still try to keep that in the back of my mind.
I just do the right thing, you know, just like, be nice to the people you work with in general, if they ask you for something like make it a priority anyway.
So if you're going to email me something, I'm probably going to respond within 24 hours, regardless of whether or not it benefits me towards making my target for the quarter.
Yeah.
I mean, having done some of this, like, partner program definition stuff before, I think the other piece I like to think about a lot is what's the relationship type in kind of helping segment what are your different kinds of partners? So you mentioned, like, you got platform partners, and it sounded like you were talking about maybe kind of marketing type partnerships where it's like, hey, let's you know, co market some functionality that we've built together, which for me, is always like a great starting point, because to your point, a lot of times, those are just on a handshake.
Yeah.
Co marketing, co selling.
Yes.
You don't have to get the lawyers involved, right.
Yeah.
And you can share some customer value and not necessarily have to empty the bank on one side of the equation to do it.
yeah.
Cool.
I mean, they can go as deep as to co productizing.
Also, it depends on how tight you are and with the commercials if they're happening, commercials put in place.
But the ideal is to be like if a customer is buying another company's product that my product also comes along with it, add a value, add to them.
And then there's some sort of commercial exchange that happens on the back end.
But that gets really complicated.
Yeah.
The kind of bundling type arrangements.
Yeah.
I'd like to transition this conversation into something you mentioned briefly, which is the understanding of premium.
So I would assume that a lot of people in our audience are perhaps on the fringe end of understanding what premium is.
Yeah.
Sure.
So premium generally, as a model, is allowing some sort of sign up and usage of your product for free.
However, you define it some sort of free level of usage that comes with at some point, hopefully a purchase down the road knowing that there's going to be this long, long, long tail of free users that are signing up and learning about your product and maybe getting some value from it.
But some sort of break point where they have to either add a credit card to their account and start getting charged on a credit card or get their company involved to purchase the product for larger scale usage.
So all the API companies I think I've worked for well, at least in the past ten recent years have all had free medium models, and in my opinion, it works.
I love it.
I love from, like, on the sales side.
I love having a super long free or a free long tail to sell into.
So it's great for sales.
What are the benefits? Yeah.
What's great about it? Go ahead.
Yeah.
In the simplest form, just to give you a very simple example, like Aggregating, all the domain sign up, sign up of a company.
We'll just say Chase dot com or something like Aggregating.
Okay.
You've had 50 people, 50 different developers within your company.
Sign up for a free account.
What's that about? It opens up the door for so much conversation that I can just drill into, and that sort of becomes the most valuable sales motion I can do.
So I love it that's, like most of the error are brought in, has been through that sort of conversation.
Yes, a postman for sure.
That was the value because postman has a lot of collaboration functionality.
It's not.
But with that, it can be something as simple as like, hey, procurement and security team.
Did you know about this? You know, right.
Sure.
The risk.
Exactly.
I've sold in through that Avenue, and then they shake out the right people that I need to talk to.
And then it could be something like super well designed, which I haven't seen any API companies get this right completely right yet.
But I know what's going to happen eventually is SSL is like the start of it single sign on where you can offer that product.
And then you've got all these free users that somehow become aware that SSO exists within your product.
What I'm looking for down the road is for API companies with freemium models to really create like this, especially around domain sign ups that are targeted customers in the UI that they have for dashboards analytics of the customers API usage to really build in an experience of how many other people at your company exist within this application, visually shared across everyone and the benefits right in the application so that someone like me, like a human, doesn't have to go and interfere with that experience.
It's already known.
And then when I do come in, all the 25 or 50 people who have ever signed up for the product, they know why I'm coming to knock it on the door.
There's no surprises.
That's incredibly interesting.
It speaks to a value prop of visibility that many people who are building their program just don't simply have.
Yeah.
They don't have the visibility across the organization to see who's using it.
I mean, I would love to see this.
That's an interesting idea.
And I would love to go work for that company if you have that built right now and you call me, no one does it.
I don't know why.
I guess I suspect that it's like to the engineering Department.
It's not cultivated to have, like, sales functionality in the application from day one.
So I think by the time they start hiring folks like me who are begging for this sort of stuff.
It's kind of late.
Interesting.
Now the other piece of premium, I guess, to take it out of why is it good for running your business to set things up this way is also for prospective customers.
My tagline for this is like, developers try business buys.
And if you don't have a way for developers to try something, then you have very little chance of convincing the business stakeholders.
You have the checkbook to actually sign it.
Yeah.
So do you look at kind of developer activity and how they're engaging in the free side? It gives you some signal that they may be ripe for conversion.
Yeah, I do.
So my attitude on this is like Twilio got it right.
Like, a decade ago and they were saying, Ask your developer that whole famous campaign at this point, probably the best API marketing campaign ever.
I love selling in three developers, because that's where the rubber meets the road.
Like, they're the best Champions.
I don't sell top down very often through an organization.
It's just like, always building really cool relationships with developers.
Like, figure out what they care about, especially like, passion developers who really love their product or P.
Like, you know, anyone in engineering really that are, like, super into what they're building.
So I do look at their behavior.
I'd say the key indicators, some to a degree.
I only have limited access to what I can see from user behavior that's changing.
I'm actually talking to a really cool startup called Mosev.
They're trying to change that and really give.
They just got some funding.
Yeah, they just got funding.
Yeah, they're growing.
They're awesome.
They're awesome.
So I'm looking forward to seeing them out in wild more because for someone like me, I could get really detailed insights as to who's cranking on our APIs and like, really hammering them and why.
I ask the questions of why.
But right now it's just like user sign ups and aggregating volume.
So user trends last logins to a degree consumption numbers if I have access to them, but not really, like, smart consumption numbers.
It's just sort of like, you know, anyone who's getting near or breaking through the free tier.
there is no, I don't have a blanket statement for that.
Every API is so different.
It really relates to the API in the market that they're in and then, like, the persona of the their customers.
What are their problems they're trying to solve? Right.
Yeah.
And then what are your solutions to those problems for sure.
Yeah.
Yeah.
I do feel like I have to copy out for listeners that if you just glue an API on top of your business and monetize it on a per call basis, you are probably doing it wrong.
And the fact that we're talking to Tea, who's working on Maps and we're referencing things like Twilio.
These are more kind of commoditize able things on volume, which I think is actually the exception and not like, should not be the default state.
And so I like the way that you talked about understand what is the business? How does it work? Who is the customer? Where are they getting value? That stuff will lead you to the right way.
Yeah.
I think in you guys case, it seems like your whole host of product offerings are all pretty tier pricing, usage based.
Yeah.
Right.
I actually kind of like the model we have at Map box.
But I will say something else if you're considering trying to price out your API right now, you may want to go with defining what the value is per industry and get different pricing for each because you could really shoot yourself in the foot by having and industry have too low of pricing, essentially like driving crazy value with very minimal usage of your API.
And like, you really don't want to get yourself in that situation kind of stuff to back all from there.
So I mean, I can't share at the details of maps and that boxes business per se.
But an extreme example would be a company that I guess it's all very specific to to the industry and to the API itself.
But I'll give you an example for Postman.
So Postman has this great headless version of Postman and Command line, and customers can just go nuts getting value off of that.
And as far as I'm aware, I don't know, it's been a few years.
Maybe they've since fixed monetizing that, but that wasn't monetized at all.
So I would have customers getting all sorts of value, like testing their API at scale, like, you know, math testing with this headless version of Postman.
It's like, oh, well, you figure it out.
Okay.
Yeah.
Well, on the next opportunity.
I mean, I think from some other spaces I've been in like, you letting go, like, PayPal.
You don't see PayPal charging you to call the API because going through the process, you're going to create a transaction which inherently has some, you know, some Rev share piece of that transaction.
And so the API's are just a tool to create transactions, the transactions to goal or like in type form where we did forms.
Yeah.
Monetizing.
The API often did make a lot of sense because it's about getting sort of usage and retention, getting folks to actually use the thing.
And automation just creates more usage.
And that's a good thing.
Yeah.
So directly monetizing the API, I think a lot of cases doesn't it doesn't help what your core business model is for a lot of especially SAS products.
I'm consulting with a marketing API company that is creating essentially a gateway into microinfluencers for marketing at scale.
So the idea is that you define what you want to market and how you want to market it on online, and that API will then call out to systems that can actually make the purchases for micro influencers.
And a part of that the way that they were originally thinking of pricing.
This was through the number of creators that each of their customers brings on the platform they wanted to charge per creator.
And I actually kind of discouraged from doing that because I think it's early, so it's hard to tell what KPIs are going to matter, but I really think the number of creators on their platform is actually going to be like one of their biggest platform selling KPIs.
So I was like, you do not want to send back that like, you should allow your customers to invite as many creators the platform as possible.
However, you may not want them to be able to transact beyond $10,000 a month for free or something.
You know, there's got to be some other Breakpoint, but in this particular platform or this particular API, I'm currently leaning towards the actual dollar volume aggregate per month being transacted through the API as like the the limiter for free.
So with some advice you have for developers who are working on APIs that they're hoping to productize? Is it as you're creating features, think about the different people who will be using it and think about the different outcomes that you could monetize? A lot of developers aren't really thinking in that way.
Yeah.
I see.
I think very carefully about it.
Give up a few hours of dead time and think very critically about this.
Ask a lot of questions.
Ask if you have investors, ask your investors.
If you have employees, ask your employees, ask your customers, how do you literally got your customers and your potential customers today? How do you want to be charged for this? Like, what do you think is a fair price? If you don't have ten customers yet, you should be doing that for sure.
That is the only way to, like, get even close to the right answer.
You're probably still going to get it wrong, but you may not get it as painfully wrong as you would if you're not asking these questions and you're only going to figure out the two three years down the road and then you're going to pay someone like me a ton of money to go fix that problem.
Yep.
Another bit I wanted to kind of call out here is throughout talking about this.
We talked about kind of the integration marketing piece, so to speak, of listing in each other's marketplaces and that kind of thing.
But I think the way you were describing some of these things is looking at your platform as a marketplace who's producing who's consuming.
So like, you're mentioning these influencers.
If you think about things in in marketplace terms, you're looking for positive network effects and you can dotted line back to how are you going to build revenue off of that? And so you were saying to incentivize those creators, those kind of high network value people to come on by not putting barriers up.
yeah.
I have too much experience of that happening, at least within the companies that I've worked for.
I've seen it happen to other folks on Shopify is probably one of the best examples of it where it's like, I didn't.
I didn't actually quite know how important that was going to be when it first started.
And I was like, a really good example of how to create an app environment.
And I have to be customers that are doing it now, too.
And I think what they expect the same, some level of success based on that, too.
But short answer is I don't really know how the app marketplace works.
Maybe I should learn more about that and how it interacts with APIs.
Well, I think I think one piece is app marketplaces for sure.
I mean, that's obvious.
Right.
When you glue something called connect on and start connecting with partners, everybody gets it what that means.
But I think sometimes even when there's not sort of an app marketplace per se.
If you're thinking of there quite often when you're building platforms with APIs, there's different audiences that are interacting on that platform.
And if you're thinking about who's producing the value, who's consuming it, and what are those interactions that you can kind of monetize or incentivize? Sometimes it goes back and forth in building that network bigger.
Yeah.
Right.
Come for the value stay for the network kind of thing.
So I think it's applicable in all kinds of places that don't seem obvious initially, and to some extent that that's what can drive you through, which API should we do first? How should we think about monetizing that value to that kind of thing? So I don't know, you know, just maybe I've just worked at too many places of marketplaces.
yeah.
A curious question of like, if I'm building a new API first company, like which API do we build first? It's a really good question.
I've tried.
I'm not ready to be a founder again.
I have some history founding in the past being a startup founder.
But, you know, if I were going to do it again, I think generally Super Super generally, like, search type API's are really useful.
So being able to put out some sort of request for information with some parameters.
And getting an array back of search results through an API is like, probably one of the easiest ways to get started and like, offering value.
But again, this is very situational.
Yeah.
And that's what's weird these days.
Right.
Apis are everywhere.
Yeah.
I'm curious to get your opinion.
I'm very bullish on blockchain decentralized apps.
And like, personally, my decentralized app customers are just crushing it as we film this.
Like, I'm seeing astronomical numbers of usage.
How do you all stop light? See, API is interacting with decentralized apps.
And do you have customers using Stop Light to build their APIs? The central decentralized companies building APIs through Stoplight.
Yeah.
I don't think I can really think of any great cases for it.
Okay.
I think a lot of the decentralized stuff is using different protocols like your blockchain and all that kind of stuff that are sort of a different thing.
Yeah.
Yes.
And there's sort of a little bit more standardized way to do that stuff.
Yeah.
I'm curious to see in the next ten years, I'm like how speaking of, like, API intersect.
Right.
Like, how is blockchain and decentralized apps going to intersect with APIs? I'm really curious.
Yeah.
So that's why I thought maybe you all would have the, like, the tip for me on how that's going to happen.
For my money, I think both things, both things exist in parallel.
So it's fine to have that decentralized network, whatever.
Okay.
But you know, at some point you're going to have to have an app that interacts with that platform, and it probably needs to be able to call API if you're going to have a multi channel presence with Web and mobile and all that stuff, something is going to have to aggregate and pull together that blockchain log and turn it into something meaningful for users.
Exactly.
Yeah.
So that's exactly what I mean.
I'll give you an example.
So I'm well in with a customer of mine called Helium.
So look it up.
If you're interested in decentralized apps that have crypto currencies that are popping off and have real work use cases.
Helium is a customer of mine.
Helium has a secondary community of followers, and I include myself in that.
And some of those folks are building tooling around the data in their blockchain.
Okay.
So, like, different ways to visualize the data in the blockchain or ways to sort of glean information about what's happening in that blockchain.
And I'm like, okay, so one of these community members of developers is going to build an API for this, and I just don't know who's going to do it and when and what the API is going to be, but it's going to happen.
And I imagine this is going to happen many times over with all the decentralized apps that are being built right now.
So we'll say let's look at this podcast a couple of years from now and see if I'm making any sense here if I'm just way off base.
I'm sure we're all terribly wrong.
No.
I think at this point like you can't build any kind of platform without having some kind of API to at least connect those multi channel user interfaces.
I think that part doesn't go away now.
Obviously, the prevalence of things like graph QL making that kind of stuff easier.
That certainly changes what we might imply that API means, as were a lot more things tend to be like Http based today.
Okay.
But you know, what we always see, too, is and we see this a lot with top like customers is like it's the metaphorical tip of the iceberg.
Right.
The externalized APIs are usually only a tiny fraction of the total platform that's being built and decentralized.
Maybe it's not quite not quite that big of a tilt and that you may have less centralized services.
But to your point, like once you have a blockchain out there, you got this activity log going on.
Someone's got aggregated bring meaning to it.
That's going to be, I think, more traditional architecture bits, at least for some time to hear.
yeah, yeah.
I'm curious.
We'll see how that unfolds.
Yeah.
Alright.
We went all over the place and this is so much fun thinking about API economy and the business of APIs.
I guess any thoughts that help us sum this up and we always try to frame kind of our wrap up around the idea that, hey, Matt Box is a successful company and you got all these products and it's big and complicated, but I'm just getting started.
Yeah.
So simplest form on the map box side.
If you need to add maps, they're integrate maps into any application anywhere you can come find me on LinkedIn to search T space, Antonio on LinkedIn, and I'm sure you'll find me.
And then also, if you're an API on up and you need some go to market consulting, feel free to reach out to me there as well.
And I don't know to summarize like, this is really the way I see the industry is like, VR is super exciting.
Like, AI is really cool.
Cryptocurrencies popping off like, everyone sleeping on APIs like, it is really where, like, a technology that is really happening and is apparently the most boring thing for, like, news coverage ever.
So I'm happy with that.
I love that it's sort of a small industry that has a lot of money flowing through it, and I'm really happy to be part of the industry.
So I hope to be in it for a long time.
So that's my main message if I'm going to wrap it up, like, if this is the first time you learned about APIs, like, you've been sleeping on it for a while.
Yeah.
The party's over here.
Yeah.
I don't think everybody's sleeping on it.
No, I know.
We're certainly not.
Bye.
But, I mean, look at the coverage that all these other things are getting right.
Like, no one writes about APIs, like, at least on muscle.
Yeah.
But I do think somewhere in there that there's a lot on sort of the rise of platforms.
And when you just scratch beneath the surface of that, the way you define and build platforms is by creating a consistent portfolio of APIs.
Yeah.
So that's what we've seen in the last year or two is that I think the world in some ways is waking up to that kind of transformative journey and starting to really take on how do we define these things? Consistently build a lot of different APIs innovate faster, but end up with something that feels like one platform that developers can interact with all the different APIs and not have to reinvent the wheel or relearn everything each time.
So I think that is just a tidal wave of activity in the industry right now.
totally.
Yeah.
I mean, I would love to also learn more if you have folks that have products that are already well adopted, larger companies that are building API product for the first time, I would love to learn how they approach it versus startup being API first.
Bye bye.
Yeah.
And I mean, in some sense, that's why we have this podcast.
It is to help folks understand how to get there because the truth is out of the gate.
People make a lot of mistakes.
You already said the biggest one.
Yeah.
Right? Build it.
They'll come that's the classic one.
But there's lots of other ones out there, too.
And so to some extent, what we try to do is help pull together folks who've done this and had some success to help give guidance to those who are just learning and getting started.
Because in our business, we hand them a toolbox and say, here you can go create a consistent platform.
But there's a lot of other moving parts to being successful at it.
yeah.
And I think there is a lot more consistency and approach than I certainly maybe thought before we start the podcast.
But I think there's a lot of other pieces around the business side around all these different kinds of marketplaces.
How to monetize APIs effectively.
I think that.
ideation.
Yeah.
I think there's so much more to go there.
You know, it might be cool is to bring in one of these API founder type folks and, you know, like, have a jam session on how to productize their APIs, like, just do brainstorm for an episode, you know? Hey, if it doesn't work out, we can always can it.
Alright.
nice.
Alright.
Well, I really appreciate you being so open and kind of sharing all your thoughts here.
And Anna, thanks again for co hosting and helping kick around the business stuff here.
anytime.
yeah.
Thanks for having me.
I hope to come back.
Alright.
Well, thanks everyone for listening.