We believe a 100% of this kind of software is going to be built by nondevelopers. 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. So

Hi, everyone. I'm joined today by David, the founder of retool. David shares how they found their early customers, how they've changed their business with AI, and what advice he has for founders starting a dev tool right now. You have the my all time favorite h one, like, of of any product. I remember, like but it was, like I I I still have the screenshot of it somewhere.

I should have pulled this up in advance, but it's like, stop doing this. Stop struggling with this and banging your head against the wall. Stop building internal tools that move your business forward or something like that. And it was just like you were just like I remember reading the the description. It was just such a, like, great articulation of, like, the pain that I was struggling with as, like, a fat pretty junior developer.

And then, like, trying to build these tools, I was just spending so much time on, like, really think things that felt like they've been done a million times before. And I kind of had that as, like, my kind of, like, every time I want to, like, write hero copy, I always go to that, and I've got it saved somewhere.

That's hilarious. I probably wrote it. I I think this was pretty early, I think, when he probably foresaw that. And I think what you're describing is honestly what our experience was too. So my cofounder and I, we're both engineers, and, we both built a lot of internal tools in previous jobs, lives.

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 gotta make a new Redux store. Okay. Great.

I gotta make a new table here. Oh, here are the columns. Okay. I gotta 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 the same thing over it should be way easier. And I don't know if you ever used Rails.

I'm 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 recall 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 bo boilerplate. So

Yeah. It's it was amazing. And maybe this I can I can almost, like, give the pitch of a retail for you in the we I was working with this? It was a really cool use case. It was like I was working with this charity that does surf therapy.

They're called The Wave Project. Mean, hopefully, they're not gonna be mad for me to say this. But they were, like, using Retul to, like, see all of, like, the bookings and stuff of people. It's so great because you could just create a query to a database, so you got everything. And then you can actually people that are on the devs can actually just go and see that and change statuses, chain up you know, basically update the database.

Don't have to, like so so fast to just get that up and running. Was like it's like a massive, massive time saver for us.

That's amazing. That's great. And, yeah, it's really cool. I think one part of being a DevTool 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 what are use cases?

Like, Amazon is a customer, and they have this app where they, press buttons and satellites actually move, which is pretty run Kuiper. 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, you know, write a report. And I I talked to the engineer who built this, and he was saying that back when it's pen and paper, you know, you have a giant stack of paper at the end of the quarter, and no one really wants to enter those reports to a database. And so just don't know where the hurdles are. And now they've built a mobile app where they take a photo of the hurdles, and they say, here are the hurdles, and here's how many.

I think they use LLMs actually to say, here's how many hurdles they Here's the lat long where the turtles are. And so they say, oh, don't dredge here because their turtles there's a tall population here. So it is use cases like that 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.

So

Yeah. So people just, yeah, can use it in ways you can never imagine. Yeah. That that's wild. And so now, like, how so I was saying to you before, but, like, I'm I'm extremely familiar with, like, Retul before AI.

And how has how has Retul changed with LLMs and stuff now?

Yeah. So as as you know, because you've used you've used Retul, Retul for a long time was always entirely geared towards developers. And over the past maybe eighteen, twenty four months, I think we've developed the conviction internally, but also, you know, in large part due to the evidence that, you know, technologies that we've tried, that actually production software, especially internal software, so, you know, apps that write back to a database, to an API, they give you some reports that, allow you to run your business. We believe a 100 of this kind of software is going to be built by nondevelopers in the next twenty four or thirty six 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 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 engineer spending time?

It's gonna be stuff like that. That's the kind of stuff that, you know, it's it's honestly even a little bit harder to vibe code or or it's you know, the quality bar is so high. Right? You care so much about the pick 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, you know, 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's 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 nontechnical, but they're, I would say, Excel users. They're people that on data teams, people on RevOps teams, people like that that are able to write SQL, that could write a few lines of code if, you know, they really wanted to, but we're 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 eighteen months, I would say.

Scaling DevTools is sponsored by WorkOS. If things start going well, some of your customers are gonna start asking for enterprise features. Things like SSO, SCIM provisioning, role based access control. These things are hard to build, and you could get stuck spending all your time doing that instead of actually making a great dev tool. That's why WorkOS exists.

They help you with all of those enterprise features, and they're trusted by OpenAI, Vercel, and Perplexity. Here's what Kyle from Depot has to say about WorkOS.

We use WorkOS to effectively add all of the SSO and SCIM to Depot. So for us, we can effectively offer SSO and SCIM, and it's, like, two clicks of a button, and we don't ever have to think about it. It's, like, one of the best features that we can add to Depot, and it's super affordable, which effectively allows us to, like, break the SSO tax joke and essentially say, like, you can have SSO and SCIM as, an add on onto your monthly plan. So it really allows smaller startups to essentially offer, like, that enterprise feature without a huge engineering investment behind it. Like, it's literally we can just use a tool behind the scenes, and our life is exponentially easier.

Thanks again, WorkOS. Back to the episode.

I think that, Retul, as you know, historically has been pretty focused on front end applications. And I think front ends are yeah. Today, it's a very sizable portion of our revenue. But, actually, our fastest growing slice of revenue was actually more agents or automations. And, specifically, well, this is gonna get into my whole take on AI right now, but I'll just give it quickly, which is I 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 LMs being so smart, they can solve, you know, IMO level math problems. They can, do all sorts of crazy things, and yet they're not super useful right now, in work. In in coding, they're very useful. But outside of coding, you know, LM use cases are actually not super easy to find.

And maybe a summarization is one, but it's kinda shocking that despite how smart they are, how little impact they have on most CIO VPE lives today. And I think the main missing thing is LLOPs 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 Cloud Code, you could actually do in ChatGPT. You could, you know, you could say, hey. You know, I would write me this code. I copy the code. I paste it to my IDE.

I get an error message. I copy back at ChatGPT. Obviously, it's very ineffective, you know, 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 Cloud Code does is they say, oh, forget it. Know? Why don't 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, you know, let this LM 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 LMs get really, really powerful. So that's maybe the second way Retul has changed is that instead of just building front ends, we're now very focused on agents and allowing LLMs to actually do things in your business, which I think is honestly gonna rival front ends as a market in the next few years.

Front ends themselves may even go away, I think, in

the next few years. Interesting.

Go how'd you mean go away? Oh, well, so for example, I 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 the new device has no screen. And if you think about it, honestly, you know, how often do you need a screen? In some cases, 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. You know, I just got off this podcast with Jack, but there are some few next steps.

Can you go do those next steps? You can just tell your AirPod that. And your AirPod could, you know, theoretically go call an LLM or call an API, and it could just go do this. The LLM will connect it to your email account or connect it to your to do list or connect it to your databases. Maybe it just does all the next steps, and there's no front end at all there.

So

Yeah. Yeah. That makes sense. The shameless plug where we just made a little, like, voice interface for quote code, like, running on your on your on your computer, but then, like, you know, it's also from your phone. And it's like it is kind of a lot of stuff you can just if you trust that it can do it, it's like, I guess you don't need to, like, get involved with the screen.

You can just tell it, like, once, just take care of this for me. Yeah.

Totally. I 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 that you check goes down. Like, let's say, a restaurant reservation, for example.

You know, I could just you know, if I get an idea of a restaurant I wanna go to tonight, I just tell my airport, hey. Can you make me a reservation for this place? And the LM can clone, just do it. And if it tells me and tells her, hey. You know, I made a reservation for this I would you know, I probably would trust it, I think.

Again, depending on freshness. But I think that that's the future. So those are the two ways that Retul's really changed, and we've scaled our, you know, Retul, the regional dev tool, is one is we've broadened our ICP to tomorrow's developers. And secondly, we've broadened our what Retul helps you build from just front end applications into our fastest growing segment now is actually agents and automations.

Yeah. I the on the ICP part, I felt like as I was saying about the kind of, like, the heading, I remember reading it and thinking, like, okay. These guys get it. Like, they understand this. It was like, I they they understand my pain here.

Like, spending all this time doing stuff that feels like it's been done loads of times, and it's still annoying. How do you understand your ICP well and build what they need?

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 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 a lot of what I do, a lot of the for the features we work and a lot of the copy that we write, all those things.

All that really is only possible because we know the I see we 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. We so I I don't know if I have great advice. I I would say if you're not a developer, you probably shouldn't start a dev tools company. It's 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 are not always the PM, for example. So there's a lot to discuss there maybe, you know, as the company scales. But to be honest, I think you just have to it has to yeah. To start a DevOps company, you have to be a developer and to have to start it yourself, and you have to outsource as little as possible.

Because I think as you know, I mean, as a developer, I'm this way too. I can tell very quickly if the tool's not for me. And if it's not for me, you know, I I I bounce. I'm not interested anymore. And so today, one of our challenges actually is how do we appeal to not the totally nontechnical person, but the semitechical person and the developer?

And that I think is a yeah. It's a interesting topic. So

Yeah. Because I because I was gonna say, so it makes sense, like and when you were starting and that's another question I'm gonna come back to, but I know you started off like I I'm pretty I I listened to you on Indie Hackers, like, back in the day, and so I did write. I'm not imagining that just to Don't Chek.

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

Yeah. So I'll come to that. But as you do expand and broaden it, like, you know, you're probably not the ICP of, like, Excel user, like, heavy you know? How are you, like, kind of trying to keep that, like, real understanding as it goes beyond sort of, like, your experience, I guess?

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 nineteen fifties or forties, for example, when program computers, well, I punched cards. That's, you know, that's pretty challenging. It's very low level.

If you're a CS major, you probably took assembly courses when you were in in university, and I I did as well. And it's a very low level. You know? Trying to write an assembly is it's, you can do it, but it requires so much effort, and you have to hold so much of your head. It's so easy to make a mistake.

And, you know, you go from assembly into something like c, which is higher level, but you still do manual many manual memory management. And I'm old enough, and you're probably old enough too, that we still remember, you know, the debates of, oh, you know, do you like garbage collect languages or not? And it should do manual. Today, no one really talks about that anymore. You know?

It's I mean, maybe some people do, but today, it's pretty obvious to most people that, at least most web developers and, you know, web programming now is is obviously all JavaScript, and it's pretty high level. You know? I don't think anyone is really yearning for those days where you had to go manually manage memory, allocate it, deallocate it, etcetera. It just doesn't happen anymore. Right?

And so I think what's happening is, and it will continue to happen, for sure, 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, twenty twenty, for example, what percent of those people would have been developers had the only language they could write been Assembly? I don't think a 100%. I think maybe 20%, let's say, because Assembly is a harder language to write than, for example, JavaScript.

And so there are probably less people interested in it. It's probably more frustrating. Some people select it less, etcetera. 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, you know, good at writing formulas, that can reason through things, that can pick up a good sequel, honestly, as that different as yesterday's developers who are now moving higher level. You know, many people at Regal today, many engineers at Regal today use Cloud Code extensively. Yeah. And the way they're coding with Cloud Code, yeah, you do have to read the code, obviously.

You know, you're not just fully vibing, obviously, but it's definitely moving higher up in the stack. And that's actually why we target semitechnical people. We don't target totally nontechnical 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 some code. And the reason for that is LMs just very easily make mistakes. And I don't know if you've tried vibe coding in, you know, for example, Lovable, Reclit, Bolt, you know, these 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, 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. They were all being used extensively in the company, and all three dashboards did the same thing but showed different numbers.

And that gives you a sense where, like, well, I mean, like, those three people probably were not technical. They probably didn't check the sequel. And they're like, okay. Like, you know, it kinda looks about right, and so I'm gonna ship it. And that that's I think we're gonna see a lot of that, I think, over the next few years.

And I think, you know, if we can't get rid of hallucinations and LLMs, which I don't think we can, technology wise, at least in the next twelve, eighteen months without a new totally new architecture, you won't see problems like that. And that, I think, is pretty scary, honestly. And I think as software engineers, it's gonna be it's it's it's really frightening to get pulled in to be like, okay. Well, we've got three dashboards that have different numbers. What do we do?

And we're like, okay. We gotta stare at the code. It's like, a lot of people create software, but, also, there's lot of problems. So so, anyways, I I think there's something interesting there that we can talk about. But to go back to your original question, I think that the needs of the pro 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.

How are you maybe this is kind of a similar question or something you alluded to earlier, but, like, how do you actually call out like, how do you speak to that broader group that's, like, developers plus people that are, like, five coding or or, like, just dabbling and and starting to, like, occasionally look at code, but for the most part,

not. Yeah. So what's really interesting is actually if you look at the stats internally for who is actually building in Retul, it turns out that four years ago, the percent of developers building a Retul was, like, 95%. Like, pretty much everyone was a professional software developer like yourself. You're building a 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 it's an LLM. It's independent of LMs. Although LMs are probably have actually, in fact, accelerated the trend. I think two years ago, the percentage of nondevelopers building a retool is maybe thirty percent.

So 30% of people building a retool is actually nondevelopers. Today, it's around 60%, actually. And so that gives you a sense, like, this is a trend that, will continue regardless, honestly. Whether a retool exists or not, doesn't matter. This trend will continue.

Nondevelopers will go build software. More people will go build software because software coming higher level, easier to build. And so I think that, to be honest, the there's a lot of latent demand for software. Almost no company has this sounds kinda weird, but almost no company satiated their demand for software. You know, they're always thirsty, full for more software.

And so, I think there's a lot of people that want to go build things. And if you can provide a, application layer or a you know, 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 very, very powerful. And I think it's gonna be an enormously large market.

So do you think that you would say like, just this is something that my boss, Ashley, was talking about and, like, some other people of, like, what is like, would you say that you guys are still a developer tool?

I would say so. But what I would argue is that the definition of a developer is changing.

Mhmm.

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 you're not doing everything at such a low level anymore. You're so high level. Just like how possibly c developers look at today, JavaScript developers are like, oh, this these aren't developers. You know? Just slinging code around and writing some JavaScript and they're not you know, they don't know what writing real code is like.

But to be honest, I mean, I would call people writing JavaScript. I'd call them developers. You know? I pretty well accepted today. And so I think at every stage, there is this, as the definition of the developer broadens and more people come into the tent and more people go build software, there is a bit of uncertainty and a bit of, you know, are they really developers?

But I would define developer as someone who's able to build, iterate, maybe debug software is what I would say. And so I I think maybe that's where, you know, you get into the nontechnical 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 pulling 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 yeah. I don't know what I would call that. You know, that's vibe coding.

That's the downside of vibe coding. You know? 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 out a developer. And so I think we are a developer tool, but the definition of a developer is certainly again, with or without is brought in. In.

Yeah. That that makes sense. I I like that, actually. So it's people that are actually gonna iterate and and debug and yeah. If they do that, however they do it, even if it's just with the prompt, then it's still developing.

Yeah. Totally. Yeah. Yeah. And it is the time for it's finally time for JavaScript developers to look down upon a new breed of the time has come.

Yeah. It's funny because I had some people, you know, back in the day would say, oh, you know, all you do is you write front end code. All you do is write you write CSS. That's not real development. Obviously, it is.

Right? I mean, you're writing software. It turns out that it's on the front end. Is more declarative, if you will, programming language, and so maybe it's easier or harder in certain ways, but it's still programming. So getting a computer to do your bidding.

Maybe that's another way of putting, which is if yeah. If a computer can do what you want, you're a developer. And if it doesn't do what you want, you don't know to get it to do what you want, you're not a developer. Yeah. So

Yeah. That that that's amazing. David, I wanted to ask about, like, the origins of Retul and kind of the the early days because I think it's it's very interesting, especially, like, you know, the fact that you started out, like, bootstrapped. Yeah. I I always find that extremely interesting.

Yeah. So we started a retool in around 2017, I believe. And at that point in time, we started it, honestly, just because we were developers who were had built so many internal tools. We thought there had thought to be a better way. And it's funny because, like I mentioned, I I came from a Rails background.

And so when you use Rails, actually, building a admin interface, I think it was active admin, was what I used back in the day. It's super easy. You can just generate it because Rails has all the models. Right? And so you could just generate views very quickly on top of that, and it's all plugged in, and authentication is handled for you, etcetera.

It's super simple. And I believe what ended up happening was actually my cofounder and I, we built an application not in Rails. And we were like, okay. Crap. Now we gotta go build an app interface for this thing.

And we're like, what do we do? And there was surprisingly nothing available. There is something you know, if you use Django, there's Django admin. If you use, what else? Yeah.

It was active admin. But if you I I think we might have built it in Node or we might have built it in Clojure script. I don't remember. I I think it I think of it was maybe actually Clojure script, actually. Clojure.

And there is no ABO framework. And so we were like, wow. So you truly just have to write all of this from scratch? And that was the state of internal tool development in 2017 when we first started, was you would have to do that from scratch. If you didn't use a framework and even at that point, even if you had used Node, I don't think there was a because as you may know, like, Node has less batteries included than something like Rails is.

And Node doesn't tell you, oh, you have to use this you have to use active record, for example. So it's not sort of all, you know, cohesive, if you will. And so you kinda have to roll your own in a lot of cases. You're putting, you know, pieces together, if you will. So that's where Ritual came from, is we thought there's yeah.

I can't believe that every time we add a new model, every time we add a new table or a database, we can't generate the UI. We actually have to go in and manually work on the UI. And And so we thought about, you know, if we work on code generation, is that a good idea? We ended up deciding that it's actually better to go build a framework like Retool, that instead of, you know, doing code gen because code gen is a little bit more brittle, you have to regenerate code sometimes if you add another table, etcetera. You have a new relationship to your tables.

You know, it gets more complicated. So with that, let's go build something like Ritual. So that's where the idea of Ritual First came from. And we built it entirely because we wanted a better way of building internal tools. And so ties back to honestly, if, we were not if we were not the ICP, I I don't think we would have been able to get retool off the ground because it is so hard to sell to people.

It's so hard to find users. It's so hard to know what feature to build, etcetera, without being guys' feet yourself.

How how long did it take you to build the first version?

To be honest, the first version was very, very bare bones. It's, it's funny because the despite all internal tools doing so many different things, every internal tool kind of looks the same. And so the very first version we built of Retul, I think, had three or four components, That was it. It was a text input, a table, and a button. And, you know, like, oh, yeah.

You know, three components doesn't sound that impressive. But, actually, most internal tools are combinations of those components put together. You know, later on, we added charts, for example. I think we added some maps later. We added a microphone component.

Someone who's interviewing for us built that microphone component, actually, so you could go record sound. But you can I mean, it was it's pretty simple? And so we built that first version, I think, over the course of a few weeks. And then we started, asking people, would you use it? And that's how we go for started.

Wow. And who who did you ask, if you would use it? Like

Let's see. So we started with friends first, but it turned out that, most people in the world are not building internal tools at the exact moment we talked about. And so they were like, it's kinda cool, but, yeah, I I don't know if I have a need for it right now. I've already built internal tools, and so I I don't need it right now. So so that wasn't super successful.

And, actually, we ended up trying another strategy which also failed, which I'll talk about quickly, but it's kind of interesting. Yeah. Was, we have a hypothesis, which is, so what is retool most like? Is it, are there any products that may be similar to a retool? It was kind of one of our first ideas.

And the idea of building user interfaces without having to write a lot of code is not, you know, actually new. It's not totally revolutionary. There's actually a bunch of other products that have done that, including one called FileMaker. And so FileMaker was a, pretty early, almost like a HyperCard kind of application where you could, you know, piece together UIs without writing much code. You can build simple forms, stuff like that.

And so I actually ended up joining a LinkedIn group for FileMaker developers, and I infiltrated, if you will, a group pretending to be a FileMaker developer. And they started messaging these people, asking them, hey. You know, I know you're a big FileMaker fan. I I am too. And I've actually built a new product called Retool.

It's kinda like FileMaker, but it's in the cloud, actually. And so would you use this product? And I think we reached out to maybe a 100 or 200 people, and out of 200 people, I think we got, like, four replies. And, I think three of them were nos. I'm not interested in meeting you.

And one reply was, let's hop on a call. And on this call, I'll tell you how bad this idea is. It's it's pretty funny. It was it was not an easy thing to get started, if you will. And so it was pretty uphill.

In the end, we ended up going through Y Combinator, and I think we ended up talking to a bunch of other companies during YC. And out of the maybe a 100 or 20 companies in that batch, I think we found one that became a real customer. Maybe two, actually. Two became customers of ours. And those were our first two customers.

And they were building admin panels, and they just didn't know how to spend so much time doing that. So that's those were our first two customers. That's how we both first started.

That's very cool. And then did were you like how did you then go and were you then just going out to, like, find other people building? I I guess because it's hard if you if you're looking for people that you have to catch them at the right time, then it's like when you're starting out and you're trying to validate, like

Yes. So we got pretty good at getting specific at what were the qualities that would make you like Retul. And for example, one quality was if you're more of a pragmatic engineer, you will like Retul more. If you care more about the business and you're achieving business outcomes, you're a better fit for Retrol. If you're a very dogmatic person, maybe you are, I don't know, a functional programming advocate, which which actually I am one, and you only write closure, for example, we're like, maybe that person is not quite the right fit for each role because they're not gonna be very receptive to it.

So that was really more on the developer side. But a company quality we looked at was how fast did the company itself scale up. Because the faster the company is scaling, the more software it needs, probably. But, also, we filter down to specific kinds of companies. So if you're a SaaS company, for example, you actually don't build that many internal tools.

You know, you don't, need that many tools. Whereas if you're an operationally operationally focused company, let's say, like a DoorDash, a retail customer, Airbnb, a retail customer, Boeing, retail customer, or Lockheed Mart, another retail customer. These kinds of companies have a lot going on in their business, as you can imagine. And so they need more applications, and therefore, they need more retool. So that's kind of the what we focused on was we started with a few small customers in our YC batch, and then we expanded out into these kinds of companies.

Yeah. And because just because we're at this stage right now where we're, like, you know, in that, like, search for product market fit. And so it's I have a lot of questions on this just because it's very, very top of mind. But were you were you kind of as you, like, started to, like, refine, like, who the target customer is in terms of company, were you were you, like, reaching out to them directly? Were you kind of, like, trying to, like, lay, like, marketing traps as to, like, where people that, you know, were in that category would hang out?

Or, like, how are you how are you kind of expanding that?

Yeah. Let's see for a sec. I think it helped to be very specific about who our target was, but it was broad enough that it was more than one person, if that so like I mentioned on the first version of Retool, we had three components. Components. And And what we discovered was that that is versatile enough to go acquire a fair number of customers and to get them interested, and then we'd have to go build more components or, you know, other things too in order to make them more satisfied.

But we I guess I what I would say is, you know, try to start with sort of the smallest kernel of an idea that does have product market fit, but is still specific enough that you can go find people who want exactly that. And I think you're gonna try a few hypotheses just like we tried, like I mentioned. You know, you would think the FileMaker developers, you know, someone who cares about building duos in a faster way. You would think that they would care about redo, but they didn't at all, actually. And so I think we tried a few tactics like that, and I actually don't know what number, operationally heavy company was a pragmatic engineers was, but it was probably, I don't know, like idea number four.

You know? It it wasn't the first idea, if you will. And then you intersect all that. You're like, okay. So we wanna find pragmatic engineers at, operational companies that are scaling very fast.

Well, you you can find that. You know, you can go on LinkedIn. You can see, you know, companies are growing quickly. We filter those down by, who's operationally heavy. And And then to find the pragmatic engineers of them, we actually typically targeted the CTO or the cofounder and the engineering cofounder of the organization, because those are generally the most pragmatic engineers.

Because if you're, if you're starting a company, you know, you probably care about the company doing well. You care about moving fast. You care about the business, but you're also technical. So technical cofounder. Right?

So, you know, that that gives you some some way from hypotheses like that. We tested it. And oftentimes, we were wrong. Like, the FileMaker one, we were just dead wrong. Sometimes, we're right.

And if we're right, then we repeat it. And it turned out that operationally heavy companies are growing fast with technical cofounders was a, you know, there's enough of them out there that we could get enough revenue to hire some people, get to the next stage, if you will.

Mhmm. Yeah. That's really cool. It's really cool. I was trying to think of, like, how I came across Retul, and I I actually can't even can't even remember how I actually came across you guys.

But I remember that when I heard your I remember, like, the name resonated with me somehow. Because it was like, oh, like, yeah, building internal tools. And I just remember being very I think the very actually, the very first time I discovered it, was working at a start up, and I'd just seen, like, engineers spend, like, weeks. Like, like, we we were a mobile app start up, and, like, I mean, there were three of us and three developers. And one of the senior engineers spent, like, weeks.

And then, like, some of the founders were were saying were, like, unhappy with how Yeah. These internal tools looked. And they was, like they were spending so much time on just how it looked. And I remember being like, what? You know, and I was the most junior one at the time.

But I was like, what? Like, this doesn't matter, surely. Like, this is just for us. Like but a lot of people can't look at a terribly formatted table. And and I remember that there was, like, the like, lot of the like, form Formico or something, and, like, there's all these, like, JavaScript libraries for, like, forms.

It's just, like it was quite complicated, and it's just, like, really easy to get it wrong. And then you wanna put a filter, you wanna put, like, sorting, and there's all this stuff that just, like, takes a long time, like pagination. It's just, like ends up taking, like, weeks to just build, like, this little table that, like, you know which sounds crazy now, I think, with the AI stuff, but, like, it was genuinely, like so I think when I heard about it, I was like, oh. And then I came to your landing page. Was like, addressed every every problem.

So it's a long way to say, but how do you think people can kind of really tap into, like I feel like you tapped into, like, a pain very well.

Well, to be honest, I don't have a great answer to share besides the fact that it was our pain, and it turned out that more people besides us had that pain. My only advice here is and we're thinking a lot about this now as we think a lot about LMs and how powerful they are and the agent stuff that I talked about earlier. You know, that's a new product. It's not a product that a retool, a lot of our customers, I think, want it. They told us they want it, but it's it's new.

Right? It you know, it's when we launched it last year, at least, when we first launched it, certainly. We have zero customers when we first launched it. So we had to go discover, find product more fit, and now we have, which is great. But the advice there, I would say, is I think you, to some extent, have to live in the future.

You have to think about ideal in an ideal world, this problem that I have, how would it be solved a year from now, five years from now? And can I build that today? You know, the the technology exists to build that today. And for each one, we certainly could. And for agents, you can today as well.

Just to give you an example, like, you know, I use Cloud Code quite a bit myself, not just for coding, but also for automating other you know, running other things. I use the Chrome extension, for example. So Cloud is a Chrome extension that allows Cloud Code to actually control your web browser. And when you try it out, you could see the glimmer of something interesting there, where, you know, when you give it the tool of a web browser, it can do a lot. And yet, it's so hamstrung, actually, where it's often I've taken screenshots of web pages, and it's clicking, you know, particular it can't really parse the DOM sometimes because the DOM consumes so many tokens.

So it would rather take an image, screenshot. And it's like, obviously, you know, this is not the best way to create a calendar event. It's not, you know, to go into cal.google. You know, calendar.google.com and then, like, try to drag this thing and then, like, if we hold the mouse button down or hold the mouse cursor down so the dragging doesn't work, it's like, wow. Like, you know, it's that one is so smart.

It's so powerful, and yet, you know, it's missing these things. And that's actually one of the core ideas behind our agents product is what if instead of, you know, giving an LLM such course tools, you give it very specific tools and connect it to actual business data. If you can do that, then the LM can do pretty gnarly, pretty crazy things in your business, and it's really pretty impactful if you do that. And so that's an example where, I I think like, this is an example of problem that I have, and, you know, it results in the product. But, I I think you have to sort of have your own problems, if you will, and then think about, you know, how will I solve this problem?

Like, you know, to me, the LLM interacting to the world via screenshots and it being very inaccurate, being very slow, cannot possibly be correct. It has to have more specific, sharper tools, if you will. And so that's, where our industry product is going. And so that's maybe the only advice I would have is, I think, have your own problems and think about how to solve them in a future ideal state.

Yeah. Okay. I think this will potentially be the last one, Fanning. But one question I wanted to ask is, like, a lot of startup DevTools founders now that I speak to are having this kind of, like, existential kind of questions around, like, if Cloud Code can write you know, if we extrapolate and ColdCode can write code much better than we imagine now, and the product that you're selling is is code, how how do you think about, like, building kind of, like, business, you know, something that's valuable in the long run when, you know, maybe your customers can just say, like, I want this. You know?

And that's there's something that I'm seeing hearing these conversations, being part of these conversations a lot. How how do you think about that?

It is honestly a little hard to say. I think the only answer I would have there I was actually gonna share an opinion first is that I do think and we see this at our customer base a lot today. People are buying less SaaS software, including DevTools, which is a subcategory of SaaS, because they are able to build their own thing themselves. Now Retool has had multiple customers who have turned away from Salesforce, turned away from Workday, turned away from their own ERP systems into Retool. Because now with AI, in Retool, you can actually go build these applications very rapidly, especially if it's connected to data, you know, in Retul's case with security guardrails and everything.

So to be honest, I I see that happening. I would say that I think if I were a founder today in the dev tool space, I would really try to focus on a problem where it's possible to go build a moat, and the moat is strong enough that you people wouldn't rebuild you. And I'll just give two examples. One, not ridicule rated and one retool related. So one not ridicule related is Tableau, which is today, theoretically, you could maybe get Cloud Code to go build you a Tableau maybe, but or even build, you know, a dashboard of not the Tableau platform, you know, a dashboard.

But, honestly, I think most people would probably still say if you, especially if have Tableau already purchased, even if not, well, purchased. Even today, I would probably still say, I would rather just buy Tableau, pay them $25 per user per month, and have them handle everything. And let's we can go Vibe code things, but let's go Vibe code to SQL. You know? Because SQL is specific to us.

We have to do it. I don't know if I would wanna spend engineering resources, building a query caching layer, building all those front end components, building all those charts. Like, it's just not worth it. I mean, I I maybe could, but, like, would I do it? I I don't think so.

Or would I direct my CTO or VP engineering to do it? I don't think so. And so, the point I'm trying to make there is Tableau has built up a pretty strong moat, where it doesn't really make sense for, people to go do that. Maybe, you know, similar one is, theoretically, you could build cursor very easily. Cursors you know, it's almost like a Versus Code plugin.

Like, it's not I I don't think there's that substantial moat there. Yeah. Cursor's still a pretty big business. And, yeah. So does yeah.

That's kinda maybe how I would view it is I did try to make as much of a moat as you can. I think user experience is more premium now because people will be willing to pay for that. Yeah. Unfortunately, I think the cost of building yourself has gone down, and so a lot of people will buy less software, including developer tools, because they get built in themselves. And so I'm you know, on behalf of maybe I apologize because of people putting this as a retool.

So sorry. But I I do think it that happens.

Yeah. Yeah. It's an interesting time. It's fun. I don't know.

But, it is it is weird. Like, the it it definitely feels like that equation. I saw this chart. This, someone made this, like, graph that's like your PMF can kind of usually, you would have to it would kind of increase the bar would increase linearly as to what customers expect. You have to keep up with that.

But now sometimes because of AI, it just goes up and the whole path to, like, having PMF just falls out from below you because, you know, like, the agents can do it. It's interesting. I don't know.

Yeah. It is interesting. Excited to see what happens the next few months, honestly, a few years.

Yeah. Okay. And then actually related, I do want because I do want I do think, like, scaling DevTools, like, is scaling dev like, is it gonna be a thing in, five years whereas, like, people still talk about dev tools or if it's just like, you know, just tools. I don't know.

So, yeah, maybe you're right. Maybe it'll be more scaling tools, if you will, than necessarily developer tools. But I yeah. I I think it remains to be seen whether everyone wants to be a developer. I I don't I'm not I'm not confident in that.

Yeah. I I think that I think that's right. Yeah.

Yeah. It's like yeah. Even if you're we all do math. You know, we can all do addition, multiplication, etcetera, but, you know, not many of us are mathematicians, if you

will.

We all use math to some extent, but it's not yeah.

Yeah. I think that's true. David, where can people go to learn more about what you're working on over at Retul?

Yeah. So, Retul, our website is just retul.com. So come find us there.

And, have you got any shout outs you wanna make? Any, any plugs?

No. I think we have an incredible team executing on our strategy of winning enterprise application generation, so pretty excited for our whole team. But there's a lot to go and do this year, so thanks for having me on the show. Shout So out to you, I suppose.

Thanks. Amazing. Well, thank you very much, David. Thanks for listening. Thanks for creating for making it happen, and, yeah, thanks for Yeah.

Everyone.

Thanks, Jack. It was really great to meet you.

So Great to meet you.