[{"data":1,"prerenderedAt":59},["ShallowReactive",2],{"leap-week-extensions-and-marketplace-plans":3,"leap-week-extensions-and-marketplace-plans-next":42},{"id":4,"slug":5,"vimeo_id":6,"description":7,"tile":8,"length":9,"resources":10,"people":10,"episode_number":11,"published":12,"title":13,"video_transcript_html":14,"video_transcript_text":15,"content":10,"status":16,"episode_people":17,"recommendations":25,"season":26,"seo":41},"b9284b99-793b-4e71-a706-7b2f0ae2cb7a","extensions-and-marketplace-plans","959643594","Learn about the main core themes for our new team focused on extensions and the Directus Marketplace.","87826de1-4c2d-4d1b-8e0f-ffc8d28a958e",5,null,6,"2024-06-17","Plans for Extensions and Marketplace","\u003Cp>Speaker 0: Good day, everyone. I'm Benny, and I have the privilege of talking about our plans for the extensions and marketplace ecosystem. I recently joined the team with the goal of focusing on the developer and user experiences of Directus Extensions. This includes the overall extension development and deployment lifecycle, our public facing marketplace, and the underlying registry API. Many of you have been wondering what will come next for the marketplace since our release of the beta at our last Leap Week.\u003C\u002Fp>\u003Cp>Let me start by thanking each of you who have contributed to testing and providing feedback on the marketplace in any way. Let's discuss the developer experience first. One of the key parts of improving the developer experience, and also partly the discoverability of extensions is in bringing new capabilities to the Extension Sandbox SDK. With the upcoming release of our new policy system, we are expecting to be able to provide granular access to things like the underlying file systems, users, notifications, and emails. One of the biggest opportunities for improving the sandbox that we have identified is, of course, enabling support for importing external libraries.\u003C\u002Fp>\u003Cp>Even though this may be a significant technical challenge to implement whilst retaining the important security benefits of having a sandbox, we are looking forward to solving this for you. Okay. So what about new extension features? We are exploring how to augment existing extensions, how to deploy data and config templates using the same APIs as extensions, how to add functionality to allow developers to define extension specific settings, and we are looking at increasing the amount of life cycle events available to extension developers. We are frequently asked how to add new plugins to the built in block editor, for example, as well as adding tweaks to other extensions and experiences.\u003C\u002Fp>\u003Cp>Right now, this is cumbersome, and we think that extensions will benefit from being able to install lightweight enhancements. This means extension developers will be able to package the core functionality for their custom developed user experiences whilst being able to allow others to build on their work. Being able to deploy templates and config via extension system will allow users to include things like data structures and email templates in a controlled way. Extension settings being configurable in the app will allow the inclusion of API keys and other configuration that isn't dependent on having access to environment variables at deploy time. Our life cycle hooks will allow for better management of installing and uninstalling extensions.\u003C\u002Fp>\u003Cp>These are just some of the features we are planning to add to the road map soon to help craft our growing extension library. The last set of work we will be focusing on before moving the marketplace out of beta will ensure your extensions are seen by the widest audience possible. Our marketplace listings will be more dynamic and easier to find what you are looking for. This will include providing more options for meta information to control elements such as how details about individual contributors are displayed, as well as adding elements like hero screenshots and logos. This may also include enhancements to the configurable meta information, like better tagging options to improve searching for extensions.\u003C\u002Fp>\u003Cp>To help increase visibility, we are looking at how to make extensions listed in the marketplace discoverable outside of the director's studio so that anyone can link to them for consideration outside of an existing project. We also want to provide extension authors with insights into how their extensions are performing. This may include being able to do things like react to comments, reviews, and feedback from users as a verified extension author. Finally, we are looking at how to indicate the quality of each of the extensions public in the marketplace in a clear and transparent way. This will help users get the best experience and provide developers clear guidelines on how to produce high quality extensions.\u003C\u002Fp>\u003Cp>These new changes will be implemented in both the Data Studio as well as the registry API. Once these changes are implemented, we will publish the registry API spec to enable developers to publish and maintain their own additional registries. As you have heard, there is a lot going into the marketplace. We are looking forward to sharing the road map with you in the next couple of weeks, and you'll be able to see the priority of the item stem. We wanted to take this opportunity to provide some insight into how the road map is being developed and what will be coming.\u003C\u002Fp>\u003Cp>Once this work is done, the marketplace will be ready for general availability. We hope you are as excited as we are for some of these upcoming changes. We are really passionate about the directors extension ecosystem, and I can't wait to see what you create.\u003C\u002Fp>","Good day, everyone. I'm Benny, and I have the privilege of talking about our plans for the extensions and marketplace ecosystem. I recently joined the team with the goal of focusing on the developer and user experiences of Directus Extensions. This includes the overall extension development and deployment lifecycle, our public facing marketplace, and the underlying registry API. Many of you have been wondering what will come next for the marketplace since our release of the beta at our last Leap Week. Let me start by thanking each of you who have contributed to testing and providing feedback on the marketplace in any way. Let's discuss the developer experience first. One of the key parts of improving the developer experience, and also partly the discoverability of extensions is in bringing new capabilities to the Extension Sandbox SDK. With the upcoming release of our new policy system, we are expecting to be able to provide granular access to things like the underlying file systems, users, notifications, and emails. One of the biggest opportunities for improving the sandbox that we have identified is, of course, enabling support for importing external libraries. Even though this may be a significant technical challenge to implement whilst retaining the important security benefits of having a sandbox, we are looking forward to solving this for you. Okay. So what about new extension features? We are exploring how to augment existing extensions, how to deploy data and config templates using the same APIs as extensions, how to add functionality to allow developers to define extension specific settings, and we are looking at increasing the amount of life cycle events available to extension developers. We are frequently asked how to add new plugins to the built in block editor, for example, as well as adding tweaks to other extensions and experiences. Right now, this is cumbersome, and we think that extensions will benefit from being able to install lightweight enhancements. This means extension developers will be able to package the core functionality for their custom developed user experiences whilst being able to allow others to build on their work. Being able to deploy templates and config via extension system will allow users to include things like data structures and email templates in a controlled way. Extension settings being configurable in the app will allow the inclusion of API keys and other configuration that isn't dependent on having access to environment variables at deploy time. Our life cycle hooks will allow for better management of installing and uninstalling extensions. These are just some of the features we are planning to add to the road map soon to help craft our growing extension library. The last set of work we will be focusing on before moving the marketplace out of beta will ensure your extensions are seen by the widest audience possible. Our marketplace listings will be more dynamic and easier to find what you are looking for. This will include providing more options for meta information to control elements such as how details about individual contributors are displayed, as well as adding elements like hero screenshots and logos. This may also include enhancements to the configurable meta information, like better tagging options to improve searching for extensions. To help increase visibility, we are looking at how to make extensions listed in the marketplace discoverable outside of the director's studio so that anyone can link to them for consideration outside of an existing project. We also want to provide extension authors with insights into how their extensions are performing. This may include being able to do things like react to comments, reviews, and feedback from users as a verified extension author. Finally, we are looking at how to indicate the quality of each of the extensions public in the marketplace in a clear and transparent way. This will help users get the best experience and provide developers clear guidelines on how to produce high quality extensions. These new changes will be implemented in both the Data Studio as well as the registry API. Once these changes are implemented, we will publish the registry API spec to enable developers to publish and maintain their own additional registries. As you have heard, there is a lot going into the marketplace. We are looking forward to sharing the road map with you in the next couple of weeks, and you'll be able to see the priority of the item stem. We wanted to take this opportunity to provide some insight into how the road map is being developed and what will be coming. Once this work is done, the marketplace will be ready for general availability. We hope you are as excited as we are for some of these upcoming changes. We are really passionate about the directors extension ecosystem, and I can't wait to see what you create.","published",[18],{"people_id":19},{"id":20,"first_name":21,"last_name":22,"avatar":23,"bio":24,"links":10},"bba2d38c-9ddf-44e0-a978-34e28e212595","Benny","Michaels","4c8bca99-3056-4ed8-ac41-aac00b30242d","Engineer, Directus",[],{"id":27,"number":28,"year":29,"episodes":30,"show":38},"edaf4f46-b4d7-468c-bb14-4778c0e3b304",3,"2024",[31,32,33,34,35,4,36,37],"a8eb1187-ee58-4583-824a-5d9cbefa8d7c","e477c1e4-2942-493c-b2d4-e41f589eac72","191de350-707d-4a57-a8f5-e749820530d9","369abe83-ca5d-4fbc-81c8-626912b0a7f8","c5593b03-9801-43e9-9606-facfcfb2791f","1927e10b-f96b-41e4-a57a-42ed26094a0a","a48019be-7fd1-4b64-9b25-2b579196f121",{"title":39,"tile":40},"Leap Week","62816023-fa7e-4a76-b9a1-2733ee2093a6",{"title":10,"meta_description":10},{"id":43,"slug":44,"season":45,"vimeo_id":46,"description":47,"tile":48,"length":49,"resources":10,"people":10,"episode_number":50,"published":51,"title":52,"video_transcript_html":53,"video_transcript_text":54,"content":10,"seo":55,"status":16,"episode_people":56,"recommendations":58},"bbaa3063-6fbe-4d96-bbc7-e50672f9a308","ui-era-shifting","289f6534-7fdd-46df-8c00-89a75469fe41","1176272144","Hear from Directus CEO & Co-Founder Ben Haynes on software is shifting from UI-first to data-first. When everyone can build an interface, what is actually valuable?\n\n","08f64249-c879-4294-92f1-b73a3ea82750",14,1,"2026-03-27","The UI Era is Shifting","\u003Cp>Speaker 0: So let's kick things off. This is Ben, founder and CEO at Directus. And today, I need to talk to you about the end of the UI era. A little sensational, but let's dive in so that I can explain. First off, you might be thinking, don't we have better tools, more people than ever building all these front ends, all these UIs?\u003C\u002Fp>\u003Cp>Yes, absolutely. But when everything is special, nothing is. The front ends have been, commoditized. So let's explore what actually makes software magic, and specifically where the value of software has shifted to and where it's heading next. So since software was created, the interface has been mistaken for the product itself.\u003C\u002Fp>\u003Cp>Users click through, buttons and interfaces and they said, Oh, this is the magic. They saw a dashboard and they said, Oh, that's the application. The Shiny part got the attention for most users. But engineers, you know, for those who are out there, you know better. The visible part of the software is the tip of the iceberg.\u003C\u002Fp>\u003Cp>What lives underneath is the expensive, the fragile part. The part that takes years, decades, to get right. AI has made this a really big deal. Anyone can spin up a decent looking UI, a form, with solid UX, dashboards, components, all of that. They can stitch it together and you can get something that looks just like software.\u003C\u002Fp>\u003Cp>That's amazing. But it's also misleading and maybe even a little dangerous. It creates the illusion that software got easy, but it did not. The front end got easier. The back end maybe even got harder.\u003C\u002Fp>\u003Cp>We have so many builders out there. The back end is the tricky part. And the reason for that is you don't know what you don't know. So while most non engineers can definitely dream up an interface, you are a non technical person. You probably don't know what is needed behind the scenes to actually build this out, make it scalable, make it resilient.\u003C\u002Fp>\u003Cp>So you can Vibe code a UI in a day, but you cannot Vibe code trust. So maybe we just delete the backend. Cursor a little while back actually deleted their headless CMS. As an example. They replaced it in a couple days for a couple $100 worth of tokens.\u003C\u002Fp>\u003Cp>And that really works for a company like theirs. A small team, highly technical, very capable. But that's not going to work for other organizations. You can delete the CMS, but you can't delete the problems that the CMS solves. They come back and when they do, you're either gonna be building from scratch or you're gonna be drowning.\u003C\u002Fp>\u003Cp>So switching gears, let's talk about the back end. You can't one shot your way into production resilience. You can't fake your way into scalable architecture, granular RBAC or access control, reliable APIs, multi tenancy observability, governance rollback strategy, operational maturity. All of this is earned the hard way. Cursor, Lovable, Replit, Bolt and others, they've all made it really easy to create a front end in minutes.\u003C\u002Fp>\u003Cp>And it works. But without a back end, really what you've created is a clickable prototype. The front end and back end distinction gets really blurry because of the excitement around, you know, the generation of this of this front end. And I I love metaphors, so I'll kinda take a a second here. You wouldn't build a house starting with the doorbell, or something like that.\u003C\u002Fp>\u003Cp>You know, the the fresh paint, the beautiful fixtures, the interior design, none of that matters if you've got plumbing, leaking behind the walls, if you've got electricals, you know, sparking fires behind the sheetrock, a foundation that's not even poured and the house is just sinking into the mud. That's just not how things work. Anyone can build these demos, these facades, but far fewer people can build something that actually survives success. You just you can't vibe code trust. So if the front end is becoming free, where does the value go?\u003C\u002Fp>\u003Cp>It goes deeper but not just deeper technically, deeper organizationally. The thing that makes software software wasn't really the pixels. It's not the front end. It's the layer underneath where your whole organization goes, to work together. It's the logic, the APIs, the permissions, the 99.999%, uptime.\u003C\u002Fp>\u003Cp>Your performance under load. You know, does that work? Auditability. Maintainability. The stability that people don't notice until things break.\u003C\u002Fp>\u003Cp>It's not what you see, it's what you feel. You feel when your app goes down. When the data is suddenly corrupted or truncated unexpectedly or deleted. Permissions break. Traffic spikes and things just fall apart.\u003C\u002Fp>\u003Cp>The front end may be what people admire, but the back end again is what people trust. That's what really matters here. So let's first clarify what do we mean by back end. There's the Supabase Lovable partnership and people would refer to Supabase as the backend. It's a database.\u003C\u002Fp>\u003Cp>It's got infrastructure, an API. But really the backend is more than that. The backend is a collaboration layer. It's where technical and non technical users can go to actually access, to browse, manage, and visualize data. It's where data is governed, and used.\u003C\u002Fp>\u003Cp>Not just by engineers, but by anybody in the team. AI accelerates what individuals can do. Our own engineering team uses Cloud Code every day and the velocity gains are very much real. But more complex use cases require humans working together across teams. Engineers with PMs and ops, marketing, legal.\u003C\u002Fp>\u003Cp>AI doesn't solve the collaboration problem. It actually makes it larger. The winners won't be those that can create the prettiest screen the fastest, but those that combine the speed of AI built interfaces with the true discipline of back end engineering. And then democratizing that across the entire organization, technical users and non technical. That's how a hobby project becomes an actual product, or in some cases, how a product becomes an actual company.\u003C\u002Fp>\u003Cp>Okay. So let's break down the back end into three pillars. The first one we'll call governance, how you collaborate safely. The data is there. It's in the database behind every application, that's that's out there.\u003C\u002Fp>\u003Cp>But it's locked behind the doors of IT, as it were, for every report, every change of the data that's needed. If you're non technical, you're probably submitting a support ticket. We need tools that unlock the database for the technical users. Technical users are about 3% of an org, typically. And so we need something like a database administration tool but that's simple, safe, and intuitive enough for anyone to use.\u003C\u002Fp>\u003Cp>It's not about locking things down. It's about opening them up, responsibly. How many one shot AI applications are actually considering RBAC and granular permissions and all that in their system? I would guess not many. So we need to browse, manage, and visualize our data, in an intuitive way.\u003C\u002Fp>\u003Cp>We also need docs, API references, specifications. Those are needed as your team grows, more people join, you need integrations with other services. Those are boilerplate. Let the subject matter experts do their work. We all have seen, you know, a game of telephone and how that can degrade things.\u003C\u002Fp>\u003Cp>You can't pass these requests along. You need people to do that work directly. And so we need interfaces that work for everyone. The second one is scale, or how we take that collaboration and we make it survive the complexity, of the real world. You could also consider that to be production efficiency, resilience.\u003C\u002Fp>\u003Cp>There are a lot of things to consider, consider here. Anyone can build a v one. The problem is when you get to v two, v three, v four, v n, when you go from beta testers out to actual users, in the real world, you bring more people onto your team, internal users. Eventually, you can't just throw hardware at the problem to get by. You actually need to have a proper back end that supports growing your application and whatever it is that you're building.\u003C\u002Fp>\u003Cp>And the third pillar is ownership, or taking all of this and making sure you own what you're building. Again, the value of what you're building is not the front end. That's been commoditized. It's not your cloud infrastructure, your hosting, that's a utility bill, and it's not even really your data that can be scraped, pretty easily these days. So the value is your back end.\u003C\u002Fp>\u003Cp>It's the architecture, the logic and your team, that's, you know, back there moving faster through this collaboration. It's the trust that you create, again, through scale and governance and all of that. It's the value that you unlock from your data with all of this. So you want to pull these systems closer. That's your fence.\u003C\u002Fp>\u003Cp>That's your moat. Self hosting, data sovereignty, open systems. This is where you take control back. So these are the three things that are needed for a proper Backend. But even for the modern organizations that check off all of these boxes, they're still seeing ten, twenty, 30 plus, of these back ends, you know, all over the place.\u003C\u002Fp>\u003Cp>Disparate systems, each with their own API. Maybe it's REST or GraphQL, webhooks. You know, they're all different integrations, different interfaces, different logins. They don't talk to each other. Data is siloed, and so is collaboration.\u003C\u002Fp>\u003Cp>So we're looking at something that has no federation, no unified layer, no consistency and no strategy. And for AI apps, that's even worse. They typically don't even have a backend at all, you know? So here we are. The backend era has begun.\u003C\u002Fp>\u003Cp>So what do we do now? What do we need? We need a unified layer, a single pane of glass that you can put across these disparate systems and bring them together, leaving the data in situ, leaving the data where it is, but federating it and bringing it together. We need to wrap all of that with the granular access control, the rule based permissions, that allow humans and other integrations and agents all alike to have CRUD, to have create, read, update, and delete control, so they're not deleting the data so that you gain more of that trust. You need to bake the tools into this platform that give it the scale and resilience that we were talking about.\u003C\u002Fp>\u003Cp>Not just the API throughput and the data pipelines, but also scaling your team. So again, you need to be able to have everyone working together. And you need to make this a model that is completely yours. So deploying where you need to deploy, whether that's cloud or on prem, you wanna make sure that you are working with an open core, that it's source available. This is the value.\u003C\u002Fp>\u003Cp>So you want to keep all of this really safe. This is actually what we've been building at Directus, and it works. We have 45,000,000 Docker downloads, 35,000 stars on GitHub, You know, over a thousand customers. It started back in 2004, twenty two years ago. My agency in Brooklyn.\u003C\u002Fp>\u003Cp>We were building for Google, Prada, Snapchat, SoulCycled US government, AT and T. And behind every project that we built, there was a database. And we made something for that database that was simple, safe, and intuitive enough for the business user, this collaborative back end. Back then, my team was human, obviously. And we were creating those innovative front ends and now here we are two decades later and it's even more important.\u003C\u002Fp>\u003Cp>Everyone's a builder. Everyone has these interfaces that they're generating. Alright. So I will leave you with this one last bit, for today. Our Directus platform powers production applications for very large brands, around the world.\u003C\u002Fp>\u003Cp>One of these global pizza delivery app, brands is actually handling 9,000 requests per second, sustained. This is not something that you just one shot your way into. You're not going to vibe code your way, in, you know, the hour, the day, the week for these mission critical production scale applications. The front end may be what most people admire this exciting, you know, glamorous thing that we're seeing, very, very recently come out of all these AI app building tools. And it's phenomenal, but the backend is what they trust.\u003C\u002Fp>\u003Cp>So invest accordingly. From me and everyone at Directus, thank you so much and happy building.\u003C\u002Fp>","So let's kick things off. This is Ben, founder and CEO at Directus. And today, I need to talk to you about the end of the UI era. A little sensational, but let's dive in so that I can explain. First off, you might be thinking, don't we have better tools, more people than ever building all these front ends, all these UIs? Yes, absolutely. But when everything is special, nothing is. The front ends have been, commoditized. So let's explore what actually makes software magic, and specifically where the value of software has shifted to and where it's heading next. So since software was created, the interface has been mistaken for the product itself. Users click through, buttons and interfaces and they said, Oh, this is the magic. They saw a dashboard and they said, Oh, that's the application. The Shiny part got the attention for most users. But engineers, you know, for those who are out there, you know better. The visible part of the software is the tip of the iceberg. What lives underneath is the expensive, the fragile part. The part that takes years, decades, to get right. AI has made this a really big deal. Anyone can spin up a decent looking UI, a form, with solid UX, dashboards, components, all of that. They can stitch it together and you can get something that looks just like software. That's amazing. But it's also misleading and maybe even a little dangerous. It creates the illusion that software got easy, but it did not. The front end got easier. The back end maybe even got harder. We have so many builders out there. The back end is the tricky part. And the reason for that is you don't know what you don't know. So while most non engineers can definitely dream up an interface, you are a non technical person. You probably don't know what is needed behind the scenes to actually build this out, make it scalable, make it resilient. So you can Vibe code a UI in a day, but you cannot Vibe code trust. So maybe we just delete the backend. Cursor a little while back actually deleted their headless CMS. As an example. They replaced it in a couple days for a couple $100 worth of tokens. And that really works for a company like theirs. A small team, highly technical, very capable. But that's not going to work for other organizations. You can delete the CMS, but you can't delete the problems that the CMS solves. They come back and when they do, you're either gonna be building from scratch or you're gonna be drowning. So switching gears, let's talk about the back end. You can't one shot your way into production resilience. You can't fake your way into scalable architecture, granular RBAC or access control, reliable APIs, multi tenancy observability, governance rollback strategy, operational maturity. All of this is earned the hard way. Cursor, Lovable, Replit, Bolt and others, they've all made it really easy to create a front end in minutes. And it works. But without a back end, really what you've created is a clickable prototype. The front end and back end distinction gets really blurry because of the excitement around, you know, the generation of this of this front end. And I I love metaphors, so I'll kinda take a a second here. You wouldn't build a house starting with the doorbell, or something like that. You know, the the fresh paint, the beautiful fixtures, the interior design, none of that matters if you've got plumbing, leaking behind the walls, if you've got electricals, you know, sparking fires behind the sheetrock, a foundation that's not even poured and the house is just sinking into the mud. That's just not how things work. Anyone can build these demos, these facades, but far fewer people can build something that actually survives success. You just you can't vibe code trust. So if the front end is becoming free, where does the value go? It goes deeper but not just deeper technically, deeper organizationally. The thing that makes software software wasn't really the pixels. It's not the front end. It's the layer underneath where your whole organization goes, to work together. It's the logic, the APIs, the permissions, the 99.999%, uptime. Your performance under load. You know, does that work? Auditability. Maintainability. The stability that people don't notice until things break. It's not what you see, it's what you feel. You feel when your app goes down. When the data is suddenly corrupted or truncated unexpectedly or deleted. Permissions break. Traffic spikes and things just fall apart. The front end may be what people admire, but the back end again is what people trust. That's what really matters here. So let's first clarify what do we mean by back end. There's the Supabase Lovable partnership and people would refer to Supabase as the backend. It's a database. It's got infrastructure, an API. But really the backend is more than that. The backend is a collaboration layer. It's where technical and non technical users can go to actually access, to browse, manage, and visualize data. It's where data is governed, and used. Not just by engineers, but by anybody in the team. AI accelerates what individuals can do. Our own engineering team uses Cloud Code every day and the velocity gains are very much real. But more complex use cases require humans working together across teams. Engineers with PMs and ops, marketing, legal. AI doesn't solve the collaboration problem. It actually makes it larger. The winners won't be those that can create the prettiest screen the fastest, but those that combine the speed of AI built interfaces with the true discipline of back end engineering. And then democratizing that across the entire organization, technical users and non technical. That's how a hobby project becomes an actual product, or in some cases, how a product becomes an actual company. Okay. So let's break down the back end into three pillars. The first one we'll call governance, how you collaborate safely. The data is there. It's in the database behind every application, that's that's out there. But it's locked behind the doors of IT, as it were, for every report, every change of the data that's needed. If you're non technical, you're probably submitting a support ticket. We need tools that unlock the database for the technical users. Technical users are about 3% of an org, typically. And so we need something like a database administration tool but that's simple, safe, and intuitive enough for anyone to use. It's not about locking things down. It's about opening them up, responsibly. How many one shot AI applications are actually considering RBAC and granular permissions and all that in their system? I would guess not many. So we need to browse, manage, and visualize our data, in an intuitive way. We also need docs, API references, specifications. Those are needed as your team grows, more people join, you need integrations with other services. Those are boilerplate. Let the subject matter experts do their work. We all have seen, you know, a game of telephone and how that can degrade things. You can't pass these requests along. You need people to do that work directly. And so we need interfaces that work for everyone. The second one is scale, or how we take that collaboration and we make it survive the complexity, of the real world. You could also consider that to be production efficiency, resilience. There are a lot of things to consider, consider here. Anyone can build a v one. The problem is when you get to v two, v three, v four, v n, when you go from beta testers out to actual users, in the real world, you bring more people onto your team, internal users. Eventually, you can't just throw hardware at the problem to get by. You actually need to have a proper back end that supports growing your application and whatever it is that you're building. And the third pillar is ownership, or taking all of this and making sure you own what you're building. Again, the value of what you're building is not the front end. That's been commoditized. It's not your cloud infrastructure, your hosting, that's a utility bill, and it's not even really your data that can be scraped, pretty easily these days. So the value is your back end. It's the architecture, the logic and your team, that's, you know, back there moving faster through this collaboration. It's the trust that you create, again, through scale and governance and all of that. It's the value that you unlock from your data with all of this. So you want to pull these systems closer. That's your fence. That's your moat. Self hosting, data sovereignty, open systems. This is where you take control back. So these are the three things that are needed for a proper Backend. But even for the modern organizations that check off all of these boxes, they're still seeing ten, twenty, 30 plus, of these back ends, you know, all over the place. Disparate systems, each with their own API. Maybe it's REST or GraphQL, webhooks. You know, they're all different integrations, different interfaces, different logins. They don't talk to each other. Data is siloed, and so is collaboration. So we're looking at something that has no federation, no unified layer, no consistency and no strategy. And for AI apps, that's even worse. They typically don't even have a backend at all, you know? So here we are. The backend era has begun. So what do we do now? What do we need? We need a unified layer, a single pane of glass that you can put across these disparate systems and bring them together, leaving the data in situ, leaving the data where it is, but federating it and bringing it together. We need to wrap all of that with the granular access control, the rule based permissions, that allow humans and other integrations and agents all alike to have CRUD, to have create, read, update, and delete control, so they're not deleting the data so that you gain more of that trust. You need to bake the tools into this platform that give it the scale and resilience that we were talking about. Not just the API throughput and the data pipelines, but also scaling your team. So again, you need to be able to have everyone working together. And you need to make this a model that is completely yours. So deploying where you need to deploy, whether that's cloud or on prem, you wanna make sure that you are working with an open core, that it's source available. This is the value. So you want to keep all of this really safe. This is actually what we've been building at Directus, and it works. We have 45,000,000 Docker downloads, 35,000 stars on GitHub, You know, over a thousand customers. It started back in 2004, twenty two years ago. My agency in Brooklyn. We were building for Google, Prada, Snapchat, SoulCycled US government, AT and T. And behind every project that we built, there was a database. And we made something for that database that was simple, safe, and intuitive enough for the business user, this collaborative back end. Back then, my team was human, obviously. And we were creating those innovative front ends and now here we are two decades later and it's even more important. Everyone's a builder. Everyone has these interfaces that they're generating. Alright. So I will leave you with this one last bit, for today. Our Directus platform powers production applications for very large brands, around the world. One of these global pizza delivery app, brands is actually handling 9,000 requests per second, sustained. This is not something that you just one shot your way into. You're not going to vibe code your way, in, you know, the hour, the day, the week for these mission critical production scale applications. The front end may be what most people admire this exciting, you know, glamorous thing that we're seeing, very, very recently come out of all these AI app building tools. And it's phenomenal, but the backend is what they trust. So invest accordingly. From me and everyone at Directus, thank you so much and happy building.","d312a30e-6db1-4a83-8dea-ae5c75e3e179",[57],"02c14164-7bd1-470f-aa71-bd2a16d33a86",[],1781213218019]