How Retool reached $2M in ARR before launch by focusing on developers — David Hsu

 Great. so retool, launched in 2017 and I know the company has seen tremendous success since then. Recently you raised a 45 million series C backed by some great folks, the Collison brothers, Sequoia Allo Gill, and a really impressive list of customers. Allbirds, DoorDash, Amazon.

And really, I think Retool has established itself as the go-to platform for developers building internal tools. And so when people hear stories like this, David, I think they have a tendency to assume that the road was always smooth. But we know that's never really how company building works. And so today, I wanna zoom in on the details with you, kind of from the early pivots you had to make to your path to finding product market fit 

So to kick things off, uh, would love to rewind to your days in college at Oxford. Tell us about that.

 Yeah, well it was a lot of fun. Um, so I actually grew up in Palo Alto, so sort of even going abroad, uh, to study, uh, you know, pretty far away was kind of a big decision. Um, I ended up there actually because, uh, I really wanted to study, uh, both compsci and philosophy. Uh, and, uh, there are very few sort of schools in the US that offer that.

Um, one school that offered that actually was Stanford, uh, but I grew up Palo Alto, so I really did not want go to school at Stanford. And so, uh, I was, uh, to some extent, uh, I knew I would be in tech afterwards, and so I was like, I should get outta here, get out of SBA area for maybe a few years while I still can. Uh, and so I ended up at Oxford, uh, mostly because they had one degree, which was, uh, philosophy and computer science

 Oh, that's so cool. They actually have a joint degree in that.

 They do. Yeah. It was interesting cuz I think, um, I had probably started coding, uh, I don't know, maybe in high school, something around that. but coding was something that, you know, you could sort of pick up by yourself.

So it wasn't really sort of something that I necessarily needed to study. That said, I really wanted to study philosophy. Uh, I think ever since, uh, maybe from a young age or something, I think I was always interested in finding, you know, what potentially the meaning of life could possibly be. And that motivated me to study philosophy. it turns out when you study philosophy, you find, uh, there are sort of so many more questions than their answers but it was a lot of fun. 

 That's awesome. And so, you know, how did that kind of studying computer science and philosophy together, ha has that informed the way that you think about building retool or has that informed the way, you know, you think about building.

 Oh, certainly, I think philosophy is surprisingly applicable. Uh, it may not seem very applicable to sort of building a company or even day to day life or whatever else, but. Uh, for me, I think philosophy really taught me sort of what first principal's thinking looks like. Uh, so when you think about, for example, is a number, uh, what is zero?

You know, what is one, what is two, uh, what is addition for example, et cetera. Um, that stuff is really interesting and I think when you think about company building, uh, to some extent, uh, you kind of wanna think it that way as well, which is, companies, five years ago look like this, or 10 years ago look like this.

What has changed? Uh, sort of what are the first principles that sort of, uh, lead to X being this way or y being this way? And for example, in the case of retool, Visual programming, sort of programming and this drag and drop way is not a new idea. Actually it's been around for maybe 20 or 30 years and yet it's actually always failed before.

And so thinking a bit about sort of why it is that an idea would work or would not work 20, 30 years ago but could potentially work today. And sort of thinking with the differences the world are, uh, you know, have changed in the past 20, 30 years, I think is super interesting. So essentially, I think thinking from first principles is what philosophy really teaches you, but it really, uh, it can be used in a surprising amount of ways.

 Okay, so let's talk about the idea for retool, and I know that while you were at Oxford, you were working on side projects, and so where did the idea first come from?

 Yeah, so, we had worked on a budget side project when we were in school, um, maybe five or 10 different side projects. And time you work on a side project, you basically have to build internal tools, uh, for it. And, uh, we were like, Well, you know, every side project difference, every internal tool, you know, basically needs to get billed from. Uh, but we were spending probably half our time, half our engineering time internal tools we were engineers. And so, uh, as engineers we were like, there's gotta be a faster way of doing all this stuff. so that's kind of where the core idea of retool came from is, hey, could there possibly be a much faster way of doing all of this stuff? If we think about how programming's been done over the past maybe 20, 25 years, there's actually been very little innovation how programming's actually been done. And so, uh, we were thinking, you know, could there be sort of a higher level way, if you will, of building all this internal software? And that's where the ideal retail first came from. And when we first started retool, it was actually really for other, like two or three person companies. You know, we thought that sort of, uh, retool could be this, uh, uh, sort of fast way a three person company could use to build their internal tools. After launching retool, uh, we discovered however, that actually maybe something like 50 or 60% of all the software in the world actually is eternal facing. actually big companies spend practically all their time building internal tools. Uh, so that really, I think, validated the idea as well.

 Okay, great. So you had this notion that internal tools were something that everyone had to build surprisingly large percentage of all software created in the world. But what was like the very first step, like you had this idea, internal tools, what was the first thing you did or the first thing that you built?

 Yeah, so, uh, if you've built, you know, 20, 30 year old tools, a pretty good sense. Basically, all internal tools are basically tables, buttons, text inputs, And so the initial version of Retool, even though Retool's sort of this generic broad programming environment, if you will today, uh, the first thing we did was basically say, Hey, we want to build a table component, a text input component, and a button component.

And so when you, for example, uh, you can load a table of your users, and then you can search your users you can do something to that user. So maybe you can deactivate that user or activate that user or something like that, basically. And so was kind of the first, uh, Version or prototype of retool, if you will. Uh, and that was surprisingly applicable, uh, because, uh, the sort of initial companies that we sold to, um, basically all their use cases were, were tables and they're taking action at the table and search at the table. And so that turns out to be a surprising percent all internal tools like that, probably like 20% internal tools is basically tables plus buttons, plus forms 

 And do you remember the first person besides, you know, you and your team that tried retool, like the, the first couple testers that you had?

 Yeah, so, uh, when we were starting, were a YC at this point. So this is

 I wanna say June, of 2017, something like that. Uh, the initial companies that use retail are basically other YC companies. Uh, We'd be, uh, you know, at every sort of YC dinner, I think it was every Tuesday night, we'd be annoying and try to get everyone to use basically. And, actually our first two customers, or these two other YC companies, Um, one was starting a tutoring business. Uh, and so had to use to sort of manage all the students, manage all their tutors. And you can imagine that basically is in a bunch of tables, a bunch of forms, bunch of buttons, to assign, you know, tutors to students, stuff like that. Another one was a, uh, app that, uh, allowed, uh, drivers to drive for both Uber and Lyft at the same

 they had a lot of internal tools, uh, to sort of manage the billing, the subscriptions, even sort of when every time Lyft changed their app, for example, they would use a retool to sort of, you know, uh, figure out what has changed and how they need to change their app and reaction to that, et cetera.

 cool. And how far along was the product at that point? I, you know, we get into these conversations with founders about like, what does your MVP look like and how done does it need to be? How, done or how polished was retool at that time?

 Oh, it was not very published at all. Uh, are features that are in retool today that seem sort of so basic and some maybe so sort, sort of quarter retool that did not exist at that point. So, for example, um, that, uh, the second customer I mentioned there, uh, they were the ones who got us to build APIs, integrations, and retool.

So now at this. I think the API sort of, a generic API is the second most popular integration to retool today. Uh, it did not exist actually when we, uh, sold, uh, retool to this, uh, customer, they were like, Hey, retool seems really cool, but I don't actually have a database I only have APIs. I, uh, connect, uh, my APIs? And we were like, a great idea. us come back to you tomorrow. It'll be built. We stayed up we built it and we came back and, uh, it worked. So, uh, sort of the early days of retool were very fast iteration cycles. like, you know, one day or one night or something, we'd come back with a product oftentimes at work, sometimes it didn't.

And we have to iterate, you know, from there too. But it was a pretty, uh, immature product at that point.

 Got it. Were, were those first few customers happy with retool, like kind of right off the bat, or did it take some time to get the product to a state where they were really like pleased with what it was doing for them?

 Our goal always, uh, was when we started retool, so from the, uh, zero to let's say a few million dollars in arr, goal always was happy customers was how do we get to a hundred happy customers? Um, because the idea basically is we can find a hundred, you can probably find a thousand, you can probably find 10,000, probably find a million yard cetera.

So our goal was, Even revenue at that point. It really was, can we get customers to be happy and if they're happy, presumably, uh, we could find other people like them basically. Um, and so, uh, that sort of was our North Star metric in the early days. Uh, those two customers, they probably got to happy within maybe a week or two, I would say. Um, so it wasn't instantaneous. Like for example, if you, second customer literally cannot use a retool because, uh, we didn't connect APIs. And so we came back the next day with API connections. Uh, and then I think they had a few more feature requests, and then we built a future request. But within, you know, a week or two, I would say they were happy customers.

 Very cool. I wanna ask a few more questions here. Cause I think it's an area, you know, where so many founders live is like, how do I get from my first two customers to my first 10 customers? Talk us through that. Like how long did that take for you? How much did the product change during those days? What was that like?

 Yeah, so I'm thinking about the dates a little bit. So this was probably around again, maybe June of 2017 when we're going through yc. Um, at that point we probably had maybe of. Few ish customers, so maybe 3, 4, 5, something like that, basically. Uh, and, uh, those we had gotten via sort of, you know, outbound essentially we were, you know, sort of outbounding in person, if you will. but, uh, the next few customers came via, uh, email outbounds. so we were in winter 17, uh, for yc. Uh, Brex was also in winter 17. They became an early

 middle customer. So we emailed them. Um, I had sent them an email, uh, and I think, Pedro and Henrique, uh, had said, Hey, internal tools.

R indeed the challenge for us, because they're a FinTech company, they have a lot of operational things going on. Uh, and I remember visiting their. Uh, I think point Rex is maybe, maybe 10, 15 people, something like that. And I was thinking like, wow, this is a huge company. You know, I can't believe there are 10, 15 people already. Uh, and we still did them. Uh, and so it was very much outbound basically, and it was maybe very customer driven in the sense that we were interested in sort of hearing what their problems were. And, but it just turns out the problems were actually relatively alike across different companies, uh, which is, uh, DoorDash is of the early customer of our, for example.

Um, believe it or not, sort of the problems that a DoorDash had was actually pretty similar to the problem that a re had was actually pretty similar to the problem that, you know, sort of the other companies that had mentioned, uh, had as well, which is they, uh, had engineers, but their engineers wanted to focus more on building the customer facing side of the business.

Uh, for a company like Brx, for example, uh, their engineers are working. can we sort of create the, card product, or the banking product for example. They were less focused, or uh, they wanted to be less focused on internal software, uh, internal tools specifically. And so for them, value prop of Retool was, oh.

With something like retool, I can actually go replace, you know, whole engineering teams. Um, now my engineers can move a lot faster sort of the first order effect. And the second order effect is once I have really great internal software, I can serve my customers a lot better. I can be operationally excellent.

 it turns out that valley prop was sort of pretty, uh, uh, pretty broadly applicable for companies like DoorDash, for example. It was similar where, uh, they themselves, you know, have sort of an iOS app and they Android app, a web app they want to go and work on. And that's what's really impactful for the business. but uh, they have a lot of internal operations they need to go and build. Uh, the first team we, uh, sold to uh, our champion's name was Rohan, who was on the dispatch team. And you can imagine on the dispatch team there's on a lot of internal tools to build. And, uh, I think, a lot of what has, uh, made DoorDash so successful in the past few years is really being operationally excellent.

And I like to think that sort of retool played a small part allowing them to have sort of bespoke custom software that enables them to be operationally excellent. So the value prop, I would say, uh, You know, early on was sort of pretty ironed out already, and then it was a matter of finding more customers. the path we took to find more customers was, uh, outbound emails. Uh, and that probably took us from maybe to 20 to 30 to 40 customers. And so by the time we had launched Retool, uh, on hacks, I think this is maybe in 2018, so almost a year after maybe 2018, you can probably still find on Hacker News. Um, by the time we launched it, we had maybe around 40 or so customers, maybe around a million, $2 million in ARR already. So

 so to go back to the, um, Happy goal. Uh, we wanted to make sure that, uh, what we were doing was actually replicable. And so that was why we did so many outbound sales, uh, because we really wanted to prove to ourselves that we could go find, you know, we've built a product is not just useful for one company or two companies, or, you know, five customers or 10 customers, instead as useful for, you know, 30, 40, 50.

And then once we, you know, had 40 happy customers, we were pretty convinced, you know, something was going on here in that if we could find 40, you know, presumably we were ready to launch basically at the initial version of the product. And so ever since launching the initial version of the products, basically all bit inbound since then, before that it was outbound actually.

 I got a couple follow ups on that because you covered some really interesting ground there. So one is you guys were really far along, you know, in terms of customers and arr when you quote unquote launched. Like how come you waited so long to launch?

 Hmm. I think for us, uh, we are in the sort of developer tool space, uh, as a developer tool. I think developer have very high standards, uh, sense that they are not interested in using products that are buggy, don't work, have, you know, crappy user experience, et cetera. And so we want to launch, uh, only when we were confident.

Uh, it took a while for us to build that confidence. Uh, There are, uh, I remember, I, I think we had talked to Peter from Segment, uh, maybe I wanna say months after we had, uh, first started retool or something like that. And I think Peter's experience of product markets did, it was something like, uh, once you, uh, have it, it's sort of so visceral, you immediately feel it.

I think he describes it maybe as like a geer or something like that. Like it just explodes basically. We honestly never felt that, I mean, maybe part of it was we were outbound, so it was kind of hard to feel that necessarily. but I remember, uh, thinking, uh, with our early, you know, with number five, customer number six, number 10, number 12 or something. I remember thinking like, war building actually a sort of rep replicable product. I wasn't sure actually. And so every customer that we had got it. You know, customer number 12, 13, 14, number four, number five, kind of felt like this is the last customer we're ever gonna get. Basically like, sort of every uh, uh, use case honestly seemed pretty different actually.

You know, and you can kind of see why, like, you know, for a company like DoorDash, for example, building logistics tools, uh, to manage, drivers, and orders and stuff like that, pretty different from Rex, which is, for example, managing or AML managing credit limits, for example.

And that's pretty different from a tutoring company that's matching, uh, uh, and tds, for example. So I remember thinking. As we're working through these early, you know, five, 10 customers that's sort of, all these cases are so different, can we actually serve these customers and make them happy? Uh, and it turned out, you know, by the time we got 30, 40 customers, we sort of had built up that confidence and say, Hey, there are these all 40 different use cases, they're all built on top of Reto and they're all happy customers, then we're actually pretty confident that if we launched this product, it will actually resonate. Um, part of it also was also iterating on messaging, which is, uh, when we were talking with early customers, we would say things that were pretty out there, uh, just to sort of see, uh, what people, uh, thought about it. So, you know, actually the initial way we fished, retool was, um, said it was Excel, like with higher order primitives. Uh, and no one turns out knew what that meant.

 Yeah, that did not land. But I mean as a developer, for me actually, I was like, that's kind of how I thought about it which is sort of retools this, you know, sort of high level programming language. And with Excel, sort of the, you know, primitive is the cell, which is, uh, cells, you know, can depend on the cells.

You can perform them inside them. You can put data inside of them for retool instead of a cell as a uh, uh, sort of, uh, base component. the react component is the base component. And so you can put things in React components and they can depend on each other. And so you can sort of say, Hey, this react component depends on this other react component, for example.

And so to me, uh, it was quite obvious that we should pitch retool as Excel, like with higher order primitives. we discovered that was not a good pitch, uh, for the product uh, to most of our customers. And that did not resonate. So think iterating the messaging, iterating of the product, iterating of the use cases, was what, uh, the early customers helped us with. 

 sometimes we, we think of that as language market fit. , and I'm wondering when, when did you start to see that? Like what was the language that you could tell was starting to resonate with folks?

 This is one reason why we really love outbound or at leasts outbound for early stage startup. But so good because it sort of gives you a very good sense on how resident something is, especially cold outbound. Uh, because if you get a warm intro, uh, for example via an investor for example, obvious people will take the call, uh, and they'll say, Yeah, yeah, sounds interesting.

Uh, yeah, we'll love a demo. Uh, maybe send me some, you know, a login details later. I would love to play it around with something like that, which is sort of very non-committal, very vague. And that actually is very harmful to an early stage startup because, um, that makes them think that they may have brought a market fit even though they don't. This sort of warm interest can be quite dangerous basically. Cause they sort of give you false optimism or false hope. We, uh, always, uh,

 outbound because we thought that would sort of be a, uh, good way to prove out whether the product was landing or the messaging, like you said was landing. And, uh, I remember, uh, there was one time we had done a cold outbound to a company called Rappy. They're kind of like DoorDash of Latin America. I think there are maybe a few thousand employees now or something like that. We emailed them like they were on a thousand or so, and. To be honest, like when I sent the email, I didn't expect anything.

I was like, Let's try and see what happens. I think within maybe 15 minutes, uh, their cto, uh, had replied saying like, Hey, let's get on a call. Uh, and I was like, Cool, how about tomorrow? And he was like, How about today? I was like, Great idea. How about today? In fact, and uh, I think that was maybe the first sign that the message was really resonating.

The fact that the CTO of, you know, a thousand percent of the company Hey, let's get on a call right now because, uh, this, uh, sort of problem that you described internal software, internal tools is so important to me that I wanna take time, you know, 30 minutes. I, I will reschedule a meeting to talk to you right now. I think that was sort of good evidence that the messaging messagings sort of the landing. So, uh, after that we're like, Okay, well, you know, clearly these sort of, uh, build home tools, faster messaging is really resonating. Let's go sort of, uh, apply that other company that continue to work. And so that, uh, was maybe sort of the early iteration that really worked.

And if you go to a website even today, is the core of a messaging today, sort of build internal tools insanely.

 So build internal tools faster, you know, rather than excel with higher order primitives. That was the very concrete, right, Val, Very value proposition oriented.

 That's right. Yeah. That could not be a lot more effective.

 Another question I had, David, you know, as you were talking through that path from, you know, two customers to 20, 30, 40 is, you know, one observation is that you, you said the value proposition was very consistent, but the use cases were very different.

And so what did that mean for you in terms of prioritizing features? Like you've got one customer asking you for one thing, and you mentioned like the API was, was based on a customer request, another customer asking you for another thing. How, you know, I know that's a question that a lot of founders have of like, how, what do I build for which customers and how do I prioritize all these things?

 Yeah. Yeah. So this is actually a good example sort of I think, where first Principal's thinking comes into play, which is, um, our customer, uh, has always been the developer and that has a lot of. Consequences that may not be sort of immediately obvious. Uh, and this is why, uh, we believe a lot more in, uh, retools market, than say, code market, for example. And what, uh, having the developer, the customer enables you to do is developers actually don't really want you to do professional services. For example, they actually want buildings themselves. want you to give them the sort of building blocks so they can assemble those building blocks into what they want.

They don't actually want the end product. They can't customize. And so to your point around future requests, uh, if we're selling to a non-developer, a lot of feature requests would probably be a lot more specific. They would probably say like, Hey, I want specifically X or specifically Y or specifically Zed.

And please do that for me and I will. Instead, because we were selling developers. What developers actually want is they say, Hey, want you to build me sort of the, uh, APIs or scs such that I can go build X with a re tool. And that turns out to be sort of a lot more, uh, generalizable. for example, us, a developer might say, Hey, I want a, uh, map component.

Because of the map component, I can start displaying, uh, if I'm door lash, what deliveries are going, Uh, or if, uh, I'm Lyft or Uber, for example, I can display where my drivers are. Or if I'm Airbnb, I can display where all the uh, properties are, Now if we're selling to a non-developer, they might say something like, Hey, I want you to go build me an app that sort of shows where all my drivers are or my orders are going. And that's actually not with the developer wants. Developer says, Gimme the building block of the map. And I will figure it out how to sort of leverage this map component such that, uh, I can, uh, uh, build the app that I want. And so some of the developers have actually allowed us to sort of build sort of more of these primitives. And so we today are very customer driven in our development, but we are customer driven in the sense that we are always building sort of frameworks and APIs and SDKs as the developers can use this as sort of their generalizable SDKs that all of our customers can use. And so, you know, maybe it's the case that, you know, for example, Airbnb might be more likely to use a map than let's say a tutoring company, anything that we build ends up being used by sort of a large percentage of our customer base. And that is only possible. Because we sell to developers, because developers, uh, don't actually want us building the exact end product. They want us giving them sort of these building blocks themselves can assemble.

And so for us, from sort of a product prioritization perspective, we always prioritize basically, uh, what are the sort of building blocks that we can build that would enable sort of the greatest good for the greatest number of customers. Uh, and uh, that was sort of our North star. And that is actually quite clarifying because, uh, when we think about all the features that we build, we basically never build any sort of consulting features or we never build anything for any one particular customer. What ends up happening is anything that we end up building, for one, you know, particular customer up being used by maybe 30% of our customer base. So, for example, uh, DoorDash, wanted audit logs, uh, cause they wanted to sort of see people are doing inside of the product. Uh, and uh, let's say when someone refunds an order or gives someone a credit, they wanna know who did that.

Basically, that's a simple feature that we built very rapidly. Uh, I think we built that in a week or something. And that feature is now used by probably 50, 60% of regional customers today. And so, the features that we built are sort of these building block features basically that could be used by a lot of customers rather than any one off feature.

I think we basically have not built one off features because our customers can build it themselves we give them the, uh, necessary, uh, building blocks.

 That strikes me as an amazing property of having developers as your customers, is that you get to build building blocks, you get to build components, rather than having to build like separate one off features. was that a conscious choice always for you, that developers were your audience and how did you, how did you decide that?

 It was, and. It's funny because, uh, it's sort of, so obviously a part of retool, uh, and it's, I think the cause of the early success that we've had thus far, still very early days, is allowed to prove out, but certainly developers have our focus and developers I think has really helped us a lot. But if we look back five years, the retool first started, it was actually. Really non obvious. It was, it was actually a bad idea. Most people thought it was a bad idea

 so the way, we, uh, sort of way of history ritual instead of excel high recruitment is, is you can say, Hey, we are creating a drag and drop way. that developers can code. Faster.

 Let's see. And developers, uh, are allergic to drag and drop. They hate drag and drop. Uh, I remember, you know, I was a developer. If you told me, Hey, should build this website via, you know, drag and draw away, for example, I'd be like, Oh, that's not for me. Like, that's for marketers. Like, I would never touch a drag and drop tool.

I'm a hardcore engineer, like I write code. Uh, and so the idea of rewatch, it sounded like quite a bad one, which is we're gonna teach people who already know how to code, but we're gonna change their mind about how they should code. In fact, we're to sort of tell them that drag and drop is a better way of coding, which is completely antithetical to sort of their sort of mental model to how coding has done. And I remember actually, uh, in our IC batch, I think we had maybe a few other companies actually come up to us and say, Hey, we tried this idea of Florida, it's not gonna work. Like, it's not gonna work for xrays and wires. And, and one reason, uh, actually, uh, someone told us that it was not gonna. It was because, they said you're basically become a consultant job.

Uh, you are going to, basically be the one building all the apps uh, it's not a SA business, so you should probably stop now. Uh, I would recommend that we tried it two years ago when we pivoted ourselves. Uh, and, this is where I think sort of again, the first principal's thinking is so interesting because it's like you have to, I think, uh, my sort of theory of starting startups essentially is have to have differentiated beliefs about the world also happen to lead to success. if you believe your beliefs are, you know, of the average, accepted belief, uh, that everyone else has, There's kind of no reason why you're gonna find success when everyone else did not. and so my belief basically is I think we had maybe a few of these core beliefs that were, I think quite, uh, maybe controversial or, uh, non obvious that a lot of people would disagree that at the time, and that has now led us to success.

Uh, so for example, one I think is the developer focus Another, uh, line that a lot of people might say is sort of more promising than what Retool, uh, should focused on they could say, Well, we're not focused on developers. You should actually focus on non-developers they have no alternative in the sense that, uh, if, uh, a developer can actually always go on right and learn to react, for example.

And so those alternatives actually now that bad, like, you know, saving them a bit of time, but they have alternative. Whereas if you focus on, let's say, people who actually cannot code, then you're quote democratizing programming, and, uh, because these people have no alternatives, sort of, it'll be a stickier product or a more valuable product, for example.

So there's a lot of reasons why you might wanna sort of start a product like non-developers, we thought that, uh, actually, uh, when, uh, you're building complicated apps, the only way to build a complicated app is by actually writing code. the only way, uh, to do that is by selling to a developer, basically.

And so an example where. Sort of the commonly accepted cause I think, you know, when we started in 2017, what was, I think more in vogue at that point was really, uh, quote, democratizing programming. we were like, No, actually we are squarely focused on the developer and we think that will lead us to more success, the focus of the non-developer.

So think we had maybe three or four of these kind of core beliefs. Uh, the developer focuses one of them that I think really helped us, uh, and has led to our success.

 I love that story. That's an awesome story. Um, about just your contrarian beliefs at the time. How did you get developers over this thing about drag and drop? Like how did you get them to love drag and.

 Yeah. So, uh, it's probably two things. Uh, the one, uh, first one is probably developers hate building internal tools. So it turns out hate building internal tools more than they hate drag and drop systems. The second, is that. If you look at sort of the history of programming over the past, uh, 20, 30, 40 years, there's actually been relatively little innovation in programming.

Uh, if you sort of think about the last major change, uh, or the last, few major changes, for example, going from punched cards, uh, to actually, uh, assembly that was a pretty big change for the whole computing industry because now , you don't have to wait sort of 13 hours for your code to compile for it to run.

And then you come back the next day and then it turns out there's a bug and you have to go fix it again. Like should speed, you know, sort like so long back when we had punched cards, um, then we move to assembly. Assembly is higher level, it's a lot faster, and then you go from assembly to something like a C for example.

Um, and that's, you know, a big change as well. And then c has gone to, you know, something like a, you know, like a Java Java has now gone to, uh, sort of higher level, like a Python or a Java script. But actually we look back, you know, 10, 20 years. There has been relatively little innovation, like sort of what an engineer does today versus what an engineer did 10 years ago versus 20 years ago. kind of the same actually. Like, you know, today in order to build a simple Cru app, you have to manage sort of a giant package just on file. You have to sort of install 30 dependencies, you have to go debug all of that. And then when things break, when versions are wrong, like building a simple Quad app that writes back to a database or an API probably takes a few hours, if not, you know, a week or two if you're sort of, you know, trying to deploy this in sort of a production environment. And, uh, to us that seems just ridiculous to us. It's, you know, you should be able to get a credit app going and like five, 10 minutes, uh, with, you know, permissions, with Connect into APIs, you know, all sort of built in basically. And so, uh, I think the higher level nature retool is sort of a different way of programming and I think think sort of such a better way of programming. that has really helped get developers on board.

 This is great. I can see the computer science and philosophy things coming together here in that answer. Love that. Um, so let's, let's move, um, more towards, uh, larger customers, because I know, David, that you, you actually had some enterprise customers fairly early on, which I think is, is relatively uncommon for startups.

Um, so how did that happen and did you always sort of know that these, you know, kind of Fortune 500 ish companies were going to be target customers?

 Initially, no, initially we started the company, uh, we were thinking it was sort of a fast way to build internal apps for small companies, basically. Um, it was actually quite surprising to us to find that the problem was actually even larger, these larger companies. the reason for that, uh, that if you think about sort of all the Silicon Valley companies or, you know, our job essentially, you know, whether it's a Dropbox or Retool or any other sort of software company in Silicon Valley, our job is to sell software basically.

Uh, and, we are building software on selling, and that's how we met. We all make money, even Google or Facebook. That's how they make money as well. Uh, Uber, Lyft, Airbnb, et cetera. And, uh, selling software is how is our business model basically in Silicon Valley. That's it. If you actually, uh, zoom out and look at sort of most companies in the world, most companies are not software companies.

Uh, we look at, let's say like an nbc, for example, one of our customers or a Jaguar Land Rover, another one of our customers. These companies are sort of not software companies. They're actually, you know, manufacturing cars and they make money by selling cars by being media companies. But it turns out actually that these companies have a ton of software engineers all their software engineers, all they do day in, day out basically is builds internal software. And so, uh, when we sort of look at what percent of software in the world is actually internal versus external, actually most software in the world is actually internal facing, which is kind of, sort of a pretty, uh, unexpected fact that you might not know if you're in Silicon Valley actually. And so once we discovered that, we're like, wow, this is a ginormous market. Like if we can change the way that 50% of all software is built, that would be really incredible. They maybe give you one specific example of this, uh, sort of how big the market is. Uh, one of our early customers, maybe customer number four or five, something like that.

636bf415768628c618c0c041

Retool's founder and CEO David Hsu goes back to the early days of ideating on and building the product, from going against the grain with his idea, finding language/market fit, and signing on early customers in the Fortune 500. 