 Thank you very much. It's great to be here. My name is Andre, and I'm the founder and CEO of Encore. Encore is a backend development engine, and we help engineers realize possibility. The cloud launched today about 15 years ago. And from then to today, how we build software has fundamentally changed. The cloud has become mainstream, and the developer experience has fundamentally shifted. What used to be the case in the past was developers were spending most of their time writing business logic and being creative. And today, most of that time is instead spent managing cloud infrastructure. And it's very complex and disjointed. Now, don't get me wrong. Cloud providers provide an incredible amount of value. They help you build globally reliable, scalable systems in a way that was never possible before. But at the same time, they also shift a lot of these responsibilities onto the developers. You're no longer spending time actually building your product. You're actually spending time dealing with this infrastructure. AWS and the same argument goes for all the major cloud providers. They offer an incredible amount of services, over 200 and counting, each with tens to hundreds of features and configuration options that you can change. And so do you actually need all of this functionality? Well, no. Most of it is actually there for very small, narrow use cases. But each and every one of those features make the cloud more and more complex over time. So it's no wonder that we're spending all of this time actually trying to deal with that complexity instead of actually building the products that we're dreaming to create. And this isn't necessarily aligned with developers. When it comes to how the cloud works, every single feature that they add, it's usually slightly different from how the other clouds operate. And it means that over time, as you begin to depend on them, you just become more and more locked in. And it becomes more and more difficult to move to another cloud provider. So developers are spending the vast majority of their time kind of composing services together. They're not so much creating something unique as much as they're really modern day plumbers. You're taking the output from one cloud service and you're putting it into another and dealing with how do you configure all of this to work together. And so what ends up happening is basically every company I talk to end up spending the vast majority of time here and then realizing we need to improve this situation. We need to build a bunch of internal tooling to make this better. We need to improve our developer productivity. And so you end up creating your own internal developer process that it's a bunch of tools put together. It's a huge hack. It's all holding together with duct tape and it ends up looking something like this. And so all of this together is causing development to be incredibly slow. And all of this complexity is adding a lot of bugs into the process. How many times have you tried to launch a feature only to on release day realize that we have a giant problem and we need to go back to the drawing board? Or you spend days double and triple checking everything to make sure that everything works, only to realize that there's a giant problem and we need to fix it. And it delays every single feature release by days, weeks, or even months. Here's a world cloud from AWS's documentation. And the thing that you actually should care about, the code that makes your product unique is basically a footnote. And everything else is just jargon and terminology that you shouldn't even have to care about. So I was a software engineer for many years. And what you actually should be thinking about when you're building cloud systems is a core set of building blocks that make up almost any distributed systems. And it's things like databases, APIs, pub subtopics and queues, object storage, and so on. And if you build your application with that, you can build almost anything. The problem is AWS doesn't really want you to think that way. They would rather look at every application as a set of black boxes that they don't want to know anything about what they are about. And so what happens is you as a developer are the one that actually knows what's going on inside of your box. And what happens then is you as a developer have to spend all of your time actually setting up everything to make all of this work. If instead we had tools that actually understood what was going on inside of these boxes, those tools could begin to actually help developers do all of this job for them so that the developers could focus on actually building your product. And that's the core insight behind OnCore. It's really about a tool creating a developer tool that understands what's going on inside of an application. And if you do that, it turns out that you can take all of these undifferentiated pieces of work, whether it's setting up cloud infrastructure, configuring your application to use that infrastructure, instrumenting your application for observability reasons, or finding and fixing bugs in production. And so OnCore is from the ground up designed to enable this. And it's a fundamental change in how software development works. Here's a screenshot from the sort of symbolizes how OnCore works. When you're writing your application with OnCore, OnCore builds up an understanding of your system that exactly mirrors how developers think about their systems. And so it understands what are the different services, what are the different infrastructure requirements, and more. And it gives developers a shared vocabulary for how to reason about systems and how to prototype and implement new designs. And OnCore then takes this understanding and provisions all of the necessary cloud infrastructure directly into your own cloud account. And the best thing of all is that no manual labor is required. You can just write business logic and then move on with your day. And the effects of working this way are dramatic. We've been hearing from our customers that there's dramatic improvements to developer productivity, to higher quality, and perhaps surprisingly, also dramatic improvements to onboarding speed. Because developers no longer have to understand hundreds of different concepts just to get started building actual features. And perhaps what I'm most proud of is what our users are saying. We're trying to build an incredible experience. And you can't really have, you can't reason about the quality of an experience by just looking at features. And so we have users saying things like, this is what development should be like. Or I didn't want to like this, but I love it. And so I founded Encore to make building software creative and productive again. And based on what our users are saying, I think Encore truly delivers on this. We've been working on it for a very long time. We, after about five years in development, we launched it earlier this year. And on the back of that, we have hundreds of developers using it every single month to build real scale production systems. We have several paying customers across the EU and the US. And today, we're focusing on enabling late seed to Series A to build software faster and better than what has ever been possible before. So thank you very much. That's all I had to share for today. And I will catch you in the cloud.