Description Transcript
The future of app development isn't about replacing developers—it's about helping developers harness their org’s own data, in their own environment, at unprecedented speed.
In this session, you’ll hear from Retool Head of Product Marketing, Sean Allen, and Product Marketer Mads Clark on how the next generation of app dev works: where natural language prompts connect directly to your enterprise data and resources to create production-ready apps, automated workflows, and autonomous agents almost as quickly as they can be thought up.
Recorded live at SFJAZZ Center in San Francisco on October 7, 2025.
Read more 0:04 Please welcome to the stage Matteline 0:06 Clark, Retool Product Marketing, and 0:10 Sean Allen, Retool head of product 0:12 marketing. 0:18 [Music] 0:24 All right. Hey everybody, welcome back 0:26 from lunch. So good to see you all here 0:28 in the SF Jazz Center. We're so excited 0:30 to kick off the afternoon sessions with 0:32 you all. And in honor of being here, if 0:34 there are any musicians in the house, 0:36 what we're going to do this afternoon is 0:38 a little variation on some themes. 0:40 First, we're going to talk more about 0:42 going from concept to completion. Then 0:43 we'll talk a little bit more about the 0:45 next generation of builders and bring us 0:47 home with aic future. So, thank you for 0:49 attention your attention and I'm so 0:51 excited to start session one. Sean, all 0:54 yours. 0:54 >> Awesome. Let's do it. All right, 0:56 audience participation time. We want to 0:58 see a show of hands for those of you who 0:59 have built a cool prototype in the last 1:02 month or two. Get you. There we are. 1:05 Okay, maybe even outside of retool. 1:10 All right, it's okay. We get it. It's 1:11 taken us a minute. Um, all right. Now, 1:14 how many of those hands that are 1:16 hopefully still in the air? Sorry, we're 1:17 about to lose effect. Get those hands 1:19 back in the air. Cool. All right. Now, 1:20 how many of those hands actually shipped 1:21 it to an audience outside of themselves 1:24 or their team and they're actually it's 1:25 actually being used and it know about 1:29 it? 1:32 All right. Awesome. That's what we're 1:33 here to talk about today, right? The gap 1:35 between a thing I built and a thing that 1:37 everybody's getting um great utility out 1:40 of. 1:42 >> We know we have an explosion of 1:43 creativity happening right now. AI is 1:46 putting the power to build in everyone's 1:48 hands. But if we're honest, most of 1:50 those brilliant ideas die in the 1:52 production tunnel. And we know that's 1:54 not a tooling problem anymore. It's an 1:57 architecture problem and it's a 1:59 governance problem. It's a we built this 2:01 amazing thing and now it needs rowle 2:04 security and audit logs and compliance 2:06 approval problem. 2:09 >> So today we're going to show you how you 2:12 can close that gap from concept to 2:15 completion. And we mean it literally. 2:17 From the moment you have the idea till 2:19 the moment a large group of people are 2:21 getting advantage of your brilliance in 2:23 production. 2:26 Here's an obvious news flash. Something 2:29 profound is happening in the world of 2:30 appdev. 2:33 How we build, what gets built, who's 2:36 doing the building are all growing and 2:39 changing. We're standing at the 2:41 beginning of a massive shift from appdev 2:45 to app gen. 2:48 It's a really exciting transformative 2:50 time, but it also creates new challenges 2:53 for getting real work done in the 2:55 enterprise. What transformative actually 2:58 means here is that your analyst who's 3:00 been dreaming of a new inventory 3:02 dashboard for 3 years can suddenly go 3:05 build it in an afternoon by having a 3:09 conversation, 3:13 >> which is incredible. which is terrifying 3:16 if you're in security. 3:18 >> Yeah, that's fair. Digital 3:20 transformation has been the buzzword in 3:21 our industry for what, over a decade? 3:24 Every year, we're promised faster this, 3:26 more of that, smarter tools, quantum 3:28 leaps, and you know what we've mostly 3:29 gotten instead? 3:31 >> More complexity, 3:33 tool sprawl, data overwhelm, tech debt 3:36 piling up like dirty dishes, governance 3:38 chaos, and meanwhile, the demands just 3:41 keep coming, right? new initiatives, 3:44 tighter budgets, fewer resources, and 3:46 everybody's boss or their boss's boss or 3:48 their boss's boss's boss is asking, 3:50 "Where's the innovation?" 3:52 Something has to give here. Something 3:54 has to change with the way we're 3:56 approaching this. 3:58 What if it didn't have to be that way? 4:01 What if safely creating enterprisegrade 4:03 software were as easy as creating a 4:06 document? 4:08 Ideas become working apps, not someday, 4:10 but today. Business logic and process 4:14 become part of a shared platform instead 4:16 of being trapped in silos. AI mandates 4:19 turned into motivators and catalysts for 4:21 change, not unachievable goals and 4:24 bureaucratic nightmares. 4:27 >> For that future, we do need a different 4:29 approach. We need enterprise AI appgen. 4:34 >> In the last year, we've all seen and 4:36 felt the power and hope of generative 4:38 AI. It's like magic. 4:40 >> Don't say it. 4:42 But everybody's using that word for AI. 4:44 >> Exactly. 4:45 >> All right. It is limitless creativity. 4:48 Now, anyone can describe an idea in 4:50 natural language and instantly see it 4:52 come to life as a prototype. A new tool, 4:56 a custom workflow, a dream app, all 4:58 sketched out with unprecedented speed. 5:01 The barrier to prototyping never been 5:03 lower. And it's unleashing individual 5:06 potential in ways we never dreamed of. 5:10 But again, let's be honest with 5:11 ourselves. How many of those amazing 5:13 ideas and prototypes make it to 5:16 production? The truth is, while the bar 5:19 to build has all but disappeared, 5:23 the bar to ship really hasn't moved. 5:28 There is an incredible amount of new 5:30 energy driving individuals, especially 5:34 about 50% of this crowd of domain 5:36 experts to build. AI tools in hand, 5:39 clever ideas are turning into prototypes 5:41 at blinding speed. And this rampant 5:44 though generally positive energy brings 5:48 a whole new layer of activity to the 5:49 company. It's a massive burst of 5:51 creative output. 5:54 >> And most of you have experienced that 5:56 explosion in creative problem solving. 5:59 You've seen the demos, you're tinkering, 6:01 you might be building stuff yourself, 6:03 but those prototypes hit a production 6:05 tunnel. 6:07 And not much makes it out the other 6:09 side. 6:11 Most of these ideas get stuck not 6:13 because they're bad ideas or because 6:15 they're flawed, but because they run 6:18 into a buzzsaw of governance realities. 6:22 Security, data access and integrations, 6:25 architectural standards. All of those 6:27 things are what make up the walls of 6:30 that tunnel that every prototype has to 6:32 pass through. So extremely few of the 6:36 really great ideas actually make it to 6:37 broader usage. So what we have left is a 6:40 massive anticipation of forward 6:42 progress. We've got all this momentum 6:44 brewing, but it hits a really narrow 6:47 tunnel. And what that leads to is 6:50 devastation of unmet promise. 6:54 And in this scenario, that's actually 6:57 the best case because the likely outcome 7:00 is that some of those tools without the 7:02 proper foundations do escape, 7:04 circumventing proper requirements, and 7:06 then you find yourself with a whole new 7:08 set of problems. Governance violations, 7:10 compliance gaps, security holes. That's 7:13 the paradox. 7:15 The trends that we're discussing make 7:18 individuals faster, but they actually 7:20 slow teams down because they ignore or 7:23 continue to push continually push 7:25 against the guard rails that are 7:27 required for companywide acceleration. 7:31 Is anyone here vibing with the feeling 7:34 of being crushed by your production 7:35 tunnel? Having your ideas and dreams 7:38 crushed, or maybe just feeling like you 7:40 had a burst of creative energy and it 7:43 started bouncing off the walls of the 7:45 tunnel. Raise your hands if you're 7:46 feeling a little bit of pressure on 7:48 that. I certainly am. 7:51 There's almost a feeling of productivity 7:53 overwhelm that happens when there's all 7:56 of these ideas and apps being generated 7:58 and a lot of energy being spent on it. 8:01 When each app or idea tries to move from 8:04 that creative spark phase to the let's 8:06 get this in production phase, that feels 8:08 even more stressful. 8:10 And often that acceleration of more apps 8:13 and more ideas and more experiments 8:15 turns into more bugs, more integrations 8:18 you have to chase down, more approval 8:20 requests, more time, more spend in 8:22 reviews. 8:25 So the question then becomes how do we 8:28 collectively embrace this explosion of 8:30 creativity in without creating a 8:34 explosion of tech debt and new security 8:36 vulnerabilities 8:38 because we've learned that you can't 8:39 just say no to innovation. We don't want 8:42 to, right? People are going to build. So 8:45 together let's find a way to harness 8:47 that energy instead of blocking it. 8:50 This is especially important when the 8:53 definition of a developer, a builder, is 8:55 expanding much faster than organizations 8:57 are able to keep up with and realize. 9:01 We're not just talking about engineers 9:02 anymore. Analysts are writing SQL 9:04 dashboards. Ops teams are automating 9:06 processes. Data scientists are turning 9:09 notebooks into apps. 9:13 >> These are the domain experts solving the 9:16 real problems. They understand the 9:18 business context better than anyone and 9:20 they're using it to build real 9:22 solutions. 9:25 >> But the reality is if you want a world 9:27 where these new builders can actually 9:29 safely create, you can't just slap on a 9:31 new point solution. Nor can you just 9:34 wave a magic wand and turn them into 9:36 engineering prodigies, which is often 9:38 what you feel like you need to do in 9:40 order to understand the output from most 9:42 of the AI assisted tooling. You have to 9:45 put secure innovation into everyone's 9:47 hands. 9:51 >> Imagine an approach that doesn't just 9:52 lead to generated code and new surface 9:56 areas of vulnerability, but one that 9:58 actually understands and codifies your 10:01 architecture, your patterns, and your 10:04 own constraints. 10:07 Many of you in this room representing 10:09 the 10,000 customers who are already 10:11 trusting us have captured those guards 10:14 and those constraints and requirements 10:16 on top of the secure baseline of the 10:18 retool platform. 10:20 And we know these aren't just generic 10:22 security policies. They're your specific 10:25 requirements embedded into the app and 10:28 platform itself. 10:30 For a healthcare company, that might 10:32 mean something like every app inherits 10:34 HIPPA compliant logging. For a financial 10:37 services firm, it looks like something 10:39 it looks something like uh transactions 10:42 over a certain threshold trigger an 10:44 approval workflow. And for a major 10:46 global enterprise, maybe it means 10:48 something like all apps respect data 10:51 regional data requirements. The point 10:54 is, these aren't just restrictions or 10:56 requirements you can bolt on later. 10:58 They're integral to the way that you and 11:01 everything you build have to operate. 11:06 If you build on a platform where every 11:08 app automatically follows your 11:10 architectural and security standards, 11:12 you can drive structured innovation and 11:14 scale institutional knowledge across 11:16 your entire org. You get to expand the 11:19 walls of this production tunnel from 11:20 ideas and concepts to complete apps, 11:23 flows, and agents. Now, every builder in 11:26 your organization, and I mean every 11:28 builder, can innovate safely. More 11:30 sparks of creativity turn into working 11:33 solutions in the hands of people who can 11:37 and need to use them. 11:41 So today, we're proud and thrilled to 11:43 continue diving into exactly how we can 11:46 bring that to life with the first 11:47 enterprise appgen platform built to 11:50 effortlessly turn natural language, 11:52 visual canvas, and code into 11:54 productionready software on your data, 11:57 in your cloud, and secure by default. 12:00 This is the way for all builders to turn 12:03 problems into software that's instantly 12:05 usable, deeply integrated, and aligned 12:07 with your governance and data models. 12:10 Welcome to the new retool. 12:13 >> All right, enough vision. You guys want 12:16 us to get into the product a little bit? 12:19 >> That's what I thought. So do we. 12:23 >> All right, let's say your operations 12:25 team needs a cash flow dashboard. You 12:28 know the rough requirements. you know 12:30 generally the shape of the app you want 12:31 to build. So you hop into retool because 12:33 you know you want to build something 12:34 fast. 12:36 We have the connections we need to 12:38 actually build this. And so let's just 12:40 describe the app we actually want. 12:43 I want to create a dash flow that shows 12:45 the highle KPIs a timeline of upcoming 12:48 payouts and a list of any inpaid 12:51 invoices. 12:52 Now what's great is we can just atntion 12:55 the resource we need. We're pulling data 12:57 from Stripe and since our finance team 12:59 already set up the permissions in Stripe 13:02 to make this usable for us and 13:03 accessible to us, we can call it right 13:05 within the prompt and start building on 13:07 it immediately. 13:09 Just like you've already built upon the 13:11 resources that you have in Retool, 13:12 they're here right for us. 13:16 This matters because you don't have to 13:18 continually recreate connections or 13:20 fight with API keys. Any of the 13:22 resources, the live resources and data 13:24 you have, they're ready to go. The 13:26 security and access to them has already 13:27 been handled by the teams with the 13:29 expertise to make that safe. So you can 13:32 get started. 13:35 Now in the next step in our process, 13:37 what do you guys notice? 13:40 We stopped at a plan. We didn't barrel 13:43 headlong into mountains and mountains of 13:45 generated code. This like runaway train 13:47 of generation, right? I love this. It 13:49 actually paused and said, "All right, 13:50 let's figure out a plan together of 13:52 everything that we need." So step one, 13:54 what we saw actually generated a mockup 13:56 for us. It walked through the wireframe, 13:58 pulled in what components we'd probably 14:00 need, and then in step two started 14:02 defining the data model and dependencies 14:04 that we need to actually build the app 14:06 we want to see. Then in step three, 14:09 retool read out and created the 14:12 implementation plan and all the next 14:13 steps that we need to hit. So let's say 14:16 you know we want to add titles to the 14:18 containers. We want to add the UI 14:19 components that are necessary. Create 14:20 some variables with our mock data 14:22 literally step by step. What we can do 14:25 here is guarantee that the dashboard 14:28 that we're about to create is actually 14:29 going to meet the requirements we set 14:31 out in the first place. That's pretty 14:33 awesome. And we can stop and give 14:34 additional guidance or make tweaks here 14:36 anytime we'd like to. 14:39 Why this matters is we can see the 14:41 blueprint before any building actually 14:43 begins. before we have to deal with that 14:45 runaway train and honestly before we 14:47 have to waste a lot of our own or others 14:49 time. We can stay in control from start 14:52 to finish of this creation process. 14:57 All right, once we click go, let's see 14:59 what happens. 15:05 Now we have in literal seconds our full 15:08 functional complete app right here. If 15:11 you were paying attention, you might 15:13 have seen that some of the resources and 15:16 um variables and components were already 15:18 pulled in and automatically connected to 15:20 that livestripe data. So at the very top 15:23 we had our key metrics immediately 15:24 pulled up to be the cash balance, the 15:26 accounts, all of the metrics that matter 15:28 to me and the ops team. The Gant chart 15:31 turned into a live uh timeline of the 15:34 payouts that we need to see. And then 15:35 the unpaid invoices table was pulled 15:37 with real numbers. It even caught an 15:39 error that we had in our data and fixed 15:41 it for us. 15:43 So what we have now is this fully 15:45 functional app. We just described what 15:47 we needed in plain language. Didn't have 15:49 to wrestle with the complexities of 15:51 components, setting up or configuring 15:53 anything. We just focused on the 15:54 requirements of the app and not the 15:56 implementation details and let retool do 15:58 all the heavy lifting fast and secure on 16:01 our realstripe data. 16:04 Now, if we want, let's say we want to 16:05 make some different adjustments 16:09 over here on the right, you can see you 16:10 can just hide a column. If you don't 16:12 want it anymore, if it's not critical to 16:14 your application, you can just boop hide 16:16 it. You can use the visual canvas there. 16:18 You can use something natural that feels 16:20 like it's in your workflow. You can also 16:22 make live adjustments, anything that the 16:24 UX will automatically adapt to. 16:28 Some of these things may not matter to 16:29 us. The point is we can continue 16:31 customizing within the app itself and 16:34 see the live results immediately. 16:37 What that gives us is the speed of 16:40 generation, right? We've been able to 16:41 literally generate an app, but the 16:44 customization and finesse and 16:46 flexibility to make it usable to us to 16:49 make this a piece of software that feels 16:51 like it belongs to me and my team. 16:54 And once you're in the app itself and 16:56 you want to continue optimize, you can 16:58 work in whatever mode makes the most 17:00 sense for you. You can do the booping on 17:02 the the columns. You can move things 17:04 visually. You can go code if you'd like 17:06 to. All of that is available to you. 17:12 Now, let's say, all right, we've done a 17:14 little bit of UX tweaking, but we 17:15 actually need to add one more piece of 17:16 functionality. So, we hop back into the 17:18 prompt. What we want to do is add a 17:21 search by customer name. Now, we're 17:24 going to see what's generated for us. 17:26 And if we don't like what's available on 17:27 the other side, we can just revert to 17:29 the previous version. And again, what 17:31 it's going to do for us is write the 17:33 step-by-step process and give us a 17:34 glimpse into everything that's happening 17:36 behind the scenes. So, step three, 17:38 actually going to update the table 17:39 filter logic for us. We can see that 17:41 that happened. And number four, it even 17:43 confirmed that the status filter worked 17:44 for us. That's so great. We can see that 17:46 it's already live and ready to go. 17:49 And we check back in our app. 17:52 There it is. It's live. 17:55 Now, we know that this is the version 17:57 that we wanted to add that filter to. 17:59 But if we wanted to go back and forth 18:01 and see the different versions that 18:02 we've been creating, we're able to do 18:03 that right in the UI as well. You can 18:05 even have multiple threads of multiple 18:07 changes going on at the same time. So, 18:10 it's so easy. The barrier to experiment 18:13 is so much lower. And we can see these 18:15 actual changes on real data in real time 18:18 side by side. That's fantastic. I can 18:20 actually make the choices I'd like in 18:22 the design of my app on real data in 18:24 real time. So any of those choices would 18:27 be based on real observation. 18:30 I love that you could experiment without 18:32 breaking things or sometimes more 18:34 importantly experiment with having to go 18:36 back to square one every time you want 18:38 to try something new. You can compare 18:40 those options side by side with real 18:41 data and you can iterate as quickly as 18:44 you think of the next experiment. 18:47 Now, we spent a fair bit of time here in 18:49 the setup in the building, but there's a 18:51 lot more in creating an app and actually 18:54 shipping it to production and making it 18:55 usable by others. So, let's take a look 18:57 at access control and publishing the app 19:00 itself. 19:02 Once we're ready to publish, we create a 19:04 group for our ops team. We give them 19:06 ownership access to the dashboard that 19:08 we just created. We confirm that all the 19:10 right accounts are actually in that 19:11 list. And then we publish. Now, this is 19:14 totally live. So, If we once it's live, 19:18 we can see that the search function 19:20 works. We can play around, do a little 19:22 testing ourselves. But the great thing 19:23 is once it's live, we can go ahead and 19:25 monitor the usage with audit logs. We 19:27 can take advantage of the governance 19:29 features already in retool to make sure 19:31 this is sustainable, governable, and 19:33 scalable. Now, I'm going to stop myself 19:35 there a little bit because our 19:36 colleagues Todd and Gabriella are going 19:38 to dive into in much more depth the 19:40 specific capabilities around governance 19:42 for us later this afternoon. But it's 19:44 all to say in a few minutes we've gone 19:46 from a blank canvas in a disconnected 19:48 Stripe resource to a working app live 19:52 with everything in one place and we know 19:54 it's safe and secure. 19:57 This isn't a prototype. This isn't 20:00 ephemeral and it's not d bogged down by 20:03 bugs. It's not full of bloat. It's not 20:08 shackled by scaffolding we never needed 20:09 in the first place. This is simple and 20:12 elegant and functional. It works. 20:16 >> All right. Fantastic. Boop. Thank you. 20:20 We're going to go on to a set of 20:21 vignettes that are going to dive a 20:23 little bit deeper into specific 20:24 capabilities. Um, some of which Mads 20:27 just showed and some of which are 20:28 extensions. The first is going to be 20:30 understanding apps and logic. And we're 20:33 starting here because as internal 20:34 builder communities grow, which is a 20:37 trend that's going to be exploding as a 20:38 result of this new dev mode, solving the 20:41 problem of understanding existing apps 20:44 and assets is a massive accelerant. 20:47 Prompting can be incredibly useful 20:49 outside of just the scope of creating 20:51 and updating. It can also shorten that 20:54 understanding gap. So I can simply ask 20:56 an app. I can simply ask a a question 21:00 like how an approval action works for a 21:02 particular user and hang on to get an 21:05 explanation. Right? So the builder sees 21:07 what triggers the approval, which 21:09 operations launched as a result and flow 21:11 through the rest of the action all in 21:13 plain English for me to read. 21:17 It's now incredibly easy for any 21:19 builder, 21:21 today's builder, tomorrow's builder, to 21:23 pick up a tool that they know nothing 21:25 about and get a credible level of 21:27 information about it such that changes 21:29 and updates become a confident breeze. 21:32 This is such a necessary and key unlock 21:34 as the number of builders continues to 21:36 grow and the surface area for what's 21:39 being created explodes. 21:43 Next, we're going to talk about working 21:44 with specific resources. Sometimes you 21:47 don't want an LLM to guess. Sometimes 21:50 you want to tell it precisely what you 21:52 want to work with. So here, let's take a 21:55 look at this prompt. Couple of things 21:57 are going on. Second paragraph talking 22:00 about database access. I specify what 22:03 the required fields are for what I'm 22:04 doing. And then I specify some UI 22:07 requirements. Give me a clean dashboard 22:09 style interface. put some quick filters 22:11 at the top and one that I want you to 22:13 remember which is sort a view of failed 22:16 shipments. 22:18 Now all I need to do to specify what 22:20 resource is just at mention it. You can 22:22 see it does autocomplete. Here we grab 22:24 retool database and go. It takes all of 22:28 this information and goes through and 22:30 creates a plan. Pauses for a second. 22:32 Let's take a look at it. We've told it 22:34 that we want to use this specific 22:36 database. So what do you think it needs 22:38 to do? needs to go learn more about that 22:40 database, what's in it, what schemas are 22:42 available, etc. Then it's going to go 22:44 off and design a clean dashboard style 22:46 interface with filters, etc., etc. 22:48 Define a technical implementation plan, 22:50 and then create detailed coding steps to 22:53 actually go build the app. Let's let it 22:55 keep going. 22:57 First thing it did is that first step 22:59 that we talked about, it went and expect 23:01 inspected the database, knowing what was 23:03 asked for in the prompt, looking at what 23:06 act what exists inside the database. and 23:08 we had a hit. We already have a table 23:10 called shipment data that has all of the 23:12 things that we need, but retool wants to 23:14 learn a little bit more about it. So, 23:16 it's going to examine the shipment data. 23:17 And the next thing it's going to do is 23:18 check for failed shipments. Remember 23:20 that was part of the prompt, right? So, 23:22 it's going to dive in a little bit, but 23:23 we've paused. Why have we paused? 23:25 Because we've said always ask before you 23:27 run the query. So, it's waiting for a 23:29 human to say, "Yep, that looks good to 23:31 me. Run it." Right? And with that deeper 23:34 information, what comes back is 23:37 creating SQL queries to fetch failed 23:39 shipments, create JavaScript and SQL 23:41 queries for different pieces of it, 23:43 wiring filter components to all of these 23:45 different parameters and results, 23:47 configuring a whole slew of handlers, 23:49 etc. To the rebu retool builders in the 23:51 room, all of this sounds super familiar, 23:53 right? These are the things that you're 23:55 that you have been doing manually for a 23:57 while using the first wave of retool 24:00 productivity unlock. This is the next 24:03 one where it all happens automatically 24:04 for you. In addition, it's already 24:06 created the app structure. Kind of hard 24:08 to see, but there's a couple of boxes on 24:09 the right hand side. Continuing through 24:12 the building process, now it's going to 24:14 throw a slew of different UI components 24:16 all the way through that structure that 24:18 had already been created, adding in um a 24:21 number of data queries, action queries, 24:25 and then full access to that resource in 24:29 this case retool DB is available both in 24:32 the visual canvas as well as in code. 24:36 All 24:38 right, moving on to our third. Editing 24:40 an existing app. This one was hugely 24:43 popular during the early access period 24:46 for this launch. We found universally 24:48 that this was the main use case that 24:50 people were interested in, right? 24:52 Whether the app was created through a 24:53 prompt or is a years old app trusted and 24:57 reliable that just needed a little bit 24:58 of tuning, 25:00 an update should really be a question 25:02 away, right? So 25:06 here we want to uh um to add an action 25:08 specifically for changing a user static 25:11 status when an approval button is 25:12 pressed. 25:15 After thinking of a plan 25:18 sorry after thinking a plan is formed 25:21 and executed that focuses very 25:23 specifically on the part of the app that 25:24 we have honed in on. Now, this is a big 25:29 deal because it is an incredibly 25:32 frequent and annoying problem with a lot 25:35 of the existing AI assisted 25:37 tooling that's out there in the market. 25:39 If you don't get it right in one shot, 25:41 when you come back for your second, your 25:43 third, your fourth, your fifth, scoping 25:46 what you want to change about the app is 25:48 incredibly difficult. It just starts 25:50 changing different surface areas that 25:51 you're like, "No, leave that alone." 25:54 Right? So being able to focus it um is 25:57 incredibly important. And to that end, 25:59 while we didn't do it here, there's 26:01 another capability when you're in the 26:02 visual canvas, you can select just a few 26:05 things on that canvas and then say 26:08 prompt on that, right? So you can focus 26:11 in the scope of your prompt and of your 26:13 change. Um which is just a um a a a 26:17 hugely beneficial guard rail. 26:20 So we continue through the plan. Next 26:22 thing it's going to go do is create a um 26:24 a JavaScript query that updates the 26:27 status field to approve. It's going to 26:28 set up those different event handlers 26:30 and then very importantly verify the 26:33 approved functionality works as 26:35 expected. 26:37 Continuing through, it's going to wire 26:38 those action handlers to the UI. So 26:42 clicking approve now captures the 26:44 selected ID. It opens a model a modal on 26:47 confirm. It marks the items as approved, 26:49 etc., etc. It's just telling you 26:51 sometimes more than you want to know. 26:54 But that's where you build that level of 26:55 trust with what's going on, right? You 26:58 can always inspect what it's going to 26:59 do. Here it tells you what it's done. 27:04 When you click the approve action for 27:05 any user in the table, it's going to do 27:07 three things. It's going to open the 27:09 approval modal. So you can and then you 27:12 can optionally add notes. It's going to 27:13 update the user status to approved. And 27:15 it's going to show a success 27:16 notification. 27:19 And if you look directly over the over 27:21 the prompt box here, you'll see revert 27:23 to version and create a release. If you 27:25 don't like what it's done so far, throw 27:27 it away. Revert back to before, modify 27:30 your prompt. Also, if you're in the if 27:32 it's in the middle of thinking, you can 27:34 stop it and say, "Hang on, here's some 27:35 more context. Now, take that and go um 27:37 etc., etc." Or if it's time, I can 27:39 create a release. I can snap a line to 27:41 this and say, "This is this is what I 27:42 want." 27:46 And as the change is implemented, we 27:47 move to the ca the visual canvas and 27:49 test it out. We select a user, hit 27:51 approved. There's that modal we were 27:53 talking about. There's that notes field 27:54 that we were talking about, etc., etc. 27:56 Quick, simple, painless. 27:58 All right, let's round out the vignettes 28:00 that I'm going to go through with fun 28:02 with themes. 28:05 So, experimenting with themes can be a 28:08 large pain in the butt. It can also now 28:11 be a little bit of fun. Earlier today, 28:13 Abashek showed a really quick flyby of 28:16 turning a an application um or updating 28:19 an application with a a Spotify 28:21 branding. We're going to dig into that a 28:22 little bit more. Um right now, one thing 28:24 I want um I I'll point out here is that 28:27 our question is 28:29 first a statement, don't move any 28:31 components, 28:33 right? So don't change any of the stuff 28:35 that I like. Just focus your energy on 28:38 can you make the app look a little bit 28:39 more like Spotify? The answer is yes, I 28:42 can. I'm going to go out and learn what 28:44 Spotify looks like as a as a brand and 28:47 go ahead and make some changes to that 28:48 app that you can see happening in real 28:50 time. Then I'm going to come back and 28:51 I'm going to tell you about it. I change 28:52 the backgrounds. I change the text. I 28:54 change the accent, etc., etc. And 28:56 something really cool happens. It 28:58 doesn't just stop and say, "All right, 29:00 what do you want?" It says, "Hey, a 29:02 logical next step might be to do these 29:04 things. What do you think?" and we say, 29:06 "No, I think what I'm going to do is I'm 29:08 going to go into the visual canvas and 29:09 I'm going to make some changes because 29:10 it's just easier over there." Like one 29:13 of our awesome um colleagues, Kirsten, 29:15 she likes to explain it this way. If 29:16 you've got your hand on the wall next to 29:18 the switch, are you going to tell Alexa 29:20 to turn the light on? 29:23 So, we're going to come back and ask the 29:25 open-ended question, what else should we 29:28 what else can we do to make this more 29:29 Spotify branded? Retool. Go off and sort 29:32 it out. And boy does it. Look at the 29:34 list of things that come back, right? 29:36 Green hover effects, subtle shadows, 29:38 table enhancements. Could this screen be 29:40 any taller? Status tags, smooth 29:43 animation, sidebar layout. Right? 29:45 There's a whole ton of stuff that's 29:46 going on there. Hey, builder, would you 29:49 like me to go off and do that? Yeah, I 29:52 really would. Proceed. Right. So, it's 29:55 now going to go off and um reason 29:58 through all of those different pieces 29:59 and how it actually should look on the 30:02 app itself. Goes through and does that 30:04 and it comes back and tells me I added a 30:06 Spotify inspired dark theme, rounded the 30:08 filter containers, etc., etc., etc., 30:11 right? It went through all of those 30:12 things, told me what it did. So, it I 30:15 don't just have to look at it and go, I 30:16 I wonder what happened. It's telling me 30:18 what actually happened 30:20 next. I'm like, yes. It asked me if I 30:22 wanted to continue to polish. Polish 30:24 away. I love what you've done so far. 30:25 And here it's well, it's made some more 30:27 changes. It's changed the um the title 30:29 to um to white. Add this funky little 30:33 music emoji um uh there. And we're like, 30:38 "Okay, 30:39 calm down. I think you've gone a little 30:41 bit too far." So, um we take a look at 30:44 it. We're like, "It's not really quite 30:46 what I was looking for. It's time to hit 30:48 the reject button." Right. Let's revert 30:51 um revert to the last version. the last 30:53 version that you saw before it started 30:54 to do the the more additional polish. We 30:56 look at it and we're like, "Yeah, that's 30:59 that's actually it. That's what I want." 31:00 Poof. Had a little fun with um with with 31:03 theming. Had a little fun with some of 31:05 the other vignettes. It brings us um uh 31:07 to the next section, but what you got to 31:09 see here was starting with an end to 31:11 end, right? So starting from scratch, 31:14 using Stripe, getting an app, and then a 31:16 series of different vignettes that 31:18 hopefully you can see how you would be 31:19 weaving that into your organizations on 31:21 a daily basis. 31:25 >> No, thank you so much, Sean. Um, I know 31:27 there's nothing quite like getting into 31:28 the product and so when you guys leave 31:30 today and you're able to actually play 31:32 around with it, a lot of this is going 31:34 to feel so intuitive and exciting. It's 31:36 going to be actually at your fingertips. 31:38 I appreciate your attention as we walk 31:39 through those. And so to close out this 31:42 session, even though I know we love to 31:43 get in the weeds, we're going to stand 31:45 up. We're going to zoom back out a 31:47 little bit and we're going to talk about 31:48 what this means for everyone. How do we 31:51 connect the demo that we just did with 31:53 kind of a grander shift in the vision? 31:56 What this really means, everything we 31:58 showed you, everything we've been 32:00 talking about on stage today, and 32:01 everything we're going to keep talking 32:02 about on stage for the rest of the 32:03 afternoon 32:06 is everything for an individual builder, 32:08 for a team. For the individual builders, 32:11 whether you're an engineer, an analyst, 32:14 or an ops lead, what we showed you 32:16 changes the way you work. A critical app 32:19 or an automation is just a series or of 32:22 prompts and refinements away. now 32:26 and all of the other motivated builders 32:28 across your teams and across your 32:30 companies that currently have to wait 32:32 for it to clear a ticket or for 32:35 engineering to jump in with support. 32:37 Those folks and you go from blocked to 32:40 unleashed. 32:42 You can build custom dashboards in 32:44 minutes. You can create workflows that 32:46 actually mirror the processes you're 32:48 using in real life instead of relying on 32:51 other rigid SAS tools. 32:55 And that happens because the people 32:58 responsible for scaling development, 33:00 your platform and IT teams, and the 33:03 people closest to the problems, the 33:04 domain experts, we're finally building 33:07 together. 33:11 Platform teams get to design the guard 33:13 rails. They assemble the trusted 33:15 building blocks that we need. They 33:16 enforce the data and security and design 33:19 requirements and standards automatically 33:21 for us. So everything is created on top 33:24 of a secure compliant platform and is 33:27 production ready by default. 33:31 Once that's set, the domain experts get 33:33 to build on top of that foundation and 33:36 figure out exact the exactly the tools 33:38 that they need and will use. They get to 33:40 build those in plain language and an 33:42 intuitive canvas. And they get to 33:44 translate insight into action without 33:47 waiting for a ticket to clear or road 33:48 map to land. 33:51 The result of all of that is a new 33:53 operating model. Now best practices 33:56 don't have to be enforced because 33:58 they're just built in. Shadow tools stop 34:01 appearing at the margins because the 34:03 sanctioned ones are actually better. 34:06 And it no longer has to be the 34:08 department of no. They can be the team 34:11 that makes yes possible without 34:13 sacrificing trust, compliance or 34:16 control. 34:20 And when you zoom even further out 34:22 across all of those changes for the 34:24 domain experts, the engineers, the 34:26 platform and IT teams, even further than 34:29 that, the real meta shift starts coming 34:31 into focus as well because none of this 34:34 is just about moving faster. Though 34:36 that's awesome. 34:37 It's about changing the feel of work 34:40 itself. 34:42 Most of us didn't get into this field 34:44 because we love juggling Jira tickets or 34:48 chasing down permissioning errors. 34:50 We got into this field because solving 34:52 problems is satisfying. 34:55 There's something deeply rewarding about 34:58 untangling something really complex and 35:01 turning it into something elegant and 35:03 useful. 35:05 There's nothing quite like being the 35:07 person to find the last piece of the 35:09 puzzle and slot it exactly into place. 35:12 That's exciting. That's what keeps us 35:13 going. 35:16 And too often the work we do is hard in 35:18 all the wrong ways. What this shift does 35:22 is strip away so much of that friction 35:24 for us. So the challenge that's left, 35:26 the hard things for us, those are the 35:29 fun things, the interesting things. 35:31 Those are the challenges we actually 35:32 want to use our brains to solve. 35:36 We get to understand the problem and 35:38 shape the outcome, not spend all of our 35:40 energy like wrestling things out of the 35:42 way. 35:45 When every team gets to work that way 35:47 and every builder gets to work that way, 35:50 focused on solving the right problems 35:52 instead of mashing through the 35:54 constraints, 35:56 the chaos and the potential chaos of AI 35:59 can turn into a structured engine for 36:02 innovation where teams, all teams get to 36:05 move beyond just firefighting to 36:08 leverage governance and scale their 36:09 impact. 36:12 None of this today is about any single 36:14 feature. It's a shift in how software 36:17 comes to life inside your organization. 36:20 Now the gap between idea and production 36:22 grade software has collapsed because the 36:25 foundations that once came last holding 36:29 teams back from ever finding the real 36:31 utility of what they're trying to build, 36:33 those are now built in from the start. 36:36 And if we think about it, building first 36:38 and governing later never really made 36:41 sense, did it? Governance is how you 36:44 build now. So small sparks of 36:47 innovation, a faster path to action 36:49 here, a smoother handoff there, all of 36:52 that can add up to the real 36:54 transformation we've been talking about 36:56 across your teams, your projects, and 36:59 your companies. 37:02 >> And it is the new standard for 37:03 enterprise development. This is how you 37:05 finally get ahead of shadow IT when 37:07 you're not fighting it anymore. You're 37:09 channeling it into governed paths. 37:14 This is how you improve your return on 37:17 technology spend. Every dollar you've 37:19 invested in your data platform, your 37:22 security infrastructure, your compliance 37:25 framework. That gets multiplied 10fold 37:27 across every app and automation that 37:29 your teams build. Every solution your 37:32 team ships is ready for real use. It's 37:35 compliant, deployable, and most 37:37 importantly, it's all built to endure. 37:42 This is how you create an organization 37:44 that can respond to market changes not 37:46 in quarters, but at the speed of 37:49 thought, of insight, because your teams 37:52 can build the software they need without 37:55 waiting for external vendors or internal 37:57 backlogs. 37:59 This is how you create sustainable 38:02 velocity. 38:03 The companies that win in the next 38:06 decade or so are going to be the ones 38:07 who can turn those business insights 38:09 into working software safely, quickly, 38:13 and consistently. 38:15 When we do that, teams get freed up for 38:18 higher value work. the creative work, 38:22 their strategic work, the work that 38:24 actually moves things forward, moves 38:27 businesses forward, moves ideas forward 38:29 rather than just keeping the lights on. 38:33 And this is how enterprises become 38:35 intelligent, adaptive ecosystems where 38:38 software gets built and it doesn't just 38:41 exist in random areas. It continually 38:44 improves and evolves into compounding 38:47 returns. 38:48 And that's the hope that we want to 38:50 leave you with today. A way for progress 38:53 and innovation to finally stick. That's 38:57 what Enterprise AppGen delivers. 39:00 And the best part is the future we're 39:03 talking about is available now for all 39:05 customers. 39:06 This is enterprise appjen. 39:12 And we can't Whoa. Not yet. 39:16 Keep it though because we can't wait to 39:19 see what you build, 39:21 what problems you solve, what 39:23 innovations you ship. Now, thank you. 39:26 >> Thank you.
