Pivoting to Retool

We’re here with David Hsu, founder of Retool. Big fan… David, as you know – I know a lot of our audience is probably users of Retool. They are aware of Retool because you’ve been a sponsor for many years… But we haven’t had you on the podcast officially yet, so… Come on, let’s get you on here, right? Let’s talk about your past, your present, and your future. What do you think?

Yeah, excited to be here. We’ve been a big fan of the Changelog. So…

Big fan of y’all as well, obviously. I think we may have been like the earliest of days with Retool. I think you’re around seven years old, roughly… I was in preparation for this conversation, I kind of wanted to go back in time a little bit; not so much to bring up like the old ways of things, but I kind of want to revisit that initial video that I found on your website. I think it’s on your About page, if I recall correctly. It’s somewhere. I don’t know. It’s somewhere on the Retool website. But I found the initial – no, actually it’s on your Y Combinator profile page. That’s where I found it. And I’ll link it up in the show notes, but it’s the initial pitch that you gave… I think it’s the initial pitch. So take us back there. We know what Retool is, for the most part today, but tell us about those humble beginnings in that video.

Yeah. Wow, that was a while ago. I think that was around probably 2017 or so when we first got started. So when we first started Retool, my co-founder and I, we were both pretty lazy engineers, you could say. And we were tired of rebuilding internal tools all the time. Both of us had started a previous company before this… That didn’t really go very far. We spent so much time building internal tools at that company, and we thought there’s gotta be a better way. Why are we sort of reinventing the wheel every single time? Why are we populating tables, getting data from our database, figuring out how to build CRUD forms on top of that table…? It was just so much work to do something really pretty simple, just CRUD on top of our database. And so that’s where the initial idea for Retool came from, is could we, as lazy engineers, build a better way, a faster way for engineers to build internal tools? So that’s where the idea first came from.

And so we went through YC in around 2017, and initially it was pretty slow. When we tried to explain Retool to people, people wouldn’t understand what Retool was. “Why would I use something like this? I’m pretty happy writing code from scratch. Why would I use a product like Retool?” So it was pretty uphill for a long time. And I remember pitching VCs was very difficult, because we’d tell them we’re really focused on engineers, and they would say “Why are you focused on engineers? Why don’t you focus on democratizing programming? That feels way sexier.” So it was really a – happy to go more into detail than any one of those, but it was uphill for a long time.

I think what’s wild about hearing that is that – the narrative roughly for this podcast, hopefully, is where you began, and that story arc of what got you here. And today, the here is a lot of agentic stuff… We’ll obviously talk about the new AI platforming that you’re doing nowadays, but… It’s kind of interesting hearing that initial sentiment to build for engineers, and democratizing programming, basically, given where we’re at today. Just want to throw that in there, but let’s go back there…

So it did seem like, even initially, if I’m being honest, it did seem like even when we were first part of that sponsor pool - I don’t even know when it was. It certainly wasn’t 2017. I want to say it was like 2018, maybe 2019, if I can recall correctly, that we began to work together… And I thought, “Okay, internal tools make sense.” It seemed like it. But I recall also that you mentioned back at the YC day that you had another batch… They call them batches, for everybody listening. So when you go through YC, they’re called batches. You’ve got, I think, summer and winter batches, and you go through this Y Combinator incubation process as a two-person, three-person, whatever number person team, and out the other end you hopefully come out with funding, or opportunity, and things like that. So they call those batches.

And so when you were in that first batch, I recall you saying that Brex was also a part of that same batch, which is kind of funny, because you guys are both in this moment unicorns, right? But in those moments, you were just simply a hair on the potential of a unicorn, you know what I mean? You were not the futuristic thing that you are today.

Go back to that moment where you were bringing on larger talent like that, even; larger opportunities like Brex. How did you go from building and solving these problems like that, to solving their problems? And why was it uphill?

It was really cool, actually. So we were part of the winter 2017 batch, and I think it’s been one of the best batches for, I think, YC over the past few years. So actually, Brex is a part of that, Rippling was also a part of that batch, we were part of that batch, and a few others, too. So it was really awesome seeing a lot of these companies that today are so successful, so early.

[00:08:20.26] I remember when we first talked to Henrique and Pedro from Brex, they were just two guys starting a company… I think, actually, at the moment in the batch, I think they were actually building, I think, VR software, if I recall… And at the end of the batch, they’re like “Oh, actually, we pivoted into working on corporate cards for startups.” And I remember thinking, “Well, good luck with that. It doesn’t seem like a market to me.” But they’ve obviously done incredibly well.

[laughs] That is hilarious.

So it’s really cool to see [unintelligible 00:08:50.20] succeed in that way. They’re so talented as founders.

Yeah. Was it part of that batch process they began – you’d mentioned they pivoted during the batch process, which is really… Maybe you could speak to the details here, but it seems like some folks may go into Y Combinator with a pretty clear idea. And then that incubation process simply hyper-focuses them on that product development, the user research, the networking… Whatever it might be happening in there. And then some folks come in there with an idea that morphs dramatically. Can you speak to that? Was that at all Retool’s scenario? Or were you pretty laser focused on your first one, and you just iterated, and that incubation process was really a baking process of the real product?

Yeah, so my co-founder and I actually were working on a different idea at the very start of YC, actually. It was a P2P payments company based in the UK, and it turned out that a P2P payments company is not a particularly good business, especially when you are losing money every time someone sends the money. And so it was a negative margin business, and we were losing money pretty fast. But the lucky thing was, as part of building that product, we built a lot of internal tools. And you can imagine the kind of internal tools a P2P payment company would build. It’s tools to go manage fraud, tools to go approve signups, tools to manage underwriting… And so we built a lot of internal tools. And so we were actually quite lucky that through that process, we learned that as lazy engineers, building internal tools was really pretty challenging. And it’s an incredible amount of work required.

And so that’s actually where the idea for Retool came from, was entirely based on the fact that we had worked at a different startup prior to that, actually. And so throughout YC, we really refined that idea. And we were lucky that as part of YC there were many other companies part of the batch, such as Brex, such as Rippling, such as many other companies, too. And I think Brex was probably our first, maybe second, something like that; maybe our first five customer for us. And I remember talking to Pedro and Henrique about it, the founders of Brex, and as they were working on their credit card company, they had a very similar challenge to us with our P2P payments company, which is building a credit card company is very operationally complex. And so we told them about our story, and they were very interested in a product like Retool, because it could save them a lot of time, but more importantly, allow them to scale a lot faster.

Today, it’s hard to say what percent of time Brex spends on building internal software, but it’s probably half of the surface area of Brex is internal facing. And so having a product like Retool that allows them to move a lot faster, adapt quickly to changes, launch new product lines a lot faster… I’d like to think that we played a small role in Brex’es success, which is really exciting to all of us here.

Yeah. So that gives folks a context… I think most folks get this, but just to be super-clear - what would you consider an internal tool? What exactly is internal tooling?

[00:12:07.02] Yeah, so a really surprising fact about internal tools is that more than half of the software in the world is internal facing. When people first hear that stat, they’re generally pretty surprised, because –

Yeah, I’m surprised…

…a lot of software engineers, we work in Silicon Valley. And Silicon Valley’s job is to go build software for other people. So if you look at traditional Silicon Valley companies - Airbnb, Google, Netflix etc. these are all Silicon Valley software companies. Google is a software company that builds a software platform that connects advertisers and consumers. Same with Meta, same with Facebook, same with Airbnb, same with Uber. And so pretty much most software engineers at these Silicon Valley companies are building external facing software, the core product for Airbnb, Netflix.com, Google, the search product etc. But if you think about most companies in the world, most companies in the world actually aren’t software companies. If you go look at the Fortune 500, for example, probably 10, 20 of them are software companies. 480 of them are not. 96% of the Fortune 500 are not software companies. But they actually hire a lot of software engineers. And pretty much all these software engineers do day in and day out is build internal tools.

And so we think of internal tools as basically business applications that help you run your business, that’s not being used by your end consumer, if you will. And it’s actually the majority of the software in the world, actually, which is pretty surprising.

So you have a lot of companies that are not traditionally software companies, that are writing more and more software internally. They’re not buying their software from a vendor, they’re not buying it from a box, they’re not buying it from maybe even a SaaS, where that’s kind of internal, but it’s more of a service at that point, so it’s not like software they’re maintaining; it’s just something they buy, for the most part, of some sort of subscription. It’s a month, or a quarter, or a year. How did you go from this place where you’re building this P2P payment company, learning that internal tools kind of suck to rebuild over and over and over, and learning that this whole entire world existed? Did you discover it during the process of Y Combinator? Because you mentioned the pivot - was that when you sort of like “Okay, this clearly has got negative margin. We’ve done this thing several times; let’s not build these internal tools anymore. What if we build a platform that does it for other people?” Is that kind of how it worked out?

Yeah, to be honest, it was mostly internal conviction driven. My co-founder and I were engineers, and to us, it was obvious a product like this should exist. And so to be honest, even before doing any market validation, we built it for ourselves. So as part of our previous company, actually, we had built an internal version of Retool actually ourselves, because we were just engineers that like building things. And when we were thinking about what to work on next, this became one of the major ideas. “What if we productize this?” And it was in talking to Brex, it was talking to some other customers that we realized there was a really big opportunity here.

So another one of our – maybe customer number three or number four is this company called Tyco Electronics. And Tyco gives you a sense of how large the market is… Which is when we first launched Retool, Tyco Electronics, a customer of ours now, a person named Alessio came inbound and said “Hey, I’m really interested in using Retool.” And we were trying to understand what kind of internal software do you want to go and build, how much internal software do you actually build every day, every year… And we were shocked that a company like Tyco Electronics - I think it’s fortune number 250, or something like that. So it’s solidly in the middle of the Fortune 500. So an average Fortune 500 company. They every year spend around half a billion dollars building internal software, which to us was shocking. We thought, you know, we were working on Retool, and it was a cool thing for us engineers to use, a cool thing for us to use, to go build a few internal apps every now and then… But when we heard that Tyco spent half a billion dollars every year building internal software, we realized the opportunity here was ginormous. And specifically, we didn’t believe the half billion dollar number at first, but if you do the math, it actually makes sense.

[00:16:28.17] So Tyco as a company has, I think, around 120k, 130k employees. And of those 130k employees, around about 2% to 3% of them are software engineers. So they have around about 2,000, 3,000 software engineers. And if you do the math based on the average software engineering salary of let’s say 200k per year, 200k multiplied by 2,000 software engineers actually comes out to $400 million every year that they’re spending on software engineers. And Tyco has no external-facing software. Pretty much all they’re building is internal tools, day in and day out. And so that gives you a sense of how large the market is just for one single company.

So when we heard that, that was really pretty shocking to us, and we realized that “Oh, wow”, when we were interviewing more and more customers, we realized that actually the majority of software in the world is internal facing. And the majority of internal software kind of looks the same, actually. It’s pretty much just buttons, forms, tables, drop-downs on top of Postgres databases, on top of Salesforce, stuff like that. And so that’s when we realized the opportunity for Retool really is rather large. And we were really excited about the mission of potentially changing how developers built this large class of software.

When did you personally see a new piece of software be built on top of Retool, and you personally had this “Oh my gosh, what do we build?” moment? I mean, because if you were tired of the old way, which was from scratch essentially, and you could build on top of Retool with maybe an API key, sprinkle some code here and there for Postgres or some database calls, things like that… When did you personally feel like “Oh my gosh, this is the next big thing”?

It was probably a few separate moments. One moment was actually when Alessio, that customer from TE, described Retool as similar to BI, but a much larger opportunity. And what he meant by that was if you think about BI, which is actually a parallel space to Retool, to internal software, today if you ask any engineer, you ask anyone really to go build you a BI dashboard - BI is business intelligence. So maybe you say, “Hey, give me a chart of signups over time”, for example. If anyone asks me that, my first reaction is “Oh, I’ll go use a BI tool.” I’ll go use Tableau, I’ll use Metabase, I’ll use Power BI; whatever it is, I’ll go use that. Because when I use a product like that to build that chart, all I have to do is to go write a few lines of SQL, drag a chart on, and I’m done. It’s so simple.

I wouldn’t even consider building that from scratch. To build a BI dashboard from scratch, I would probably have to go import some database drivers, I’d have to go build an authentication/authorization framework, I’d have to go find a bunch of frontend charting libraries, and try to debug them and see which one is best… Then I’ll find out “Oh, it’s a little bit slow, so I’m going to go build a caching layer…” It’s so much work to go build BI dashboards from scratch, and no one does it today.

And so when Alessio said “Hey, actually, this is just like BI, except there’s 10x, honestly, more use cases than BI”, that’s when the idea really popped up in our heads, “Wow, this is a product that is like Tableau, but 5, 10 times larger, actually, in terms of opportunity.” And the fact that half of all software is internal means that one day half of all software could be built in this way, which is really exciting. So that was one moment.

[00:20:01.17] Another moment was when another customer actually made an analogy to AWS, which - she said that they had gone all in, this company had gone all in on AWS. This was maybe in 2016, or something like that, so a little bit earlier. And the way that she viewed it was AWS saved her a lot of time, and her company a lot of time… Which is instead of building your own data center, trying to figure out how to go manage racks of servers, when a power supply blows out you have to go figure out how to go replace the power supply, when a hard drive spindle fails, you have to go replace the hard drive… Now all they do - now we all do today - is use AWS. We press a few buttons, and servers magically appear. And if we want to go launch in a new region, we’ll press a few more buttons, and we’ll launch it in another region.

And all this commoditized, or this undifferentiated heavy lifting I think is what AWS calls it, has been commoditized. And we as Retool and that company don’t have to worry about having to go worry about all this heavylifting anymore. We just go move a lot faster actually, because AWS is handling all the stuff for us.

And the analogy she gave is Retool is kind of like AWS, but the AWS of the application layer, which is there’s so much stuff in the application layer that is so bespoke right now that you have to build from scratch. So when you’re building an internal tool today, for example, you have to worry about “What table library should I go and use? Okay, I’m going to go use this table library. Oh, that’s not quite right. Okay, let me go find this other table library. Oh, this table library comes with virtualization, so when I load big data into it, it’s actually quite slow. Okay, now that I have that built… Okay, now I have to go worry about authentication, authorization. Who can actually go use my application? How do I go hook it with single sign on, for example? Oh, now I need audit logs, because I need to go verify – when something bad happens, I want to know who did what, for example.” There’s so much crap that you have to deal with just to get a simple CRUD dashboard going. And it’s so much work. And so the idea that Retool can sort of commoditize all that away, such that the engineer can focus truly on what is unique or differentiated about what they’re building I think is so powerful. So that was maybe a second moment, too.

So I think it’s a few moments like this when you see customer use cases, the customers go build things that you could not have imagined… And they actually go pitch a product back to you, in ways that you couldn’t have imagined either… That’s, I think, what was really validating, for us to realize “Wow, this is a really large opportunity for us to change how developers really go build software.”

One thing you did say, though, was that it was a… Remind me if I’m – I’m going to paraphrase… I think you said that it was uphill, was the way you described it. Like, to describe how it was to raise awareness for Retool, to preach the mantra of “Don’t build your own internal tools, use a platform like Retool to make it 10x faster”, et cetera. How long did you spend, or are you still in that phase where it’s still kind of hard to – it’s still sort of uphill in a way, or hard to sell Retool and to help people understand that this is a real problem, or this is a real solution you all solve very easily.

I would say it’s gotten a lot easier recently, especially with AI, which is helpful. But in the early days, I think many people just weren’t sure. “Should I go trust a new company like Retool?” Today, Retool has tens of thousands of customers at this point, and so…

Trust is too easy now, yeah.

Yeah. Companies ranging from NBC, all the way to the US Army, all the way to Amazon… Companies like that all trust Retool now, so that helps quite a bit. So that’s great. But the AI has been a real tailwind for us too, because now a lot of people are really looking at “Can I go adopt new ways of building software?” The ways that we used to build software are no longer cutting it. Are there better ways? So that’s been quite helpful, too. So it’s been less uphill recently, but the first few years really was a lot of educating the market, and a lot of explaining to people why this is better than building software from scratch.

[00:24:17.10] How has Retool changed over the years? Has it always just been like internal tools, and just incrementally getting better? Have you added more user interface styles? Where has been the advancement of the platform over the years?

Yeah, the advancements we’re most proud of really are around AI over the last three to six months, honestly. So just a few months ago, a month and a half ago, we launched this product called Retool Agents, which really builds on top of a lot of the platform that we’ve built. It has enabled customers to go do some pretty incredible things.

So in particular, to use Retool to go build a frontend application, basically you can build the frontend, but then you write a bunch of queries to connect it to your databases, to your APIs, stuff like that. And one idea we had around six months ago - and this was just really an idea at that point in time - was “What if we could expose all the tools that you have built in your company in Retool, and expose them to an LLM?” That could be really powerful, because then it could allow the LLM to go do some pretty incredible things in your company.

The thesis came from – the main idea here basically is we think that if you look at the power of LLMs today, LLMs are really quite smart. I think they’ve conclusively passed the Turing test. So I was a philosophy major in college, and back in the day we would debate “How do you know if an AI is smart? What does it mean for an AI to be smart?” And I would say a good amount of philosophers thought, and to this point still believe, that if an AI could pass the Turing test, that we would consider that smart or intelligent. And the Turing test is basically, if you’re talking to an AI, can you distinguish the AI from a human? And today with LLMs, you really can’t. If you talk to any state-of-the-art model, whether from OpenAI, from Arthropic, DeepSeek, Ollama, honestly, they sound more human than humans actually a lot of the time, actually. And so they’ve conclusively passed – at this point, I think we can all say that AIs sound just as human, if not more human actually than even humans do. So that’s great.

But when we look at how much value are people getting out of these LLMs today, it’s really pretty limited, and it’s really just one use case. It’s really all just around chat. And it’s kind of surprising that if the LLM is able to do everything, or can basically pass as human, why is it that we’ve invested so much energy and money as an industry into AI, and yet there’s not that much ROI today.

So to give you an example, I think over the past few years the industry collectively has invested somewhere between a trillion and $2 trillion into AI, which is a lot of money. A lot of that has gone to GPUs, and to training models etc. But if you sum up all AI revenue in the market today, I think it’s maybe around 20, $25 billion. So that’s like a 2.5% ROI, based on how much money was invested, which is pretty surprising.

That’s interesting to think about, yeah.

Yeah, it’s kind of shocking, actually. And our thesis was, it’s not actually about how smart the models are. The models are plenty smart. It’s actually about what the models can actually go and do, which is when you use chat, the model can’t really do anything.

[00:27:56.13] I use chat frequently, for example, to go help me write things in Google Docs, for example… What I’m doing is I’m just conversing within my ChatGPT app, and I have to copy and paste it into the Google Docs… Or if I’m just building a slide deck, for example, I have to go copy-paste the data into a slide deck… And then, “Oh, actually, it’s not quite right, so let me copy-paste it back again…” It’s so much work going back and forth. And so the idea is LLMs today are plenty smart. Really, we just have to give it the arms and legs for it to actually go do things. And this is, I think, what’s so powerful about something like Cursor, about the idea like Cursor, which is theoretically, if Cursor didn’t exist, you could theoretically do - or Copilot didn’t exist - you could do what Copilot does with just ChatGPT. You could say “Hey, I’m going to go copy-paste this code from my IDE, paste it into ChatGPT, and have it write it, and then copy-paste it back. Oh, but it doesn’t work. Okay, let me copy-paste the error message. Okay, let me copy back again.”

And theoretically, that would work, but you can see how Cursor or Copilot is so much better. The fact that you could expose the IDE capabilities to an LLM and actually allow the LLM to go do everything makes your life 10 or 100 times better, actually.

And yet, if you look at how non developers, i.e. most of the world is using ChatGPT today, are using LLMs today, that’s what they’re doing. They’re kind of pasting back and forth, actually. And so our idea was, can we go expose an LLM, and allow it to actually do things in your business systems? So it could actually go run queries in your Postgres database, it can actually go refund customers in Stripe, it can actually go modify Salesforce, it can actually go send emails on your behalf, for example. If we could do that, that would almost be like a Cursor for everything, basically.

And so we shipped that a month and a half ago, and the reception has been really positive. So we can talk more about that, but that’s probably what we’re most proud of shipping, I think, over the last few years, is this product, Retool Agents, which - yeah, it’s really quite powerful.

It is powerful. And it kind of goes back to the initial framing, which was the investor had said “Why would you focus on developers”, or engineers I think he may have said; assuming gender, but… Yeah, I think you get in this place now where AI is kind of everywhere, it’s table stakes. Like, can you really be a modern day software platform like Retool and not have AI-focused features? I think the answer is hard no, right? But you didn’t just simply add AI, like you had said, with chat… I’m really curious how you do it in a way – because it’s non-predictive, right? Like, when we do generative AI, when we use LLMs, we can predict to some degree what it’s going to do, but it’s non-deterministic, right? Like, what comes out is non-deterministic. How do you unleash that on what I would potentially consider the crown jewels of all crown jewels, which is the internal software of Fortune 500 companies? And if you’ve got even a small majority of Fortune 500 companies customers, then when you unleash that kind of thing to that kind of audience, there’s got to be some concern. How do you do – how do you roll something like that out that’s non-deterministic in a way that covers your butt? …is the easiest way to ask that question.

Yeah, so this is the power behind this form of software called agentic software. This is basically what Cursor is, and many other products are, which is the core idea of an agent… Today, the most popular architecture for agents is called a React style agent. And so a React style agent is basically a reasoning and an acting agent. And so what it does is that the LLM reasons, and then it acts. And the way it acts is you give it tools. So you say “Hey, you can go search the web”, for example. Or you can – in Cursor’s case, “You can go modify some code” or “You can go run some code”, for example.

[00:32:10.14] There’s this Open AI product called Operator, which is a good example of this, which is - Operator is basically an agent with one tool, which is it can go browse the web. And it’s pretty cool, actually. You can tell it to go do things. So you can say “Hey, go buy me a pair of shoes, in this particular size, this particular color”, and you can watch it go do things. It says, “Okay, well, let me think about what to do there. Okay, well, I’m going to go visit this website. I’m going to go search up shoes, this color, this size. Click this link. Okay, great. Oh, that’s the wrong size. Okay, let me go back, actually. Let me go click this other link.” And so you can sort of watch it reason and act, basically.

And what we’ve discovered is, to what you’re saying, something like that, Open AI Operator, is pretty effective in a consumer context. So if you’re trying to buy a pair of shoes, buy a T-shirt, for example, it could be good at that. But in an enterprise context, it’s actually really, really bad at it. And the reason is, the one tool that it has, web browsing, is such a non-specific tool. For example, if you tell Operator - you can try this yourself, actually - to go onboard an employee that just joined yesterday, for example. What it’s going to do - it’s gonna go and search “How do I go onboard an employee that joined yesterday?” And it has to go find like a wikiHow article… And it’s like “Okay, great. Well, a wikiHow article says to go onboard an employee that joined yesterday is I go do these things.” And that’s not what you want to do at all. If you work in a company like Amazon, for example, there is one right way of onboarding an employee, which is you have to go add them to Workday, you have to go send them a laptop via Amazon Logistics, you have to go do this, you have to go do this, you have to go do this, you have to call these very particular API endpoints. It’s not “Let’s go browse the web, and go google “How do I onboard an employee?”

And so that, I think, gets at the power of an agent, which is with this kind of architecture of reasoning and acting, what you can do is you can actually outsource the reasoning to the LLM, but the acting needs to be deterministic. And that, I think, is the power of something like Retool Agents, which is you can go build these deterministic tools inside of Retool.

In fact, our customers have built millions, if not tens of millions of tools for agents to go and use. And so for example, for a company like Amazon, they’ve built tools to say “Hey, here’s how you go add someone to Workday… Is you call the Workday API endpoint with the first name, the last name, the SSN, and the address”, for example. Great. Okay. That’s the first thing you’ve got to go and do. “Here’s how you send a laptop. You call this custom internal API that we’ve built”, maybe a node or wherever else, “and it expects these parameters. It expects the first name, last name, address, and computer model, for example, as well as the start date, so we know how fast to ship that laptop, for example.”

And so once you’ve formalized those tools, then what you tell the LLM to do is you say “Hey, LLM, don’t just go browse the web and do whatever you want. Instead, you only get these five tools to go onboard this employee.” And then the AI is so much more accurate. And so in our testing, our AI is so much better when you give it these very specific tools.

And that, I think, is the power of a platform that allows you to outsource the non-determinism to the AI… But really, you want to minimize that. Really, you want to maximize determinism. And to do that, you need a sort of tool building platform, if you will.

Break: [00:35:37.19]

So you have the idea of an agent, which is some sort of demarcated name and role. So Add New Employee, let’s just say. That’s the agent’s name, and it has a task of X, but it’s only got limited tooling… So it’s kind of like saying “Get to Rome.” Everybody says this old adage, “How do you get to Rome?” “Well, all roads lead to Rome”, right? But what if only five roads led to Rome, and those are the only five roads you had access to. You can only go to Rome. You cannot go to – I don’t know, where else was popular back in Roman days? Some other city, right? How do you get there? Well, you can’t, because you don’t have access to those roads. You can’t go there. You can only go to Rome.

Yeah, totally. And so we’ve discovered it’s just so much more effective that way. And if you look at actually, for example – this is why Cursor is so effective too, actually… Is cursor, when you go use agent mode, it only has a few things it can do. And so it’s not just endlessly googling, and “Well, let’s google for this, let’s google for that, let’s see what happens.” It says, “Well, I’ve only got a few things. I’ve got to modify the code, and I’ve got to run it. So let’s see – I’ve gotta go modify the code and run it. Oh, I got this error. Okay. Well, let me go fix that error.” So by constraining the AI, it becomes substantially more effective. But also by giving it tools to actually go do things, instead of telling you to do things…

Nice…

Which is actually, if you look at what people are using ChatGPT for, it’s actually kind of crazy how inefficient it is… Which - today, the way I use ChatGPT is I copy and paste so much stuff into and out of ChatGPT. And to some extent, it’s almost like I’ve become the API for ChatGPT, right? I’ve sort of become this manual worker is doing what ChatGPT tells me to do. Whereas if you could glue ChatGPT to actually doing the work and give it the tools, the arms and legs to actually go do the work, you could just sit back and drink a beer, or something. It’d be so much more effective.

For sure. What you’re reminding me of - and maybe this is something you’re already onto - is as a business owner, I’ve been more exposed to the idea of systems, right? I will tire out, I will procrastinate as an individual, just me as Adam. Unless I can build some systems, I cannot scale my enterprise, or lack thereof, let’s just say. We’re not a big outfit. But in order to scale beyond the one, which is me, to do the same job I do to begin to hand off parts of it to somebody, I can’t do that unless I build some version of systems. And we use a lot of Notion… We don’t really use a lot of Retool, honestly. We don’t have a lot of internal software, but like a lot of stuff we’re doing in Notion is in those kinds of ways. But what you’re making me think of is really how systems is what’s crucial, and they’ve already built – so if you’re a deep or even shallow-ish customer of Retool, you’ve got a couple internal tools, right? And if you can systematize those things, the agent… I imagine agents are similar to systems, or systematizing these things… It’s a form of automation. Now you have the same software you’ve built out for yourself in your enterprise doing certain things, whether it’s adding an employee, or updating a BI like dashboard that’s built in Retool, et cetera. You need to – you essentially need to trust what’s happening there. How do you then expose not just this agent world, but this ability to create systems for these enterprises? Because I’ve got to imagine if you’ve got one or multiple internal tools, the next thing you want to think about is “How can I systematize it around these tools?” Is that the way they’ve also been thinking about this? Has this been sort of like “Build an agent, automate some things”? How do you sell this idea to these folks?

[00:42:21.11] Yeah, so the great thing is that for a lot of existing Retool customers, they’ve built millions of tools already. Every API you have, every database table you have, to some extent, every single query you’ve written is a tool, that you can now expose to an LLM in this controlled way, to actually go and do things. But I think this is where the industry really is going, is how can we compose or build the tools such that we can expose them to LLMs, and have LLMs decide which ones to use, to actually go automate more and more and more work.

I think tool building is going to be a critical skill, if you will. And thinking about the level of abstraction at which you build tools - is it very high level, is it very low level - is going to be really interesting. We see our customers today, for example, those that have built thousands of Retool apps, for example, and actually composing agents, in fact. And so an agent scales up to probably a dozen tools or so… But what you can do is you can actually build agents that have other agents as tools. And so maybe an agent has 12 other agents as tools that it could call, and it says “Hey, if it’s this kind of problem, I’ll call this agent. And if this agent says, “Okay, well, if it’s this particular subtype of problem, I’ll call this agent”, and that agent has itself 12 tools that it actually uses. So I think this kind of Mandelbrot-like way of scaling complexity is really going to be pretty – this is, I think, going to be how AI automates more and more labor over the next two, three years.

Mm-hm. How long have you been working on this agentic platform? What do you call it - do you just call it Retool Agents? What’s the proper nomenclature I should use to reference it?

Yeah, Retool Agents. And the way we pitch it is we basically say “Hey, have you heard of Cursor? Great, you’ve heard of Cursor. Well, the reason why Cursor is so effective is because it’s an LLM with tools that can actually go and do things.” So it can sort of reason, and actually act. And that is such a powerful loop that you can give an LLM.

The reasoning and the acting, yeah.

And if you could do that for all other aspects of your business, such that it’s not only developers getting more effective, it’s your HR team getting more effective. It’s your finance team getting more effective. That is so powerful. But actually, the people building all these agents are still developers, actually, which is really cool. Because in order for an agent like this to work, you have to build the tools, and the tools have to be built by developers. So I think the importance of developers, actually, if anything, has gotten more important over the last six, nine months for us.

Can you give me a glimpse into the kinds of agents being built? Can you expose any one customer, or any particular specific scenario that gives us some clarity?

Yeah, sure. So one pretty cool use case is we have a customer who has actually built an agent to go replace management, actually, inside their company, which is really cool. So they have a sales team, actually, that is doing a lot of cold calling, and for them, it’s important for the salespeople to be getting feedback in a timely manner on “Hey, you could have done better here. Here’s where you did really well, actually; keep on doing that.” And you can think of it – it’s pretty interesting, because as a sales manager, it’s actually hard to go and listen to all the calls your salespeople are doing. Because if your salespeople are working, let’s say 40 hours a week, it’s actually hard for you as a sales manager to be supervising and to be listening to 8 times 40, so 320 hours of calls happening every week.

[00:46:00.11] And so what this customer has actually done is they’ve actually built an agent, actually, to go manage this team of salespeople, where the agent actually, after every call finishes, goes and analyzes that call, and then thinks about it and gives feedback, actually, on “Hey, this could have gone better, but you did a really good job here. Keep on doing this”, etc. And then actually, in future calls, it can actually provide, in context, while the salesperson has the call, it can actually give them live feedback, tell them what to say, actually.

So it’s really pretty cool seeing the power and what you can do, actually. And I think a lot of jobs, actually, if you think about sort of an agent doing this, the agent’s actually probably doing a better job than the manager was before, actually… Because the LLM is able to take in a lot more information, actually, than an ordinary human is, that I am actually able to. And so I think really leaning into what LLMs are good at, which is consuming information, summarizing information… But that’s actually a large percentage of knowledge work, actually; a large percentage of my job, actually, is doing those kinds of tasks.

Yeah.

And so I think in the future we’re going to see a lot of – I think the labor market is really going to change quite a bit, when agents become more and more powerful, and have more tools, and actually go do things in your business, like giving feedback, writing performance reviews, stuff like that.

I think some of these things – I’m thinking this case in particular… There’s some things that I’m personally okay with and ready to hand off to something that isn’t… Let’s just say isn’t me. “Delegate” is the easiest word, that everybody uses. It’s the actual proper word. And I really don’t care necessarily how that task gets done; whether it’s procrastination and it just solves itself, or somebody else does it, or literally now some version of a robot or machine or AI can do it for me. I don’t really have that problem. And one case in particular, I think, which you just mentioned, which is a great example, is where a salesperson is attempting to do their job, which is to – you know, sometimes it’s selling, but sometimes it’s just simply warming the waters of an opportunity. It’s just answering questions, providing feedback, providing knowledge… And they need somebody else’s support, whether it’s a manager, a technical salesperson, somebody more knowledgeable, with a bit more experience or depth… And if I – not so much if I can remove them, but if I can speed up my personal feedback loop if I’m in that role, attempting to warm the waters of an opportunity, not just simply sell, but… I would want those answers to be fast, one. And two, I think my manager over time might get over my third or fourth request of “How do we do this?” Or “What do we do there?” That person will just grow tired, of me, potentially even like individually me… And then my question, or just generally answering questions like that of people like me. Even if it’s their job, they may just be like “This is not – it’s not a good use of my time the company’s paying me for”, for example. And so in those cases, I’m kind of happy to let those kinds of things go to the agents.

You alluded to this – and I think we all sort of see it coming, in a way, is this major shift in the labor markets… Which we’re just not able to truly predict yet. And here I am, sitting with someone who may be, in the levers of time, David Hsu, co-founder/CEO, Retool, all the things you do, could be responsible for the labor market change. How do you feel about that? Has it always been just whatever it takes to innovate? And how do you sit at that wheel, so to speak?

[00:49:53.29] You know, I think there’s going to be an enormous change in the labor market, especially for knowledge workers, myself included, over the next few years, because like we’re just talking about, honestly, LLMs are really quite smart at this point, and in many cases can do a better job than I can, actually, at consuming information, summarizing information, and even making decisions at times. Maybe they’re less biased than I am, for example… So I think there’s so much potential there.

And you add that to what you said, which is - I think ultimately we’re outcome-oriented. I think businesses, business owners, we’re outcome-oriented. We don’t actually care; even all employees, I think we’re all… As long as the work gets done, whether it’s done by a human or a robot actually doesn’t really matter that much, if it’s being done to a high quality. And oftentimes, with robots it can be done to a higher quality, faster than humans. So that I think is, from a philosophical perspective, a little bit unsettling, but the way I think about it - and perhaps this gets to your original question, is I think it really is a… I think in the short term it’s going to be painful, in the sense that we’re going to have to adapt. I think the labor market will have to adapt, a lot of humans will have to go and adapt… But those that really embrace AI – I don’t think it’s something you can really hide from at this point. Those that embrace AI, the builders that are able to go build the building blocks such that their companies can really leverage AI, I think those are the ones that are going to do really well over the next few years.

And we see so many examples of this in our customer base today, where someone takes action, and they are able to go write some SQL queries, they’re able to go build some building blocks, build some tools for LLMs, and they go automate a whole process, and they get promoted three times in a few years… I think those are the people, the sort of action-oriented people that are hands-on keyboard-able to go do things. I think there’s going to be a premium to that in the market over the next few years. But I also think in the long term, it will lead to a lot more abundance. I think Democrats have been talking a lot about this in California, around an abundance agenda… But that’s ultimately what I think AI will do for us, is there will be enormous deflation, where the cost of providing a lot of services will go down. And that will allow humans to go afford a lot more of those services, which would be really cool.

So I think overall, it’s going to shake out really well overall for humanity in the 5, 10, 20-year timeframe, but there’s going to be a lot of, I think, pain and gain for those that can leverage AI. There’s going to be a lot of gain for those that can really leverage AI in the next few years, and a lot of pain for those that can’t, and end up having to retool themselves, or to move to a different job family. So yeah, it’s going to be a pretty somber few years.

Interesting. Yeah, certainly a possibility. I can see a lot of things shifting, but even – I kind of come back… I don’t think this example multiplies well, potentially. And I could be wrong… In the case back to the manager giving feedback directly to people - over time, I’m going to get slower at it, potentially; I’m not going to be the best at it. I may give some attitude… I may not give the best response… And that really is – the context and the intelligence of the response can still come from someone like me, feeding, essentially, the LLM context, so that a salesperson, or an AE, or however you want to categorize that person or title them, they’re able to leverage my knowledge, but without me having to be present to literally handspoon, handfeed it to them, on the case by case basis. To me, that seems – I’m cool with that. I’m cool with that.

[00:53:54.20] Let’s dig into the specifics of like – I’m thinking there’s probably a certain situation or certain framework, or parts to internal tools that every company needs of some shape or form. Is there a stampable blueprint, so to speak? “Your company, you likely have these kinds of needs, for these kinds of internal tools. You should come to Retool and build them. And then on top of all that, we’re going to give you smart AI to react and take action and reason on all this stuff on top of this platform.” How close is that to being reality, where you just have like “Here, take this, and it’s done”, where you don’t have to individually build each one? You can sort of like templatize what it is to have an internal tool set for your business.

Yeah, a lot of that is happening today, where especially for smaller, medium-sized companies, a lot of our templates work off the shelf… Which is “How do you do customer support”, for example? How do you automate that? Well, you have to plug in your intercom database, plus your Salesforce, then you give that to an LLM… And it’s actually pretty capable of answering. You plug in your docs page maybe, maybe you vectorize your previous support tickets… And it’s very good at answering support tickets, actually, already. That’s a template that we have on our website, that you can check out for free, yourself. And so that’s going pretty well, I would say, especially for smaller or medium-sized companies. For the largest companies, like the Amazons or the US armies of the world, there it gets tougher, because their templates don’t necessarily work. Because Amazon is not going to just adopt to how someone else does something.

For sure.

They have a very specific way, to go back to employee onboarding, for example. They have a very specific way of “Here’s how our workday is set up.” It has these columns. And these are the required fields [unintelligible 00:55:51.25] workday, for example. And there’s no way that anyone else can really tell them how to do that. It’s sort of proprietary to Amazon, if you will. So I think that the – this is why I think the developer skillset is so important… But I think that the developer plus the line of business or understanding the requirement from the line of business, the context is going to be ever more important, if you will… Which is, I think, the sort of skill of translating a requirement into code. That, I think, is [unintelligible 00:56:23.21] commoditized. And we’re starting to see that already, with app gen products like ours, or AI IDEs like Cursor or Copilot, for example. That literal act of coding is less interesting nowadays. But the ability to go interview stakeholders, to go understand “Okay, well, this is the API in particular I should use”, that skill, I think, is going to be really, really important, at least for the next few years, I think. So yeah, that’s the most important skillset, we believe.

I think so, too. It’s interesting… I’ve seen the templates, I just didn’t think they were that expressive – I didn’t think they would be expressive to an enterprise, that’s for sure… But when you look at your audience, you have the idea of I think a lot of startups or a lot of upstarts that start their scale-ups now, so to speak. Like, Brex is no longer a startup, rightt? They’re as old as you are, so they’re knee-deep and they’re good to go… But they’re still using Retool. There’s no template to say “Out the other end, Brex.” But if I’m a particular kind of company, for example a grocery store, maybe there’s particular things that a grocery store might need. How frequently does a grocery store open up? Probably not too frequently. So that’s probably a bad example. But let’s say a barber, or a nail salon, or a massage therapy, or let’s say a golf studio. Or a range where you can go hit golf balls. There’s bespoke, different, unique businesses, but they all have employees, they all have probably payroll, they all have unique things that each and every business has. Has it ever been wise? Or does your template sort of cover that chasm, so to speak? So it says “You’re starting a new business, start on Retool. Don’t build these tools yourself. You’re probably going to use these four or five web services… Let us complement that with Retool.” Is that something you do?

[00:58:20.02] Yeah, ish. But oftentimes no, actually. So the way we think about it is, there are times when internal tools are really quite valuable. And I think for large companies, for example Amazon, internal tools are – this is why Amazon is such a successful company, is due to the internal tools they’ve built. And so it’s so important for you to – same with Brex, for example. Same with Ramp, another one of our customers. Same with Stripe, for example. Internal tools are the lifeblood of their business. To be honest, if you’re a barbershop, you probably don’t need the world’s best internal tools. You can probably go use some barbershop management software, a CRM built specifically for barbershops, and you’re probably fine, honestly.

If you’re a cafe, for example, probably just go buy Square. And with Square Terminal, you can manage your POS, you can go manage your inventory, and that works great for you. So we don’t think Retool is the right fit for everyone. We think Retool is the right fit if you truly need custom internal software. The good news is there’s a lot of custom internal software being built across the world every day - it’s half of all software - but it’s also not 100%. And in many cases, you would actually be better served just by buying something off the shelf.

So that’s something we’re pretty honest with ourselves about, and pretty honest with our customers about too, which is if you’re a cafe, probably just go buy Square instead of trying to build your own POS system. It’s going to be a lot of work, and honestly, not going to get you a much better result than just buying Square. So…

For sure. Yeah, I think what I mean is – obviously, a barber is probably going to use Square. My barber uses Square, for example. I love Square, by the way. Shout-out to Square. I always enjoy using Square, whether I’m at the barber or a coffee shop. I always love it. What I was thinking of was more like you know I’m going to use something like a Square,

I’m going to use something like a Shopify to do some version of commerce. And so because of that, you can assume certain things about the kind of business I’m running, and so you can complement that tooling, because there’s integrations, and because there’s some tooling that might be bespoke to me, that makes sense to build inside of Retool. I was thinking that you may have made some inroads there, where you can sort of predict a set of internal tools for a business. I just was thinking aloud on that. That’d be kind of cool. That’d be kind of cool. I think so. Because I think there’s some opacity… Well, there’s some opaqueness to, and some opacity level to Retool, where it’s kind of hard… There’s a lot of abstract. You can go and look at some of your templates, you can go and sort of see some things, but I’ve never seen a fleet of internal tools beyond what I’ve built for myself, which is like maybe one or two. It’s nothing that’s beautiful or amazing. And so I was thinking, is there a way to give me a glimpse behind the scenes to like a fleet of tooling, and how much of that fleet of tooling do 80% of the companies that use Retool always build? Is there a Retool for Retool, essentially?

Yeah, totally. We see our customers building a lot of pretty similar internal apps. But to give you a sense, a company like Brex, I think they have maybe around a few thousand tools that run inside of Retool. Coinbase is another example.

I think a few thousand tools that run inside of Retool every day, actually. So yes, there is a good amount of overlap. I think we could be doing a better job showing off some of these use cases. But to be honest, with AI I think a lot of this becomes maybe a little bit less important, too… Because witth AI, nowadays in Retool you can go describe the problem that you have, and we’ll go build you an app for that, actually, pretty quickly. And we pull on the knowledge that we have, all the expertise that we have.

[01:02:08.11] And so that I think is pretty powerful too, is with AI you almost have to think less about, or you don’t need to see examples anymore. For example with ChatGPT, you can go say “Hey, I’ll upload an image. Style it this way.” And it’s not like “Oh, I need to see examples of this.’ It’s just “Oh, well, here’s my image”, if you will, because it happens so quickly now. So that I think is quite cool, too. And I think we should do a better job showcasing that on the website.

Yeah. Interesting. I guess while we’re on that subject, what about your internal tooling? I mean, you obviously probably use Retool to build Retool, so you’ve got to have a ton of your own tooling built on top of Retool. Can you give me a glimpse into some things that you may have built, or things that make sense for you to build over the years?

Yeah, we have so many cool tools built in Retool. So we have one called Retool Home, which is inspired by Stripe Home. It’s basically this internal – it’s for employees of Retool to use, and you can log on and you can actually go see other people… It’s like an internal company directory. You can see fun facts about them, you can see – people generally record a video when they first join Retool, so you can go see that… There are fun games you can play in there, like how many Retools can you recognize in a row, for example… We have a decision log in there, so you can see what are decisions that have recently been made, for example… So it’s really cool. So that’s one example of an internal tool that we’ve built inside of Retool.

A lot of our customer tooling is built on top of Retool. So if we want to go, for example, reset someone’s password, add credits to someone’s account, pretty much all of that is built in Retool. A lot of our finance tooling is now built in Retool, which the finance team loves, because it is much more robust than using Excel spreadsheets for doing [unintelligible 01:03:52.01]

For sure. Gosh.

So it’s pretty cool, yeah. A large portion of Retool, probably 70% of Retool runs on top of Retool. So…

I love a spreadsheet, but… Not always. You know? Not always. I mean, there’s times that I’m like “Can I just get back to the simple spreadsheet?” and I can organize things a bit differently. But then there’s times I’m like “You know what? A spreadsheet’s not that kind of cool. I’d rather have something better.”

Especially when it’s really hairy. When you have multiple tabs, thousands of rows, hundreds of formulas, it’s really hard to parse what is going on. And I think a lot of those spreadsheets, honestly, over the next few years, are going to go away, because AI is going to make – with Retool and our Copilot product, for example, building apps is going to be so easy… And a lot of those spreadsheets that should have been apps, in the future are going to be apps.

Yeah, I wonder… And then I wonder about how do we – how does that world connect? Because it’s nice to have a random bespoke app, but at least I know where my spreadsheets live, and I can query them, and I can search them, I can history them… And maybe you’ll eventually have that kind of stuff too, but then I think “Gosh, now I’ve got applications that could have been spreadsheets simplified. Now they’re full-fledged applications.” Maybe I’ve got them in a special URL, and I’ve got to manage the domain, and DNS, and other stuff like that. Or they’re just a simple URL schema inside of Retool that makes it easy to go to customer.retool.com/whatever. Maybe it’s like that. I don’t know. How do you manage a world once you’ve got a few of those bespoke apps versus spreadsheets?

I think bespoke apps are much easier to manage than spreadsheets, because with spreadsheets you basically have no guardrails. There’s files, maybe on the cloud, maybe on your computer… It’s hard to do version control on them, it’s hard for multiple people to collaborate on them even…

Sure. Google Sheets is pretty easy, but I think a file-based sheet is less easy.

Yeah. But even Google Sheets is hard to tell cell history… For example, if someone accidentally fat-fingers a cell, that becomes quite com–

That’s true…

So I think apps are honestly way better than spreadsheets. Well, in some cases, simple spreadsheets make more sense than apps, but I think as app building becomes way easier, there’s going to be a lot more apps, I think.

[01:06:09.28] Okay. So today - am I able to go into Retool today? This shows just how naive I am about how Retool works, so bear with me. Despite y’all sponsoring us, despite me should know a lot more, this is maybe a TMI in a way. Can I go into Retool now and tell it what kind of application or what kind of tool I want to build, or what I need? I have a Postgres database, or this or that. Can I describe the problem today and it builds me the application today in Retool?

Virtually. We are launching that later in August. Today you can build large parts of your app; you can go write queries, you can go build some UIs, but it’s not a full end-to-end experience yet. This is our next big launch coming in August. We’re actually launching a full end-to-end way. It’s like app gen, basically. So it’s something similar to Bolt or Lovable, where you can just say what you want and it builds the whole app for you.

But what’s going to be really incredible is the fact – it’s two things. One is that we can actually build on top of your existing data sources. What we’ve found is with many of our customers, like Amazon and others – Amazon has a lot of databases. They use Snowflake internally, they use RDS… They have so many places where data lives. And for them, they’re not really interested in using something like Bolt, because Bolt is really great for prototyping. It’s great for generating a new application from scratch… But how often are you truly generating a new app on top of new data, where you have no data really? Not very often, actually. In most businesses, the data already exists, but you want to build an app on top of that. And that is where I think Retool is really going to shine. We’re going to be the first product in the market that allows you to go generate applications on top of pre-existing data. Whether it’s in Postgres, Snowflake, Databricks, Salesforce, or Stripe, you can actually go generate an app entirely based on that, which is going to be really cool.

The second thing is that because we’re so focused on internal software, we’ll give you a lot of things right out of the box, like authentication, authorization, audit logs, stuff like that. And so you can then say “Hey, actually, these apps could only be usable by these people, or be usable only by these [unintelligible 01:08:29.26] groups, actually”, which is going to be super-powerful. So we imagine catalyzing a wave of application building with this product, this Copilot product. It’s coming in August, so we’re pretty excited about that.

Interesting. Yeah, I’m not familiar with all these details of what’s coming… I just assumed it was already there, but apparently it’s coming. So you’ll be able to generate a full-on Retool application from scratch, which is essentially what a lot of other platforms are already doing, but you were saying on top of a database. When you said that, I was thinking, “Okay, so what will you be able to do, I suppose, by just looking at the database?” Will you take a lot of the prompt and context of what to do, but can you also just say “Hey, look at this database and generate the screens that should manage this kind of database”? Is it going to be that easy to generate, or what are some of the processes and guardrails going to be when you do that? Do you know?

Yeah, totally. So what’s going to happen is once you’ve connected a database or an API even, the LLM will realize, “Oh, I have all these API inputs I can hit, or all these tables that I can pull data from.” And so then, it’s kind of what we were talking about before - the LLM is so much more powerful and so much more correct when it actually knows the shape of your data, or is actually able to interact with your database. So the apps it generates look much better, but also actually work immediately. And it can go straight to prod, because of the security guardrails and stuff like that. There’s no product on the market that allows you to do that right now, so we think that’s really quite powerful.

[01:10:11.00] Interesting. So is this a leak you’re doing here on the podcast right now? What are you doing [unintelligible 01:10:14.27]

I actually don’t know if I’m allowed to talk about it, but I’m pretty excited.

You mean you’re going to be in trouble right now, or what?

It’s coming just next month, so I hope I’m not in trouble, but we’re really, really pumped about it.

Okay. To me, this is the cool part, honestly. I mean, I like the idea of what you’ve already released, I like the idea of reactive, where you have reasoning and you have action in terms of agents… But to me, this is the coolest, because it’s – for what you just said there, which was the… When you said the agent can only have certain tooling. So the accuracy of the predictive of what it will do is so much more guardrailed [unintelligible 01:10:52.28] to be true versus false, or a hallucination, because you’ve given it parameters. And so I think about the same things… If I’m building on my real data, or my real API endpoints, then the LLM inside of Retool before it even builds out the thing I’m building out - I can have a conversation with it about my API endpoints. I can discover it as a maybe junior-ish or up-and-coming developer for the company, where I’m learning more and more about the different systems; I can plug into Retool, given I have auth, and given I have whatever, to build out whatever tooling I need to, and begin to query the database and the API to learn even… And maybe to ask it, “Hey, we have this problem. How can this internal tool that we need to build solve it? What API endpoints will we use?” That to me is – that’s where you want to be at. And as you mentioned before, the accuracy level is high, because you’ve literally got the API and the endpoints and the details there. The context is so clear, versus abstract.

Yeah, exactly. So we think that a lot of the app gen products in the market today are quite good at UI generation or prototyping, which is awesome. That’s very valuable. But it’s hard to – as far as we can tell, no one is really using these app gen products that go straight to production, because in the end, they’re not very robust, especially if you’re an enterprise. It’s very hard to get the stuff -0 it’s hard to deploy it in your cloud, for example, on top of your data, there’s no security… So that’s all really quite challenging.

I think for us, we think the opportunity is if we focus specifically on internal software on top of your data, can we go build an AppGen product that not just generates UIs, but is immediately actually usable, and you can actually deploy it to your customers? And I think with all the context we have for your data from other apps you’ve built, we can do that. And so we’re really excited about that opportunity for us.

Does that change Retool at all? I mean, I know since the beginning it’s been internal tools, and you can sort of expand the umbrella of what internal tools means to the point where it just means software… But does this change the trajectory at all of Retool? Does it take you from an internal tools company to something that’s – or does that even bottleneck you from the true potential you can achieve?

Yeah, so we’ve thought a lot about how this changes for our customers. And our hypothesis right now is today, most developers are the ones that are “hands-on keyboard” coding. And so the developer is the one building the application. [unintelligible 01:13:37.28] AI, but they’re still building it. It’s still you that is building it. What we see in the future is we think that today’s developers will move to more of a software architect kind of role, where they’ll be building a lot of the building blocks for AIs to use. So for example, maybe you work on the API endpoints, maybe you work on the data schema, because that stuff is really important. But for the actual application building, you don’t need to be doing that anymore. It’s going to be either the AI or even lines of businesses actually building and generating applications based on your building blocks.

[01:14:17.23] And so we have this concept that we’re internally calling tomorrow’s developers, and the idea there is today’s developers are the ones that have both the skill and the knowledge to go build applications. But tomorrow’s developers may just have the skill and not the knowledge, actually. What I mean by that is – my wife is actually a good example of someone like this, which is… She was an econ major in college, and she wrote some MATLAB in college, so she’s able to code. She’s able to think in a coding-like way, if you will. But if you go ask her to go build a web application, she would be pretty overwhelmed, because there’s just so much going on. It’s so complicated to go build a web app today. You have to worry about what frontend framework do I go and choose? What state management library do I use? What are the pros and cons of using something like Heroku, or Vercel for example today, versus AWS? Should I use a VM, or should I go use an all-in-one platform? Should I use Supabase or should I go use Postgres? What’s the difference? It’s so complicated. There’s so much knowledge that is required to go build an application. And so we think that these kinds of people with AI and with software architects, with software engineers becoming software architects building the building blocks, if you give them the building blocks and you give them AI, they will be able to build really powerful applications they can actually directly use.

And so that’s kind of our vision, is we think that software engineers, their role will change a little bit, and a lot of these line of business people that can learn SQL, can pick up SQL, will now be able to ship secure applications, and actually build them themselves and actually use them in production. So yeah, it’s going to be a pretty exciting next few years, I think.

It would be interesting to think about - to use your idea of tomorrow’s developer - somebody who has the skills, meaning they understand how to leverage the power of an LLM, or however that evolves to be talked about, whatever lexicon makes sense to say LLM. They have the skills to do so, but they don’t have the knowledge of how to build software necessarily. They may have some knowledge on how to build software, but not how to build software or internal software for the company that they work for, right? They don’t have a full understanding, but they can use the platform to query and learn, and then actually build. And if you give it enough of the security measures - like you mentioned, authentication, authorization, if that’s already baked into the way things work, then it’s pretty easy to give people more and more trust when it could be either just taking offline or regenerated differently in such a rapid manner. We used to have a fear, I suppose, of shipping software, because the cost and time to change or to blame or to fix or to redeploy was more time consuming, to put it bluntly. And now it can be a lot less time involved there.

[01:17:24.11] So maybe that speed to deployment is what’s changing things to make it more trusted. It’d be kind of cool to be this future tomorrow developer, not really have the skills to do software development or the knowledge, but have the skills to conduct and architect based on feedback and learnings to deploy something to prod, and not really be a software developer. That’s kind of what I think about, honestly.

Yeah. We see a lot of data teams doing that now with Retool, and I think that we’re pretty far from total non-technical people being able to do this, because I think if you don’t know how to write SQL, if you don’t know how to debug it, it’s going to be a little bit challenging for you to go build full stack applications. But if you are able to write SQL and you have software architects or today’s software developers becoming software architects building you the building blocks, then absolutely. I think it’s going to be really quite powerful.

Interesting. Alright, David, tomorrow’s developers can’t wait to ship some stuff to them and get some cool stuff. Anything left? Anything left in closing? I know we’re – I think we have like maybe one-ish minute left. I just realized we’re right at time here… What’s left that I haven’t asked you, that you want to leave on the table here?

I think we covered a lot. We covered agents, we covered Copilot, we covered tomorrow’s developers… Yeah, I feel pretty good. Yeah.

Yeah. Right on. Glad to finally have you here. Big fan of Retool, as you know… I’m just such a fan of enablement, like you’ve done. I don’t personally in my small business have a vast need for internal software, but I know a lot of teams who do. And I’ve used – what’s kind of cool actually, to circle it back, is I used a vendor onboarding form recently. And I can tell it was a Retool application I was using… Like, “Okay, cool…”

That’s awesome.

Because we’re sponsored, so we deal with a lot of different brands who work with us and whatnot, and so we have to do vendor onboarding, and who are we, where do we live… Not so much live, but like where we work, kind of thing, and I have to share some data with them. And I filled out a form and it was a Retool application as an intake form for them. I was like “That’s pretty cool. That’s pretty cool.”

That is really cool. Yeah. Awesome.

Yeah. After all these years of working together, finally circling back personally to use some internal tools from Retool. Alright, David, thank you so much. It was good talking to you.

Thanks for having me on. Yeah, it was a lot of fun.