How Retool got their first customers

We believe 100% of this kind of software is going to be built by non-developers. Amazon is a customer and they have this app where they press buttons and satellites actually move. The US Army is a Retool customer too and they use Retool to save the turtles. That's the cool thing about a dev tool, right? Is that developer tools span all industries.

That's hilarious. I probably wrote it. I think this was pretty early, I think, when you probably first saw that. And I think what you're describing is honestly what our experience was too. So my co-founder and I were both engineers and we both built a lot of internal tools in previous jobs and just like what you said, it's kind of remarkable how rote it is. It's just doing the same thing over and over again. It's, oh, I got to make a new Redux store. Okay, great. I got to make a new table here. Oh, here are the columns. Okay, I got to figure out how to submit the form now. Oh, wait. But the submit button, I wanted to show a loading indicator. Oh, how do I do that? You know, it's like it's the same thing over. It should be way easier. And I don't know if you ever used Rails. I'm a big Rails fanboy. And Rails is so easy. It just handles so many things for you. And so that's kind of the idea behind Retool is could we allow you to only write the code that is specific to your business which as it turns out is 10% of the code that you actually write is specific to your business. 90% is all boilerplate.

That's amazing. That's great. And yeah, it's really cool. I think one part of being a dev tool company or founder is that you get to see so many use cases. I never would have thought that would have been a use case. But one of the use cases like Amazon is a customer and they have this app where they press buttons and satellites actually move which is pretty crazy. So that's pretty interesting. The US Army is a Retool customer too and they use Retool to save the turtles where seriously so they do dredging at different ports across the country and as they do dredging sometimes they run into turtle populations and so they actually have to track where the turtle populations are, how big are they and it used to be all pen and paper. They would say oh turtle report and they would write a report and I talked to the engineer who built this and he was saying that back when it's pen and paper you have a giant stack of paper at the end of the quarter and no one really wants to enter those reports into a database and so just don't know where the turtles are and now they've built a mobile app where they take a photo of the turtles and they say here are the turtles and here's how many I think they use LLM actually to say here's how many turtles there are, here's the lat long where the turtles are and so they say oh don't dredge here because there's a turtle population here. So use cases like that are just so cool, you know, you never really imagine. But that's the cool thing about a dev tool, right? Is that developer tools span all industries.

Yeah. So as you know because you've used Retool, Retool for a long time was always entirely geared towards developers. And over the past maybe 18, 24 months I think we've developed the conviction internally but also in large part due to the evidence that technologies that we've tried that actually production software especially internal software so apps that write back to a database to an API that give you some reports that allow you to run your business. We believe 100% of this kind of software is going to be built by non-developers in the next 24, 36 months. I think developers will still be required especially for more complex projects but honestly a lot of the time those more complex projects are the consumer-facing applications. You can imagine so Airbnb is a customer of ours as well. Airbnb's mobile app is an amazing mobile application. Their website is amazing. And if you think about if you were the CTO at Airbnb, where would you want your engineers spending time? It's going to be stuff like that. That's the kind of stuff that, you know, it's honestly even a little bit harder to vibe code or it's, you know, the quality bar is so high, right? You care so much about every single pixel. Whereas what Airbnb uses us for is they use us for processing insurance claims. And the alternative is using a spreadsheet. And for a simple app to process insurance claims, does a developer really need to get involved with that? We think the answer is not. And so that's the major change there. There's two major changes. That's one of them is that now Retool is geared towards, I would say, what we call tomorrow's developers. And these people are not totally non-technical, but they're I would say Excel users. There are people that on data teams, people on RevOps teams, people like that that were able to write SQL that could write a few lines of code if they really wanted to but are not professional developers. And the idea here is that instead of having to go learn Redux, instead of having to go learn React and all this crap that you have to learn to become a developer, you can just write a bit of SQL, maybe even Vibe Code a bit and now get production applications. So that's I think one pretty major change for us over the last 18 months.

I think that Retool as you know historically has been pretty focused on front-end applications and I think front ends are today is a very sizable portion of our revenue but I think our fastest growing slice of revenue was actually more agents or automations and specifically well this is going to get into my whole take on AI right now but I'll give it quickly which is my take on AI is that I think LLMs are incredibly incredibly smart at this point. At any given task, they are probably better than you or I at any specific task. And yet, despite being so smart, they can solve IMO level math problems. They can do all sorts of crazy things. And yet, they're not super useful right now in work. In coding, they're very useful, but outside of coding, LLM use cases are actually not super easy to find. Maybe summarization is one, but it's kind of shocking that despite how smart they are, how little impact they have on most CIO, VP of Engineering lives today. And I think the main missing thing is LLMs are plenty smart already. The problem is they don't have arms and legs. They can't go do things in your business. And so, we've been really focused on how do we allow tomorrow's developers to go harness these LLMs and really give these LLMs arms and legs to do things in your business. Because if you think about something like a Claude Code for example, theoretically everything you do in Claude Code you could actually do in ChatGPT. You could say, hey, I want to write me this code. I copy the code. I paste it to my IDE. I get an error message. I copy back into ChatGPT. Obviously, it's very ineffective, because you are the API for the LLM. The LLM is using you as its API basically, and you're pretty slow, right? And what Claude Code does is they say, oh, forget it. Why don't you just let the LLM do it itself? And it's very effective. Now if you could bring that but not just to coding but to all jobs, let this LLM send the email, let it make a phone call, let it actually do things in Salesforce, let it actually do things in my database, that is what I think LLMs get really really powerful. So that's maybe the second way Retool has changed is that instead of just building frontends we're now very focused on agents and allowing LLMs to actually do things in your business which I think is honestly going to rival frontends as a market in the next few years. Frontends themselves may even go away. I think in the next few years.

Oh well so for example I think there are rumors you may have seen like OpenAI is working on a new device for example that they're trying to challenge Apple and I think all the rumors say that the new device has no screen. And if you think about it honestly how often do you need a screen? In some cases, the screen is pretty good for sure, but in many cases, you don't need one. You can imagine, for example, you could imagine AirPods as a computing interface where AirPods are always with you. They listen to everything you listen to. And you can just tell the AirPods to do things. So, you might say, hey, I just got off this podcast with Jack. But there are some few next steps. Can you go do those next steps? You just tell your AirPod that. And your AirPod could theoretically go call an LLM, call an API, and it could just go do things. The LLM, we're connected to your email account, we're connected to your to-do list, we're connected to your databases. Maybe it just does all the next steps and there's no front end at all there.

Yeah, totally. I think the screen is helpful for checking work because maybe you can scan information a lot faster than you can listen to information. At least that's true for me. But like you said, I think if the checking, if the correctness goes up, the percent of things you need to check goes down. Like let's say a restaurant reservation for example, I could just, if I get an idea of a restaurant I want to go to tonight, I just tell my AirPod, hey, can you make me a reservation for this place and that can just do it and if it tells me, hey, I made a reservation for this place, I probably would trust it. I think again depending on correctness, but I think that's the future. So those are the two ways that Retool's really changed and we've scaled our, you know, Retool the original Retool dev tool is one is we've broadened our ICP to tomorrow's developers and secondly we've broadened what Retool helps you build from just front-end applications into our fastest growing segment now is actually agents and automations.

Yeah, great question. So, to be honest with you, I don't have a great strategy here except for the fact that we are developers and I haven't tried starting a startup where I'm not the ICP. I think it would go a lot worse because to your point a lot of what I do, a lot of the features we work on, a lot of the copy that we write, all those things, all that really is only possible because we know the ICP, we know the developers so well. You know we know how hard it is to learn Redux for the first time for example. You know it's functional programming you do a fold it's like do you really need to know that probably not. So I don't, if I have great advice, I would say if you're not a developer, you probably shouldn't start a DevTools company is probably my only advice there. I think maybe as the company scales, you obviously have to figure out how to get product marketing talking to your developers. Your developers are not always the PM for example. So there's a lot to discuss there maybe, as the company scales. But to be honest, I think you just have to, to start a dev company, you have to be a developer. You have to start yourself and you have to outsource as little as possible because I think as you know, as a developer I'm this way too, I can tell very quickly if the tool is not for me. And if it's not for me, I bounce, I'm not interested anymore. And so today one of our challenges actually is how do we appeal to not the totally non-technical person but the semi-technical person and the developer and that I think is an interesting topic.

You did? Yes, I was on Indie Hackers some time ago. They're great.

So my overall thesis on where programming or development is going is that we continuously move higher and higher up in the stack. And I think that is an inevitable and it has always happened and it will continue to happen. And what I mean by that is if you look back to let's say the 1950s or the 40s for example when you program computers why you punched cards. That's pretty challenging. It's very low level. If you're a CS major, you probably took assembly courses when you were in university and I did as well and it's very low level. Trying to write in assembly is, you can do it but it requires so much effort and you have to hold so much in your head. It's so easy to make a mistake and you go from assembly into something like C which is higher level but you still do manual memory management and I'm old enough and you're probably old enough too that we still remember the debates of oh do you like garbage collected languages or not and should you do manual and today no one really talks about that anymore. I mean maybe some people do but today it's pretty obvious to most people that at least most web developers and web programming now is obviously all JavaScript and it's pretty high level. I don't think anyone is really yearning for those days where you had to go manually manage memory, allocate it, deallocate it etc. It just doesn't happen anymore right? And so I think what's happening is and it will continue to happen is that we are continuously moving higher and higher up the stack and every time you move higher up in the stack there are more people capable now of programming. Which is even before AI if you look at the web developers of let's say 2020 for example what percent of those people would have been developers had the only language they could write been assembly. I don't think 100%. I think maybe 20% let's say because assembly is a harder language to write than for example JavaScript and so there probably less people interested in it. It's probably more frustrating. Some people select it less etc. Right? So yeah every time programming moves higher level more people can do it. And so I actually don't view the two personas, let's say the Excel, the power Excel user who's good at writing formulas and can reason through things and can pick up a bit of SQL honestly as that different as yesterday's developers who are now moving higher level. Many people at Retool today, many engineers at Retool today use Claude Code extensively. And the way they're coding with Claude Code. Yeah, you do have to read the code obviously. You're not just fully vibing obviously. But it's definitely moving higher up in the stack and that's actually why we target semi-technical people. We don't target totally non-technical people is that for now I think for the next few years I would say it is actually very important that you are able to read some code and the reason for that is LLMs just very easily make mistakes and I don't know if you've tried vibe coding and for example Lovable, Replit, Bolt, these kinds of applications but those things are so so inaccurate right now it's funny. I was talking to a customer the other day and they were trying to build some dashboards with Replit actually and they built actually three people in the company built the same dashboard. They all independently had the same idea. So they built the same dashboard and they were all being used extensively in the company and all three dashboards did the same thing but showed different numbers. Like what I mean like those three people probably were not technical. They probably didn't check the SQL and they're like okay it kind of looks about right and so I'm going to ship it and that's I think we're going to see a lot of that. I think over the next few years and I think if we can't get rid of hallucinations in LLMs which I don't think we can technology-wise at least in the next 12, 18 months without a totally new architecture you will see problems like that and that I think is pretty scary honestly. And I think as software engineers it's going to be, it's really frightening to get pulled in to be like okay well got three dashboards that had different numbers what do we do and we're like okay we got to stare at the code. It's like a lot more people create software but also this level of problem. So anyways, I think there's something interesting there. Maybe talk about a little bit to go back to your original question. I think that the needs of the power Excel user are actually not that different from the developer because the developer has moved higher level. But that has also enabled the Excel user to start programming. But the developer actually does not want to be writing Redux code. They don't want to be writing assembly anyways actually. And so yeah, that's how I would view sort of these two personas almost merging over time.

Yeah. So what's really interesting is actually if you look at the stats internally for who is actually building in Retool. It turns out that four years ago the percent of developers building in Retool was like 90, 95% like pretty much everyone was a professional software developer like yourself you were building in Retool. But if you actually look at where it's gone to in the last few years and this was happening even before LLMs actually. So it's independent of LLMs although LLMs have probably actually in fact accelerated the trend. I think two years ago the percentage of non-developers building in Retool was maybe 30%. So 30% of people building actually non-developers today it's around 50, 60% actually and so that gives you a sense like this is a trend that will continue regardless honestly whether Retool exists or not doesn't matter. The trend will continue. Non-developers will go build software. More people will go build software because software becoming higher level, easier to build. And so I think that to be honest there's a lot of latent demand for software. Almost no company has, this sounds kind of weird but almost no company has satiated their demand for software. You know, they're always thirsty for more software. And so I think there's a lot of people that want to go build things. And if you can provide an application layer or infrastructure to help them go build in a safe secure accurate way which I think we're the only company that helps you do that. I think that's a very very powerful and I think it's going to be an enormously large market.

I would say so. But what I would argue is that the definition of a developer is changing. Just like for example if let's say you move from assembly to C. You know C I think came in 1976 when it was first written and you can imagine that some people that were writing assembly before would look at the people writing C and they would scorn them. They would say oh that's not a developer. You're not hardcore enough. You're not doing everything at such a low level anymore. So high level just like how possibly C developers look at today JavaScript developers are like ah these aren't developers, just slinging code around and writers of JavaScript and they don't know what writing real code is like but to be honest I mean I would call people writing JavaScript I call them developers, pretty well accepted today and so I think at every stage there is this as the definition

The definition of a developer broadens and more people come into the tent and more people go build software where there is a bit of uncertainty and a bit of, you know, are they really developers? But I would define a developer as someone who's able to build, iterate, maybe debug software is what I would say. And so I think maybe that's where you get into the non-technical people, and I would not call them developers. Which is, you know, if they let's say vibe code something and they have no idea, and if let's say the number is wrong, you know, they're building a dashboard, the number is wrong, and they're like, 'I don't know what to do, I give up,' that I would probably not consider a developer. You know, that's vibe coding, that's the downside of vibe coding. But people who are able to iterate and maybe inspect and understand, 'Oh okay, this is the issue, let me go fix that issue,' I would call that a developer. And so I think we are a developer tool, but the definition of a developer is certainly again with or without broad.

Yeah, totally. Yeah.