Retool founder David Hsu: AI, future of DevTools & how Retool got their first customers
Retool founder David Hsu on infiltrating a FileMaker developers' LinkedIn group to find early customers (three said no, one wanted to explain why the idea was bad), why he thinks the definition of "developer" keeps moving up the stack, and why he'd only start a dev tools company today around something with a real moat.
David Hsu is the founder of Retool, the platform used to build internal tools at companies from Amazon and Airbnb to the US Army. He and his cofounder started it in 2017 after getting frustrated building admin interfaces from scratch — Rails had ActiveAdmin, but nothing else really did.
We get into how they found their very first customers after friends and a LinkedIn-infiltration attempt both failed, how AI has shifted Retool's target user from professional developers toward what David calls "tomorrow's developers," why he thinks front ends themselves might eventually disappear, and his advice for DevTools founders worried about Claude Code eating their product.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did Retool actually start — what problem were you personally hitting?
My cofounder and I are both engineers who'd built a lot of internal tools in previous jobs, and it's remarkable how rote it is — make a new Redux store, make a new table, figure out the columns, wire up the submit button, oh wait I wanted a loading indicator on that, how do I do that. I came from a Rails background, and Rails made this so easy with something like ActiveAdmin — it already has your models, so it can generate views and handle auth for you. Then we built an app not in Rails, maybe in ClojureScript, and needed an admin interface for it, and there was basically nothing available outside a couple of specific frameworks. We considered building a code generator instead, but decided code gen is too brittle — you have to regenerate every time you add a table or a relationship — so we built a framework instead. The idea was: can we let you write only the 10% of code that's actually specific to your business, since the other 90% is boilerplate you're rewriting every time.
What did the very first version look like, and how long did it take to build?
Very bare bones — despite internal tools doing wildly different things, they mostly look the same underneath, so the first version had three or four components: a text input, a table, and a button. That doesn't sound impressive, but most internal tools are really just combinations of components like that put together. We added charts and maps later, and someone interviewing with us even built a microphone component so you could record sound. That first version took a few weeks to build, and then we just started asking people if they'd use it.
How did you actually find your first customers? I heard there was a FileMaker LinkedIn group involved.
We started with friends, but it turned out most people aren't building an internal tool at the exact moment you ask them, so that mostly failed. Then we tried another angle: we figured Retool was similar in spirit to FileMaker, an older tool for building simple UIs without much code, so I joined a LinkedIn group for FileMaker developers pretending to be one myself, and messaged people saying I'd built something like FileMaker but in the cloud, would they use it? We reached out to something like 100 to 200 people and got about four replies — three of them were flatly not interested, and one wanted to hop on a call specifically to tell me how bad the idea was. It was a pretty uphill start. We ended up finding our first two real customers through Y Combinator instead, talking to other companies in our batch who were building admin panels and didn't want to spend the time doing it themselves.
How did you refine who your ideal customer actually was?
We got specific about the qualities that predicted a good fit. On the developer side, more pragmatic engineers who cared about business outcomes liked Retool more; very dogmatic engineers, say a functional-programming purist who only writes Clojure, tended not to be receptive to it. On the company side, we looked at how fast a company was scaling, since faster growth usually means more internal software needed — and we filtered toward operationally heavy companies like DoorDash, Airbnb, Boeing, or Lockheed Martin, rather than pure SaaS companies, who just don't need that many internal tools. We usually targeted the CTO or technical cofounder directly, since they tend to be the most pragmatic engineers — they care about the business doing well and moving fast, but they're also technical enough to get it immediately. We tried a few hypotheses like this before landing on the right one — the FileMaker idea was just wrong — and once we found one that worked, we repeated it until it brought in enough revenue to hire and get to the next stage.
You've said if you're not a developer, you probably shouldn't start a dev tools company. Why so strongly?
Honestly, I don't have a great strategy here beyond the fact that we are developers ourselves, and I haven't tried starting a company where I wasn't the target customer — I think it would go a lot worse. A lot of what I do, the features we build, the copy we write, is only possible because we understand developers so well, down to knowing exactly how painful it is to learn Redux for the first time. As a developer myself, I can tell very quickly if a tool isn't for me, and I bounce immediately if it's not — so if you're not a developer building for developers, you're going to struggle to build and market the right thing. As the company scales you obviously need product marketing that can talk to developers even if they aren't developers themselves, but to start a dev tools company, you have to be a developer, and outsource as little of that understanding as possible early on.
How has AI actually changed who builds in Retool?
Retool used to be entirely geared toward professional developers — four years ago, about 95% of people building in Retool were developers like you. Today it's around 60% non-developers, and that shift started even before LLMs, though AI has clearly accelerated it. We think roughly 100% of internal, production software — apps that write back to a database or an API and help run your business — will be built by non-developers within the next two to three years. Developers will still matter for genuinely complex, consumer-facing work: Airbnb uses their own engineers on their beautiful mobile app, but they use Retool internally for things like processing insurance claims, where the alternative is a spreadsheet and a developer's time really isn't the best use of it. So we now target what I call tomorrow's developers — not totally non-technical people, but Excel power users, people on data or RevOps teams who can write SQL and maybe a bit of code if they had to. My broader thesis is that programming keeps moving higher up the stack — from assembly to C to JavaScript — and every step up brings more people into the tent who couldn't or wouldn't have programmed before. I don't think the Excel power user and yesterday's professional developer, who today is often using Claude Code and still has to read the code it produces, are really that different anymore — they're converging from opposite directions.
Front-end applications used to be your whole business. Now your fastest-growing segment is agents and automations. Why the shift?
My take on AI right now is that LLMs are already extremely smart — probably better than you or me at almost any specific task — and yet outside of coding, they're surprisingly hard to find great uses for in most people's day-to-day work. I think the missing piece is that LLMs don't have arms and legs; they can't go do things in your business. Something like Claude Code works so well because instead of you acting as the API between ChatGPT and your IDE, copying errors back and forth, it just lets the model act directly. If you bring that same idea to every job, not just coding, letting an LLM send the email, make the call, update Salesforce, touch your database, that's where it gets genuinely powerful. So Retool has shifted a lot of focus toward giving these models very specific tools connected to real business data, rather than blunt general-purpose tools. I use Claude's Chrome extension myself, and you can see the glimmer of something powerful there, but it's often hamstrung — taking a screenshot and clicking around a webpage because parsing the DOM eats too many tokens is obviously not the way you'd want an agent creating a calendar event. Give it specific, sharp tools instead of a screenshot and a mouse, and it can do genuinely impressive things in your business.
You think front ends might eventually 'go away.' What do you mean?
There are rumors OpenAI is working on a device to rival Apple with no screen at all, and if you think about it, you don't actually need a screen for a lot of what you do. You could imagine AirPods as your computing interface, always with you, listening, and you just tell them what you need — "I just got off this call with Jack, here are the next steps, go do those" — and it calls an LLM connected to your email or your database and just does it, no front end involved. A screen is still useful for checking work, because you can usually scan information faster than you can listen to it, but as the correctness of these systems goes up, the percentage of things you feel the need to check goes down. Something simple, like making a dinner reservation, you'd probably just trust the result and move on.
A lot of DevTools founders are having an existential moment about whether Claude Code will just let customers build what they were going to sell them. How do you think about that?
I do think this is happening — we see customers at Retool itself moving off Salesforce, Workday, and their own ERP systems because AI now lets them build what they need themselves, quickly, especially when it's connected to their own data with the right guardrails. If I were starting a dev tools company today, I'd focus hard on a problem where you can build a real moat, strong enough that people genuinely wouldn't just rebuild it themselves. Tableau is a good example outside Retool: in theory you could get an agent to build you a dashboard today, but most people, especially if they've already bought Tableau, would still rather pay $25 a user a month and have Tableau handle the query caching, the front-end components, the charts, everything, rather than point engineering time at rebuilding all of that. Cursor is an interesting counterexample — it's almost a VS Code plugin, arguably not that hard to rebuild, and yet it's still a big business, so a moat isn't the only thing that matters, but user experience is becoming more of a premium people will genuinely pay for. Overall, though, I do think the cost of building things yourself has gone down enough that people will buy less software across the board, including dev tools, because more of it gets built in-house.
Links & references
This episode is brought to you by WorkOS.