David Hsu, founder and CEO of Retool, joins Ben to talk about low-code and no-code tools: why some folks love to hate them and whether they really help devs work faster or just allow those of us who aren’t programmers to muck everything up. Or both! Plus: How David’s philosophy degree shaped his approach to business.
Retool is a development platform that lets users—95% of whom are engineers—build internal tools quickly with a drag-and-drop interface.
Read David’s account of how Retool won early sales deals in the company’s Operator Playbook series.
Connect with David on LinkedIn.
Today we’re shouting out Stellar Question badge winner ahajib for asking How to convert a list to a dictionary with indexes as values?.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, Director of Content here at Stack Overflow. We are going to talk a little bit about an issue that we've covered a bunch of times on our blog and which often elicits a bit of a reaction. It gets some hate and some love in equal measure, which is low-code, no-code. Are these tools that help developers get things done faster? Are these tools that let citizen developers join from the marketing team or the sales team and contribute, maybe taking up less time from the seasoned engineers so they can focus on what they want to do. Or are these tools dumbing things down and maybe allowing folks who don’t know what they're doing to sort of muck up the process? So we have a great guest on to discuss it– David, who is the founder and CEO of Retool. David, welcome to the program.
David Hsu Excited to be here.
BP So we always start out, just tell us a little bit about yourself. How'd you get into the world of software and programming? What brought you to the position you're at today?
DH Yeah. I started coding when I was maybe around 12 or 13, something like that. And it was so fun. That idea that you could get a computer to do whatever you wanted to do was sort of so addicting or so empowering, if you will.
BP What were the languages and frameworks when you were first getting started? What were you using?
DH I started with Python, then I went to Lisp after reading SICP. SICP is a really fun book too, because it kind of taught you sort of the beauty of programming.
BP Yes, Lisp is for the aesthetes. That's what Paul Ford would tell us.
DH Yeah, it's fun.
BP And so did you work at some companies before founding your own, or were you always an entrepreneurial mindset?
DH So actually I ended up studying Comp Sci and philosophy, which was really fun as well. I studied that in the UK, and when studying philosophy you sort of think a bit about first principles; why things are the way they are, why they are not the way they are, stuff like that. And when in uni, we actually worked on a bunch of side projects. We were just sort of building side projects for fun, basically. And it was funny because I remember when I was learning Comp Sci, when you're learning Lisp for example, the real world applicability of it is really pretty low. I think it's sort of incredibly interesting. You can think about lists in new ways and stuff like that, but it was really not very applicable. And so that's when I started learning Rails and I was like, “I would like to do something actually with all this Comp Sci knowledge I have and maybe build some businesses.” And so we worked on a bunch of fun side projects. One of them was, if you're going to a new city and you're interested in all the destinations in a particular city, maybe you're visiting London for example. Maybe you might want to visit the London Eye, maybe you want to visit the Tate Modern, for example. Or perhaps you want to visit a cafe, and so it's almost like a traveling salesman problem basically, where we would sort of figure out what you should go to at what point in time. And you probably don't want to go to a bar at 10 AM. You probably don't want to go to Tate Modern at 10 PM. And so that was a lot of fun, and as we were working on these side projects, one discovery we had was really you spend a lot of time just building internal tools. So even just that simple project over there, we had to build internal tools to worry about sort of opening hours, restaurants, the hot restaurants would change for example, so we actually had to build a CRUD interface on top of that. And it became shocking to us how difficult it was to build a simple CRUD interface ‘internal tools’. And because we've worked on so many side projects, we're sort of building these CRUD interfaces again and again, and they all looked the same, even though the data obviously was different. In some cases mapping data for example, other cases was just names, emails, balances, stuff like that. But it was shocking how long it took and how tiring it was to build these internal tools. At that point, we were already I think using Node, and to get anything done on the backend you needed 30-40 different packages on the front end similarly, you had to go learn Redux. Redux was obviously great because I loved Lisp, but nevertheless, it wasn't clear why I needed all this knowledge about how to fold things left and right in order to get a simple button to make a post request. And so that's where the idea really for Retool was born. Maybe there could be a much faster way of building all these CRUD apps.
BP Your philosophy professors must have been very upset when you told them that you wanted to do something with all of the learning, like maybe start a business. That doesn't seem to square with my experience of philosophy departments, but I guess they let it slide. So in founding Retool, what was sort of the first problem you attacked? Clearly you had identified a pain point for yourself. What was the MVP like and how did you build that?
DH So this I think is super interesting because the MVP we built was conceptually very simple. Again, it worked for so many use cases that even we were actually rather surprised by it. Basically the MVP we built was a table, a button, and a text input. And so for those who don't know, Retool is like React but drag and drop, you could say. And we support all API authentication, stuff like that for you. And so when we first started out, we only had three components in our component system, in our design system basically, and it was a table, a button, and a text input. And it was pretty simple, it wasn't really that complex, but it was really actually quite shocking to us what you could do with just these three components. If you really squint, most internal tools are basically some combination of table, text input, and button, basically. I think our first customer was this mobile app that was an easy way for Lyft and Uber drivers to drive for both at the same time. They had a lot of customer support tickets and so they were managing all that via internal tools built inside of Retool. That basically was a bunch of tables, and then they had to refund customers via buttons. They had to search customers up via text input. They maybe wanted to give people credits also via text input. So it was kind of shocking really to us how similar internal tools were, whether it's a company building an iOS app, all the way to a tutoring company which I think was our second customer. And again, over there they were intaking students, and so students would sign up and they would tutor them. They would remark on how well they did in the lessons and stuff like that. Again, just text inputs, maybe text fields for example, and buttons. So it was really surprising to us how similar internal tools are across companies that are radically different. And that I think has really become the core thesis behind Retool– no matter what kind of company you work in, you're probably building internal tools, and the internal tools you are building probably look very, very similar to the internal tools that some other companies in totally different industries are building. The business logic is totally different. For example, we have customers like Airbnb, or a popular streaming service. These are obviously two pretty different companies. And yet when we look at the internal tools, if you really squint, again, it's just a combination of forums, buttons, tables, apps to some extent. But the business logic is different, which is why we allow you to write code as well, so you can specify your business logic.
BP So I guess the question I wanted to ask was about sort of tech debt, bit rot, and where you see maybe customers saving time internally, not just in the act of building the tools, which I think you identified. Everybody wants the folks who are handing out the picks and shovels when there's a gold rush going on, but maybe also in the idea of maintenance. Is that part of the value prop you bring?
DH It is, totally. Because the only thing developers hate more than building internal tools is actually maintaining internal tools. For a lot of our customers today, a lot of the value prop is, “Hey, I built it and I actually know it's going to continue working. In fact, it's actually going to get better every day,” because Retool ships new features to our customers.
BP I don't want to call us out, but as someone who joined Stack Overflow 10 years into its life, I was amazed at the number of things we'd built on our own from email to billing, stuff like that, and I just wondered why it wasn't off the shelf. In part, that was an engineering culture, a mindset of, “We're a place where we want to have top engineers and so we're going to build it ourselves.” But I think over time we've increasingly shifted to the best practice of buy what we can and build what we need.
[music plays]
BP Turn compliance from a burden to a business accelerator with 24/7 continuous monitoring. Automate evidence collection for your entire tech stack with over 75 deep integrations. Book a demo at drata.com/partner/stackoverflow. Make sure to use that link, and you’ll let them know the podcast sent you.
[music plays]
BP All right. So let's get to the no-code, low-code side of this. Where does this come up? You said you feel people sometimes misunderstand your company. Do you think that sometimes when you go to make a sale to a new customer there's resistance internally from the engineering department who's like, “Hey, we don't want things dumbed down. This would be better if we build it ourselves.”
DH Yeah, so something like maybe 95% of our customers are engineers, and people building apps overall are all engineers inside of Retool today too. And so we've actually trained as Retool has grown over the past few years –today we’re around 350 or so people– we've actually trained all of our salespeople to never say the words ‘low code’ or ‘no code’ actually. And it's funny because I think no code basically is a dead end. And the reason for that is you are able to get to 50% of what you want really very quickly via no code. So it's great for that, but then the last 50% is basically impossible actually. Let's say you are a company using something like Airtable. Airtable is really fast to get started with. You can prototype, you can do things really quickly. But then when you actually want to build complex forms or complex front ends on top of Airtable, you’re in trouble. The only way you can really do it is you can try to integrate with the API, but the API has a five requests per second rate limit. That's honestly quite a bit worse than a Postgres database, for example. And so you're like, “Okay, well I guess I'm kind of stuck. This is how much I can do.” And the only way to say, “Okay, well actually I'm going to migrate all my data to a Postgres database now, or MongoDB or whatever else, and build everything again from scratch.” And so for that reason, we think most software is pretty complex, to be honest. And the only way to build this complex software is actually by writing code. We think code is the best way of getting a computer to do something, which I think is maybe a pretty controversial belief, at least for non-developers at least.
BP So you and I talked a bit about internal components and how those might be similar at companies. That was kind of the spark that set you off on building this company. But now you have a much larger suite of that from workflows to databases, templates to self-hosted. Can you talk a little bit about how the business has evolved over time and what you do in some of those other areas?
DH Yeah, totally. So what we've discovered is as developers have adopted more and more of Retool, they actually want to do more things inside of Retool. So I would say sort of the core thesis behind Retool is that a lot of things that developers work on should actually be commodities. For example, you shouldn't have to Google around for the best React Table component. We should just give you the best React Table component. When you're making a post request from a button, you shouldn't have to worry about setting, “Is fetching to be true” inside of Redux, and then when fetching is true, show a loading indicator on the button, and then when it comes back with an error, show the error message. You shouldn't have to worry about trying to bounce the button so it can't be clicked twice so the form submits twice. These are all basic things, basically, and so we want to give you all these things out of the box so you can actually focus on business logic that's specific to you. So if you are a specific customer, whether you're an Airbnb or an Amazon, what is specific to them is actually not the button. It's not setting is fetching to be true. Instead it's the core business logic of how the insurance program at Airbnb works. So that to us is what we really focus on. We allow developers to focus on the code and then not focus so much on the commoditizable stuff. And that's true of front ends, but also true of back ends, which is why I started Workflows. So with Workflows it's a similar insight to the front end, which is getting a cron job to run on a regular basis and making sure it never goes down is actually a surprisingly hard problem. Because let's say you have an EC2 instance, for example. How do you monitor that EC2 instance? What if the cron job starts silently failing? How do you get notified, et cetera, et cetera? These are the kinds of problems we've realized developers also had on the backend, which is why we launched a Workflows product, which is sort of cron in the cloud, basically. Where there are errors, we immediately notify you. You can go and browse results from past runs so you can go debug things nicely, et cetera. So that's how we expanded up into Workflows and how we expanded to mobile and DB and storage as well. So now Retool is a pretty fully-featured platform.
BP So how many employees do you have at the company now roughly?
DH Today we're around 350 or so.
BP And what has been your take and maybe some of your employees’ on the latest turn of the wheel? You talked about how far you think no code can go and that code is the best way to communicate. What about all this brouhaha I see on Twitter of people just telling an AI, “Hey, go build me this button and while you're at it try out this back end,” and it spits it back some code and you can test it and you go from there. Do you think that that's something that people will actually be incorporating into their companies in the near future and do you think there's ways that maybe Retool can take advantage of some of those advancements?
DH I think totally, and we're investigating that right now. We have a bit of a research project going on right now actually inside of Retool. My take on this AI stuff is, I think it's very good for getting you started, in the sense that you still do need to know what code is. It would be I think difficult for someone who doesn't know anything about code to specify to an AI, “Oh, I want a program that does this and does this,” and for you to sort of explain the nuances. I think again, code is actually the best language. And if you look at AI also generating code, so you can read the code and iterate on it. And so we think AI is a really big accelerant in getting a V1 for example. But then, as we know as developers, getting to 80% is kind of not the hard part. You can build 80% of any big website, of an Amazon or a Netflix or whatever else or Airbnb, you and I could do it in a weekend if we really wanted to. We could build 80% of any of those websites. In the end, the really hard stuff is the last 20%, the real customizations basically. And that is, I think, where you still will need to know code, because you're trying to get a computer to do a highly specific thing that cannot have any ambiguity.
BP Let me ask you from your perspective where you sit, what are you most excited about in the year to come? Are there things on the roadmap you want to tease or just developments within the space that you think are exciting that you might be able to capitalize on?
DH Yeah, so one thing we're pretty excited about is launching some sort of app store on top of Retool. Today if you think about software, –sorry, this might be kind of philosophical for a bit– but if you think about software, it's either basically build or buy. So you either build something entirely from scratch, sounds like you guys have done it at Stack Overflow, or you buy something off the shelf. And when you buy something off the shelf it’s generally cheaper, but it's probably not custom specifically to what you want. And if you build something internally, it takes a long time but it is exactly what you want. So what we're really excited about at Retool is, what if Retool can give you a template or a good starting point? And so one example here is that Stripe uses Retool actually for equity management. I bet there are a lot of other pre-IPO companies that are very interested in how Stripe manages their equity. Wouldn't it be really cool if we had an app store where you could go and see the Stripe app and you could say, “Hey, actually that's 80% of what I want. Let me go and fork it actually and take things that I like from there, but then change it 10% and add 10% of things onto it.” So it's almost a sort of GitHub for enterprise software. GitHub is great right now for libraries and the building blocks of software, but it’s actually not very good for fully-built applications. And so, that I think is something that's really exciting, that Retool today now has many customers that have a lot of internal operations, and actually these internal ops across all of our customer base is actually kind of similar. And so for us to open up some sort of app store I think would be really exciting. It'd be somewhere between build and buy. As fast as buying something off the shelf, but also as customizable and as flexible actually.
BP Yeah, that makes a lot of sense. We did an episode with the folks from Backstage, which was the developer portal that they built at Spotify, and they found when they would go out to these tech conferences and they were showing off something they built, what people wanted to see was not the feature that they had built, but the thing behind it that they were using to show it off. And so now it's open source to the degree that lots of folks can come in and try it out as their developer portal or build integrations with it. So I guess in a similar way you're thinking about it for Stripe. The advantage would be showcasing their technology, making a little bit of it open source, and that burnishes their brand, maybe attracts new technologists to come to them, or maybe even people improve on it a little bit and they notice that and can do it in-house.
DH Totally, yeah.
BP Well I think that is a good place to wrap. It sounds like an exciting thing. Do you have a sense of when the app store would arrive or this is just kind of something that's coming in the year 2023?
DH In the year 2023. Well, we're super excited about it.
[music plays]
BP All right, everybody. Thank you for listening. That was a fascinating episode. As we do at the end of every show, I'm going to shout out the winner of a badge– somebody who came on Stack Overflow with a little curiosity or a little bit of knowledge and helped a bunch of others. Awarded two hours ago to ahajib, a favorite question badge. They've asked a question that's been saved by 25 users, so it must be worthwhile to a few people. “How to convert a list to a dictionary with indexes as values.” Asked six years ago. 140,000 people have viewed, so helped quite a few folks. Appreciate it, and congrats on your badge. I am Ben Popper. I am the Director of Content here at Stack Overflow. You can always find us, podcast@stackoverflow.com. Email us with questions or suggestions. You can always find me on Twitter, I'm just @BenPopper. And if you want to leave a rating and a review because you like the show, go ahead, it helps. David, tell the folks who you are, say your full name, your title again, and then where you want to be found on social media if you want to be found. And then give a shout out to where you think listeners who are developers or engineers, where should they go to check out Retool or to try a demo or to learn? Just whatever call to action you think is best.
DH Hey, I'm David Hsu from Retool. You can find me on GitHub or Twitter @DvdHsu or at Retool.com. Thanks.
[outro music plays]