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

Todd: So welcome to the show, David.

David: Hey, how's it going?

Todd: 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.

David: 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

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

David: 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. 

Todd: 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.

David: 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.

Todd: 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?

David: 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.

Todd: 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?

David: 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 

Todd: 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?

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

Todd: Okay.

David: 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

Todd: Ah,

David: 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.

So those are our first two customers.

Todd: 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?

David: 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.

Todd: 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?

David: 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.

Todd: 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?

David: 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

Todd: And nice.

David: 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.

Todd: Right.

David: 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

Todd: Wow.

David: 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.

Todd: 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?

David: 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.

Todd: that one didn't land.

David: 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. 

Todd: 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?

David: 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,

Todd: Okay.

David: 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.

Todd: 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.

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

Todd: 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?

David: 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.

Todd: 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?

David: 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

Todd: Why.

 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.

David: 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.

Todd: 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.

David: 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.

Todd: 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?

David: 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.

Um, they are a fortune, maybe like number two 50 or so. So, you know, sort of average Fortune five company basically. Um, they have around 120,000 employees every year. Uh, they spend $400 million building internal

Todd: Wow.

David: And, know, that's kind of sounds unbelievable. How would you spend four half a billion dollars building internal software And when you peel it back, it actually makes a lot of sense because, um, uh, you know, in their company of 125 K people, uh, round about two K of them are software engineers. And if you sort of, uh, divide, you know, $400 million by 2000 software engineers, that sped is basically 200 k per software engineer, which actually is quite a reasonable sort of software engineering salary actually. And so, and all they do day to day out is build internal software. And so that gives you a sense like sort of the market for internal software is ginormously large and it's something that you don't really see.

And so, uh, upon discovering that sort of, you know, most software actually is internal software, that was really energizing for us. Uh, because, if we can convince people and, uh, become actually the way all the software is built, that would be so impactful. And I think that is, uh, what motivates a lot of us.

Todd: Let's talk about, you know, the concept of product market. Um, because one of the things that I think is so interesting about your story, David, is to me when I hear this, it, it feels like you found product market fit pretty quickly. You know, you, you had two customers and then you had five, and then you had 10, and everybody, you know, is sort of digging the same value prop.

But I know that, you've talked about it, you've said, Well, we actually weren't sure we had product market fit for maybe a long time. Can you unpack that for us? Like what is your internal bar for product market fit?

 maybe I'll zoom back a little bit or wind back a little bit and then I'll answer that question. So, uh, part of both of it did not come that easily actually. Uh, and. It requires a lot of, I think, flexibility, but also strong opinions. think going back to sort of, you know, of startups, I, I think you sort of need to have, uh, strong opinions about a few things that will hopefully lead you to success, but you also have to be flexible about some other things too.

David: So sort of the, uh, combination I think is a very, a powerful one. So you wanna be outcomes oriented but you wanna have sort of the few values that you sort of deeply believe, you know, for us, for example, developer versus one of them. Uh, and, uh, to give you a sense of sort of early, you know, journey upon market, for us, when we first started retool, it was actually not totally evident what kind of developer would be the market were retooled.

Um, it turns out today, uh, at sort of, you know, frontend developers, backend developers and, you know, sort of react developers or doing JavaScript developers overall, I would say was sort of one, uh, major market for us, but really not evident to us. That was the case in the beginning. At the beginning actually, I remember.

Um, and this, I think, Gets also to a sense of the space of decisions you could make really is quite large. So if you think about, retool at the beginning, hypothesis we had actually was, retool is a product actually is kind of similar to something like a file maker, for example, or a Microsoft Access or a Visual Basic, And so what we should do is actually we should go find customers of File Maker and try to convince the news reto, you know, that seems sort of like a, you know, very plausible path basically to finding product market fit. And I remember I was like, that sounds pretty good. Like, let's try that. Let's see what happens.

You know, I have a lot of confidence that this is gonna work. And so, uh, what, I did is, uh, I didn't know any file developers, so, uh, I wanted LinkedIn basically filed a sort of who filed the user groups. And I was like, Let me go join these groups, basically. So I applied as a sort of FileMaker developer I, uh, sort of infiltrated these groups 

And then, uh, once I got it, I was like, Okay, great, you. A few thousand members here. Let's, you know, see who was here. Let's go try to, find where they work and maybe send them to cool emails basically. And we did that and I think we probably said, you know, a few hundred cold emails. I think we got like a, you know, 1% reply rate, something like that.

Uh, but, you know, sent a few hundreds, we got like three replies or something, I think got one call out of that into that one call. Uh, the file developer that we talk to basically said, This is a horrible idea. Uh, I cannot believe you're working on this idea. Like, file maker is great. why would I ever use anything Buffalo maker? you should again go do something else. Like, you know, if I were you, I would not waste your time on this. This is like a dead end idea basically. Uh, and you that we're like, Okay, well it's kind demotivated to hear you're telling us start about us so bad. You know this by us thinking that, uh, you know, you might have been in sort of our target market and we found market value you. And that's, I think a good example of, um, product market fit is not just the product, but actually also the market that

Todd: Right.

David: you know, retool today even a. Actually it does not really sell to pharma. Could funnel become developers. We sell to, uh, react developers nowadays for example. And, you know, we're sort of fairly successful doing that. And so I think that gives your sense like, you know, it was not, uh, finding product market, It was not like, you know, we sort of, uh, turn on the product and great, you know, product market. It happens instead of sort of very much like iterative cycle like, Hey, we believe as developers that there is value into the product like this. Now it is, let us go find the market that is sort of, uh, most interested in a product like this. think this kind of goes to sort of the, you know, strong beliefs, but maybe, uh, sort of you need to be sort of flexible with how you achieve your outcomes, uh, as well. Uh, which is we're like, okay, well great, maybe if I develop this actually not, you know, we, we sort of believe that it might be the case that they were the market, but they're not the market, so let's try somewhere else.

And so they were like, okay, well maybe CTOs of uh, operationally heavy companies, let's try that. So we emailed for example, Bucket a Door Dash or Brexit or a wrap. And that really worked. And you know, we probably tried a few other things as well, but, uh, so that I think gets the sense that sort of the space of all these we could try to start up really is quite large. And you have to sort of have a few core beliefs that guide you. You know, everyone emailed, it's basically a developer. We never emailed non-developers, even within sort of the developer umbrella, there are sort of a lot of types of developers were quite flexible about, okay, well that did not work for these reasons.

What do we learn from that? do we apply that to sort of the next audience that we go after?

Todd: Okay, But, so you know the point that you mentioned earlier, you know, 10, 20 customers build internal tools, lightning fast, that's resonating. What, wasn't that product market fit? Or you don't, you don't think that was like, when did you really start to feel like you had it?

David: I think we are quite paranoid, Uh, and, uh, every customer we, uh, had, uh, in the early days felt very one off and. This is why really it felt sort of like every customer is our last customer. Uh, because like, wow, DoorDash is building this, Brex is building this, uh, X company is building y Like this feels totally different because like actually building sort of a generic, you know, product or a platform means by all these companies.

It was really unclear and uh, because it was all outbound at the beginning, um, uh, that was actually a very good, I'm very happy we ended up doing that. Cause I think that really built a sort of strong muscle, uh, for us because it was all outbound. Like, if we didn't do anything, the company would die. I mean, most startups die.

And so, it was sort of like we had to constantly apply effort in order to sort of keep the, uh, ball rolling forward. It was kinda like pushing a giant stone uphill. Um, and if you stop pushing, it'll start rolling back down sort of fairly rapidly. And so, For us, that was our experience, uh, in the early days or maybe, you know, zero to a few million of ar.

Um, and even I think at, even at like maybe 10 million, maybe 20 million of ar I think we were actually, I remember I was still pretty concerned about that. I was like, Hey, you know, it's 10 million hour part of market, you know, I'm actually not sure. And uh, I think again, maybe that goes to paranoia. I think you always passion to be paranoid about sort of what your market is, how specific your market is, et cetera.

So for example, we like to think that the TAM for mutual is ginormously large because it's, you know, half of all software basically. But when we actually think about you, how do we tackle that tam? You know, what is the initial TAM we wanna go for? Maybe it's, you know, the initial one, maybe CTOs or VPs at operationally heavy companies.

How big is that Ham for example, you know, how saturated are we today? think about some of our customers today in FinTech we now have Stripe, Coinbase, plaid, Chime, ramp, Brx, all those customers. Are we saturated there? Like should we be thinking about like, hey, have we saturated the tam?

Should we move on other markets, Uh, so I think you have to be sort of very paranoid about this and I think for someone who is paranoid the. Admission of product market fit has not come easily to me when I hear, you know, Peter product market fit, I'm like, wow, seems like life is good.

You can just go sell to the sunset. you don't have to worry about anything. At that point, certainly It was not like that for us. Like we had a lot of things that we were thinking very critically about, even though we were at, you know, 10 20 on product and sort of arr. So I viewed product market fit as sort of a lack of stress or a lack of worry or something, or a lack of paranoia. in, you know, if you define it that way, I think should always be paranoid. 

Todd: Right. I mean, it could, it could, it could be, uh, your mentality. Like I, I think this analogy of feeling like you're pushing the rock up the hill and pushing and pushing and pushing it, and I think for some people, you know, when it starts to feel like it's rolling down the hill, that's like product market fit.

But is maybe it's just how you are. Like, are you, are you still feeling like you're pushing it and pushing it uphill? And it's never sort of started to roll down?

David: Yeah. Yeah. quite like biking. Uh, and so I think maybe biking is a good, good analogy for this, which is you can always go faster. Uh, you know, it's great. You can go Paul kill, let's say seven minutes, but why not six, for example. and so, uh, I kind of think of that. I, I kind of think of a startup as that too. And I think maybe one more thing that, uh, really motivates me is about starting a startup, is that if we were just building an average company, I wouldn't be here. Like, I wanna be building this company. And I think it's true for a lot of the team as well. I think we sort of have this unique opportunity where, uh, programming really that's been so little innovation. you know, I'd argue retool is, you know, one of the major steps of innovation and programming in the past, you know, 10, 20 years. if we are able to do this, like, you know, sort of the impact we have in the world on our customers is so phenomenal. and that I think is what really drives us today.

Like how can we build sort of an excellent, a truly excellent company that changes how an industry actually operates? Uh, that I think, uh, and if you think about it that way, you know, sort of, you always have to be paranoid. You're never sort of complete. If we think about sort of 1% of software as built to deal today, you know, a few years ago it was.

0.0001%. You know, today it's maybe like 0.00, zero 5% for example. But most software, the world still not built in retool. You know, most engineers, the world have never heard about retool. and so, uh, that I think is sort of something that we think a lot about. Like sort of what could we be doing better?

How can we grow 10 x, a hundred x maybe 10,000, or even a hundred thousand t today? 

Todd: So on this topic of product market fit, uh, thinking about advice for future founders, um, you know, if you put yourself in the shoes of a founder who is today where you were five years ago, what's a piece of advice to founders on, on how to find product market fit or like mistakes that they need to avoid?

David: Yeah, I have two pieces of Vice Early City Childers. Um, one is, uh, take more photos, which is the same you starting to hopefully grow very quickly. And, uh, a lot of the early days I surely document that. But more, more to your product market fit. Um, The way we found product market was highly iterative, uh, and extremely customer driven. And I think you have to pick it that way. Uh, I think we, first of all, were lucky that the product that we're building retool, uh, because we're all engineers at Retool. And so, uh, we're lucky that sort of, we knew the product, we knew the market. it weren't for that, I think will not have, you know, not have found a product market fit probably. Um, and because we were the customer, sort of, we had taste and sense that, oh, like, you know, a customer says I want an api, you know, I wanna be able to connect arbitrary APIs, like, That makes sense.

If I'm developer, I want that too, so let's go build it. So because we were, the customer can have good taste when it comes to, uh, strategic decisions, uh, for the company, product. Um, so I think that's one part of it is sort of you have to know the product intimately. The second is that you really have to iterate very rapidly. Um, and so for us, when I think about, uh, our sort of method or playbook, provid a product market, and today, We're starting now, uh, three or four new product lines,

Todd: Hmm.

David: for all those four actually work, uh, sort of in various, uh, stages of finding a product market as well. The way we think about it is, uh, you have very, uh, paranoid close and customer driven. and, uh, you know, more specifically with what that means is when we started retool, uh, in the product, we instrumented everything. And so anytime, uh, sort at the beginning, we had no customers. Uh, no one was retool. And so we instrumented it such that, um, we sort of added analytics in a very granular fashion that we could have a very good sense of what people were doing with the product.

So, you know, if you're dragging a table on or you're sorting the table or you're writing a sequel query, uh, or you're writing an api, query whatever else, highly instrumented.

Todd: you're using Mix Panel or you're doing this custom.

David: we actually did this in house and the reason we did this in house was, uh, developers, a lot of 'em have ad block.

Uh, and so maybe this is another, like first principles thing is, um, We wanna capture all data. Uh, a Elizabeth came to analytics basically. Um, and so, uh, uh, because that would give us a, you know, and the earliest gives us a very good sense sort what people were doing with the product basically. So we actually, you know, wrote our own server, that was, uh, we sort of send events to that server basically, and that server would then send it, uh, for example, to a big career or whatever else.

Um, and so anyways, we wrote that ourselves and, uh, that allowed us to collect a lot of analytics data from our customers. And again, at the beginning, no one was using it. So then we actually set up a sort of, uh, slack, uh, web hook that would say like, every time someone is doing anything in the product, we immediately get notified in Slack. and, uh, we had notifications on our phone at that point, right? So like, It was, uh, we sort of immediately know whenever, whenever anything happened basically. Um, and at that point, because no one used the product like we would, we had pinged very rarely, And so any time we actually got pinged, we'd immediately be watching sort of, uh, very carefully what they were doing. Uh, and that I think was highly helpful because it sort of taught us very quickly what customers are doing, because we can't always be next to customers to using the product, right? I mean, I wish we could actually, but we can't. And so this analytics kind of got us closer and then we set up c such that anytime any error occurred, we'd immediately reach out to the customer.

You know, we might have even

Todd: Oh wow.

David: even text them. We have the phone number. And, uh, so, you know, from a customer experience perspective, um, their experience was really quite intimate in the sense that, you know, using this product, run into any error immediately. The CEO calls you, you know, a minute later or something like that, uh, and they're like, Hey, I saw you into this problem.

Here's the work around, you know, whatever. We'll fix it this way, basically. Uh, and I think that, really built a lot of trust that early customers, uh, they're like, Okay, well, something goes wrong. Real's got my back. You know, they'll sort of figure it out. also taught us so much about the product because we immediately sort of learned what the sort of major, uh, buggy areas were, For example, when they were using the product, what was friction full and what we should actually go fix, how we should prioritize the product, what the use cases were, Cetera. All these things we learned sort of very rapidly because we had this very tight feedback cycle. And so let's say we found a bug, we'd go fix it, you know, the next hour or something, and then do a deploy, you know, in a few hours later or something. And of course there'd be war bugs, you know, we'll figure it out.

They have a feature request And the fact that we called them, they would say like, Hey, you know, great, you know, thanks for fixing the bug, actually also I was wondering I could do X or Y or Z or something like that. We'd be like, Oh great, well that's wonderful. Let's help you with that too. And I think, uh, sort of the customer intimacy is so helpful because lot times in a SAS product, especially sort of early days, uh, it can actually be hard give the customer on the phone with you.

Uh, because if you are always texting them and like, Hey, wanna do a build session, or, you know, use the product together, you're like, No, that's not a priority right now for me. Like, go away. I wanna put it out with myself. But when they run into a problem while using the product from a customer experience perspective, like if you call 'em at that point, that is the best thing that could possibly happen to them because they're like, Well, great, like I had, I was gonna use the product, I ran to an error you're fixing the error for me.

And also answering some other questions. That's a great

Todd: Right, Right. Especially for an engineer.

David: Yeah, totally. So that was much more effective than trying to, uh, sort of send them emails, you know, trying to get them to use the product, whatever else. Instead it was, they could choose when to use the product and when they had an error, we were immediately on it.

And so I think that really built a lot of trust, really helped us find part market fit

Todd: That's a great example of just being truly customer obsessed. let's talk about, go to market a little bit, David. I know that, you're a big proponent in the early days of outbound and, and really you were selling the product, you and your co-founders, I imagine selling the product. Um, when did you sort of start to evolve the go to market and, and bring in other folks and scale up your approach to go to market?

David: There's a lot of, uh, mixed advice on this, and we, uh, listen to some of it and we regret listen to some of it. And I think this kind of goes again, sort of the first principles thing, advice is very nuanced and sort of advice that works for one company or a group of companies may not necessarily work for you. And we had heard from multiple people, um, that, uh, hiring AEs was really important, uh, because sort of AEs will unlock, you know, giant contract sizes. They will, uh, really help you sell the product. you could focus on the product, you know, your own product, development yourself as a founder, you know, stuff like that.

And so, uh, I think our, uh, so, so first of all, actually. We hired actually pretty late. Uh, I think, uh, uh, the first of person in maybe the go to market focus that joined us, who joined us probably around a million or a million a half, maybe two, something like that. You know, sort of low single glitches and ARR actually.

And so ourselves had sold maybe 40, 50, 60 customers at that point. So it was sort of, you know, pretty, it was going basically. Um, and uh, I remember the advice that we got, uh, and uh, this is not a knock on the advice, the advice, you know, is, is true and good advice, like, you know, for from great people.

Like first of all Peter room segment, uh, who, uh, had told us, uh, that hiring ae, I think was sort of one of the biggest unlocks, uh, he had. and he was initially very skeptical of hiring AEs. He was like, How can ae sell sort of a product, uh, like segment that's so technical and the hire a and a crushed it.

They sort of did extremely well was sort of a major revenue unlock for our segment as a company. Um, and so, you know, we heard this advisor heard advisor from a few other people and we were like, Okay, let's go hire an A basically. Um, and. Uh, to be honest, we messed up. Uh, that was not, it was not effective and uh, it was because we were not, I think, first principle enough and thinking about, uh, sort of an AE can help and how AE can not help.

Um, and for us at that point, the sales process, uh, kind of going back to, we were talking about re was a very broad, horizontal product. And so it is actually quite a difficult product to sell if you don't have sort of the dynamicism or you don't have total knowledge of the product, uh, that I as a founder for example, would have. And so, uh, the sort of earliest sales team though we brought on we're actually, they were all pretty unsuccessful. And it's not their fault, it was actually our fault in the sense that the product itself was just a difficult one to sell and. It required sort of extreme, you know, extremely broad knowledge basically of developers, of customers, of use cases.

And it was just a very challenging product for anyone, uh, for any sort of a, to sell. What ended up happening was we ended up sort of hiring, uh, Initially one, then two, then three actually people, who, uh, were, uh, I would say they were maybe Comp Sci major minors, basically. So they sort of studied comp sci in college, but they weren't, uh, more interested the commercial side than being a software

Todd: Mm-hmm.

David: Uh, so more interested in business, let's say, uh, than necessarily in software engineering. hired one profile like this, uh, and we initially, you know, were not sure, uh, sort of whether this person could learn to sell retool, but they actually were much more effective than sort of the experienced AEs that we ended up, that we hired initially as well selling retool. the reason for that is I think, uh, sort of that technical background they were very dynamic and they were very good at, reacting on the spot or sort of figuring out what parts of the product were applicable parts were not.

How to talk to the product, how to talk to engineers. was much more effective, uh, for us than sort of traditional AEs. our early go to market team basically looked like three of those, uh, sort of profiles. Uh, and I think we got to, even with just two of those profiles, I think we probably got like five or eight or nine or even 10, something like that in ARR basically. Uh, and then we hired ahead of sales, uh, probably around that point, maybe between five and 10, something like that. Uh, that then scaled sort of the learnings that we had from these two or three people. we started building an A team after that. So probably the first, like, I think the first AE that we hired at that point was probably, maybe like around 10 million R or something.

We hired our first ae,

Todd: And so the way that you were thinking about it then, does that continue on today? Are you still pretty true to that? That it's a very technical sale done by, you know, technically fluent people?

David: It is, I think 50% true today. And so, for example, a lot of our sales calls, we have a sales engineer, for example, that sits there along with account executive, sort of traditional ae uh, pairing. Um, that said, I think we have invested a lot of resources in training, for example, and also marketing materials and even category creation. now, uh, half of retail customers who end up using today had users at a previous job, And so, There's just a lot more knowledge of retool in the market today, which I think really helps a lot because, uh, for example, a recent customer of hours that, uh, signed maybe just a few weeks ago actually was Chime, uh, 

That Champion that had bought Retool at Chime had actually used Retool at Brx already. so that's a good example where, the sales process was actually a lot simpler, uh, in that case, uh, because they were actually so bought in on the product because the impact that we've had on Brexit has really been quite phenomenal.

And so they're like, We want a similar impact, uh, at Chime as well. And so, uh, the sales, uh, motion, uh, changes I think the product becomes more mature, the market becomes more aware of the product offering. Uh, and so today, uh, and it's changing, we'll continue to change probably over the next 3, 4, 5.

Todd: Let's talk about this idea of operational excellence, which is something that I think you have a lot of thoughts on. And, and you know, you've said that the job of a CEO pre-product market fit is different than the job of a ceo post product market fit. What do you mean by that?

David: Yeah, so Ali Rogan, who is a YC continuity, he has a great blog host about this. It. His thesis, uh, is, and I think it's, it's completely a correct one and a very astute one is that, um, your first job as a startup ceo, when you know you're two people, five people, whatever, is to go build a product and define product market fit. Uh, you don't find product market fit, nothing else matters. Uh, your startup will die. You don't find product market fit. Um, but once you find a product market fit, then your job as the CEO actually is not necessarily to even, you know, maximize product market fit or, you know, do the exploration. Instead, it actually goes to a company can Repeatably achieve success that product market fit. Uh, and uh, that is actually, you know, sort of quite a mindset shift in you know, every day you are talking to, uh, customers and sort of working very closely with them and then even building the product, sometimes all the way to how can it build the machine that builds, uh, the product and goes to, finds more customers. that I think is a sort of very interesting sort of postpartum work of a transition. And you know, it's to me is sort of an extremely interesting and si the sense that, um, as we discussed before, I think, uh, When I think about what excites me about regional today, it is, can we build sort of a truly excellent company sort of, you know, does sales at the highest level?

Like we are not interested in growing, for example, the average of what's house companies grow. So it's like a triple, triple, double, double, double, for example, sort of the average company that goes to IPO actually grows, you know, triple, triple, double, double, double. So you 1 3 9, 18 3, 2 72 

Which I mean these companies are ipo, you know, companies, right? So like they're pretty good companies actually. Um, and yet for us it's like, hey, you know, that's actually not enough. Can we actually go further than that? Sort of what does truly excellent look like? What if we triple, triple, triple, For example, we triple four is in a row I think idea of sort of how we operate accidentally, whether it's from sort of a sales metrics perspective or go to market perspective or from a product perspective, sort of how do you sort of launch new product lines, early on in your company and have them achieve product market and have them grow hopefully, actually faster than what retool even grew in the early days, 

Um, I think that uh, the idea of sort of building a machine that can accomplish that, building a team that can go actually build a new product that can go find product market fit. I think that really is sort of my job in our job as a company today. It's like we sort of repeatably launch products that find product market fit and achieve success, get a hundred billion ar you know, a few years Um, that I think is really exciting. So that's, One reason why we're so interested in operational excellence. The second is that, uh, this kind of goes to sort of our customers actually is help a lot of our customers achieve operational excellence. And that I think is also really important, uh, to a lot of our customers too. The sense that we think about, you know, for example, why a company like Brax is able to scale so quickly. I think part of that is because they have truly great internal software, and if you think about sort of the world of, you know, business today, if you will, Most businesses are shockingly inefficient.

And I mean, I'm sure retool's shockingly few times for first round, I'm sure it's, but most companies this call are shockingly efficient. Like we have sort of spreadsheets that are floating around. We're doing CV exports daily. but that gives you a sense, sort of like there's so much, uh, room for software companies to become operationally excellent. And we think about the impact that software has had over the last, you know, 20, 30, 40, 50 years on all of us. Uh, if you think about a company like DoorDash, for example, the way that we place an order on software, the way DoorDash fills that order is via software, internal software. The way the restaurant even sort of goes about procuring food or, you know, procuring supplies, managing, their staffing.

It's all via social software. It's not a tremendous impact in the past 50 years, even in the next 10 or 20 years, we think software have a. Bigger impact, sort of all the apps that are being built today. Uh, all the spreadsheets that are getting replaced by sort of real software applications, that I think to some extent is the mission of Retool is can we sort of bring the power of software that used to be locked behind, you know, sort of, you know, you get a software here and spend a lot of time building all the software. if you could have sort of any act that you want in a few minutes, in a few days, for example, what does that mean for the world? That's something that I think its us, it gets a lot of our really excited allows a company to scale so rapidly. 

Todd: Got it. Makes sense. Let's talk about what's ahead and, uh, what's next for Retool. what are you thinking about today as you're running the company and, and what do you think about what's ahead?

 So retool, uh, despite the phenomenal group we've had over the past two years is really just getting started. You know, again, if we sort of think about what percent of softwares you think about what percent of internal software is building a retool, most people, uh, In the world. most engineers in the world have never heard about re even most engineers building internal software have never heard about retool.

David: And so for us, sort of with, you know, such an incredibly large tam, uh, the goal really is how do we sort of, uh, get more awareness, Rachel, how do we get more people aware of, uh, and sort of using Retool? And a lot of that I think comes down as sort building a really great product, expanding a product offering.

So today, for example, Retool is, uh, sort of more used for the front end is sort of a front end builder. Um, we want to expand out into backend. We're expanding on mobile apps right now. We're expanding onto workflows in the backend. We're expanding into sort of backend storage, et cetera. 2 0 3 product lines actually we're launching.

And the next actually, you know, two, three months And so finding front of market hit for those, uh, uh, getting those to, you know, 10, 20, 50, a hundred million one day, like that's sort of we're already focused on, but also improving the core product. If we sort of look at the core product itself, so much sort of a room for us to, uh, improve that. so many things we have to sort of think about from first principles, again, sort of should we reinvent, we sort of adopt best practices. So for example, uh, a good example is, uh, when you think about retool, uh, as a product, it's kind of like a new way of developing software basically. thinking about how does testing fit into that?

How does something like multiplayer fit into that? does, for example, observability, you know, how does hooking the data doc, you know, fit into that? For example, Uh, these are all sort of interesting questions. Uh, how do you verge control a, uh, visual app like that, for example, that, you know, has less code than sort of a React app, These are all sort of interesting, uh, products that we're working on, but really the goal is, uh, to, uh, in front of more people in sort of eventually, hopefully, uh, become the way all of the software is built. If we look back in 10 years and say, Wow, you know, half of all internal software is built in our retail today.

I think, uh, that would be such an incredible, uh, moment for us to look back and such an incredible sort of North star, for us to go to.

Todd: David, thank you for being here today. So many great stories. I think so many lessons that are applicable to future founders, so really appreciate it. Thank you for being on the show.

David: Yeah. Thank you do for having me.