How 48% of Non-Engineers Are Shipping Production Software (with Retool CEO David Hsu)

22:31Should he have access to Asana? You know, is that a good idea? Is that a bad idea? Let me look at my policies. Should someone in this department? Oh, it's fine. Okay. Well, let me go now into Asana and add them. It's like, okay. Like that's actually pretty doable if you just have five tools basically. And so, uh, whereas the S-TratGVT, you know, Hey, you can try and ask you to give Corey access to asana that should you be like well you should go into asana i should click this button over here and they should click the button because it can't do anything you know so i think that's where the magic really happens is when you can actually allow lms to gather its own information and actually do things in the world it's scary but it's so powerful well let's let's talk about

23:09David Hsu:this in the context of non-engineers building software right so so how like you know you you have potentially like non uh well hopefully it's not a non-it person building this it agent hopefully it's it person so they know what what they should and shouldn't allow but like for instance like if you have someone who's like coding a tool and they're gonna release that into production how do you maintain the quality when that person might not understand like the best practices of of what an engineer would know that's a good question so this is the magic of the Retool platform. And I think this is a actually pretty subtle, but accelerating change in the world, which is how it works in the Retool platform is engineers can specify what kinds of building blocks non-engineers are allowed to use.

24:00And so you might say, hey, when you're generating, let's say dashboards to view customers, we should always use this customer component that the engineer built. So that way, there's a canonical one. It never goes off track. You might say, hey, from a security perspective, these tables should never be accessible by these people, by these octa groups, for example. So once an engineer sets these things up, then non-engineers or tomorrow's engineers can go wild. They can do whatever they want because you're within the security guardrails, basically. And the subtle change that's happening here is developers, we believe, instead of being the ones who are hands-on coding an application, they become almost like a platform engineer, where they sort of build the building blocks that then non-engineers assemble together with AI.

24:46Because I think to your point, if actually engineers are totally out of the picture, it might get kind of crazy because you would have non-engineers writing back to production databases. It's kind of scary. It's pretty scary, actually. But when you can actually have engineers building some of these building blocks, then you have sort of a very nice path, if you will. And I really believe that this is, I really think the era of engineers writing code and IDE, compiling it and running it, I think that's so 2025 at this point. Wow. And 2026 and 2027. It's going to be pretty cool that engineers are not the ones doing that anymore.

25:22Because they have better things to do. They want to enable other people to build. That's awesome.

25:27David Hsu:That's so interesting. So I have kind of a two-part question here. does that leave us creating some kind of technical debt maybe of sorts? And what's the scariest thing that could go wrong when you democratize this type of building? Yeah, let me think about that for a second. Take your time. Take your time. From a tech debt perspective, we haven't really seen that with our customers. okay but this maybe gets him to i'll just explain very quickly because i think it may be interesting so how one of the big theses behind the retool platform is that most of the code that people are writing where you actually find bugs is not code you should have written anyways that does just think of a internal tool 90 of the code that you're writing is actually not unique to your problem or your tool.

26:31And it's actually a lot of boilerplate. But actually that 90 % of code is where actually most of the bugs were found, actually. And so the idea is if you can actually eliminate all that code and have the Retold platform handle it for you, then you actually get less bugs. Maybe an analogy for this is like using Stripe, which is instead of using Stripe, you could say, hey, I'm not going to use Stripe. I'm going to build my own Stripe, actually. And theoretically, you could do that. But you're probably going to have a lot more bugs than Stripe is going to have, actually. And so by outsourcing all that stuff that you don't want to handle and saying Stripe handle it for me, Stripe focuses on the problem and actually ensures there's less tech debt in that code, actually.

27:06Just like with Retool. And our hypothesis is that, and this has been true, I think, over the last seven, eight years for Retool, is a lot of the code that an engineer would write for internal tools where the tech debt really built is code that Retool should focus on. and we will write it for you. And we are fully focused on how do we deliver laser focused on the best platform for building internal tools on top of. And so you can eliminate all that debt. Maybe the last analogy, because I really passionately believe in this, is kind of like BI tooling, where if you were, if you asked me today to go build a dashboard, let's say of, you know, revenue over time, I would say, oh, I'll use Tableau, I'll use Metabase, I'll use Looker, I'll use something like that.

27:47And the reason I use a tool like that is so I can say, hey, all I have right is the three lines of SQL that are specific to my chart, and I'm done. I don't have to work on the database drivers, the authentication, the authorization, all that crap. So that's kind of how I think about retools. I think for that reason, Tech Dad is not that big of a concern. But on the second part of your question, I think there are dangers. I think we should walk in with eyes wide open. I think the dangers, I would say, are mostly around how strong the guardrails are and are people breaking out of the guardrails without the engineers noticing.

28:30that's probably the scariest thing which is uh if uh you don't have any guardrails you say hey you know this i'm gonna give you raw sql access you can do whatever you want to this database that's pretty scary because yeah i mean you could drop i mean you probably see this i think replit announced this thing the other day where i think it's actually jason lemkin uh who's you know uh big on twitter he was using repl the replit dropped his whole database yeah that's right So I really think the guardrails are really, really critical. And that's why Retool is invested so much in these kinds of guardrails to make sure that doesn't happen.

29:09So that I would say is the biggest risk is when you don't have guardrails. That makes sense. I feel like, you know, having a base understanding of some things like, you know, what would you, what's the bare minimum you'd really want someone to know? Like, you know, you should probably understand versioning a little bit. you know uh some some things like that you know as far as being able to walk back changes and stuff would be really helpful for folks uh well i think part of it though is really on how powerful or abstractive if you will the platform is which is this is the problem with actually most abgen platforms like like replet like the drop the database is that uh there is no sort of good higher level permissioning system.

29:53And what I mean by that is how this works with Retool actually, is you can say, hey, this Okta group, so non-engineers are these 17 Okta groups, but you can set up a Retool such that they can never have write access or update access to tables. And so the only thing they can do with Retool is actually build dashboards that read only from your data. And that's pretty safe. You know, when you read data, nothing that bad can happen basically. But that's only possible because you have a platform like Retool that has these abstractions atop of your data. Whereas if you're just writing raw code with a replit and you're kind of just vibing, raw code can do some pretty dangerous things.

30:29And so that's why I think actually the safety, if you will, is more important than ever before. Because now non-inders can do more than ever before, but with great power comes great responsibility. And so I think that's, yeah, you need a responsible platform that allows you to build those card graphs.

30:47David Hsu:So tell us about AppGen, which is your new tool to address this wave of non-coding creators. What is that and how does it work? Yeah. So it's basically something like actually the UI is actually not dissimilar to Bolt, LoveWall, Reclin, all these Figma make all these kinds of products, except the product it generates is actually not running raw code. It's actually running on top of the Retool platform. And so that Retool platform natively already connects to 100 plus data sources, including Salesforce, your Postgres, whatever. and it's actually hostable in your cloud. And so you can say, hey, it's a Docker image that I download and I directly just run it on my cloud.

31:26And for a company like Procter & Gamble, that's critical because I think for them to expose their data to, let's say, lovable, it's pretty scary.

31:35David Hsu:I mean, it's a pretty simple data. Yeah, I bet it is. It runs, you know, pretty sensitive data there. And so I think that is really powerful. It's sort of the, on top of the retool platform, it's in your cloud, it's on your data, in its security guarantees built in, that's, I would say, what our AppGen product is. So we're pretty excited about it. Wow. That's awesome. What I like about this is I heard this great quote, I think it was today, from Mike Maples on the Matt Berman podcast, who said something to the effect of, we talk a lot about agents, but the real unlock for AI is how high agency humans are using AI to get stuff done.

32:12David Hsu:And I really like that. I think it fits with what y 'all are doing. So who do you really think will be like AppGen users There's like, who will be the first one? Is it operations? Is it finance? Is it product? And how should we think about how they're using this to get stuff done? You kind of addressed that, but. It's a little bit of a fuzzy line, but I would say the clearest line to draw probably is Excel users, which is if you think about the advent of Excel, I think Excel was tremendously empowering for so many people. I mean, when I look at our finance department, it's nuts what they can do with Excel.

32:42And if you compare Excel to a Word doc, you can see a Word doc is powerful, but it's like a Notepad. It's not extremely powerful. But with Excel, you can start doing programming effectively. You can do calculations on multiple columns. You can do pivot. It's very powerful, if you will. But if you think about from the advent of Excel or Lotus 1, 2, 3 up until now, Now, if you think about that average user, they have not really gained many more capabilities beyond those simple Excel features. Like Excel has not changed that much. It's in the cloud now. So there's a little bit better versioning, you know.

33:19A little prettier. Yeah. For sure. Yeah. Clippy came and went, but quite on the same, right? It hasn't really evolved dramatically. And I think what AI is doing now is for these people that are now able to go write Excel formulas or Excel junkies, now they can go build full production web applications on top of databases and APIs. And that is so, so powerful. Because I think I was watching this interview with Saida Nadella the other day, and I think Excel has around a billion users now. That's so crazy. Yeah. It's not more than 10 % of the world using Excel, right? So that's kind of who we think of as the sort of builders, if you will, of the future is this people that for the last 10, 20 years have been empowered by Excel, but not much more are now able to go build production applications on top of data.

34:12I think that is going to unlock, to Mike Mabel's point, so much. And I think if you're a high agency individual that wants to have an impact, now, like never before, you can wield AI, wield Retool to have an incredible impact to organization. You'd probably get promoted four times in five years, like Charlie did. Your rock stars are going to be bigger rock stars. Yeah.

34:34David Hsu:So I'm not going to make you confirm or deny this, but it's almost like you're going to remove Excel from the equation. So no one needs open Excel ever again, basically. I will confirm it. I mean, because if you think about it, Excel is almost like a hack, right? Like, I would argue that I think a complicated Excel spreadsheet is a pretty shitty UX by any means. You know, it's easy to make mistakes in there. There's no version control, really. If you share it, you know, it gets really messy. It's hard to understand it. You mess up one formula, it's like breaks. Yeah. Yeah. Every complicated Excel sheet about what sort of complexity level should be an application.

35:13but the problem is most Excel users cannot build applications, which is why there's so many complicated Excel spreadsheets. But if you enable them to go build apps, then yeah, I think Excel probably loses a lot of market share, I think. Interesting. So answer me this. When we're talking about average people building software, do you feel like the biggest impact for this will be in internal tools or there will be customer-facing solutions? I think that internal software is probably the juiciest, most exciting, and most impactful on the world market for this. But undeniably, I think there will be a lot of consumer-facing software that's built in this way as well.

35:55I had a friend the other day who built a birthday website, actually, for his partner using Lovable, I think. And that's awesome. I think that the power that now consumers can go build websites easily is awesome. But I really firmly believe that most of the software is being built in enterprises. And that is where you would have the biggest impact on the world, if you will. Absolutely. So what would your advice be to, say, engineering leaders right now who might be looking at this kind of stuff as a threat? I would say that I think you really have to embrace AI in the sense that I think if you're kind of just hiding in your cave, even be like, I don't care about AI.

36:38They're also going to come find you sooner or later. So you might as well embrace it, I think. Yeah. And I think the best way to embrace it is in a safer guardrails driven manner, if you will, rather than a let's vibe code and see what happens and let's give everyone access to a product and databases. Because really that, your production data is probably going to get dropped by Reply if that happens. Yeah. So I would say that you have to embrace it because if you don't embrace it, stuff like that's going to happen. but uh by you leading the charge it can be a lot safer if you will so awesome awesome um so what

37:12David Hsu:skills do you think um become more valuable in this world where everyone can engineer like what how how should we think about this like for people who are non-engineers like now suddenly having these powers yeah i'll just have one thing that i'll think a little bit more but the one that comes to mind is i think what mike maple said which is agency uh and uh specifically, I think especially because today, at least, AI and LMS are low agency. You know, like we talked about chat, like it doesn't do anything for you. You have to ask them to do something. Those that have high agency have more of an edge because they can leverage, you know, something low agency, you know, and they can push it more, if that makes sense.

37:53Yeah. That I think is a key one. And when I look at some of our customers that, again, that have had the most success in their company, the ones that have gotten promoted multiple times in multiple years, it is, I would characterize it as agency or curiosity maybe is another one. Sort of this embracing of what's next. So I would argue that is the probably number one quality. I think maybe a number two is around some level of technical proficiency. Yeah. Because I do think that some level is required. Like if you don't know what a database is, if you don't know what an API is, if you can't think of data in like a row by column basis or level, I think that you might get left behind, honestly.

38:35So I think some baseline level of technical. But again, I think Excel is kind of the limit. You don't need to be much more technical than that. So maybe those are the two qualities of agency plus baseline technical effectiveness. The ability to recognize those kind of shortcomings is big too, I think. and understand how to quickly go learn something, whether that's a Coursera course or hopping into JetGPT, for example, and being like, hey, run me through this, talk me through it till I get it. And, you know, operating in a lifetime of little micro lessons, for lack of a better way to put it. Yeah, I think as technologists, we're changing very rapidly today, I would say.

39:19And so the faster the world moves, the more of an edge learning fast is. And so the faster you, yeah. So I think it's a, yeah, there's more of a premium if you will for that today. Yeah.

39:30David Hsu:Totally. Yeah, it's moving so, so, so fast. Speaking of that, should we do a couple of rapid fire questions? I think that's a good idea. We always have a couple of little quick fires here. So what would you say is the biggest misconception people have about no code or low code tools? And you can tell us whether you identify as low code or no code.

39:55wow rapid fire uh you'll have to respond quickly they're just you know just just for fun i don't think we identify as that and uh i think actually most of the perceptions are kind of true honestly like that's fair it's kind of old kind of stodgy i think a lot of the building are in ecosystems that are not very effective because they're not state-of-the-art so yeah honestly not a fan. That's fair. That's fair.

40:21David Hsu:Would you say vibe coding is a no-code tool? Like if you mentioned Bolts or some of those? I actually would not call them low-code. The reason is I think they share some similarities, but they're also still writing code. That's true. This is too specific, but this is how I as an engineer think about it. The reason why engineers hate low-code tools is because they don't use standard technologies. They don't use JavaScript. They don't use stuff. So when I as an engineer get something that was spat out by a local tool, but I can't even do anything with it. It's so unassessable. Whereas, for example, Bolt or Retool, we use JavaScript.

40:59And so we are generating code, but at least it's modern code that someone could do something with.

41:03David Hsu:So that's actually why I view it as different. You can even tell it what language you wanted to use, right? Depending on the tool. Yeah. Exactly. Nice. What's one feature you wish AI could handle but still can't? Oh, I think it's really just around knowing limits. I mean, it's, yeah, it hallucinates so much. It does not know what it does not know. That's probably the only one thing. It's the biggest human problem, too, sometimes. Yeah. Yeah. I think there's a lot of papers about the architecture and how avoidable is this. Maybe it's not really avoidable with current transformer architecture. So it's hard to say, but that's the biggest problem by far, I think.

41:48We would have a job.

41:49David Hsu:And what you're talking about specifically is when you ask it, hey, can you fix this feature? It's wrong. And then it's like, sure, I'm fixing it right now. And it's not doing anything. Or it is writing code that just clearly is not real, doesn't work. It's referencing fake libraries, that sort of stuff. yeah totally yeah like i asked a question recently about uh some company and then chad chad said oh yes i was in the born meeting last friday and we you know here's the results presented i'm like that's totally not you made that up man it's ridiculous oh my gosh do you think that hallucinations are getting harder to spot then because i feel like i don't have that situation happened that much these days.

42:33David Hsu:It's kind of scary. Not to the level it was say, a year ago? Yeah. Yeah, I think a large part of it is how you apply or use the LL. And this is, I think, why LL is so effective at coding, is that there is a right answer. There's a right or wrong answer. You can say, hey, does the button do the thing? You can write a test for it. And then you keep on entering here, the test turns green. And I think in a lot of real world cases, there is not that. You cannot verify the veracity of a statement as easily as code. Or like the IOI, for example. In the math competition, you can sort of go through it line by line and be like, does it work?

43:10Is the proof correct or not? Largely speaking, you can test it, right? Whereas in a lot of other types of work, you cannot. And I think over the next year or two, a lot is going to come to this verification, if you will. That's a good call. Yeah. Don't work is not a test that works for all applications. I hadn't considered it.

43:30David Hsu:Well, like creative writing, you know, famously is like the one where it's so subjective. It's like, how do you create a universal verifier for that? You could put software in that category. I mean, other outside of the function, but the actual like, for lack of a better word, like the design of the software or like the user experience of the software, like that's maybe harder to verify. You might have more insights on that than I do, but I think that would be a hard one. Yeah. To be honest, the space of UIs is actually not very large, especially for internal applications. It's pretty much buttons, tables, forms, dropdowns, which is why I think actually AI is so good at this specifically and why the retools are really leveraging it.

44:11That makes sense. If you try to build Airbnb's next redesign, you're right. I think LLs will really struggle to come up with something truly innovative there. So last of the fast questions here, and it takes a little bit of a crystal ball. if you're at 48 % now when it comes to shipping where do you think that will be in five years? I think 100 almost no doubt about I really think the era of engineers hands on keyboard coding applications especially internal apps because they don't want to do it like no engineer wants to code an internal app.

44:51David Hsu:Yeah. The move that is so clearly over I think it's going to be engineers building these guardrails of frameworks for non-engineers to piece them together with the AI. That is inevitable to me. So I think in the next AT24 months it'll happen. Wow. Wow. That's so wild. What's in your personal AI stack? What are you using these days to engineer on a daily basis? I myself, in my personal life, actually use a bunch of agents, actually. Cool. There's a bunch of... It's kind of funny, actually. To some extent, it's kind of like I'm very predictable, if that makes sense. So, for example, on the weekends, I like going biking.

45:30And what I do is I open the Apple Weather app, and I check three locations, and I choose the sunniest one, and I go biking there. And so it's very easy to go build an agent or a workflow to go do that for me. That's genius. I love it. You know, places, this particular hill is the sunniest one. So just go there. So I like a lot of small things like that, basically, that do save me a bunch of time. But, yeah, stuff like that. I've been tickering with one to make the meal decision at the end of the day. There's nothing I hate more than after a long day, having the long discussion about what do we want to eat?

46:00I have no idea. We've got to think about it. We debate. It goes on and on and on. And I'm like, man, I wish I could just hit a button and get a suggestion and just hit refresh until I liked one. And I think that's my very, very practical thing I want in my life. Wow. It would be awesome if you could track what foods you have in your pantry, in your fridge, how much effort you want to spend on cooking. Is it 10 minutes or an hour? Yeah, there's so much. I've been building out a spreadsheet of what I like, what I don't like, where I like to eat, where I don't, what ingredients I hate. You know, no pickles.

46:34I hate pickles. Yeah, exactly. Well, do you have any final thoughts on where this democratization trend leads us overall? I would say that my highest conviction statements are the ones that we've talked about, which is engineers will not be the ones building these internal apps in 18 to 20 or four months from now. It'll be the business users, the operation folks that have high agency, that have technical proficiency, that I believe really strongly in. I think there is a question of does a lot of that work just become agent agentified if you will yeah I think quite possibly and then there's a question of how much labor is there in the US how does the labor market change as AI or LMs with agents are able to do more and more could there be a world where half of us are unemployed, actually, because our job has been automated by AI.

47:40I think probably, I think. I don't think we're quite there yet, but I think it's actually going to be this sort of next 18, 24 months of these non-engineers building these automations of software that will lead us there. And it's a little scary, but I think that the people that will do well are the ones that are able to build these automations. They're able to learn these skills for now. Until AGI is here. Which means as fast as we're going right now, there are going to be more builders, increasingly more builders over time, which is probably going to, at least in my eyes, I just don't feel, at least from the pace, from the vantage point of Grant and I, it always feels like it's getting faster.

48:25It just like it never feels like, oh, we've plateaued here. And it's, look at this slow week. It's always like, oh, look, we've got nine data centers, 17 new models, and four great new tools for today.

48:39David Hsu:And it just never ends. More than you could possibly process in a day. It's wild. I do think that that's an interesting take. and I think it's interesting because it's like, okay, if you're an agent builder and you work at a big company and you accidentally make an agent that can do your job and then you get laid off, what do you do? It's almost like you then now have to take those skills that you learned to make that agent and then go start your own company to compete with your former company. And then it's just, we're going to have a ton of smaller companies fighting it out. That's sort of like my thesis.

49:15David Hsu:I don't know if you agree with that. I'm just crazy, but I think that's going to happen i think for startups yes but for the larger companies that have a larger moat uh like it's i think pretty hard to start a tide pod competitor like an ai first pod not sure what that looks like that's a good point a physical world still dominates yeah yeah but i think for software companies especially those that have not achieved revenue scale Yeah, totally. I see that. Yeah. Yeah, any kind of digital services as well. Yeah, there's a lot of... It's going to be interesting. Well, David, thank you so much for joining us today.

49:56David Hsu:Where can people learn more about Retool and AppGen and everything you guys are working on? Retool.com. So come check us out and give us a try. And if you have any feedback, let me know. I'm david at retool.com. Thank you, Grant. Thank you, Corey. Thank you. Oh, yeah. Thank you for joining us. Yeah, it was a great conversation. And to our listeners, if this conversation sparked ideas about what you could build at your company, you might even be a part of that 48 % soon. If you enjoyed today's podcast, we'd appreciate it if you'd take a moment, like, subscribe, do all of the things. You know what to do.

50:28And don't forget to check out the Neurons Daily AI newsletter. Join more than a half a million other people who sit down with it every morning. And that's all we have for today, folks. But there's always more to come. Farewell for now, humans.

50:54行きましょう.