 Cool. So hi, I'm Laura. I worked Stripe. Thanks so much for being here tonight. And today I'd like to talk to you about building for builders, developing for developers, and how we built a developer focused API. So I'll share some concrete tips based on lessons we've learned building the Stripe API. And I'll talk about how this has allowed us to scale our developer products really effectively. So before we dive in, I'd like to take one moment to talk about the API economy and why developer experience matters so much in this context. So it's become radically easier for software developers to start a company. Between 2000 and 2011, the amount of money required to start a tech company dropped by three orders of magnitude, from a few million dollars to a few thousand dollars. So the cost of launching a tech startup was estimated at around $5,000 in 2011, and it's probably even lower now. So why is that? Certainly the proliferation of open source and cloud computing were huge. But in the past 10 years, we've also seen the rise of API products that solve a lot of big problems for businesses. Using APIs is cost efficient, but it's also a smart business and product decision in the long run. Because an API provider will work on giving you the highest standard in the industry and help you future-proof your apps and services. Still, there is a huge range in the quality of developer offerings. So as the API economy continues to mature, providing a truly great developer experience becomes even more important. As an analogy, you can think about building APIs the same way as building roads. Our vision is to be the infrastructure, the roads and the highways, to help people build their ideas. Infrastructure might often be underrated, but it's absolutely essential for any economic growth, whether it's in taking payments, starting an on-demand business, or growing a platform for services. Good infrastructure allows people to build businesses that they wouldn't be able to. Building in a way that's optimized for use is crucial to providing good infrastructure. So I'm going to share with you five concrete tips from what we've done at Stripe. The first one is about incentives. In the past few years, we've seen many tech companies build a product first, and then add an API as an afterthought. So before starting down the path of building an API, some fundamental questions to consider. If developers start building on top of your API massively, will that be good for your core business over the long-term? On the flip side, how will your success make developers more likely to succeed? So the lesson we take from this is that, aligning your business incentives with the incentives of developers will ensure that you prioritize the right things when you're building an API. This might sound obvious, but we've seen way too many super successful tech companies release API products that end up posing their own servers and bringing down their core services or APIs where there's no way for developers to really own their product experience or profit from them. So if you rewind about 10 years, payments was extremely hard to deal with firsthand, especially when starting a business. You had no other choice but building it in-house, and this is what you would have had to go through, and this is from 2007, not 1997. So that's why we created Stripe, so that anyone can accept payments from anywhere in the world in a matter of minutes, and we believe that payments is a problem that should be rooted in code not finance. Today, while Stripe has grown, we're still fundamentally working on improving and expanding our APIs. Programming languages. So it's important to make sure your users are empowered and efficient no matter what technology they're using. Yes, we support users who don't use Ruby, sadly. So as developers use a more diverse set of programming languages than ever before, as we can see from Stack Overflow's most recent developer survey. I personally feel like Ruby is a little underrepresented here. Maybe we're all a little more hipster than I thought though, so give yourself a low key round of applause. So by offering libraries and SDKs for a wide range of platforms, you can provide idiomatic readable code and abstractions for some advanced behaviors. So SDKs are really critical for a great DX, from Ruby to Node to Go. So beyond the classic REST abstraction, they can help with things like Automagic Object Expansion. So let's say you're retrieving a charge. You can pass in a parameter that will also give you the JSON data for an associated customer. They can also help with things like Network Retries, where we can item potently retry under the hood to save developers some frustration. Of course, there are other benefits of having SDKs. One of those is that you know exactly what the code should look like in every language. So you can provide great snippets in your docs. So sometimes deciding what languages and frameworks to support is super easy. We're really excited about React at Stripe. We moved our entire dashboard over to React last year, and we have lots of Stripe users who are really passionate about React as well. So creating a wrapper with React components made a ton of sense and was a super easy decision. Similarly, back in 2014, we saw a lot of growth in Go. And so we built an open source Go library, which is used by Stripe users like Grab Today. However, there were some less clear decisions. So for a long time, we had a slow but steady user base using .NET. And we didn't have an official library for it. So a bunch of third party libraries sprung up to meet the needs of our users. And so we eventually worked with one of the creators to bring it as an official Stripe library and worked on bringing the feature parity up with the other ones. And so now it's an official library maintained by Stripe. Of course, libraries and SDKs don't replace great API design. Developers should always be able to get started with an API immediately or use third party libraries for a long tail of languages like Rust or Haskell. And there's always one Haskell fan in the room. I know who you are. You know who you are. So every week at Stripe, we conduct API review sessions where we review and discuss written proposals for any change to the API whatsoever. And so that can be a new attribute and a JSON payload all the way down to a whole new set of endpoints. And so there's opportunity for anyone to comment. And there's always a lively discussion. So to set our engineers up for success here, we have an internal doc that has best practices on API design patterns and philosophy. So this is a living collaborative doc where people comment and debate. And the goal is to provide guidelines for reducing the complexity of our API and optimizing for reusability and predictability when adding tons and tons of new features every year. So for example, we have a sources API, which can be used for adding payment methods from credit cards to WeChat Pay to SEPA, a popular European bank payment method. And our API design principles help ensure that users can access the right information no matter how they're integrating and where in the world they are. So it's really important for these things to be written down and constantly updated so that we can share this with new Stripes who join and we can have engineers globally making significant changes and really owning all aspects of technical design. And so the first feature I ever shipped for Stripe was to one of our core payments APIs. That was my like first week project. So this is a great segue into tip three, which is documentation. We think that API documentation should not just be a static user manual. We think developers should be able to start integrating in minutes no matter what the API does. So having great documentation is critical to win the hearts and minds of developers. If it's not easy to access or delightful to use, people will move on to the next one or if they do use it, they won't be excited to integrate new features. So I'll walk you through some ideas we've implemented at Stripe on that front. Since the early days, Stripe has always made code and APIs front and center. So that's a screenshot from 2011 where we had a curl command on our homepage and you can copy pasta and run it right away. Fast forwarding to today, once you've caught a developer's attention, don't make them spend 10 minutes creating an account and logging in. You can just let them play with your API right away in test mode, that is when no money is moved. So give them a snippet of code to copy and run so they can immediately see an actual result. First impressions are everything. So here on the screen, you can see how to create your first Stripe token for a credit card without the need to sign up. And we have copy and pasteable snippets throughout our site for front end, back end and including our reference docs. So you should obsess about every detail of your documentation and optimize for how developers will actually integrate. So this is an example from our launch of Apple Pay for the Web. Here, if you're using Safari, you can do a test purchase using Apple Pay without leaving the Stripe website. And the process behind these APIs is started by defining the JavaScript code that would feel right from a developer's perspective. And then we make that code a reality by implementing it in Stripe.js. And so we try to follow this approach for every product launch we have, where we optimize for the code that developers will have to write and the documentation and then everything else is abstracted. So besides guides and tutorials, the API reference is a key part of the developer experience. If you're signed into the dashboard, then it will automatically populate code samples with your own personal test mode API keys so that you don't have to copy and paste from two different places. And once you've started making your first API calls and you have some data coming back, then we feed that data back into the docs. So here you can see the data from my Stripe account is automatically populated on our docs reference page. So let's take a look at behind the scenes how we actually build our API reference. So we auto generate our docs from the source of the API resource. So here's a pared down version of what our charge API resource looks like. And if you add a new user facing parameter without user facing documentation, then our CI will catch it and your build will fail. So it's basically impossible for us to have our API reference in the docs out of sync because the code all lives in the same place. Okay, next up, let's talk about error codes and messages. So docs are important, but they're not the whole story. So try to anticipate what common mistakes developers might make and always make the response actionable. So here, for instance, if you don't pass an API key, then we give you a direct link on how to find yours. Or even better, in the second example, an API key is used, but it's a test mode key, but the object was created in live mode. So we tell you exactly this. And so even with 500s, which happened rarely, where it's necessarily unknown, the error message says to reach out to our support email and gives it to you right there so you can figure out what went wrong and how to fix it. So in addition, provide developers with complete request logs in the dashboard to make debugging easier for any unanticipated situations. Final tip, so we believe in constantly talking to users and listening to them and having a platform to advocate for what they need internally. So more broadly, think about what your users need to be effective and successful at whatever you're helping them with. And if they don't exist, go build them. If they do, consider investing in them. So ultimately, Stripe can only succeed when the tech companies who use Stripe succeed and our incentives are intrinsically aligned. So RunKit, which is now part of Stripe, is a simple environment for developers to rapidly prototype and explore new ideas with truly zero configuration where you can instantly use all of the building blocks from the Node.js community. So if you look at these three lines of code, it's using Open Notify to take raw data from NASA and it's then exposing, as an API endpoint, the coordinates of where the International Space Station is in real time. And RunKit detected these coordinates and output it as a map on the dashboard automatically. So this is super useful for a lot of our users for prototyping and trying out some ideas really quickly without a whole bunch of setup. So talking to our users who are tech companies around the world, one of the major problems wasn't tech, but it was figuring out the mechanics of how to start a business. Especially for first time founders and developers, starting a new company can take way too much time that could be spent on building a great product. So an engineer at Stripe originally asked the question, why can't there be an API to incorporate a business? And Stripe Atlas was born from there as a tool to handle everything involved in establishing a business from setting up a legal entity to opening a bank account. And so we ultimately decided that Stripe was a better product as a dashboard, not an API. But its roots are in reducing barriers for Stripe users to build excellent products and get started really quickly. So when we would talk to our users who were having problems accepting payments and found Stripe, we would also hear that there's a lot of pain involved in making payments as well. So Stripe issuing lets you create a new credit card with an API call, and the card can be used immediately online and added to Apple Pay and Google Wallet. And so physical cards can be customized and then shipped to either a merchant or their user in a few days. And so all with an API, you could start a company where you hire caterers, issue them credit cards, and then approve their expenses in real time only if they use them at fair price for extra food. And that all happens automatically. Cool, so thanks. So providing an API means establishing a different kind of contract with your users. The more transparent, easy to use, and powerful your API is, the more successful you'll be in setting up a healthy ecosystem. So I hope these tips were helpful and come work with us. Now for the obligatory pitch, we have roles open, whether you wanna work on with our polyglot experts like Shang Wei, who work closely with our APIs and work on developer experience on either our developer support engineering or integration engineering teams, or if you wanna work with me on the global engineering team building out our payment products across Asia Pacific with our Ruby repo. So a few months back, we announced that we'd be scaling up an engineering hub here and we're gonna have tons of different teams and products run out of our Singapore office. And so it's really early days and we're growing a lot. So we have a lot of work to do. The dark purple countries are where Stripe is live and the light blue is where we're in betas and there is still a lot on there that is white. So there are a lot of problems that we need to solve to light up these other countries and doing this while maintaining our high standards of developer experience is gonna mean a lot of challenging, ambitious projects that are gonna be driven out of the Singapore office. Thank you so much. Questions for Laura? Yeah. I imagine that when Stripe was built, not every attribute had like a proper documentation. So how does it transition from like a very issue state of the company to a state where you have everything document built up? So in the very, very first stages, it was the founders helping every single user integrate. But as soon as it became public from the really early days, we did have some like pretty basic documentation that there was always something there. So I think we iterated over time, but from the very beginning, like making sure that we support our users as they integrate, because payments can be hard and it's high stakes for pretty much everyone. Like you don't wanna move the wrong order of magnitude of money or something. People do it. So yeah, that's always been kind of part of our DNA and how we approach products and making sure that people understand what they're doing. Anything else? Yeah. What changes are struck path in extending to other countries are what's supposed to feed our users? Yeah, definitely. Lots and lots and lots of fun challenges. Some are more on the legal and regulatory side and then there's some also really interesting product challenges here. Payments are changing much more quickly in this region. We're seeing a lot more innovation than we're seeing in the Americas and in Europe. And so figuring out how to help people accept different payment methods and how to make that really easy and make it for businesses easy to navigate changing landscape is a huge problem and there's gonna be a lot of very unique products built for the area. Anything else? Or shall we hand it off to our lovely second presenter?