EPISODE 1703

[INTRODUCTION]

[0:00:01] ANNOUNCER: Retool is a platform to help engineers quickly build internal front-ends. It does this by abstracting away repetitive aspects of front-end development. The platform was started in 2017 and has received funding from Sequoia, Strike co-founders, and Nat Friedman. David Hsu is the Founder and CEO of Retool. He joins the show to talk about why he started coding, studying philosophy and computer science, Retool's tech stack, and more.

Pawel is a tech lead and a software engineer with a background in launching products and startups and big companies. He's also the founder of flat.social. Check out the show notes to follow Pawel on Twitter or LinkedIn, or visit his personal website, pawel.io.

[INTERVIEW]

[0:00:55] PB: Hi, David. Welcome to Software Engineering Daily.

[0:00:58] DH: Hey, really excited to be here.

[0:00:59] PB: Let's kick off with the first question. What is Retool?

[0:01:02] DH: Yeah. Retool is a fast way for engineers to build internal front-ends. The idea is that we as engineers, I'm an engineer too, we spend a lot of our time basically doing repetitive things on the front-end, especially for internal tools. And so, Retool could have stressed a lot of the stuff away.

[0:01:19] PB: You started Retool, and I was wondering in the early days, how did you get into programming and what were your first steps in the software industry? How did it start?

[0:01:29] DH: Yeah, so that's pretty interesting. Let's see, when I first started programming, I was initially maybe, I don't know, between the ages of 10 and 13, more of a gamer. When I was gaming, I eventually got into building my own PCs, basically. This is just putting things at the motherboard, loaded the motherboard into the chassis. Pretty basic stuff, basically. At some point, I was like, "Well, this hardware stuff is pretty interesting." I was overclocking my PC. I was trying to undervolt it a little bit to keep the heat down, etc. I was doing all those fun hardware things. At some point, I was like, "Hey, it would be really cool, I should get to the software side, too."

The reason for that is mostly because I was - this is going to sound trite, but it really is true, I looked at some of the impact the software was having on the world. At around this time, this is probably when the Arab Spring happened. If you remember this what Twitter was taking over the world, and it was remarkable to me that Twitter, which was a company, I think not that big at that point, maybe 1,500 people or something, was in San Francisco, which is actually not far from where I grew up, actually toppling a dictator halfway around the world, actually. I was like, "Wow, the impact of software is really phenomenal." If I want to create a positive change in the world, software really seems like the way to do it.

That's when I started thinking, "Hey, I should learn how to code, basically." When I first learned how to code, I wanted to say that I first learned via a book called SiCp. It's, I think, the Structure and Interpretation of Computer Programs. It basically teaches you how to code and at Lisp, actually. Lisp was a pretty interesting language, because it's not super practical. I think people use closure and closure script today, but Lisp itself is scheme, I should say, is not a super practical language to be coding in today. But it really actually taught me the fundamentals of programming, which is really interesting. Actually, then I, a few years later, I went on a study compsci philosophy, actually, at Oxford.

At Oxford, actually, the first language they teach you there is actually Haskell. That was also pretty interesting first language. The second language is Scala. Scala is functional and Java-like in some ways, too. Functional programming is actually still one of my passions, if you will. Just yesterday, for example, I think there was an article in Hacker News about currying, for example. It's reminiscing about how cool currying is in Haskell, and it's too bad that - Well, actually, a lot of - It's funny. There are a lot of comments on that article saying, currying is stupid and it makes code really difficult to read, and Haskell sucks. To me, it's at least it's a program language to learn from. It's really interesting, because it's a totally different paradigm, if you will.

[0:04:00] PB: Did you find like, you and your older classmates that you have in the beginning was a big change for you to think the Haskell way? Or did you grasp it quickly?

[0:04:08] DH: I actually don't know what percent of the compsci class knew programming before. If I had a guess, it's 50-50, honestly. Actually, I think a lot of people who were studying CS had not actually coded anything before. For them, it's like, well, Haskell is just the way you code. Then actually, going to something like the more imperative language thinking like a scholar was actually shocking. It's like, what do you mean? You should tell the computer to do things? Is that just declaring it to be so? That actually was a little bit stranger, probably going for functional declarative. I think most people did not have that much coding experience, actually.

For me, I think after I learned Scheme and Lisp, I think I then did learn Python. Python was, I think, a lot easier to code in, but it was, like to get any problem done, basically. I actually found it far less interesting, because I think it's far less mathematical, if you will. When you finish a Scheme program, you feel really good about it. If you finish a Python program, it's like, "Oh, cool. Okay." Am I proud of the code? It's okay.

[0:05:07] PB: How did you find, because you said you studied computing science with philosophy. I don't know if in US you can have combinations like this, because I know that in UK, it's quite common. For example, my degree, which was in AI, had two first years, we had all of the psychology courses. We did all the modules in psychology, which was very interesting. I see a little bit maybe of a similar thing here. How did you find studying philosophy with computing science and how did it affect your maybe, thinking in the future? Just, was it different?

[0:05:36] DH: Yeah. That's actually the main reason why I ended up in the UK for university was because of the degree specifically. I was actually pretty lucky to have found it, because compsci and philosophy, I think it was the year I did it, it was actually the second year it was ever offered, actually. I think maybe Oxford has introduced maybe two degrees in the past hundred years. I was really lucky that I just got that extra time. If I were born three years earlier, then I would not have been able to study it, actually. That was really quite lucky.

That was actually the main draw was that it was actually one degree, which is when you study, perhaps, it was really cool, because I think in the US and the other schools, you can actually choose to major in two things if you really want to, if you're ambitious, for example. The two things that you choose to major on, they're not really going to be related. You're not going to have many courses in the middle if you are covering the two separate majors you chose.

Whereas, actually at Oxford, this specific degree actually has one degree. It was computer science and philosophy together. That was really quite interesting to me, because I had always wanted to study - I had actually wanted to major in philosophy. I actually was probably on that path, actually, of wanting to major in philosophy and actually not compsci. The reason was I had already taught myself how to code, and so figured that teaching yourself to code was not that hard, and so, I didn't necessarily need to study it, basically.

Whereas, philosophy, it seems like, it's going to be more discourse-based, for example. Actually, having other people study it with and talk about it with would be more interesting. Whereas, with compsci, you run programs, you compile them, it's correct or not. Then I found this program, and I was like, wow, this is really what I want to do. People oftentimes ask, what is the intersection between computer science and philosophy? Because it's not obvious to some people, actually, where the intersection is. The intersection is probably in two places. One, sounds like you're very familiar with, which is AI. AI was much less hot back in the day.

Back in the day, I think it was mostly around machine learning. It was what most people were interested in. I think in 2013, when I started studying it, I think that's when neural nets have just been able to score relatively high on MNIST. MNIST was the handwritten digits. You basically, people handwrite one, two, three, four, five, all go up to nine. Then neural net can recognize it. That was the state of the art for machine learning. It wasn't as hot as it is now.

Specifically, what the intersection between compsci and philosophy as it relates to AI was basically, what are the limitations of a computer? And can a computer think? That's actually really quite relevant today. Because if you look at the Turing test, for example, I think Alan Turing said that if you can converse with a computer and the computer types responses back to you, and you as a human cannot tell if it's human or computer, then the computer has achieved human level thought, basically. There's no difference with a computer and human.

Today, I think what LLMs they certainly have, so the LLM certainly pass the Turing test without a doubt. Actually, at this point, I sometimes suspect the humans I interact with actually are computer actually. It's got to turn around, it's funny.

[0:08:20] PB: Yeah, it can think, doesn't it?

[0:08:22] DH: Yeah. That I think is one area, sort of, what is the limitation of a computer, basically? Are humans just biological computers, if you will? That's one pretty interesting area. The second really interesting area that I'm actually more passionate about is actually logic. Logic is basically the underpinnings, if you will, of both philosophy and computer science. For example, philosophical logic, maybe the most simple version of it is trying to formalize concepts about the world. Maybe it's like, hey, the sky is blue. It's P and Q is the sky is red, for example, and P and Q are contradictory. P and Q cannot be true together, for example. That is the underpinnings of logic, philosophical logic, but also the underpinnings of computer science, actually. If you think about how computers work, actually, it's really quite comparable.

[0:09:05] PB: I think it's an interesting - and the parallel paths, but they do cross occasionally, right? It's an interesting thing to study. I was wondering from all of this, how did you end up working on Retool? Where did the idea come from? What was this beginning of Retool as an idea and as a company?

[0:09:22] DH: Yeah. Retool started mostly because my co-founder and I were both engineers, and we were working on a bunch of side projects. Every side project we worked on, we always did a good build and parallel tools for. To give you an example, one of the side projects that was the most successful one was we basically launched a P2P payments product in Oxford. If you're from the area, you'll know that in the UK, for example, it's actually quite hard to send money back and forth, actually. I think today, nowadays with Monzo, for example, the revolution, it might be a bit easier. Traditionally, people sent money, it's basically by memorizing the account number and a sort code, basically. You send the money and the money, I think, takes two hours or something to arrive, typically.

One of our ideas was, hey, what if we made a faster electronic way basis of sending money? We can keep balances in the app and then sending money is just incrementing, or decrementing a balance. It's effectively instant, basically. We did that. We built it and we're like, hey, for fun, now that we've built it, might as well launch it, basically. So, we launched it. What's really cool is actually, we got actually got 70%, 80% of the school, actually, the university actually using it. It's undergrads, at least, using the product weekly. That's pretty cool.

Then we quickly realized that now that people are using this product, we have to go build internal tools for it, actually. That project probably lasted somewhere between three and six months. I think we literally spent half our time, if not more, literally building internal tools, just day in and day out, basically, the tools you can imagine. Tools to, for example, manage withdrawals, tools to manage fraud. There's a lot of fraud, as you can imagine, with a P2P payments app. We built all tools to go detect fraud, for example, to see the network, basically, who's sending money to who and stuff like that. We're building all these tools. We've built a bunch of tools before too, along with this front-end CRUN apps, basically, before for other side projects. We quickly came to the realization that actually, building these tools is extremely repetitive and it's extremely boring.

I think if you ask most engineers, for example, well, part of the job that they hate the most as a software engineer, honestly, it's probably writing tests and building internal tools. That's probably it, actually. The reason why both these are so boring, or why both these tests are so hated is because they're so repetitive. Specifically on building internal tools, one thing to think about is, if you think about building, let's say, a form, for example, that somebody's post request your back-end API, for example, like a pretty common internal tool, internal UI, if you will. That form is actually surprisingly hard to build.

It's pretty easy to get a initial version working very quickly. If you use HTML, for example, it's very simple to get a form going. Then let's say, you want to display a loading indicator, for example, when you press the submit button, hypothetically, because you don't want people pressing the submit button five times, it's submitting five times, right? Like, hey, well, I want to disable the show a load indicator and disable the button. Well, to do that, you can't just use a predetermined amount of seconds, or milliseconds. You just have to say, "Hey, I need to track state," right? Now, you need to track, actually, is the API request pending, for example.

Once you're doing this in React, you're like, okay, well, now I've got to go import Redux, actually. Redux is a pretty complicated library to understand. Let me track at Redux, I've got to track its fetching in the Redux, for example. Then let's say, it displays an error message back, for example. Okay, well, now I've got to track the error message of Redux, for example, and then I've got to go find a toast library, for example, to go display the error message. Maybe I've got to worry about authentication to my back-end point, because there's authentication, probably where you have to worry about authorization. If you're like, "Hey, I want certain people to be able to submit this form, but not everyone, for example." It's not for authorization, but front-end, for example. There's a lot of work, basically, that goes into building a pretty simple form.

The really annoying thing about this is actually, all internal tools, every form you build needs these similar things, right? Every form you build probably should have a submit button that gets disabled after you press it. You should probably go display error messages and with a toast, for example. That's what gave us the idea of a Retool, which is why is it that we're coding in such a low-level way? Is there a higher-level way of coding? That led us to basically, the Retool.

One thing I will add, which I think is pretty interesting, and it's a common misconception about Retool, is that Retool is probably, I think, 90% of the time used by software engineers. This is actually very controversial. We first got started, because people would say, "Hey, software engineers already know how to build internal tools. Why are you making it better for them? Why not allow everyone to go build internal tools? Why not go allow non-engineers to go code, for example? Why not democratize software engineering, which sounds really pretty sexy?

For us, our hypothesis, I mean, we were software engineers ourselves, our hypothesis always was that actually, if you build something a no-code tool for non-engineers, you basically, really lose out of power and flexibility. That's actually why engineers hate these no-code tools. I'm an engineer, too. I hate using a no-code tool. The reason why that is because I know it's not going to be powerful enough. I know that when I need to do something that is even slightly more complicated than what the company had in mind, I'm going to hit a brick wall, basically. An example is, let's say, there's a Zapier, or a no-code tool, for example, let's say that I want to branch on if the input is even or odd, for example, which doesn't sound that hard, I better hope that in Zapier, they have an even or odd function, because if they don't have an even or odd function, I'm screwed. I can't use Zapier anymore, basically.

Maybe they have the even or odd function. Maybe I want to say, hey, can I mod 7 it, for example? Well, they probably don't have a modulo function. Maybe they have even or odd, but they don't have mod 7. Then it's like, well, I hit a brick wall. I can't do anything, right? We as an engineers, really hate it. That sort of feeling of being boxed in, or not having power and flexibility. With Retool, we actually very intentionally focus on software engineers. The hypothesis, basically, is that we can get you to 80% of what you want very quickly. The last 20%, we always give you the escape hatch, where you can always write JavaScript wherever you want, basically, or go import your custom React component, or go write Python even. For us, we're quite engineering first, which is actually very surprising to a lot of people.

[0:15:04] PB: Would you think that simplifying the complexity of building software for the people who cannot code, who create even more complexity and open a Pandora box of maybe different issues and problems, and the product would get massively complicated?

[0:15:21] DH: Exactly. Yeah. The way we think about it is that there is irreducible complexity in programming. Code is the best way to attack that irreducible complexity. For example, like the mod 7 thing, right? If you have to do that in a visual way, let's say it's Zapier. If it was possible, you would be like, "Okay, we'll have a node. Maybe case one, go over here, case two, go over here." It's so complicated, basically. Whereas in coding, it's very easy. You can just say, "Hey, I don't know, N equals the variable mod 7," for example. Then you say, "Hey, switch N, and then case one, case two, case three." It's so much simpler to write that in code than to try to use a GUI to write that, basically.

[0:15:56] PB: You're trying to end up with a massive tree and almost like -

[0:15:59] DH: It's hard to read and it's hard to reason about and it's hard to fold the code. Code is actually really quite good. We just think there should be less of it. I think an analogy here that we often tell that actually customers sometimes tell us, is if you think about programming 30, 40 years ago, for example, I mean, I've programmed assembly myself, too. I don't know if you have, but assembly, it's pretty hardcore. You go write assembly if you want.

Honestly, in most cases, you don't need assembly. Most programmers today would argue, you're not programming assembly anymore. If you're building, let's say, I don't know, maybe if you're programming the International Space Station, for example, maybe you're very memory constrained, for example. When you're working in tech, that's the computer itself, that's the chip that's running it as a few years old. Maybe you have to program it a very specific, very low-level way, for example.

Most engineers are solving business problems. Don't need to be programming a low-level way, basically. If you look at the evolution of programming languages and move from assembly to, for example, interactive terminals and then higher-level languages, like a C, for example, actually C++, like a Java, something like that. Today, like a Python, Ruby, JavaScript, these are much higher-level languages, basically. If you think about it, though, in the past 20 years, it actually has not been another leap for programming, basically. The idea is that, might we look back at engineering today, or programming today, the way that we look back on assembly, for example, today, which is in 20 years' time, people are like, wow, I cannot believe that they used to program in such a low-level way, where I was just so worried about, hey, let me go make sure that when I press the button, I set its fetching to be true. Then when API request returns, I set its fetching to be false. I capture the error message, and it's playing a toast. What if you don't have to worry about any of that, so you can actually focus on what is specific to you and your business, actually, or your problem, which is probably not like, hey, how do I track the state?

Instead, it's actually, hey, what should be going in the form, for example? Will the form for this error? What should I display to the user? That is code that is specific to you and your problem. That's the code that you should be writing. All this other stuff, it's boilerplate, basically. There's no reason for you to be writing it. That's the core idea.

[0:17:56] PB: We can use it then and to create new bugs, just be building, or building, or building. It doesn't matter if you build a foreign 20 times in the past year. There's still possibility to introduce new bugs. If you have a tool that's a little bit higher level, I would imagine that not only speeds the work and the speeds that work up, but also removes an entire spectrum of issues that could happen. 

[0:18:16] DH: Totally. Yeah, exactly.

[0:18:18] PB: This include complicated elements, like tables.

[0:18:20] DH: Yeah. The really cool thing is that we can give you actually good defaults, so you know, speak of the table component, for example. Tables are, as you just noted, they're really complex, especially when you load a lot of data into it, for example. You have to worry about how do I virtualize rows? How do I virtualize columns for big data sets, for example? How to filter it? How to do group buys? All these things are actually pretty hard things. But if you use Retool, we actually can give you all these defaults out of the box.

I think one interesting thing about Retool, too, is that we are really only focused on internal software and internal UIs. The reason for that is we think React might actually be the correct level of abstraction if you're building something really complicated. Let's say, you're building airbnb.com, for example, which is a pretty complicated website. It's got to be highly performant. It's highly customized. The design has to be just exactly perfect. Animation is exactly perfect, etc. In those cases, actually, maybe React is a perfect for the job, because you need to customize in a really deep way.

However, if you're building Airbnb's internal tools, do they need to be as perfect as airbnb.com? Probably not, actually, because a lot of the internal tools, actually, as a customer of Retool, a lot of their tools are actually in spreadsheets. In spreadsheets, it's super easy to make mistakes. The reason why it's in spreadsheets is because they don't have time. They don't have the engineers to go build good software via actual programming, basically, and build actual applications as opposed to spreadsheets. That's what Retool is really tackling is, is there a class of software? And we think there is. Is there some percent of software, basically, that we think could be built in a higher-level way? That's effectively what Retool is focused on.

[0:19:47] PB: I have worked on internal tools, actually, with very old and long-lasting corporations. I have seen those monstrous Excel spreadsheets many times. Quite often, we've been called to, okay, here is this very intelligent employee that we have, but it's not their job to code. The only tool they had at their disposal was Excel. Also, they just put all their mind power into creating the most complicated Excel spreadsheet that could have been solved with software, but instead is solved with Excel. The use of Excel, even for internal tools, I think it's pretty high, still.

[0:20:20] DH: It's super high. I mean, probably some large percent, maybe 30%, 40% of internal tools that people are building in Retool today are basically replacing Excel spreadsheets, or spreadsheets more generally. I think what's weird, I mean, I'm curious to hear your thoughts on this, too, is that so many of these older companies literally run of these spreadsheets, even though the technology behind React, for example, even databases have been around forever.

I think, it's just like you said, there's such a large class of people who are able to code in Excel. There are so many Excel spreadsheets that are already built, and they're so hard to maintain, but it's just what exists. People just has a lot of momentum, if you will. I mean, as you know, Excel is really crappy. It's very easy to make a mistake, if you accidentally press one wrong button, for example. It may not be obvious, but your whole spreadsheet might actually be broken. Or maybe it's sitting as mistakes you can make if you add an extra zero, for example. I think there's so many stories of businesses making huge mistakes, because they add an extra zero to the spreadsheet, for example. That, I think, is the power of software. Yeah, it really should be running a business custom software, not spreadsheets. It's just that custom software today is so expensive to build, and so boring to build for an engineer, too.

[0:21:30] PB: I would imagine quite often, given that how expensive it is to build software and the amount of time that you need to invest. Also, the amount of proficiency you need to have to build, for example, front end, like using React. You cannot expect a business analyst to go and just build amazing React application. I think quite often, what might happen within those teams is that somebody has a problem that they need to solve, but they are not, for example, within a large corporation, they would need to ask for a developer to be assigned, or a development team to take care of this. They want to be more independent, so they grab the tool they have on their hand, and they do the best with what they have. Then just pile up more and more things on top of that Excel spreadsheet.

[0:22:09] DH: Yeah, totally. I'm trying to think what the biggest Excel spreadsheet Retool replaced. It's probably been the orders of hundreds of megabytes, actually. You can imagine, that's a pretty big Excel spreadsheet. You can imagine, if you actually have a custom UI for that and actually, with the data in a database, for example, how much better that is. I mean, it's much more performant. It's much easier to collaborate. You can actually version track control all the changes, etc. Yeah, it's remarkable.

[0:22:33] PB: Yeah, if multiple people work on the same, especially the same, oh, my God.

[0:22:36] DH: You have like V77, V78. Yeah.

[0:22:39] PB: Yeah. Just imagine the amount of issues that result from that. You also spoke with SED back in 2020. If whoever is listening and wants to listen to the previous episode as well, I think that if they type in Retool into SED's website, then they should be able to find it. I was wondering, what happened since then and what changed?

[0:22:57] DH: Wow. Yeah, 2020 was a lot of time ago. I think Retool has probably grown, I think a bit more than 10X and basically, all useful metrics. For example, whether it's revenue, number of customers, number of apps built, etc., etc. That's been really exciting for us. For me, I think the most energizing thing about Retool is seeing use cases that people have built inside of Retool. The use cases that people now build today are just so remarkable. Ranging, for example, from a company like, MBC, who actually schedules the Olympics, actually, via Retool. They basically want to figure out like, "Hey, at what point do we want to show an event in order to maximize viewership for the US time zone compared to the European time zone, for example?"

Amazon, for example, is now a customer. They actually literally use Retool to control satellites in space. They press buttons on the retool Application and satellites actually move, which is really cool. It's really remarkable seeing what software people have built in Retool. That to me is the most energizing part.

[0:23:56] PB: it feels like, it's almost like creating a new programming language that then you can see what people create using this programming language.

[0:24:04] DH: Yeah, exactly. Yeah. Then I think it's what makes it, for me, at least so interesting to work on Retool, because you're not building software. You're almost building meta-software, basically, because you're building software that allows other people to go build software. The problems that we face are not the problems of, hey this app was not ideal, or whatever else. It's like, how do we create an application that allows people to go build really good applications? That's really pretty interesting.

[0:24:28] PB: As I mentioned, for example, from a very practical way of thinking that imagine that I'm building a new real estate business and I have to create a website with listings of all of the apartments that I'm selling, potentially a notification system for all of the employees and to use within the organization itself. I was wondering how Retool could help and thinking through what elements from Retool could I use? What kind of workflows maybe? Is there anything ready that I could use as a startup, let's say, within this area, for example, to build the backend?

[0:25:01] DH: Yeah. What we see now, if you're a startup, is that actually a lot of people basically prototype in Retool to get a first version of applications you're talking about there. Because to be honest, I'm an engineer, you're an engineer, I think if we built that app together, for example, it wouldn't take that long. Maybe it would take a week or something, maybe a day for a particular screen, you have to configure the data schema, etc. It won't to take an enormous amount of time. It would take a week. Then what gets challenging is when you start talking to customers, because the customers have a lot of ideas about it that we could add. Then we talk to realtors. The realtor is like, "Hey, I want to be able to add, for example, in the US, the laws are actually changing about sales commissions, actually, on real estate." Maybe the realtor is like, "Hey, I want actually a way to specify the commission that I charge, for example." Like, okay, well, now let me go modify the front end, go add a text input.

If you go build back-end system. I have to go build a admin tool, basically. It has to say like, "Hey, I don't want people, like consumers to be able to modify this, obviously. It's only modifiable by the realtor, for example." You have to go build a back-office tool for that. Then you talk to more customers. Maybe, let's say, a prospective homebuyer is like, "Hey, what I want to see is my distance to work, for example." Distance to work is probably not a component that you've built, because you're prototyping, right? But, hey, the customer wants it, so you should go build it, basically.

What we have noticed now is that people actually, especially startups, will basically prototype their startup in Retool, because it allows them to move very quickly. Instead of taking a week to get a V1 out, maybe it takes a day, actually. You get the customer and say, "Hey, customer. What do you want, basically?" The reason why this is so powerful, I think, for the startup using Retool is because the reason why startups die is not because of engineering, or engineering capabilities. That's generally not why startups succeed. Instead, the startup probably fails because they couldn't find a product market fit, and they couldn't build something what customers wanted fast enough, where they ran out of money, basically, or run out of energy.

What's really exciting about Retool is they could iterate extremely rapidly on, "Hey, I talked to a customer, they said they want an extra button here," an hour later, boom, it's done, basically. That, I think, that extra iteration speed is really exciting. That's how startup might use Retool. For a larger company, what they end up, what they typically do is they actually build a lot of these back office, or, I think, for a larger company, they want to actually call these internal tools. Because internal tools are actually what primarily what they work on all day, actually. They call it more  like a business app, for example.

Maybe some portion of the business says, "Hey, I want an app, for example, that will allow me to allow salespeople to input their forecast for the quarter, for example. I want this app deployed to a 1,000 salespeople, for example." Then that's a pretty good ritual use case, because that's, in the end, basically a crud app. It's a crud app that you email to a 1,000 people. Maybe if I remind them to fill it out, if they don't fill it out, so you can use the backend workflows product. It's like a cron in the cloud, basically, so you can use that to remind them. You can build the front end very quickly in Retool, probably on a day or two. You can deploy it on-prem, so it's a very secure, for example. I think you get the app shipped very quickly. That is probably how a larger company might use something like Retool.

[0:27:49] PB: Also, thinking from building the internal tools at large companies, if I'll be introducing, for example, Retool to one of the companies that I've worked at, probably one of the first questions will be the security, because if the data is related to business, if it's sensitive, especially within large corporations and also, granular access and is needed to that data. What steps do you take to make sure that the use of Retool can be secure and safe within large organizations?

[0:28:16] DH: Yeah, great question. This is where I think actually, the fact that both my co-founder and I were developers actually really made a big difference. Because as developers, we typically don't want to copy your data anywhere. We want to store data at one place and have one source of truth, for example. A second is we don't want to trust anyone, because trusting anyone in general is a bad idea. We basically want to minimize who we talk to overall.

This actually led to a couple of design philosophies for Retool that were actually pretty interesting. On the former, Retool never stores any data. We basically connect to your data no matter where it is. Whether it's in your backend API, for example, or a database, whatever it is, we connect to it. This is very different from actually most no-code tools. If you think about an Airtable, for example, or a Notion, Airtable and Notion both store data, right? The major challenge with them is if you want to let's say, use Airtable to edit the data you have in Salesforce, for example, the only thing you can do is, or database like PostgreSQL, for example, the only way is to build a two-way ETL sync.

A two-way ETL sync is as a engineer, you don't want to build that. So many ways for things to go wrong, basically. For us, we always connect to the data no matter where it is. That I think is one major differentiator. A second, that's pretty interesting, is that we allow you to just host Retool. That was always very important to us. The reason for that is especially when this is probably more true if we start it out. Today, we have great companies like in Amazon, NBC, etc., using us. Back in the day, none of these people used us, right? To actually gain their trust, we had to do is we could say, hey, you can actually - Retool is just a Docker image. You can host it however you want. In fact, if you want, you can actually air gap it. If you air gap it, if you think about it, basically, this is really no different from running, for example, a Kafka, for example, or even a Redis, or something like that.

Basically, it's a service to run on your own cloud, the Docker image, and you control everything. It's actually air gap, so no data can go in and out, basically. Then you're not really trusting Retool at all. I mean, I guess, theoretically, if you ship really bad code, we can maybe drop your database, that's probably the worst thing that could happen. No matter what, data could never surface to the outside world, basically. That to us was really pretty important. Actually, we, I think, launched Retool and then I think a month later on, on-prem, actually. We just got this feedback from customers.

I think actually, I think on-prem, it's getting more popular today. Actually, I think we were probably the first developer tools company, I think, to really embrace on-prem this way. Part of it is timing related. I think we were just lucky. We started Retool at 2017 when Docker was just getting more and more popular, and so it was just really easy for us to ship Retool on-prem.

[0:30:44] PB: I was wondering, as a developer as well, whether in corporation or in startup, if I would want to introduce Retool to my product as a part of the back office of my product, or as an internal tool, how do I pay? What's the pricing? Do you price per usage? Also, if I use it on-prem, does the pricing differ?

[0:31:02] DH: Yeah. What happens generally when people want to use Retool is it's actually free to get started. You can just use it, you can download it. We have Docker, but you can download yourself if you want, actually. On-prem or cloud, you can do whatever you want, both are free. I think it's free for up to five users or something. It's basically very easy for you to get started, prototype your app, etc., basically.

If you go past five users, what we do is we charge a price per developer and a much lower price per end user. I think with a developer, I think it's $10, or $50 per month. Even the developer is like, not that expensive. The end user is something, I think, $5 or $10 a month. It's fairly cheap to get started. If you're a really big company, like for example, actually today, five out of the Fortune 10 are retail customers today. Because we sense how well adopted Retool is today, which is something we're really proud of. They generally have pretty custom pricing plans. If you want to roll out Retool to 10,000 people, for example. I think we have one retail customer that rolls it out to, I want to say, a 100,000 people, actually. Then the cost per user, I think is a dollar or something like that. It's really very cheap, basically.

[0:32:02] PB: Would that be the 100,000 people, but this will be running on-prem?

[0:32:06] DH: I would imagine, they run it on-prem. Yeah. Yeah.

[0:32:09] PB: Looking at the cost, but also from the perspective of how much time do you save, do you maybe have any idea, or opinion? Obviously, this is just a general question. What is the cost of not using Retool?

[0:32:22] DH: Yes, we've actually wrote surveys on this to compare every time you build an app in Retool, later on, we'll send you a survey asking you like, how much time did you save? The reason why we ask for this is because it's good to keep ourselves honest, basically. Because if Retool isn't actually saving you any time, then we should probably really re-examine what the product is doing, basically.

I would say in general, we probably save you anywhere between five and 10X of the time spent on building a product. The reason for that is, as you know, you having worked at a big company, a lot of the time in building a product is actually not just the building itself, but actually it's the iteration to the end product, basically. What's really powerful about Retool is that let's say, your customer, for example, is internal customer, maybe it's like the sales team, for example, maybe a VP of sales wants you to go build this forecasting app, for example. Typically, what happens is you get some specs, you get some requirements, you build it, and you ship it to them, they're like, "Hey, these five things are not right." Then you have to respect, or go rebuild these things, basically.

With Retool, it's really cool. You can actually sit next to this customer and be like, "Hey, what do you want, actually?" You can literally build the application live with them, actually. It really cuts down on the feedback cycle and the iteration loop. A project that might take three months, for example, without Retool, honestly, probably it would take, I don't know, maybe five days, I mean, even 20X faster, stuff like that. We see that with many customers.

There are some cases where Retool is actually slower, though, in particular. For example, if you're looking to build something that where you really care about the look and feel. If you're building like, airbnb.com, for example, I'm pretty sure that if you try to build airbnb.com in React, for example, versus Retool, it would be slower in Retool. There are a few examples like that, where there are things that Retool is bad at, basically. I think if you are building a crud UI, Retool is without a question, I think something five times faster.

[0:34:09] PB: We talked a lot about how to build things using Retool, but let's talk a little bit about how Retool is built. I was wondering, what's your tech stack? Did anything change since 2020? Is there anything that you use that maybe other companies don't use that you find very useful? Is there any advice on the technology used?

[0:34:27] DH: I think what's maybe really funny, if you will, about Retool is we first started working on retool, actually. We built a lot of internal tools, actually, enclosure script. The reason why that is the case is because we were looking to make, building internal tools more interesting. Because really, building a crud UI is very boring. Why don't we try to learn a new framework and a new language while we're at it, basically?

[0:34:48] PB: Two birds with one stone?

[0:34:49] DH: Yeah. It was fun, actually. Today, I would say, Retool is a pretty typical, I don't know, 2024, if you will, tech stack. The reason for that is it makes hiring, for example, a lot easier, because we actually, I think, actually, considered using closure script actually for Retool as well. It would make hiring really hard, because, I mean, the pool of engineers can hire becomes way smaller if you're comparing React to closure script, for example, or JavaScript.

Today, let's see, I mean, Retool is basically a type script, mostly on the front end. We use React on the front end, and with the back end, it's Node. Although we're looking to rewrite some of the stuff in Java, actually. Yeah, pretty typical. Not too interesting tech stack, if you will. There are maybe the front end, for example, on the front end tech stack, if you will, we used to use more off-the-shelf components. We used to use Ant design, for example, for most of our components. We're now moving to actually building that actually totally in-house. The rationale behind that is something like a Ant design, or any material UI, or any one of these libraries, they're actually not very well built for internal tools.

Internal tools, for example, you care more about performance, you care more about speed, you care more about informational density, for example. These things are actually not that - not, for example, what a material UI is really optimized for. We're looking to bring some of that stuff in-house. But pretty typical, yeah, tech stack.

[0:36:04] PB: How large is your engineering team in respect to the size of the entire company?

[0:36:10] DH: Yeah. The APD, engineering product design together is around a third of the company, maybe around 35%, 36% of the company. Engineering itself is probably around 25%, 27% of the company, round about.

[0:36:23] PB: Wouldn't the majority, would be JavaScript developers, like full stack JavaScript developers, that they can use and move quickly between different projects?

[0:36:30] DH: Yeah, exactly. They work up with the front and the back end. We're generally organized in terms of product teams, because we find that leads to higher velocity. We don't have a front-end team, or a back-end team. It's just like, hey, if we ship a feature, it's the whole - you can work on any part of the stack, basically. One challenge I will say is we have found it challenging to hire front-end developers for no reason. I think it's too bad that I think it almost feels like, front-end engineering as a craft is not as big as it should be. I think part of the reason for that is because most front-end is pretty boring at most companies. Because if you think about the average company, even the average Silicon Valley company, for example, front-end is it's not generally cutting edge, if you will.

If you go look at, I don't know, even very popular companies today, like an OpenAI, for example, or if you look at all the AI companies, I don't think they're doing anything really interesting on the front-end. If you look at most companies that have been found in the past 10 years, I don't know, you can look at Dropbox, for example, it's not what you're front-end there. You can look an Instacart, DoorDash, it's a bit of front-end, but it's not too deep.

I think we have really challenging front-end problems. For example, I'd probably say, it's similar to Figma in terms of front-end challenges. We're really looking for front-end engineers. If you're listening and you're a front-end engineer, please do reach out. That's probably the area where we really talent the most.

[0:37:42] PB: I always found that front-end engineering with JavaScript a little bit this zoo that you enter, and there's different animals and each single one of them is different. All the frameworks, all the different patterns that people use, somebody might use TypeScript, somebody might just use the vanilla JavaScript. There's still a lot of people on Twitter just voting, we're only using jQuery and just plain HTML for the -

[0:38:05] DH: That's old school.

[0:38:06] PB: It's very old school, but then at the same time, from the perspective of how this is done, at the end of the day, it's about creating the great experience. I mean, as a user, do I really care if the great experience has been used jQuery, or did somebody create React in React, and then added some additional CSS framework on top of it? I think it's about performance and the great experience at the end.

[0:38:29] DH: Yeah, totally. I think this gets to maybe the core idea behind Retool is that in the past 20 years, I think programming has maybe more moved sideways than it has gone up and up, if you will. It's crazy that we're still talking about, oh, why not build the app in jQuery? I mean, the fact is, actually, jQuery actually has some advantages actually over React, because it's conceptually extremely simple. It's not that many lines a code, actually. Whereas in React, even when you spin up a perfectly React app, I think it imports like, what, 20, 30 different node modules? You're like, "Well, what do these things do? I have no idea, honestly." But actually, optimize the performance of React, because it's not hard enough to optimize the performance on jQuery and jQuery out of the box is actually quite fast.

There's a surprise that there's been like, basically programming has not gotten it any better in the past 20 years. Front-end development has not gotten substantially better in the past 20 or 30 years. It's funny that we're still looking at how good things were 20 years ago, when it was just jQuery, for example. That's what Retool is really hoping to change, is that we hope that when we look at this era of programming, we don't think this is the global maxim of programming. We don't think we've achieved the peak programming state, if you will.

We think there's another evolution or two left, basically. We hope that Retool could be a big part of that. Is there a much better, faster way of building software? At least for a subset of software, we think definitely, so.

[0:39:42] PB: I was wondering, in continuing a little bit on how Retool was built, what was the biggest technical challenge in building Retool? And how did you overcome it?

[0:39:50] DH: Yeah. I think this is a pretty interesting story. I wouldn't necessarily say it's an interesting technical challenge, but it was a really big surprise, if you will, from our side. What happened was, this is when Retool was maybe around a year old. What happened was, we were deploying to a pretty big company. We're on-prem. It's a pretty big company. Their actual chief security officer reached out to us and actually said, "Retool is very insecure." We did security audit and it's insecure. We're like, "Why is it so insecure?" He said, "Basically, actually, we don't trust our developers, and the way that you've built Retool."

Effectively, how Retool works, we touched on this a little bit, but it's a programming environment where we can build the applications of the developer, build the application of Retool, basically. When you build the application, you can use curly, curly braces. It's like, actually, JSX, for example. If you use a curly brace, for example, you can go to JavaScript with a curly brace. You know it is wrong, right? In our case, just like in React, if you write JavaScript in that way, it is run on the front end, which makes sense.

The user who is using the application then will run that JavaScript, basically, within our curly, curly braces. This is actually what makes Retool so powerful, because if we don't support something, you're like, "Hey, no problem. I can go run my own JavaScript. I can go import a library, whatever." You can write a custom JS everywhere in Retool, basically. It's very powerful.

However, this CISO basically said, "Hey, problem is that we don't trust your developers." What if, for example, we have a malicious developer, actually, that actually writes, for example, some malicious JavaScript, because this runs on the front-end, you have access, for example, to cookies, for example. I could actually siphon off your cookies, for example, the user's cookies, and actually send them to my backend API, or a separate malicious backend API, for example. What happened then is actually, let's say, a malicious attacker could, for example, build this application that siphons cookies out. They could send it, actually, to everyone in the company. Now that he would actually, as a malicious developer, he or she would actually then have the cookies, actually, for Retool, for actually all these different users, actually.

Now they could, as a malicious developer, could actually go impersonate all the different users, for example. Maybe they could impersonate, for example, the CTO of the company. The CTO of the company maybe has escalated, has more permissions than this person does on Retool. Maybe with this person's permissions, they could delete apps, for example. Maybe they could add more backdoors to apps. Maybe do all sorts of bad things, basically. This is interesting, because for us, we were like, developers, you have to trust your developers, right? You don't trust your developer, isn't it a game over anyways?

Actually, at a big company, at a large, a 100,000 person company, actually, if you don't trust all your developers, or you trust them in different ways, right? Maybe you trust this developer with this portion of the codebase, but you don't trust if they make a commit, if there's other part of the codebase, you don't trust them, etc. It was really pretty interesting. We're like, wow, that's actually a really different way of thinking about, because we were thinking like, hey, maybe you don't trust the end users. Maybe the end users will do something bad. Actually, in this case, the company didn't trust the developers. It's the way past all this is basically, you have a sandbox on the JavaScript you run.

Today, all the JavaScript that is running Retool, if you run it with a curly, curly brace, it's not run within the Retool context. It's run within, actually, a separate tab, basically. A separate tab, that tab is a sandbox, that sort of actually have access to, for example, cookies that might have a retool.com, for example. That, I think, was actually pretty - that was a pretty early, if you will, technical challenge. Sandboxing itself is actually not that hard, but then the question is like, how do you do message passing, for example? Because, for example, maybe someone wants to calculate inside this JavaScript, actually something really big. Maybe they want to pass in a 100,000 rows of data, for example. They want to do a sum, so then to compress the, you know. It's pretty interesting, basically.

Yeah, so that was a pretty early security, or technical challenge that actually really surprised us. Because we had never worked as such a big company. We're actually going to trust the developers, if you will. That was a -

[0:43:31] PB: Also, quite often what happens is that companies, they hire not only primary employees, but also, contractors. Then the contractors are there, for example, for two, three months. Let's just get this project out of the way. Then, not always they are, even though that, at least in UK, as a contractor, you have to have insurance. If you really break something, that you can take responsibility for it. I would imagine that it's better not to break it and then beforehand. I understand it, and this lack of trust a little bit. I think, but it's not something that the first thing that comes to your mind, planning for the positive effect.

[0:44:09] PB: Yeah, totally. Yeah. At which point did you realize that Retool will succeed? Was there any within the growth of the company, or any user that you spoke with that you had this aha moment? I'm like, "Okay, this is going to go well."

[0:44:23] DH: Wow. I guess, it's definitely no. Because I'm not sure if Retool has succeeded yet, actually. To give you a sense, I mean, we have a good amount of revenue. The mission of the company, we really want to affect change of how software is built. We want to bring good software to everyone. It's actually the mission of the company. We want to do so by actually changing the way developers build software.

If you look at what percent of software is internal facing in the world, we think that probably something like, 50% of all software is internal facing. I feel, base in Silicon Valley, this might sound surprising to you, because Silicon Valley companies typically sell software. What software, they build external facing software. As you, for example, have worked at a large company, most companies in the world are not software companies. Most companies in the world, many of are customers.

If you look, for example, at like a, I don't know, Coca-Cola, for example, Coca-Cola is not a software company, right? I mean, they sell drinks. They sell beverages. Most software engineers in the world actually work with these non-software companies, basically. Basically, building internal tools day in and day out. We think half of the software in the world is internal facing. That's what Retool is really targeted at. If you look at what percent of even that software, what percent of internal software is being built in retail today? Man, I mean, I think it's grown 10X, as we know, we chatted last time with Software Engineering Daily. But even growing 10X, even today, it's maybe 0.1% today of all internal software is built in Retool today, as opposed to 0.01%, which is maybe where it was, let's say, four years ago, right?

It's also grown 10X, but I think it's a 100, or a 1000X it could grow, actually. Until we do that, until we actually - I hope that when we look back in 10, 20 years, we'll be like, "Wow. I really cannot believe that we've programmed in such a level way." Retool is a major push towards, can we program? Can we make, build these internal apps a lot faster, a lot better, a lot easier for engineers? I hope we can say, hey, Retool actually play the large part in that. If you look at it, as that as our mission, I mean, we're a failure. I hope that we will eventually become a success, but it's pretty far away.

[0:46:19] PB: We come back in three years, ask you the same question again.

[0:46:22] DH: Yeah, maybe we'll be a few X larger.

[0:46:27] PB: It seems like there is a SaaS platform for everything those days. Do you think that we will see users drifting away from those vertical SaaS application per problem kind of solutions into more general tools?

[0:46:39] DH: Yeah. I think what's interesting now is that a lot of companies are realizing they've bought a lot of SaaS software. Oftentimes, especially if you're an engineer, I'm an engineer, if you look at the SaaS software, you're like, man, how hard could it be to build this thing in-house? It's probably not that hard, basically. The fact that you're buying SaaS is not only it doesn't cost you money, but it also is not really customizable. A lot of our SaaS products we have, we try really hard to customize it in-house, but it's not possible, right? Because it's not a programming environment, basically.

This, I think, is a cool thing about Retool as well is that part of the mission for us, too, is that can we make it so easy to build internal software, or custom internal software that actually you want to build more of it? This is, I think, maybe an overly grandiose analogy, but I think it's the core of it is true, which is you compare Retool for a printing press, for example. You could argue that the immediate effect of the printing press is that it makes it cheaper to print books, which, yeah, it's true.

Well, that's not the ultimate effect of the printing press, right? It's not just cheaper to print books. Instead, it's actually that, because it's so cheap to print books, you never want to go write a book, for example. Now, knowledge can be spread very rapidly. That's really the impact of the printing press. Similarly, we think with Retool, what could be really cool is not only is it cheaper to build internal apps, but because it's cheap to build internal apps, hopefully, developers will build a lot more custom applications, actually, that are really bespoke to their business and can solve their business problems really well. As a result of that, companies themselves will run a lot better, actually, because instead of having to run at a giant Excel spreadsheet, or running a software that doesn't really fit the way you operate, now you can actually have custom home-grown software. That to me, I think, is really exciting, too. I think, we've see that a lot, actually, with Retool use cases today, so.

[0:48:19] PB: That could potentially replace a lot of the SaaS subscriptions that we're solving any small problems, except [inaudible 0:48:24].

[0:48:25] DH: Yeah, totally. Yeah. I think even more broadly, if we think about it, one use case that I'm really proud of is there's just not enough software engineers in the world. There are a lot of really interesting problems in the world that are not being solved today, because there's just not enough software engineers to solve it. Actually, one customer that I'm really excited about, I wish I had them come through all hands maybe around a year ago or something, is this a customer called Fund for Guaranteed Income. Basically, it's like a UBI, so universal basic income, basically. They're actually running a UBI study in a city in California, actually. For them, they actually can't afford to hire software engineers, because they're a nonprofit. They don't have extreme amount of funding.

For them, they probably will not be able to run their UBI project. They will not be able to actually hand money out. They actually track who's received money this week. How are they doing? What's the level of happiness, for example? One of these, the money on, all these things. They track all that via Retool. It's all automated. A lot of it is automated. There's no way they could have done that with spreadsheets. They could not have automated all with spreadsheets. That's an example where the world needs more good software, and there's not enough of it, actually. That, I think, is really exciting to me about the mission for Retool, it's going to bring good software to everyone by making it a lot cheaper to go build, develop custom software.

[0:49:35] PB: And to free developers for coding up another form.

[0:49:38] DH: Yeah, exactly.

[0:49:41] PB: What are you working on right now?

[0:49:43] DH: one thing I'm really proud of at Retool is, I think, we've built a culture of shipping very fast. At any goal of our changelog, for example, you'll see that every month, we ship a lot of new things. There are quite a few things we're really proud of that we're working on right now. One of them is incorporating AI, for example, more into the product. One thing for us that is pretty exciting, allowing AI to actually automate business processes. I think there's a lot of talk about agents, for example, the AI world. I think the models are currently today are not quite there. They may not get there, actually, for a while, I think. The reason for that is because today, the models are very good at solving smaller medium-sized problems. They'd be small, small, medium problems.

It's like, hey do this one thing. If it's tightly scoped, the model can do a good job. If you're like, take over the world, for example, the model's like, "Oh, I don't know how to take over the world." It is really confusing to me, basically. Or even solve the support ticket. The model might be like, "Oh, I'm confused. So many ways I could go, I don't know how to do it, basically." For us, or one thing that we're really excited about working on is actually this workflows product that allows you as a human to go define, actually, hey, let me go break this problem down. It's 17 different small-sized problems. Then maybe each one of these small-sized problems actually can be done by AI. That, I think, will really allow people to harness the power of AI a lot more. Because I actually don't think that AI is very good at saying, hey, here are the seven - I think there are a bunch of experiments on the chain of thought stuff, for example.

Even that gets tricky when the number of steps gets too high, or the complexity gets too high. Really, we think that maybe actually humans, or programmers are the ones that are good at this high-level engineering of like, hey, do this, then do this, and in this case, go over this way, this case, go over this way. Then all the individual steps can be handled by AI. Maybe some of the transitions can also be handled by AI, too, for example. I think that's actually really missing right now. There's no good framework, if you will, to abstract these business problems in a soluble way for AI, if you will. That is something that we're working on right now that I'm really pretty -

[0:51:38] PB: Splitting a larger task into smaller tasks, for example -

[0:51:42] DH: Yeah, exactly.

[0:51:42] PB: Take over the world, we need to eat first, then we need to plan, then do this and that. Then tackling the smaller tasks as more digestible chunks that AI, the current state of AI can actually take.

[0:51:54] DH: Yeah, exactly. Yeah.

[0:51:56] PB: No, that makes an absolute sense, because for smaller tasks might be executed, and even just use humans to fill the tasks that could end it, and that couldn't be done. I was wondering, as a company, how do you work? Are you all based in the same place? Are you all in the same office? Do you have any team members working remotely?

[0:52:14] DH: Yeah. We do have some remote team members, but Retool is primarily office-based, and we are in SF, New York, and London. The reason why we're primarily office-based, we actually really do believe in remote work. Actually, you could say we're hybrid. I mean, we're in the office three days a week, and then not in the office two days of the week. At hybrid work, I think I actually could work, or even remote work could work quite well for a larger company. The reason why we're not fully remote is mostly, because we're a small company. I think for a small company, a lot of the personal relationships you build up today, which was about 300 or so people, is really fostered by being in the office, actually. It's much as a collaborate. It's much easier to go run into someone on the hallway and actually talk about a project that you two are probably both working on.

I think at a larger company if you're at a 100,000-person company, you probably have multiple offices. Anyways, the benefits are greatly diminished. I think for a small company like us, it actually is really important that people are really close and tightly knit. Part of that is being in the office together.

[0:53:05] PB: Speaking about that team, you said before you mentioned that you're hiring. There is the audience here, I think it's largely technical, so if you're hiring for any positions.

[0:53:14] DH: Oh, yeah. I will hire for practically all engineering positions. I think the one that we've talked about a bit already is really front-end engineering. Front-end engineering, I think, would be pretty open to honestly hiring anywhere for, because the front-end engineering talent is also pretty distributed as well. Yeah, if you're a front-end engineer, please do reach out. I mean, I think we have really, really exciting front-end engineering problems, ranging from, how do you optimize performance for a really complicated retail apps, for example, but also how do you build a programming language that by default, allows you to build really good applications, whether that's performance, or UI, or whatever else? I really think that when I compare retail to other companies, I think retail is probably in the top, maybe 1 percentile in terms of challenging problems that we have in the front-end.

[0:53:56] PB: On the front-end.

[0:53:57] DH: Retool, it's a app that allows you to build crud apps. It's actually really quite deep and quite complicated on the front-end, so.

[0:54:04] PB: The front-end to rule the front-ends, and to build the front-ends. I was wondering, also, looking into the future, where do you see Retool in five, 10 years?

[0:54:13] DH: Yeah. Well, so I talked a bit about in our mission, and our mission is twofold. One is to bring good software to everyone, which is how do we arm all the companies and all the people in the world with really good software, so they could go achieve their aims. That to me is all pretty exciting.

I think there's this old Steve Jobs line. I think it's like, what is the mission of Apple, basically? The mission of Apple, I think, computing overall is an abstract thing. What's the purpose of computing, basically? I think what Steve Jobs said was, "Hey, we want to allow every one of our customers to put a dent in their corner of the universe." That to me is really exciting, too, and that's why Retools think so exciting to a lot of the people that work here, is because we are building tools that allow other people to go build the applications, and to power their business, to power their lives, basically, and allow them to achieve things, and achieve their missions, actually, which is really cool. that's, I think, one thing, one area.

We basically want to see more applications, more software that is being built, than we're not even built via Retool, basically. Interesting way of tracking that is what percent of the software in the world is built via Retool. Like you said, I hope that in three years' time, I'll come back to Software Engineering Daily and say, "Hey, actually, 1% of all software today is built via Retool." That software will not have been built without it, actually. I'm really proud of the impact that it will have in the world. Yeah, that's the goal.

[0:55:29] PB: Personally, I'll be definitely trying Retool on the next project I'm working on right now, because I already see a couple places where I can free myself up from the forums and the tables, and actually focus on the external part of the app.

[0:55:42] DH: Yeah, let me know what your feedback is.

[0:55:44] PB: Definitely will. Awesome, David. Thank you so much for your time. It was great talking with you.

[0:55:48] DH: Yeah, thanks so much for having me. Excited to be back, and maybe see you in three years.

[END]