5 Key Steps to Evolving Your Offering Into a Platform with Eventbrite | SaaStr Software Community

So at Stripe, we're building the commerce infrastructure of the Internet. Infrastructure might be underrated, but it's actually essential for any economic growth. By providing an API, we're creating and expanding the network of possibilities.

We started Eventbrite to help bring people together through live experiences. We have a whole range of events organized on our platforms pretty much around the world, giving anyone the ability to create an organize events seamlessly. We've transformed slowly but surely the entire ticketing industry.

Good afternoon everyone. Thank you so much for being here. It's a great pleasure to be today with Renaud, Eventbrite's technical founder.

Thank you.

So when you look at most of the most valuable companies in the world today, as I was just mentioning, they tend to be platform companies. When you think about the Facebook, Google, Microsoft, Apple, all of these, we tend to define them as platform companies. For a few companies, including Stripe and Twilio for instance, we kind of started with the API in mind from day one, trying to think about the building blocks for developers to build upon. But most companies, they tend to start with an actual core product. And I think that's what we're going to talk about today, seeing how you can turn like a SaaS business or a core product you have and make it a very successful developer platform. So maybe we could start by even defining what the platform is. It's pretty hard. A lot of startups out there tend to define themselves as startups who aspire to become a platform. And it's quite nebulous to define, right, Renault. So for me, one definition I like is the one from Bill Gates when he said a platform is when the economic value of everybody that uses it exceeds the value of the company that creates it. And that's what's a platform according to Bill Gates. What would be your definition? Like, what do you have in mind?

I think yeah, there are a lot of different types of platforms. So understanding the differences between all the ones that are defined somewhere, and you can find lists of 9, 16, 20 different types of platforms. But I think in the end, I think a platform is a way for one product to connect with other products in its most basic definition. I think that's what we at Eventbrite benefited from the most. And if you think about it that way, then I think it simplifies a bit the equation. And you can think of how does that apply to your business, Right?

And of course, besides the brand I mentioned earlier, like Google, Apple and Facebook and so on, a lot of marketplaces also like Uber and Airbnb, they tend to think of themselves as platform because they have the buyers and the sellers, you know, connecting to each other. And I think on top of your definition, I would add that in addition to that co creation of value for consumers, what I really like about platform is the fact that they're kind of like pieces of infrastructure. They're kind of building blocks for developers to build upon. And I think that's kind of the mindset we've had at Stripe since day one. Like, how can we provide economic infrastructure for developers to build applications and services in a way that's really future proof? So let's start with our five key steps, and let's start with the first one, which I think really is to kind of prepare your core product for scale. Right. Can you tell us a little bit about the early days of Eventbrite and how you kind of kickstarted the product?

Yeah, I think before you can run, you have to learn how to walk. So we started Eventbrite with mostly a tool for event organizers to be able to sell tickets very quickly, Any type of event organizers. So small events like this one, all the way to larger events. But we really focused on acquiring one side of the marketplace first, which is the event creator, because they are the ones who have the inventory, the connection with the attendees. And we thought that if we could grow that side of the business, then we could extend into a platform down the line. But the initial early years, where I would say 120% focused on creating that core product, acquiring these first customers, that then we could embark into a platform offering which came much later. But that was quite different for Stripe because it started as a set of APIs. Basically.

Yeah, we started as a set of APIs. Right. The idea for Stripe, I'm sure most of you know, in the early days was to have just a few lines of code and let developers and entrepreneurs accept payments in their apps and services. And what I like to know always when I meet founders, is kind of how they manage to get their first users. How did they manage to bootstrap the company? Because I'm sure many of you have read this essay from Paul Graham when he refers to what he called the Collison installation. So Patrick and John Collison, our founders, would spend a ton of time with the early Stripe users and actually helping them write the code to install Stripe. And that's kind of how they got started. Did you have any tricks for Evan Bright to kickstart the product?

No, I think we had a great network in San Francisco of event organizers. So TechCrunch was very much nearby, and they were the first ones to have fairly large events. So they were one of our first customers. We worked really hard to understand their pain points. We didn't come from the event business. One thing we understood very quickly was that access to money for organizing an event is quite critical. So the first product we launched had an integration with PayPal that made it very easy for the event organizers to get all their ticket sales directly into their PayPal account as they were happening in real time. So. So that gave them the cash flow that they needed to power their events and organize and book the room and book the acts and all the talent that you need to make an event successful. So we spent a lot of time with this crowd. So tech events in San Francisco, then tech events in New York, and tech events in London, and then started. I think we were lucky to have the first mover advantage. So there were solutions for, for the stadiums, for the very large conferences, but nothing really for under 20,000 people. So that was really our core focus. And extending beyond tech, then we found a different set of requirements. We went to beer festivals, classes, concerts, theaters, et cetera, et cetera. So that added different requirements for each type of organizer that we incorporated into the product, which was not a platform at the time. Yeah.

And so when you build that product and you saw it grow over time with those first types of users, at which state of the company did you think about becoming a platform? Was that something you thought about from day one, but you kind of pushed in the future, or did that come along later on?

Well, we were built on top of another platform, PayPal, so we knew that APIs was, were going to be important for the future. Like that data silos were not going to be sustainable because data wants to be free. I think that you've heard that before. So we knew there was probably a platform play down the line, but we just had limited resources. So when you have limited resources, and I think that's why it's step one is to build your core product and acquire this mass of customers that you can then build for with a platform. So it was always in the back of our minds, just not a priority because we didn't have the staff to power that.

Right. So maybe that brings us to the second point, actually. So once you have your core product to scale, it's kind of time to introduce APIs in your product. And so for you at Eventbrite, when did people start using APIs and when did you start exposing some of the APIs.

So the first use case came from our users. So they were spending a lot of time taking the data that they entered on our platform and copying it into event discovery sites. Like there were a few at the time. Oodle Eventful. Yahoo, I think had different products. So we built an event search API that allowed them. Allowed our partners to pull data from us basically in a very automated fashion. So we had a daily cron that would pull the data from us and publish the events on their platform as well. So it was kind of a distribution API in a very rudimentary form and it allowed us to be present in other properties than our website. So all of a sudden all our events were automatically published to multiple places, which was great to acquire other customers onto the platform to buy tickets. Then we had clients asking for better reporting capabilities. So instead of building everything ourselves with the limited team that we had, we just opened up the API to access attendee information. It was private to the organizer and they needed to have the right credentials to pull it. But again, it was driven by the needs of our customers. Sure, yeah. And I think now it's pretty much widely adopted as a practice to build your core product onto APIs. But at the time it was definitely not the case. So we had, we built an API that was in a separate file that had no relationship with the product except the data underlying the storage of the client information.

So you kind of had to re architect a little bit. The way Eventbrite works, we haven't exposed.

We have totally re architect over time. But for the longest time, all our APIs were in one file.

Wow, that's awesome.

That's pretty scary. When you unbundle that file and create the next version.

Mvp, you know, has to work.

What did you start with at stripe? Just the JavaScript or did you have APIs before that?

So the first, the original version of Stripe was just like this one API to really accept car payments online. And I think one of the first kind of breakthroughs that Stripe made was this idea of Stripe JS, which was this idea to do PCI compliance in the browser. Because if you rewind just 10 years, payments online before Stripe were extremely complex because as a merchant, if you wanted to sell any kind of item online or even just a service, you had to apply for this merchant account. It would take days or weeks to even get approved that. But you also had to go through all these hoops of PCI compliance. And so for Stripe we had not only this idea of this has to be much simpler, you kind of have to start, you can sign up in minutes, but you can also start accepting payments without going through all this craziness of PCI compliance processes. So first I would say the API and Stripe JS for the what we call tokenization of card details in the browser.

I think at the beginning of your platform strategy, you'll find that your clients have needs and that you can fulfill them with the right integrations, the right partners. So engage with them, understand how they run their businesses every day to see what first integrations make sense and what APIs you would have to build. You don't have to make them public or open. We decided to make it open because we wanted everyone to have access to the content that was generated on the platform. But I think every business will have different use cases and just understand that as soon as you make an API public, it's a long term engagement because you're going to have people building other businesses on top of it and they're going to rely on access. And I think there's been many examples of companies being built on top of just one partner, Facebook or Twitter, for example. Then they were denied access for whatever reason and the business failed. So understand the dynamics between you and your partner very early on so that you can have enough diversity in your business model to not be fully reliant on one partner.

Yeah, totally. And what would you say was the most surprising kind of use cases for even bright at the beginning when you started to open up this API? Like what are the things that you saw and you did not expect?

Well, I think we always underestimate the creativity of developers and what they can do with your data. So we had so many hackathons happening and using our data for a wide variety of users. A lot of businesses started being created on top of our data to fulfill some of the things we were not providing to our clients. So I mean, Slido is a good example of a company that started because they could connect with our API and gain access to all the attendees and engage with an audience. And I have countless examples of this type of businesses that today rely very much on us and our APIs to function and provide the service that they provide. So that was the very fun part of seeing what people can do with our data. That I think was the most surprising. We thought we had the whole industry nailed down and fully understood, but then all these products started to emerge and filling very specific needs for specific clients.

Well, I always like to see when you open up APIs like one of the creativity of developers and what they build with those. And also, not only that, but also the feature requests they tend to have. Like back in a few years ago at Stripe, before we had this product called Stripe Connect, for instance, which powers like marketplaces, we had some very interesting feature requests. Like some developers would ask us, like, hey, I'd love to have thousands of bank accounts inside my one Stripe account. We're like, but what are you really trying to do? And then we realized that what they were trying to accomplish was actually marketplaces. They wanted to not only be able to accept money, but dispatch these payments across like multiple, multiple sellers on their marketplace. So that led us to build Stripe Connect to kind of like, you know, open up the door to all these like marketplaces that were kind of hard to build before that. So always interesting to see feature requests from developers and how they push you in a certain way.

Also you get lots of ideas from your customers. Because our first users for the APIs were our customers. And I remember going to General assembly, which gives classes to a lot of people on technical matters, and seeing they had hundreds of classes and they built this very sophisticated reporting system on top of our APIs that they used every day to manage their business and was quite impressive and gave us a lot of ideas of what type of reporting we should be adding to our core product.

Yeah, and sometimes what's interesting is if your product is so massively successful, sometimes even without opening official APIs, developers find their way to use a platform. I think I always like to remember that in the early days of Lego Mindstorm, the LEGO company never had the intent to kind of open up that to developers to play around. And same for the iPhone. Like Apple was not a platform company at the beginning. They thought of the ipod and then the iPhone as kind of like a finished product. And they didn't really have SDKs and platforms until a bit later with the App Store.

Well, that's why it's important to keep the pulse with your users in general and understand what they are solving with your co product, what you're not solving for them, and how you could be solving it through just integrations. Because the reality is like organizing an event has 2000 categories of businesses that are involved in one way or another. And we couldn't tackle them all even if we wanted to. Even now that we're a public company with more than 1,000 employees, there's just too many verticals inside that daily life of the event organizer to do them all. So we have to be very strategic about what we build, what we don't build where we partner and what makes the most sense in terms of ease of use of our overall product.

So I think that's a good segue to our third point. So we just mentioned how you start introducing APIs on top of your core product functionality now. I think the next step, when you start having some developers and some partners building, I think the next step is really to think about what kind of developer experiences do you want to offer to facilitate their onboarding and also kind of how to successfully start adopting some platform thinking at the company. Because now you're going to have this API in the wild and some developers and partners are starting to build with it. And so yeah, how do you start building a great developer experience, I think is the next step?

Well, for us it took a very long time, I have to admit, much longer than we should have. We launched a bunch of APIs, we had pretty bad documentation for them. People still built on top of it, but we didn't really have a piece of platform strategy at the time. I think we really started thinking about our product as a platform two, three years ago. We started in 2006. So it shows you that you can go a long way without having a great developer experience. Except that expectations have changed a lot. What was okay in 2008 is not okay anymore today because you have great platforms like Stripe that have set the bar very high as to what kind of experience you should have when you're a developer trying to integrate. And you have to at least offer something that's in the vein of what's available out there. So about two years ago we built a team around it. We redid the way we produce documentation so that it's machine readable. We had to rewrite all kinds of APIs to make them more consistent. We introduce concept of versioning. Communication between us and the developers was very ad hoc before. Not centralized, not shared. There was no discussion group for developers to share solutions. We were not providing solutions, we were providing a list of endpoints and up to you to figure out what to do with them. So all these components I think eventually make the success of the platform. Once you have a true developer centric team that's actually talking to customers every day and customer being the developer in this case, understanding their pain points, what's easy to use, what languages they use, we're talking about that. How do you provide the right tooling for them to get started as quickly as possible? How do you explain what's possible with your endpoints and stripes has how many endpoints today? You don't even know. Right.

I think we're like in the hundreds now of endpoints on the API.

We have hundreds as well. So how do you make sense of it for someone who doesn't know anything about your business? Because a lot of integrations are not done with specialists in your field. Like we integrate with mailchimp for example, and they have hundreds of different use cases, they don't know much about events. So how do you explain all this terminology that you take for granted? How do you make it ingestible very quickly and how do you make it as efficient as possible for a developer to get started playing with it? I think that's the key for successful integrations.

Yeah, I think we like to think about developer experience at Stripe as like a constellation of details that really all matter. And so I think for us and for me, the key is really to think about friction points, like from the moment someone discovers stripe.com for the very first time time, all the way to having a like very successful business running live payments. Like what are all the touch points during that journey and where can we remove friction as much as possible? And so I think a lot of those things matter. You mentioned documentation, you mentioned own building, but having like, you know, sample apps, having like client libraries and all the languages that you, that you use, you know, and frameworks also that developers tend to embrace these days. Like all of these things, things really matter for developers to be efficient.

Especially as you make the transition from having a few APIs here and there to really thinking about your company as a platform company. I think that's the biggest transition in terms of organizational structure and having enough resources dedicated to the platform side of things. But that also requires changing how developers develop because documentation is not an option anymore, it's a requirement. API definition have to be consistent with what's been produced in the past. So you have a lot more, I think things that slow down development dramatically when you go into a platform strategy. So be conscious about that additional cost you will incur as an organization to get there. It's not non trivial and I think we sometimes underestimate a lot what it takes to be and support and maintain a platform strategy. Yeah.

And for a company like Stripe, I think the way we see what we're building is really about economic infrastructure. So for all of you in the room, like building SaaS companies, what we really want you to focus on is really what you're best at. Like what are the unique product features you can offer to your customers. Right. And you should spend as little time as possible on anything, payments. That should be kind of something that you delegate to some like, you know, company like Stripe for instance. And so we tend to think about our APIs as like infrastructure and so infrastructure they tend to be kind of decade undertakings. Right. So that's why we want to make sure that if you start building on Stripe today, that should still work in three, four, five years from now without you kind of having to change your integration every week. Like it's something that has to be robust for you to trust the platform and the infrastructure you're using.

It's also building all the components of the infrastructure. Endpoints are the start. You need the reporting on performance, on number of calls you're making, on how many you have left, on how much you're going to be billed. Reliability, webhooks, something that's quite complicated to build and really important if you want to avoid excessive usage of your APIs. So these are maybe the more invisible pieces of the infrastructure that actually take a lot of effort to get right.

Yeah, especially if you want to have some real time components in your platform. So maybe we can mention trust also because as you're having this API and you're putting APIs out there, when people start building with them, assuming they have a good experience with your documentation, your client libraries, you also want to make sure you build that trust over time. Like how have you been thinking about the trust with developers at Eventbrite?

So there's I think different levels of trust. We have to trust the partner that they going to deliver a quality experience for our users. Because once you have an integration, you're kind of extending your product beyond your core with something that you don't fully control. So having enough monitoring of the performance of the engagement of how people are using it is, is it effective, Is it a good workflow? So being very critical about that so that your customers don't end up distrusting you because you provided a half assed solution for them fully relying that the API will be available, that it won't change without notice, that it's going to be performant, that webhooks will arrive. All these things are expectations that if you do it right then you build trust over time because they know they can rely on you not changing your policies all the time. I think that we have many examples of large companies having to change access to certain APIs and kill a lot of businesses in the process and get a lot of anger from developers. So think pretty carefully before you open something up because if you have to take it out at some point. It's a big hit on the trust that the developer community gives you. And then yeah, be fair, transparent and communicate a lot. I think we under communicate in the early days because we didn't have many people dedicated to the effort. But you have hundreds of developers who want to talk to you every day. So make sure you have the capabilities to handle that.

Yeah, absolutely. And I used to work at Twitter before Stripe and I think communication was also something we could have improved and we became better over time. But back in the days of Twitter clients, for instance, when they became kind of a threat to the company and how the ecosystem was evolving around them, I think communication is key to make sure developers are building the things that you want them to build.

You have some big API changes thanks to regulation as well.

Yeah. At Stripe. So we mentioned versioning earlier. So we try to be always kind of backwards compatible when you build on Stripe that integration will work work over time. But what's interesting is the trend of payments. I'm sure most of you in the room have heard of kind of changes in regulation coming in Europe in September, called sca, like strong customer authentication. So a large fraction of payments in Europe are actually going to be triggering 3D Secure, for instance, starting September 14th. And so how do we build an API that is still extremely simple to use, but also making sure that all, all businesses have as little work as possible to benefit from that. And so we've been working on these new APIs at stripe to make sure that whether you're building a kind of a SaaS business or if you're building a marketplace, making sure that all this kind of 3D secure complexity and when to trigger it is taken care of by the platform itself.

But it's a big effort.

It is a big effort because that's one of the rare cases when we communicate proactively with businesses to upgrade their integration to make sure the payments still work come September.

Otherwise payments get declined. Right.

That's the rule issuing banks have to decline payments if they're not three secure enabled. So it's pretty scary. But luckily we're on top of things in terms of the developer metrics or actions. Is there any particular things you look at or track in terms of the success of the Eventbrite API?

So there's the success of the developer trying to integrate and for that we look at time to first integration. We have a goal of making it as efficient as possible to start playing with the API because we think developers don't like to read documentation, really, they just want to download something and see what it can do. So we try to focus on that, on the business value of the platform effort. I think we look at our platform effort as a retention tool. So we think that once a customer has connected with different other products beyond ourselves, that they will stay around longer and that they will. It will be much more difficult for them to leave. So we look at how many. The percentage of customers that have more than three integrations through our 100 people plus selected partners that we work with. So that's the one key metric we use. We don't use monetization as a key metric because we don't think it's as relevant yet. Eventually we'll probably have some monetization efforts around the platform, but currently it's a way to keep people on the platform for longer. Great. Yeah.

For us, we tend to obsess about simplicity of the API, especially as many businesses, in particular SaaS businesses, are becoming a lot more so sophisticated than it used to, you know, like five, six years ago. Like a SaaS business might just be, you know, oh, I want to charge like $19 a month and that's it. Now the business models have become quite advanced. People want to have like, you know, metered billing, tilt pricing kind of stuff, some usage records on stripe. So as a result of that, we've kind of made our billing stack a lot more advanced, but also kind of obsessing about how do we make sure the initial on building remains very simple. So I think that's something we look at the time to first payment and time to first charge on stripe.

Organizing complexity to keep it simple is not easy. Exactly.

Doing simple things is actually pretty hard. So maybe we should move on to our fourth step, which is now you have this API in the wild. We've covered how to think about developer experience and how to think to think about platform thinking. Now the first step, like now you start having an ecosystem. How do you build like a healthy ecosystem around your platform and kind of start leveraging your network effects? So maybe you can tell us a little bit about how you thought about that for Eventbrite and which side of the platform you started with.

I mean, we started with a supply of ticket inventory first that acquired customers and as I said, I think extensions of your products is probably the first area of the platform you build up because there's already an ecosystem of products that your clients are using. They want all of them to talk to each other. So that makes sense as a first natural extension Today I think we have 100 plus strategic partners. So companies like Salesforce, Mailchimp, Microsoft and a few others that are key software that our clients use every day that we need connected. Then for us it was how do you build the Flywheel and how do you bring more consumers to our event organizers? Because in the end their goal is to fill this room with as many people as possible. For that we really invested in finding the right distribution partners. So at the time it was eventful. And the event discovery platforms, today it's much more specialized audiences like Spotify, we have integration with them or we want to be where the consumers are. So we have a lot of integrations with Facebook, YouTube. So if you find an artist that you're interested in, you'll find the events that we power that are where this performer is going to be. So distribution partners, we have about 50 plus I think today. And then there's the products that are purely built on top of our platform that don't access our users. So that's a new area of investment. The first one we launched was Facebook ticketing. So if you go on Facebook in the US today, you can start selling tickets directly when you create your event on Facebook. But we power all the backend for that. So that's a new area for us to invest in. Really that has the most potential, I think for us to grow in the future, especially with partners like Facebook that have millions of consumers and millions of events created every month, like powering their paid tickets solution was a big deal for us and really gets us excited about the future of our platform as a company. That's awesome.

Yeah. And I think it's the same for Stripe. Even though we started with the kind of utility API to make it super, super simple to accept payments in any kind of apps and services, the ecosystem started to self organize around us when Stripe grew in reach. I think over time a lot of developers started to build not only ways to use Stripe for their own apps, but also a way to extend what Stripe can do for themselves. And so we've seen thousands of companies and as you pointed out, I think there's different, different kinds of banners in that ecosystem. I think we've seen the ones where, you know, Companies like Shopify, DocuSign, Zero, they want to work with Stripe to kind of like build an entire platform and let businesses accept payments. But we've also seen integrations, extensions or plugins if you will, like extensions, for instance, like Segment or Avalara. Their goal is not really to accept payments per se, but Rather kind of extend the value of Stripe by kind of like having having these data interfaces, like how can you connect your Stripe account to like a CRM for instance? All of those things. So it's interesting to see that ecosystems tend to first, at least for us, like self organize and then we had to kind of like organize this whole ecosystem when we reached the thousands of companies integrating with us.

Yeah, and then you started building products on top of that.

Exactly, yeah, yeah, yeah, absolutely.

So you're on the reverse journey compared to us. We started with a product, we're evolving into a platform. We're a platform from the beginning evolving.

Into multiple products, into multiple products, including like Radar for machine learning and fraud and all of these things. Yeah, yeah. And one thing we also, we also did just last year was to launch like a partner program because for the, for the longest time we had kind of all these partners that we had identified and tried to kind of push our users toward if they wanted to have like specific, specific needs. But with, with the partner program, our goal was kind of to amplify and make sure we, we grow the reach of all of these companies too that do the effort of integrating with the Stripe data.

It's a bit like a acquisition business. So you have the organic growing side of the business where people start building on top of you. And then on the other side you need to think about your strategy for the platform. Like which are the most valued partners that are currently not in the, on the platform that you need to onboard? How do you make the current integrations better, more efficient, how do you monetize them down the line? All of that goes into when you're a more mature platform. In the end you have to have a strategy around what's more important to build because you still have limited resources so you cannot go after every partner the same way. So being very strategic, having the right people on the biz, dev side partnerships are a two way conversation. You need to find the relevant ones and find the right economic model to keep them engaged over the long term. So all this requires thinking of it as a very different organization in the end than your product organization.

And always be transparent with those partners. If comes the time where like your product will kind of start doing natively some of the features that they had previously built. I think it's really important for the trust with the partners to kind of communicate proactively ahead of time with them. So I think that brings us to our last step. Kind of like when you have this platform and this flywheel, as you Mentioned really running nicely. You're going to really have to start treating your platform like a core product because at that point it's become maybe your most important product, in fact. So how do you think of that at Eventbrite? Do you think you're at that stage or you're still transitioning to that stage?

I don't think we have all the pieces yet, but we do treat it like a product. So we have the same rigor in talking to our customers, in this case our partners, our developers, all the different actors of the ecosystem, engaging with them, regularly monitoring all the KPIs around the platform side of things, trying to think creatively about what solutions we can build on top of the APIs we have or the new APIs we'll build. And then, yeah, seeing what the gaps in the market are and do we solve them through product or through platform, I think that's probably the biggest decision that's quite hard sometimes. Do we build or do we integrate? So yeah, I think we're almost there. I think we need a few key hires to really think about monetization because we haven't really talked about that that much. We have some deals with some partners, but it's not something we do consistently. And then imagining what the future revenue lines could be that would be fully powered by the platform, like the Facebook ticketing deal. How do we have more of those.

And what kind of mistakes do you see companies make usually when they, when they approach their platform? Because we've seen like even the largest companies like Google can sometimes fail at a platform play. Like Google was one of them. Unless you're like 10x better with your network effect. In fact, you can have a platform that fails. So what's mostly top of mind for you in terms of those mistakes to.

Avoid and I think maybe something relevant for this audience. There's a lot of early stage startup founders here. Like it's doing it too early. I think once you, if you don't have the critical mass of an audience, then doing the platform will distract you and will not result in the type of benefits that you would get from doing it later. Once you have that critical audience, you can address through a platform offering. Not eating your own dog food. That's probably the biggest mistake we made when we launched our APIs. I said they were separate files not used by any of our products. And inevitably when you do that, it becomes dated on the first day that you launch. Basically any new feature will not make it into the API down the line. So we ended up with functionality that was totally not available through the API. Still the case for some APIs, actually. But we now change completely the way we build software. So it's all API based internally. We expose some to partners, we expose other endpoints to the general public, but we have a strategy around it. And every API, everything we build is openable at some point.

Yeah, I think being API first is a real change in culture too. If you've not had the culture from day one thinking about, no, no, no, I'm going to build the APIs first, then I'm going to consume my own APIs instead of doing two separate things.

That's the only one. I think something we talked about. Maybe the next evolution would be to build your front end the same way. So think about how you build software. You're building widgets basically that you put on your own site that allow you to do a certain thing like creating an event or buying a ticket. What if that thing was a widget that anybody can put on their site to do exactly the same thing? I think you did that with Stripe with the first card payment widget that you launched.

Yeah, and same like relevant for SaaS businesses in this room. I think we've seen like time and again so many SaaS companies having to reinvent the wheel for so many things. Like, I want an invoice and of course I want that invoice to be nicely designed and customized and work well with every single email client. And I want my customers to pay for these invoices with cards or separate debits and all of these things. Like, there's certainly so much time spent for SaaS companies that we actually took on like all these efforts to, and to provide a lot more UI components so that people in the room here don't have to reinvent the wheel, just like customize a little bit what makes sense them.

I mean, we've known the power of widgets for a long time. We've had widgets pretty much since day one. And they're really powerful because they abstract a lot of the complexity of the underlying APIs and give you full control of the experience so that you can optimize it much faster and with more power than any of your clients. So I think that's an area where we will see a lot of investments from the smart, smart companies providing much easier to integrate tidbits of code that you could just put in and get started.

I think it's important to have the full range too. We go from UI building blocks at Stripe that you can Customize to every pixel and then we have those invoices and Stripe checkout products. You can just drop in and customize with just colors and logo. It's going to have this full spectrum for people to customize. In terms of trends, by the way, in terms of platforms like we mentioned, like for instance the Stripe side, this trend around authentication for payments and everything. Any particular trends you're seeing or things you're excited about for the future of platforms?

I think there's a lot of place for decentralized services that you can integrate into your platform. So products like fraud and risk, there should be a few we can just plug and play and not have to reinvent the wheel. I think we spend way too much time rewriting things that others have written many times. So I'm curious what's going to come up in our ecosystem to solve these problems?

Yeah, that's always been kind of like what's top of mind for Stripe. Like every time we see a company or multiple companies in fact rebuild things like no, we should definitely do that for them and take the burden on us so they don't have to spend their time and energy on these things. So we're almost at time, but I guess maybe we could do like a quick recap of what we covered. So if we were to recap the kind of the five key steps of turning your product into a platform. So we said first, kind of prepare your core product first for scale, especially if you're not a platform first company, but if you're a product first, company, company Second, introduce APIs and start exposing some of your core features on this API Third step, think about developer experiences and make sure you remove all friction possible for your developers and partners to really have a great time being successful and adopting your platform really quickly. Fourth step, we mentioned how to create a healthy ecosystem around you and leverage your network effect and finally really treating your platform like a code because it might become ultimately the most important product you have and that requires nurturing every day. So I don't know. There's a lot of SaaS companies here in the room. Any parting thoughts for you, Bruno, on what you would advise them if they want to aspire to become a platform?

I think it's just very difficult to iterate on the platform side. So think about it for the long term, engage for the right reasons, build the right team around your platform side of things. It's not like a product where you can launch new features every week. So be thoughtful of that. Think of the long term strategy and how it reinforces your moat for your customers and then see what are the relevant partners for your offering, because every solution is going to be different.

Cool. Well, thank you, Rono. And thank you, all of you, for joining us today. We just had time now, but we'll be around for questions. Thank you.