What's up, everybody?
This is Cortland from IndieHackers.com, and you're listening to the IndieHackers podcast.
More people than ever are finding ways to build cool stuff on the internet and making
a ton of money in the process.
And on this show, I talked to these IndieHackers to learn about the latest ideas, trends, and
strategies they're taking advantage of, so the rest of us can do the same.
If you've been enjoying the show, do me a favor and leave a quick rating for us on Apple
Podcasts.
Let's just cover the show as well.
Today, I'm talking to David Hsu.
David is the founder of Retool, which helps companies build internal tools way faster
without having to code them from scratch.
What's really cool about David's story in particular is just how ambitious he is.
With the founding team, without hiring anybody, they were able to grow to about a million
dollars a year in revenue pretty quickly, and they didn't stop there.
They decided that their ambition was to change the way that people write code.
They've raised a boatload of money to accomplish that mission, and I think they might have
a shot at actually doing it.
Today, Retool is just a few years old, and they're already doing tens of millions of
dollars a year in revenue.
A big part of David and I's discussion revolves around how they're able to grow so quickly,
but also how do you decide to go big as an IndieHacker?
What does that process look like, and what are the trade-offs involved?
Enjoy the episode.
David Hsu, welcome to the IndieHackers podcast.
Thanks for having me.
I've been really excited about this.
I was looking up our history over email to try to find out when was the very first time
that we spoke.
It was actually an email you sent me that I didn't respond to, because at the time,
I thought it was automated, but now reading it, it seems like you almost typed it by hand.
It was right after you launched Retool on Hacker News.
I saw it, and I was like, oh, this is super cool.
You can build these internal tools way faster.
I had been building tons of internal tools for myself to just give me more leverage and
be more efficient running IndieHackers, and so I was like, I should use this.
I signed up, and then I think two days later, you send me an email, and you're like, hey,
it's Sunday night, but I'm working on Retool and got any questions.
I'm the CEO.
This is what I'm here for, and I just archived it, and didn't respond.
Yeah.
That was, like you said, right after we had launched the Hacker News, I think.
Yeah.
That point, Retool was tiny.
I think just a few of us, we had worked on it for a little bit.
I think this must have been in 2018.
Yeah.
August 2018, almost exactly two years ago.
Yeah.
So that was, I think, a year after we'd already gone through YC, and then we worked on Retool
doing outbound sales and coding, basically, for a year until we finally launched it.
I was so excited when I saw that you signed up, because I had already been a fan of Indie
Hackers for a while, the sort of whole Indie Hackers ethos.
I mean, we were living that at the time, right?
We were just a few of us coding away, selling away, and stuff like that.
So I was really excited to see you sign up.
I was kind of sad you didn't respond, but excited to see you when you signed up.
Well, I was excited to sign up, and we eventually started talking quite a lot, because once
I got end of the tool, I think you had like an intercom widget or something for feedback
in the bottom right, and it was early days.
So there were just features that were missing at the time.
And I was like, Hey, you know, Retool team, can you build this?
And you're super responsive.
You would reply and be like, Yeah.
And often you would, within the same day, add a new feature or push a bug fix or something.
And this just happened for probably the first couple months I was on Retool, where I would
just make all these suggestions and see all this stuff going on.
And I know you were probably doing the same song and dance with a bunch of other early
adopter customers, too.
Yeah, yeah.
It's interesting.
I'll sort of dive into it too deeply, but I think sort of from a product development
strategy perspective, a lot of people really think that sort of being very reactive or
sort of just building what customers want is, you know, oftentimes seen as a bad idea.
But I think in the early days, it's by far the best way to find product market fit.
Because how do we not build those things?
You probably would not be using Retool today.
And how do we not build those things?
All the other fire business would not be using Retool today either.
And so I think in the early days, reactive product development, just building exactly
what customers want, allows you to hone in on product market fit very quickly.
I think it's quite underrated.
I interviewed John Collison probably around the same time, a year and a half, two years
ago at an indie hackers meetup in Dublin.
And we got onto this topic of how do you as a prospective employee or maybe an investor
evaluate a startup?
If you want to see, you know, is this going to turn into something or is it going to crash
and burn?
And I think the conclusion that we worked around to was the best thing you can do is
look at where they are now, ask them about their goals and what they're working on.
And then check back, you know, in a month or two and see how much they progress with
their product, how many more customers they found, just kind of want to look at their
progress.
And I've seen this pattern over and over again as a user of software.
So 10 years ago, I was using Heroku, and I was pretty early to Heroku.
So I was in their chat too, just asking them questions, making feature suggestions.
And they were working super hard and like making all these changes based on things I
was suggesting.
And I was doing the same thing with you and Retool.
I did the same thing with the app we're using to record this podcast, Riverside.
And the founders are super responsive.
They're messaging me on Telegram, asking questions, making fixes all the time.
And the consistent trend that I've noticed is actually if instead of just using these
products and making feature suggestions, for every one of them I just invested, I probably
would have made a ton of money by now because all of these companies have had really good
turnouts.
They're all like way bigger than they were when I was like in their chat making feature
suggestions.
So it's cool to see that you fit the same mold with Retool.
Thanks.
Yeah.
It's interesting that you and John were talking about this, because I think it's a pretty
common idea that sort of, you know, it's not the, what is it, the wider set that matters,
it's really the slope that matters.
And everyone says that, obviously, but I was like, okay, yeah, sure, whatever, you know,
that's what people say.
But I experienced it firsthand during YC, which I know you also went through.
But during YC, because everyone comes in at a very different wider set, right?
Some people come in with no ideas, some people come with an idea, but no code written, some
people come in with, you know, a million dollars in ARR or whatever else.
And it's interesting of the sort of, sort of no matter where, if you look at, you know,
the batch that we were in, sort of no matter where people came in, the biggest successes
today, if you look at it, were the people who made the most progress, rather than sort
of, you came in with 500K of revenue and, you know, because I remember during YC, I
was so intimidated by them.
I was like, wow, if 500K of revenue, we have no revenue, no customers, how are we ever
going to catch up?
It's ridiculous.
And yet, I think progress is much more important.
The other thing I think about is, one half of the equation is, okay, you're making all
this progress, and you're being responsive to customers.
But on the other hand, like, I was still using retool despite, like, it missing, thanks.
I was still using Heroku despite it missing things, like, I was still using Riverside,
despite there being like bugs and errors, I wonder where your opinion is on this, like,
how much more important is it that you're building something in a market where customers
love what you're doing or need what you're doing so much that they're willing to put
up with a bunch of crap versus how responsive you are to all the crap that they're complaining
about.
Yeah, I think that's really interesting.
When I use products now, oftentimes, I sort of am most excited about the products that
are semi unpolished, and I can sort of see the rough edges, or I can see the bugs, because
then I almost feel as if the product was sort of more powerful, or as they built for me,
or you know, something like that.
Whereas when I see a really polished product, I almost feel it, oh, you know, there's probably
knowledge improvement to be had at this point, it's already pretty mature or whatever else.
So I'm always more excited by the products that have rough edges.
But to your point, I think, you know, exactly, I think the product market fit is much more
important than how polished a product is, especially in the early days.
Even today, I think retool has a lot of rough edges and a lot of things we could be improving
on.
But it's fortunate that we have product market fit, and I found customers that use it despite
the bugs.
It's a good litmus test, I think.
So let's talk about your market, because I think the space that retool is operating
in is something that would be super insightful for most founders to just know more about,
even if it just gives them like sort of general business principles.
But like specifically, there's a lot of trends going on, a lot of opportunities to build
in the space.
And I think what you're doing is obviously incredible.
So what is retool?
And how would you describe the market that you're serving?
Yeah, so retool, our goal is to be a fundamentally new way of building software.
The idea is you sort of look at building software for the past 10, 20, 30 years, the building
itself actually hasn't changed very much.
I mean, you and I are both engineers, right?
So we sit in front of a computer, and we basically just write code.
The code itself has changed.
Maybe 20 years ago, we were writing Java, 10 years ago, we were writing JavaScript.
Today we're writing JavaScript.
It's ES6 now, I guess.
But fundamentally, it's the same stuff.
To get a computer to do things, you sort of write these tokens.
You define functions, and you call functions, and you know that things happen.
The idea behind retool is that, hey, for a large class of software, we're starting with
internal software specifically, so internal tools, basically.
The idea is that for this very large class of software, maybe there could be a much higher
level way of building this stuff.
Instead of, let's say, working in writing JSX, sort of working on every dom note individually,
what if you could sort of have a drag and drop interface where you say, hey, I want
a table, I want a button, so you drag on a table, drag on a button, you say, hey, this
button should make a post request, and it should make it to this endpoint or something.
And so you can sort of use a drag and drop interface to get to something like 50%, 60%
of the way, so it's very fast, but then customize the sort of remaining 30-ish percent, let's
say, by actually writing code.
So that's what retool is sort of in a nutshell.
It's kind of interesting, because when we first started, and when you think about retool
as like an abstract idea, you're basically giving developers a drag and drop way of building
software.
And that sounds sort of antithetical to what every developer wants, right?
No developer wants to use a drag and drop sort of tool to build things, and yet people
do actually use retool.
And I think part of it is, you know, to your point, I think if you're able to find sort
of a product market fit, or in our case, I think developers really don't like building
internal tools.
I love to hear your story about how you started using retool, but I think developers fundamentally
really don't like building internal tools, and so they're like, oh, you know, there's
a faster way of doing it.
It is drag and drop, but hey, you know, it's actually much faster, and it's actually pretty
flexible because I can write code, so let's give it a try and see what happens.
Yeah, probably the trend most people will be familiar with today is no code, which are
all these tools that are trying to empower non-developers to build things that previously
only developers could build.
But retool is very much targeted at developers, which I think is an interesting take.
And like, you're right, like, theoretically just sitting down if you'd ask me, do you
want to drop drag and drop interface to build stuff, I would say no, but like, maybe that's
because in my experience, almost all drag and drop stuff is tried to abstract away the
idea that there's code here.
And it's not as powerful because it doesn't cater to developers, it caters to non-developers.
And I also think there's like another part of it where developers are just like skeptical
and a little bit defensive, like, nobody wants to hear that, like, oh, your job is going
to be taken away by like some automated tool.
I was reading a thread on Hacker News the other day about no code, and I think the take
and the actual post itself was like pretty reasonable.
But of course, 99% of the comments were, no code has no future, you can never replace
developers, etc, etc.
So I think we've got like, you know, maybe a little bit of a bias, a little bit of an
incentive to not want no code stuff to work.
Yeah, it's interesting.
Two things.
First of all, when we started retool, there was no sort of low code or no code space.
And so it's been kind of interesting sort of watching space sort of happen around you.
I don't know if it caused any way, but I think we certainly benefited in a bunch of ways.
For example, there's more enterprise interest, for example, low code, no code stuff today,
as well as investor interest, which has been helpful for us.
But secondly, I think I agree that I think most people talk about no code.
But if you really think about it, I think low code is actually more interesting.
And the reason is, if you think about no code, it's basically, you know, you sort of can
customize software without writing code at all.
And that's pretty good for, you know, some use cases, or maybe even sort of a good chunk
of use cases.
But fundamentally, a lot of the software that people want, they really want to be able to
customize it, right?
And it turns out that writing code is a pretty good way of getting computer to do something.
Probably a pretty good example, actually, if you think about like a switch statement.
So a switch statement is pretty simple for you to write in code, you know, you say, switch
this case one, case two, case three, case four, whatever, it's pretty simple, right?
What if you're trying to do it in a GUI, it's actually pretty hard, you know, you might
want to start drawing sort of nodes, you might want to start drawing edges, it gets pretty
complicated, right?
And so I think code is a pretty good way of getting computer to do something.
And so I think the real opportunity really is sort of combining both approaches of no
code, but also code, so maybe, you know, use no code to get to something like 50, 60, 70
percent of what you want.
But the last 30 or 40 percent, I do think you have to customize with code, I don't think
code is going to be going away anytime soon, probably bet that, you know, 20 years, I'm
still writing code, I would bet.
And so I think the combination is what is really powerful, and I think that is a sort
of fertile ground for exploration today.
I love that you're building in the low code space, but you're long on code, you think
code is here to stay.
And it almost seems like that will be the opposite, like why are you doing low code
tools if you think code's going to be around for a while, but like it makes sense, you
want if people are going to keep coding to make it easier and make them more productive.
So you're in the low code space, not the no code space.
And I think most people think the opposite way, they focus more on like the trends and
the fads.
There's a famous Jeff Bezos quote where people are asking him, you know, what's going to
be different in 10 years?
And he's like, I don't care about what's going to be different, I care about what's going
to be the same in 10 years.
And if you're just focusing on these fads, and you're always trying to sell shovels to
people in the next gold rush, then when the gold rush ends, or when the fad goes away,
like you have nobody to sell shovels to.
So I like your approach, I think it's much smarter, and if you can build on sort of an
enduring trend, then it's much less risky, it's probably going to be around for a while,
it's something you can bet your company on.
And the trend has just more time to grow and get bigger as more and more people learn how
to code.
Yeah, yeah.
It's interesting.
If you look at the major SaaS companies over the last maybe five, 10 years, I guess I'm
thinking mostly about developer facing ones, if you think about Stripe, Twilio, to some
of the MongoDB, all these things are infra E, right?
The goal is to enable other businesses to do more things, right?
So like process payments, start companies, send text messages, telephony, all that kind
of fun stuff.
So yeah, agreed.
I think we're lucky to be selling shovels.
Even in the consumer facing world, I mean, you've got all these different creator economy
platforms that are enabling people to build these businesses they never would have.
And so you got people on Shopify and Etsy, you've got all these YouTubers, Twitch streamers,
sub-stack authors, and now they're all running like these online businesses.
And you can come in and provide lots of tools, shovels basically, that just give them more
leverage so they can do what they're doing better.
You can help them clip up their YouTube videos and promote them on social media.
You can help them make their TikTok videos have all these cool special effects.
You can, you know, spruce up the Shopify store, whatever it is.
And there's just a ton of ideas here that I think people should explore.
And we'll get into this and how you're doing this in the low code space.
But before we do, I want to talk about the early days of retool, because you're able
to get to something like seven figures a year in revenue with just the founding team.
And then you decided to go big.
So I want to talk about how you did that, how you grew so quickly, and also how you
came up with the idea for retool in the first place.
Yeah, first of all, thanks.
We're indie hackers, you know, we wanted to start smalls and see how far we can go.
So when we started retool, we started it because we ourselves built a lot of internal tools.
We'd actually previously started a different company.
It was in the fintech space, it was two of us, it was really didn't go anywhere, so it
was really a failure.
But during that period, we ourselves built a lot of internal tools, and you can imagine
sort of, you know, the internal tools that Stripe might have, right?
It's a lot of sort of stuff around no KYC laws, around AML laws, a lot of regulatory
things, a lot of fraud things, etc.
And when you build enough internal tools, I'm sure you went through this yourself, when
you build enough internal tools, you realize that all these tools, despite doing very different
things, all kind of look the same and basically have the same building blocks.
And so, you know, whether, for example, for you guys and indie hackers, it's, let's say, managing the community, for example.
That tool is very different, conceptually, from a tool that Stripe might have to, let's
say, find risky merchants or whatever else.
But fundamentally, the building blocks are basically the same.
It's basically tables, buttons, forms, text inputs, dropdowns, stuff like that, right?
And so the idea really came from the fact that, you know, I think we're all engineers,
and so we were a little bit lazy and thinking to ourselves, hey, you know, maybe that could
be a faster way of building all these internal front ends, as opposed to just writing code
from scratch every single time.
So that's where the idea of retool came from.
And when we went through YC for probably around a year after YC, we didn't hire at all.
I think part of it was, having gone through YC yourself, you've probably seen this too.
I think from the outside, YC company seems so successful.
And when you get into YC, you feel so great, you feel so amazing.
But in reality, when you get into YC, and then when you graduate YC, within six months,
something like 20, 30% of the companies are dead, for a variety of reasons.
And so for us, we were always extremely scared of death.
We were always very worried we'd be sort of one of the companies that graduated, raised
the seed round, seemed really hot, whatever else, but then three months later, shut down.
And so our genius strategy to not die was to not burn money.
And so we just didn't spend any money, so we just didn't hire anybody.
And so that's really sort of where the fear of death is where the motivation for not hiring
came from.
But I think that not hiring in the early days actually has a lot of advantages later on,
even if you do decide to raise money.
I think, A, it really builds your muscle for a lot of things to do at the company.
For example, I know of many technical founders, for example, who say, okay, I built a product,
I'm just going to go hire somebody to sell this thing for me.
I think that very rarely works.
In our case, we had no one to sell it.
So we had to sell it ourselves.
We had to do support ourselves.
We had to do marketing ourselves.
Everything sort of, you know, we did ourselves and we actually learned quite a bit by doing
that.
I think, I'm trying to think, when you signed up, we were probably at maybe 500 can revenue,
something around there.
And the team was still...
Oh, wow.
So you had a ton of revenue before you launched?
Yeah, yeah.
I think people always say you can launch multiple times.
I'm not sure I entirely agree with that.
I think especially on Hacker News, there is fatigue if you launch five times and nothing
happens the sixth time, you know.
You can certainly exhaust a channel for sure.
Exactly.
And in our case, I think for a developer tool, Hacker News is the place where you want to
be, possibly a product hunt as well, but really I think Hacker News.
And so for us, we want to launch once.
I think at that point, we had maybe 20, maybe 30 customers together, you know, around four
or five Duquesne revenue or something.
So once we got to 20, 30 customers, we ourselves were fairly confident that we were on to something
interesting at least, because probably not 20, 30 people were crazy.
Yeah, I mean, that's a lot of money per customer, $500,000 a year, 25 customers, not that many
customers.
That's like $20,000 a year per customer.
That's way more than most indie hackers charge for their very first sort of beta products.
And what's cool is you weren't doing this with an enterprise sales team that you went
out and hired.
It was just the founders doing the sales yourself.
The same way that every other indie hacker does sales, which is charging way more per
person.
So I'm going to dive into this.
But not quite pricing yet.
I want to talk about the idea because you mentioned something that I love, which is
that you were working on something else and you had to build all these internal tools.
And then you realize like that was a much better idea.
And I always suggest that people, you know, come up with ideas by starting something,
anything.
And in the course of running that business, like you'll probably have better ideas.
So I'm sure you had lots of ideas while you were working on your other business.
Why did retool stand out among all of them as the most promising?
First of all, I just want to agree with you on that.
I think when you try to come with startup ideas in a vacuum, it's actually really, really
hard.
And all the startup ideas you come up with are maybe plausible sounding, but probably
don't actually have a market because you're trying to build for yourself and don't actually
have an experience.
Right.
And so it's funny because before starting retool, we didn't have that many ideas, really.
But ever since starting, we actually have many more ideas.
And of course, we're working on retool, and retool is going pretty well, so we're focused
on it.
But it is funny that by starting things, you actually get much more ideas, many more ideas.
So when we decided to start working on retool, I think most of, we had a few other ideas
too.
I know a few friends who sort of write down 10 ideas on a whiteboard, and they just try
to buy AdWords for all of them.
And then they try to sort of optimize the CPC and everything, and then they try to calculate
and then they build a landing page or everything, they build 10 landing pages for all their
10 ideas.
I think that strategy very rarely works because the signal that you get in the early days
is so noisy.
You might get one sign up, and you might feel so excited and sort of on top of the world
early that one sign up might not mean anything.
Right.
And so in our case, we picked retool primarily because we ourselves had the problem before.
And so we thought we can't be that weird.
Maybe other people have a similar worldview set of problems, stuff like that, as us.
But I think also we just, maybe because we had the problem before, we're also highly
convicted about retool because we're also like, this is something that we will certainly
use.
So I think instead of doing, let's say, a lot of market sizing research, googling, let's
say, internal tools, market size or something like that, or trying to build landing pages
and buying ads for them, I think conviction really is by far the best way to decide on
a startup idea.
I think it could go wrong, to be clear, but I think if it, you know, for the starters,
that went well.
I think it really almost always was conviction.
So if you look at companies like big ones today, it would be quite stupid to say like
Airbnb, Stripe, Airbnb sounds like a pretty stupid idea, right?
I think there is that the joke where I think when they were initially looking at market
sizes, they calculated it based on how many air beds there are, or how many air beds are
being manufactured every year.
And if all air beds eventually come out of Airbnb, how big is the market, right?
And so I think a lot of the analysis is kind of stupid.
It doesn't really get you anywhere or doesn't build up conviction, or it should not be the
reason to start a company.
I'm big on conviction, too.
I think most companies die because the founders quit.
But there's also this very classic problem of being an overly optimistic founder, where
nobody and nothing can tell you that your idea is not a good one.
You're just super convicted.
And no matter what you run into, you just never pivot, you never change.
And you just have this really terrible idea that you're just beholden to for year after
year.
How do you avoid that?
How do you make sure that your conviction alone is something you can trust if you're
not going to do all this market sizing and idea validation and really just delving into
things to make sure it's actually a good idea?
You should look at the market sizing in general.
In our case, I think we're quite fortunate where our goal is to change the way software
is built.
It's a pretty big market.
There's something like 20 million developers in the world.
And 20 million times, let's say, average 100k salary per developer are pretty big numbers.
So I guess we don't worry too much about that.
But I do agree with you.
I think you should look at the market just to get an overall take.
But that's it.
I do think there's almost always a path out of every small sounding market.
It's like the airbed thing.
If you do the back of the album calculation, the market for airbeds is probably not that
big, especially airbed rentals on a daily basis.
Sounds pretty small.
And yet, the path out, and that way maybe has a tremendously large market opportunity.
It has captured a lot of it already.
So I think there almost always are ways out as long as they're able to find early adopters.
And I think the early adopters are mostly found via conviction, or via your conviction
that you can find them.
And you find people who are similar to you, hopefully, if you're working on a problem
that you yourself had or want solved.
So I think market sizing is somewhat important.
But I want to focus on it because I think there's sort of a way out of it anyways.
I do think it is important, despite having conviction, to gather feedback from the market.
Because you will probably learn things.
I think what most will give you feedback, it doesn't come from a place of, they're not
trying to sort of intentionally shit on you, or they're not evil, right?
They're giving feedback, probably, they're not lying to you, probably, like, they're
intentions are pure, basically, to give you feedback.
And so this actually happened to us, where we started retool, well, the first thing to
say, yes, your second question.
The first thing we did was just write code.
And then, after we built an MVP, we attempted to find people who might use, who would try
to find customers, basically.
And the first thing we did was, conceptually, retool is quite similar to something called
FileMaker.
It's a company that I think Apple bought maybe 20, 25 years ago, something around there.
It's also conceptually somewhat similar to Microsoft Access.
And so our idea was, OK, given that retool is similar to these two things, but substantially
newer, maybe more high performance, better because a lot of other reasons, we could try
to find people who use Access and FileMaker and see what they think of a retool.
And so I remember, I went on to LinkedIn, found a FileMaker user group, pretended to
be a FileMaker developer, I think I changed my title to LinkedIn, actually, and then applied
for membership in the group, got in, saw the 300 or so members, and then started cold emailing
every single one of them, saying, hey, I know you use FileMaker, I saw you in this group,
I was also a FileMaker user back in the day, I would love to show you retool, which is
a slightly different spin of FileMaker and is, you know, better in these ways, worse
in these ways, would love to get your feedback.
And out of the 300 or so emails that we sent, I think we got maybe three replies.
So the reply was kind of dismal, given that, you know, I was targeting FileMaker developers,
right?
And of the three replies, I think all three of them told us retool was a terrible idea
and that they would never use it and that we should probably go work on something else,
because it's such a bad idea.
We should not waste their views on this.
And so I think it's important to have conviction, but also when you gather data, I don't think
they were telling this to us to sort of veer us off course or, you know, to be evil or
whatever else, right?
I think they really believed it.
You know, they really believed that they did not have any use for retool.
And so in that case, I think you should sort of take into account this new information.
And in our case, what we found is actually the market is not FileMaker developers or
Microsoft Access users, rather it is sort of software engineers who are building internal
front ends with React, Vue, Angular, or whatever else.
And we've pivoted, quote unquote, our market to that.
And now it's gone, you know, quite a bit better, you know, now when we send emails, the sponsor
is a little bit higher and we don't have 100% rejection rate anymore.
And so I think, or maybe two lessons, one is that you should have conviction, but you
should also be willing to change and be flexible to change your conviction, depending on sort
of the information that you find.
Because most of the information you get, I think is comes from a good place and they're
not trying to mislead you.
But secondly, I think it is an interesting product market fit, where I think when most
people, at least we thought about it this way, we think about product market fit.
You mostly think about how could I change my product to serve the market?
And so, you know, most people pivot the product, they don't pivot their market, right?
But in reality, I think product market fit is two dials, even more dimensions than just
twisting it up and down a little bit, you know, you can sort of twist your product dial,
but you can also twist the market dial.
And in our case, the product dial is working, you know, if you think about the product that
we sell today, compared to the product that we had three years ago, we have a lot more
features, a lot more bills and whistles, but fundamentally, it's the same thing.
It's just the market has changed.
And now this market is much more receptive to retool than the file maker or Microsoft
Access market that we thought we should go after.
I love that.
So if you don't have the conviction, when you get the negative feedback, you're not
going to stick with it, you're going to bail.
And it turns out if your idea is pretty good, like maybe the timing is slightly earlier,
maybe like you're talking to the wrong customers, and so you need that conviction to push through
that sort of early adversity, which in my experience is pretty common, even with ideas
that tend to work.
Like the very first podcast guest I had, episode number one was this guy, Jason, and he has
this like really cool product where if you're making music, what you probably want to do
is like market your music.
And so there's all these different music blogs out there.
And musicians and producers will like submit their music to these blogs and be like, hey,
would you like push my song to your audience?
And he ran one of these big music blogs.
And he eventually created like a SaaS app that allows you to like submit to all the
different blogs for like a dollar a song or something.
And he had to email like a thousand people in the first like four months.
And everyone was like, no, we're not going to use it.
Like this is so stupid.
Like it eventually worked.
And like almost all those naysayers are using it, but like he just had the conviction to
push through.
And I've had like, even with indie hackers, emailed 140 people to get my first 10 interviews.
And like the vast majority of the people I emailed were like, this is the dumbest thing
I've ever heard.
I would never share my like my revenue.
Are you crazy?
And now a lot of those people have been on indie hackers, like my good friend Vincent
Cole.
He rejected me like stone colds.
Like I would never do this.
And he's been on the podcast twice and shares like all of his revenue numbers and all sorts
of stuff.
So it's pretty fascinating to see how important it is to kind of push through that early sort
of negative feedback if you get it.
Yeah.
I think this is one of the big values of YC is hearing how fucked startups were in the
early days, sort of how difficult it was in the early days.
Because then you're like, Oh, actually, I could do that too.
You know, it's not like sort of everything immediately went well from day zero.
And it's been amazing since then when you learn about sort of the early stories, then
you hear it wisely.
But even at YC startup school, when you listen to the talks online, it is crazy how much
adversity almost every startup experiences in the early days.
And if you push through, you know, you may really even become strep or whatever else,
right?
And it's really incredible.
Also curious about like the shape of your growth in the early days, because you don't
necessarily know you're on a really good trajectory, right?
Were you growing linearly?
Were you growing as potentially like how obvious was it that you were really onto something?
It was mostly linear.
And for a while, that was actually very worrying, because I think if you look at any exponential
curve at the very beginning, it also kind of looks linear.
So, you know, when you go from 1000 to 1500 in revenue, it's like, yeah, it's 50% growth,
but it doesn't sound like that much, right?
It's $550 or something, right?
And so for maybe the first six to nine months, I would say we were quite worried actually,
that the growth was too linear and that, you know, this was sort of never take off.
And that was quite concerning to us.
Part of why it was linear, I think, was because we never got in the early days, we didn't
get the flywheel really go.
And so if you think about how most sort of B2B companies start, at least in our case,
we started by doing outback, because no one heard about retool, right, you know?
And so in order to get customers, we actually just had to go email people that we didn't
know.
Also, our networks weren't that big, so we had to go email people that we didn't know.
And there was a lot of iteration on sort of the exact outbound messaging, you know, we
tried the file maker thing, that didn't go very well, and then we pivoted over into building
internal tools faster, etc., so we tried a few different things.
But in the early days, it really was, we sent outbound emails, we get some demos.
Of the demos, we do the demos, see if they're interested, etc.
A lot of people say no, some people say yes, and the people that say yes are probably not
ready for them.
So we have to go and build all the features required to actually get them to use retool.
And then you repeat that, basically.
It's also interesting because I think people's memories of the early days are oftentimes
quite rosy, and I think if you talk to any most successful founders you guys have had
on this podcast, it's easy to forget how much adversity there was in the early days.
But I looked back at my calendar, actually, because in my head, I'm thinking, oh yeah,
sales was so easy back in the day, we just do demos, they'd close, maybe 80% win rate,
something like that, whatever, right?
When I look back at my calendar, I see sort of all the demos that I did three years ago,
and I remember getting so excited about, you know, everyone's opportunities, and then when
you look at how many of them actually closed, only maybe 5% or 10% of them actually closed.
It's funny that when I think back to it, when I look at the calendar, it's like, oh, you
know, sales was so good back then, you know, it was so easy, but in reality, we do 20 demos,
maybe three out of the 20 would be somewhat positive, and then of those three would lose
two of them anyways, and then eventually close one.
And so there was a lot of cold outbounding in the early days, and because of that, it's
quite linear, because we never got word of mouth really going in the beginning.
Once we hit 23 customers at launch, I think word of mouth really started getting going,
and now it's very exponential.
But in the early days, it was definitely linear, and I think all sorts are kind of that way.
How important was it for you to get better at sales as a founder?
Was it like a thing where you're just improving your skills, you're sending better cold emails,
you're doing a better job demoing, or was it more so that you were just learning about
your market and picking the right people to talk to and the right pitch to give?
I think both, which is, I think, why founder-led sales is so important.
On this second point, I think you learn a lot doing sales.
You learn a lot more about your product doing sales than even building the product, I think.
Because you talk to customers, you see what their needs are, you see what they like, you
see what they don't like.
You mention particular features, their eyes light up, you mention other features, they
don't care about them.
And so there is, you sort of really hone down on the messaging, how you talk about the product,
what you should be building what your product should look like by talking to customers,
not by building product, which is kind of counterintuitive.
Was there like a turning point for you, where you're like, oh, this is really resonating,
we're building the right features, I'm saying the right things, and it just got easier?
Eventually, yes.
I think for a very long time, we thought we did not have product market fit.
We thought that we just found 30 people, 50 people, 100 people, 1000 people that liked
retool, but maybe they were all kind of defective in their own way or something.
Like maybe this Courtland guy, he likes retool, but he's kind of a weird guy, so it's gonna
be hard to find that many more Courtlands, surely.
So for a very long time, I actually didn't think we had product market fit.
That said, I do think that it did appear that demos are resonating, but then again, I mean,
given the fact that we did 20 demos, 17 of them didn't go well, yeah, maybe three resonated,
but really, I think we were focused on 17 that didn't go well, rather than three that
went well.
But emotionally, it felt that we were not making that much progress, our proposals were
quite slow, even though of those three, if we close one, that's actually a huge win for
a small company of a few people.
I think what's good about this is that you had a business model that allows you to do
this.
For example, I talked to a lot of people selling their apps for like 10, 15 bucks a month.
And if they spent all their time doing sales, and they're closing like, you know, three
out of 20 demos, they would end up with like 45 bucks a month, and they would have to like
go get a job.
It just doesn't work.
You, on the other hand, 2030 customers got you to 500 grand a year.
That's insane.
You're obviously charging quite a lot of money.
How did you decide what to charge, sort of land on like that high of a revenue point?
Yeah, I think a lot of it is pushing boundaries.
I think most people overestimate the irreversibility of pricing or quoting pricing specifically.
And so I remember in our sale number 123, something that sort of first few sales, we
were visiting the office of a potential customer.
And I think they had news retool, they liked it, and they were thinking about purchasing
retool.
And so the founder of this company pulled me aside and said, okay, cool.
So ritual things sounds pretty interesting.
How much is it going to cost us?
And I remember thinking on the spot, you know, what is a ridiculous number that I could name?
We'd be really, really happy about it.
And so I think I said something along the lines of maybe 2K a month, maybe 2.5K a month
or something, you know, some some high numbers.
To me, that was an incredibly high number at that point in time.
And I remember the reaction, I think it was a silence for maybe a few seconds, maybe five
or 10 seconds.
And then it was it was like, there's no way that could potentially work because, you know,
look at the office that we have.
It's a nice office.
This office only costs us to, you know, 2.5, 3K a month.
You know, we're not going to pay you 2.5K a month for software.
That's ridiculous.
Right.
And so I think you should quote high prices because there's almost no downside to doing
it.
You're not shocked at the price, but you could always just cave and go down in the early
days.
You can.
Because I think when you get bigger, you definitely need pricing, regularity, and you can't give
big discounts.
It's eventually word always gets out and everything.
So now, regional pricing is very regular and structured.
But in the early days, if you go 2.5K and they laugh at you or just walk away, you can
come back to them and say, so what price would you do it at?
And they say, let's say 50 bucks a month, 15 bucks a month.
You can just say, how about 100?
And they probably say yes.
And then you sign.
They also feel great about it because they feel like they got a great deal and you feel
great because you got a customer and you tested the price and you found the 2.5K is probably
too high for this particular customer.
So I think most price quotes are in the early days.
If you have a good relationship with the customer, very reversible.
As you get bigger, I think it's totally changing.
The earlier point of no customers, I would just quote progressively higher prices and
see what they say.
Until people start saying no and they say no, just go back down again and then start
from there and start quoting higher prices again and see what happens.
It's a good feedback loop too because the fact that you were able to do this is only
possible because you're having these in person or at least on the phone sales conversations.
One on one with an actual human being or they can say something and you can respond.
Yes.
Never quote pricing or email.
Never do that.
Because they might just go away and you have no idea what the reaction was.
Exactly.
There's no reaction.
And even worse is just not talking to anybody, building something new, putting up a landing
page and a pricing page and then just launching on product time.
And okay, well of course you're going to be afraid to put a high number because this is
your launch or something and you don't want to waste it.
So I think everyone should have like this sort of early phase where they're doing this
talking to customers.
And you can't really afford to have this phase where you're trying to grow one, two customers
at a time unless you're charging a lot.
So it's a kind of two phenomenon that play off of each other.
Yeah, I think sales gets a bad rap for many technical founders.
Maybe they view it as like below them or something else.
But really sales I think is the real work to be done and start an early stage company.
You have to write the code and build a product.
But really sales is sort of where the rubber meets the road.
You can test a product with a customer, see what they think, see what the messaging is,
test out pricing, understand the value prop, all these things that make your startup successful.
I think really you find out by doing sales in the early days.
And so I really don't think this is something you can outsource.
So another thing I see happen often with early stage founders is they get distracted and
lose focus.
And when you haven't found product market fit, you're not 100% sure like what's going
to work, what's not going to work.
It's hard to follow a particular thread in a certain direction.
So I want to put you on the spot here.
Like number one, how did you get around that?
But also you mentioned earlier that you did have ideas and things did cross your mind.
Building retool.
What are some ideas that you think people should be building that you wish existed that
you don't have time to build because you're building retool?
On the second briefly, the funny thing now is I'm not looking for startup ideas anymore.
So I don't write them down.
So they kind of just pass those like, that would be an interesting idea, huh?
Just pass it through.
So I actually don't have any good advice now.
I'll think about that a bit more.
I send you an email.
How about this, what do you pay for?
What do you pay for retool?
What tools do you use?
What helped you get to the size that you're at right now?
I can tell you, I pay for retool.
I just looked at my invoice, 250 bucks.
I pay Upwork a decent amount of money.
We spend a lot of time finding contractors and stuff and I wish there's better, more
like vertically integrated Upwork platforms that would allow you to hire very specific
jobs because it's kind of general and it's hard to find someone good.
I want a place where I could just go hire great writers.
That I agree with.
We use Upwork as well sometimes for enriching emails for doing Outbound and it takes a lot
of trial and error to find the right people.
So much trial and error.
And if there were a vetted platform, we would use that.
One maybe small thing that we would use is right now we use Slack to manage all of our
relationships with customers.
We use shared Slack channels basically.
I think it provides quite a good experience if done properly for the customer because
they can just Slack you and get a reply very quickly.
At this point, we have a lot of Slack channels, I think hundreds, maybe thousands of shared
Slack channels.
And so it's quite hard managing all of them and trying to sort of do a sort of support
ticketing system.
So that I think is an interesting idea.
That said, I have had two friends start this and then pivot away from it.
So maybe there are problems with the idea, but I think a priority, it sounds like an
interesting idea and that's something that we would use.
So let's fast forward here a little bit because you eventually kind of figured it out and
you eventually made like a pretty big decision to raise a ton of money.
So recently you announced raising $50 million, which is an unfathomable number of dollars.
That is more dollars than there are seconds in a year.
I cannot count to 50 million.
If I tried to count to 50 million, the pandemic will be over, there'll be a vaccine or it'll
be very different because it would be like 2022 before I finished.
And that's a huge decision to make as a founder, especially when you had such a sweet get going
where you were just making many hundreds of thousands of dollars a month as a tiny team.
And you could have probably just kept doing that indefinitely and just lived a good life.
And you had raised money beforehand.
I think you said you raised a million dollars.
How much of that had you spent?
Oh, I think we spent very, very, maybe 100K, maybe 200K, some amount, yeah, it was very
little.
Okay.
So you're burning almost no cash, you're making money hand over fist.
Why go big?
Why raise a bunch of money from investors?
So the goal for retail, I think the market for retail for us is quite potentially quite
large.
And our goal is to be the way software is built.
And if we can be the way software is built, the market for that is phenomenally large.
It is unimaginable.
It's much, much larger than 50 million, you know, it'll take many years to count to sort
of how many dollars that market is.
So I think the fact the market was very large and the fact that it's pretty wide open right
now, the fact that the way that software engineers built software is literally by writing code,
which seems so primitive in retrospect, was the reason we thought, hey, the opportunity
is so big, we should really capitalize the opportunity as quickly as possible.
And that means raising money to have more resources.
That said, I think a lot of the downsides, I love to maybe hear about some of the downsides
you've heard, a lot of the downsides can be mitigated if you are fairly disciplined regarding
your financial health.
So in our case, we raised the seed round in October 2017, raised around a million dollars.
In March of 20, maybe April, May, something like that of 2019, raised the Series A round
about $24 million, and then a Series B this month around $15 million.
And practically all that money is still in the bank.
And I think what's interesting is if you are an indie hacker and are able to get to a point
where you're profitable, it's actually surprisingly hard to ever become unprofitable.
But B, it gives you incredible leverage on investors to raise very good on very good
terms and very good reps.
So on point A, if you think about, let's say you're profitable, you're a few people making
a few, you know, say $700,000 revenue or something, I think that's roundabout what we launched,
I think.
If you're doing that way, the revenue is growing, let's say 5x year on year, let's say grow
from, you know, 7, sometimes K3.5 next year to 15, whatever else, it's actually quite
hard to grow a company 5x year on year.
I think, you know, the first year growing, let's say, you know, a few people, 3, 4, let's
say something like, you know, 16, 20, 15, 20, that is manageable, but then growing the
company again 5x from 20 people to around 100 people is actually quite difficult.
It's very hard to keep up headcount growth with revenue growth.
And so if you're lucky enough to have very fast revenue growth, it's actually just very
hard to become unprofitable.
It's actually hard to find places to spend money, really, besides headcount, right, for
a SaaS company.
And so you are sort of in this very good place where you're sort of always, you know, either
close to profitable, and it's very hard to get your way out of it.
It's very hard to become that unprofitable, actually.
So you just set yourself up for success in the next, you know, five, maybe even 10 years
to come, which I think is really interesting.
On the second point, I think when you are in that position, raising money becomes so
easy, because you don't need money.
You know, in our case, we raised our Series A, we could have just not raised.
I mean, we had burned so little money, and we were making so much money, and the team
was so small, that for us to organically grow, I think when we raised the Series B on the
Series A, I think we burned maybe 100k, maybe 500k, something around there, you know, really
not much money out of the $25 million at that point, $24 million at that point, we'd burn
$148 billion or something like that, right?
And that, I think, is a tremendous leverage.
And so if you're able to get the correct terms or very good terms, then it's almost like
free cash.
I mean, it's true, you're giving us some equity, but I actually do think if you find the right
investors to actually do it themselves, add a lot of value, as even though you sell 5%
of the company, I think we sold maybe 5, 6% of the Series B, the value that you get from
the investor easily makes up for the 5% or the company's probably more likely to succeed
or buy at least 5% or 6% because of the investor coming in who actually is pretty helpful.
Okay, I've got a bunch of questions I want to ask you about this because typically don't
have a lot of companies on the show that have raised a lot of money.
And I think indie hackers are just, it would be interesting for people to hear about like
your mindset going through this.
So first off, how do you feel about the fact that you have a lot of pressure on your shoulders
now?
You've got to be worth something close to a billion dollars just to make your investors
whole?
Now, for me, the pressure comes much more from customers or from the team than from
the investors.
I think if you do it right, if you find customers, that is when you start hiring a team and serve
these customers, I think you eventually find that most of the pressure comes from that
rather than from the investors.
The investors sure want you to do well and they put some pressure on you to do well.
But if retool cease to exist, it would actually be much, much, much worse for the 40 or so
people that work at retool and much, much, much worse for customers that depend on retool.
You depend on retool, right?
You would have to rebuild all your internal tools, which I don't think you want to do.
And I would feel much worse letting you down or letting our team down, letting an investor
like Sequoia has, I guess maybe they'll listen to this, they have a lot of money.
They'll do fine with or without the 50 billion they gave us, whereas you actually might be
quite sad if you actually had to go build a internal tool to scratch again.
But isn't it like a different kind of pressure where I'm not, as a customer, putting pressure
on you to be a multi-billion dollar deck of corn, right?
It doesn't matter to me that much if retool gets humongous.
And so you could kind of like, the way you are right now, I'm very happy with retool.
You could almost rest on your laurels and I'm happy.
I'm sure a lot of your employees are like, yeah, this is a great gig.
Whereas investors might be like, no, no, you need to be 100 times bigger.
So I'm curious, why do you feel more pressure from customers when, as a customer, I don't
feel like I'm really putting that much pressure on you?
Hmm.
I think the, maybe this is a regional specific thing where for us, there really isn't any
ceiling to how big retool can get.
So to give you a sense, we have one customer that every year spends $400 million building
internal tools, which sounds utterly insane, but they have around 125,000 employees.
If you divide $400 million by an average software engineering salary, let's say 200K, that's
actually only 2,000 software engineers.
So having something like 1.5, maybe 1.7% of your company, be software engineers is actually
perfectly reasonable.
So anyways, we have customers that spend insane globs of money on retool.
And so for us, the risk has never been, oh, maybe retool won't get big enough, maybe retool
isn't a billion dollar company, maybe it's not a tender, 100 billion dollar company.
That was all easy though.
We'll figure that out later.
The market is so big that I'm not too worried about it.
For me, I think the worry or the pressure has much more been, what if we execute improperly?
What if we let competitors catch up and kill us even?
And so for me, I think maybe going into the theme of my life, I guess the fear of death
is much more acute than the fear of not living up to expectations.
And so for you, I think you're right, whether retool gets big or not, I think there's some
argument to be made that retool gets big, we'll probably have better support to you,
we'll build better products, we'll probably be better, et cetera.
But I think that the fear of death for me is much more acute where we can't give you
retool anymore because retool doesn't exist.
And that makes me, that is much more pressure.
On the team side, I think the team also would feel, I think a lot of people joined retool.
And partially I think this is, you know, philosophical, you need to decide whether it's what you want
to go big or not.
If you do decide you want to go big, even if you have no investors, our employees have
equity, they have a lot of equity, right?
And so they themselves are joining for the promise of the equity becoming more valuable
in the future.
And so I would probably feel worse letting them down than letting Sequoia down.
Or you know, any of you see down, really, because I mean, first of all, I interact with
them more.
But also they're contributing more to the cause and they're sort of, you know, providing
more of their, you know, time or their effort, their life to retool.
And so for me, that gives me substantially more pressure than one partner at Sequoia
who maybe can't buy a jet because retool wasn't a hundred billion dollars.
What about in terms of work-life balance, do you feel like your life as the CEO of this
20-person company like right now today is sustainable or do you think like you're going
to eventually make some changes, work a little bit less because right now you're burning
the midnight oil?
I think the nature of the work itself changes quite a bit.
And it depends on whether you find it energizing or not.
So in the early days, when you start a company, really, you're, you know, you're pushing the
rock forward, right?
Or you're pushing the rock up the hill, probably.
And if you don't push the rock, it's going to fall down and crush and crush you, you
know.
And so that work, I think oftentimes, I think it's the lack of redundancy that makes it
tiring because if, you know, for three years, I think for maybe two years, the team was
less than five people, I think.
And so the lack of redundancy, I think, can get quite tiring and quite stressful because
you can't go away.
If you ever go away, you know, it falls that the company is dead or something really bad
happens.
Nowadays, I think for me, but even for other people, a retool, there's a lot more redundancy
now, right?
You know, I think everyone at retool is incredibly important, but the good news is that, you
know, retool has built to some extent a machine that, you know, we're going to do executing,
even if you take a day off or, you know, you're really feeling bad one day or, you know, want
to take a day off and stuff like that.
So I think it's quite important for us still to work very hard.
And I think we all still do.
And I'm very proud of the team that, you know, does this.
I think it's quite important to do so.
But I do think that there because there's more redundancy, you know, you should go take
vacations now, for example, and I think everyone on the team should, if they feel tired or
put it out or whatever else, I mean, we are in the fortunate position where we can do
that.
And actually part of that is with hiring other people or raising money, because if you don't
raise money, I think as an indie hacker, if you're just doing it solo, it is very hard
actually to, if the business is fully dependent on you, it's very hard for you to go do anything
else.
Whereas if you do raise money and hire people and hire great people, which we've been fortunate
to do, they can actually pick up some of the slack if, you know, you just, you know, one
day you're feeling awful when you're feeling off or something like that.
So if anything, that may be an argument for raising money, because I think of the people
that I know who haven't raised money, I think they are actually more stressed, I think,
than those who have raised money if it goes well.
I don't know.
I've seen a pretty good split.
I think the most stressed indie hackers seem to be the ones who like haven't found that
product market fit with whatever they're building.
And they're in this like, often people are in this like sort of straddling the door between
like full time job working nights and weekends trying to get this thing to work.
Or like even more stressed people quit their full time jobs and are watching their bank
accounts deplete and yet their company isn't generating revenue.
But most of the indie hackers I've talked to could name dozens of people who've got
like kind of a revenue generating machine and they like designed a job for themselves
that works and they can afford to hire seem to be in a pretty chill place.
And I often see a high growth startup founders who just seem stressed out, like not to pick
on anyone, but like a Vlad Maglin was tweeting the other day about, you know, Oh, the hardest
part about my job is to explain to my wife while it's all why it's all worth it.
And I have seen an entire spectrum of people who've raised a ton of money and just feel
super stressed.
And maybe it has to do with like, whether or not they're living up to various expectations
or you know, how they manage their own time.
So I'm curious about what that looks like for you.
For example, I often like do research on Twitter before I bring someone on the show.
And I went to your account and I saw you were following me and it's like, I'm, I'm like
such a jerk.
I'm not even following David.
And I scrolled down like you don't have a single tweet.
So I immediately unfollowed you again, like, Oh, I get it.
You're not spending your time on Twitter.
How do you spend your days and how do you avoid some of this stress that I've seen other
high growth founders going through?
Well, first of all, you're a jerk for unfollowing me.
You got to tweet something.
The past is no predictor of the future.
Who knows what may happen.
But that said, yeah, I think the early days of a startup, I think you have to be fairly
heads down and sort of fairly focused on the startup.
And I think this is probably true even until maybe a year, for me at least, I think maybe
until year five, year 10, even year 15, like for a while, I think actually.
And like part of it is sort of the philosophical choice you make when you start the start or,
you know, when you find traction or whatever else, are you doing big or is this kind of
just a, do you want to live a chill life and you know, make a million dollars a year from
this and move to Hawaii or whatever else?
In our case, we chose because I think the opportunity was quite large to really try
and go big and see if we can be the way software is built.
That to me personally is more exciting, but I think it's a personal choice.
I know of other friends who would much rather just go move to Hawaii and make a million
dollars a year.
And life is very good in that way.
But I think if you do make the choice of trying to really go big, I don't fully like to go
big because it feels, it's almost too positive.
It feels like, you know, I want to go small, no one wants to say I want to go small, right?
I don't want to pass any value judgment really on sort of going big or going small.
But let's say, you know, you're raised VC, you really want to make a really large company
that has a really big impact, then I think it is very important for you to be very heads
down and sort of very focused.
I feel, this could be wrong, I feel of my friends who start startups that don't succeed
in the early, let's say two or three years, I feel like a lot of it comes down to focus.
I could be wrong about that.
The focus may be caused, lack of focus may be caused by the fact things are not going
well, have not found part of a market failure or whatever else.
But I do think focus is a tremendously large predictor of startup success.
Again, there may not be causation or it may be correlated because the startup is going
well, they need more focus on it.
It's hard to say.
But I think it is correlated with how sort of well things are going.
What's the downside here?
Like, let's say, you know, worst case scenario for retool, a competitor does catch up to
you and eat your lunch and no one's using retool anymore, but you've raised all this
money.
You know, what does that look like to you?
And also, have you mitigated that risk?
Like, did you take money off the table when you raise money or do you think about like
exit plans or like what could happen if the growth doesn't go the way that you want it
to go?
Yeah, so this is tremendously stressful.
Because this may be one of the most stressful.
I think it's actually maybe the most stressful thing, actually, about retool.
I also bike a good amount and in biking, the thing that stresses me out the most is when
I am ahead and I can hear someone trying to pass that is so stressful, catching up with
someone.
That's fine.
If I can't catch up, that's okay.
Whatever.
You know, they started before me.
Whatever.
Right.
But when someone started after me and I started before them and they are catching up, nothing
gives me as much stress as that.
And so for us, in our case today, we have every reason to win.
If we don't win, it's going to be entirely because we fucked up.
If you sort of look at the revenue, if you look at the number of customers, the logos
that we have, the great investors we've raised from, etc., everything is going our way.
The people to work at retool today, you know, everything is going our way.
And so for us, if we don't make it big, we must have really fucked up somewhere.
And so that I think, I guess is sort of your previous question around sort of do VCs give
them pressure?
I guess not really.
I mean, that comes from the team for maybe me internally.
I guess to me, I really feel like, you know, and I think there's a real possibility we
could fuck up that, right?
There are tons of startups, as you know, that raise the billion dollar valuation and just
disappear basically.
So that is really quite scary for us.
In terms of mitigation, I mean, it's kind of like cycling, right?
You know, someone's catching up to you really, the only thing you can do as someone's trying
to catch up to you is bike faster.
And that really is the only strategy is faster.
I think I read something actually about, I might be making this up, I might've just like
dreamt of this, but I'm pretty sure I read this or like, there was a scandal in the cycling
community where bikers will like split the winnings, kind of.
And they would say, Oh, you know, like, I'm going to come in number one this time, you
come in number one the next time, because I just really don't want to have to pedal that
hard at the end of this race.
And like, I don't know what the analog would be for founders.
Like, I'm pretty sure there aren't startups who are doing this, but like you can take money
off the table.
I have a friend who raised $20 million and took like, like, I think three or four million
dollars off the table.
So he's like, Okay, well, if this doesn't work out, at least like, I'm doing fine.
And I feel much more comfortable going big.
So like, there are things you can do where like, you know, maybe if you don't pedal fast
enough, and you lose, you have kind of a softer landing.
How do you think about that as someone who's raised money?
I think to some extent, the pressure is good when I check my Strava, when I sort of look
at, you know, what cases wantages very high when I'm cycling, it's actually when people
are behind me.
That sort of is like the most motivating thing for me, actually.
So I don't know if this is actually a legitimate, I don't know.
You don't want, you don't want to parachute.
Yeah, I don't know.
This is a good financial decision.
But I do think the sort of competitors chomping at you, at your ankles when you're biking,
I think does actually make you execute faster or pedal faster.
So I think to some extent, it's a good thing.
I'm trying to think.
Some companies I've seen too, like, for example, Zapier, pretty sure they just stopped raising
money.
And it's not like, okay, we're failing, we should stop raising money.
But it's kind of like, oh, we're fine here.
We don't need, I guess, the sort of risk-reward balance, found a place on that curve where
they were fine.
And, you know, maybe there's a significantly profitable company like Retool, where you're
not like an Uber or a Facebook, where you're selling rides at a loss, so you're spending
a ton of money.
Like, you theoretically could be just fine if all the investors were like, give us our
money back, tomorrow.
Yeah, so I think that also makes it a lot easier, because I agree, if you start a consumer
company, you may be on problem for a very long time, and you have no idea where it's
going to go.
It could be huge, or it could be not, right?
Whereas with the SaaS company, I think most companies in the hacker start, it's quite
stable, right?
If you sort of look at revenue growth over time, if you look at churn, it's very low
for us.
It's, in fact, not negative.
So on average, people sort of spend more than they actually churn.
So that makes it quite predictable.
That's it.
All the Zapier things.
I think I slightly disagree there, because if you look at Zapier's competitors, I think
there's like 10 or something now, right?
There's like one called trade on IO.
There's another one.
I don't remember the name of these, but.
Integromat.
Exactly.
Integromat.
There's a few others too.
Some of them are actually getting pretty big, actually.
And so for me, again, I don't know the Zapier founders, and so I don't know their motivations
or whatever else.
But for me, maybe I'm quite competitive.
I guess it's kind of like cycling.
I always want to be number one, and if I'm not number one, I'm very, very, very unhappy
about that.
So for me, I would almost try to get every advantage possible in order to be number one,
without doping, obviously, in cycling.
But my money is sort of perfectly fair advantage, right?
You sell some percentage of your company in exchange for great people helping you, but
also a lot of resources, which with you can scale.
So for example, in the Series B, we were lucky enough to get a guy named Carl Essenbach from
Sequoia joined as a board observer.
And he's on the boards of Snowflake, Zoom, UiPath, Palo Alto Networks, Workday, et cetera.
And having him on our board has tremendously helped from a go-to-market perspective, because
Zoom and Snowflake are incredible SaaS companies.
And this is the advice that, frankly, I don't think we could have got it had we not raised
money from Sequoia.
So I think you can sort of view fundraising almost as a way of getting your advantage.
And I do feel exactly right to some extent is losing their advantage.
Again, maybe the goals are different, I don't want to pass any value judgment on that.
But if I were in the position, I would probably raise money in order to stamp out all these
competitors and declare Zapier the winner.
Yeah, so let's talk about how big retool can get and why it can get so big.
You mentioned earlier that you hadn't really unlocked the key to word of mouth growth yet.
When you had 2030 customers, you thought, maybe these are just weirdos and we're just
pushing this rock uphill, and we're doing a good job pushing the rock, but it's not
going to go on its own.
Whereas nowadays, I assume the implication of what you're saying is you do have word
of mouth growth for retool.
Is that true?
It is.
Yeah, for a long time, it was worrying to us.
I think it's just a word of mouth takes a surprising amount of time to get going.
I remember asking multiple other people about this in the early days.
And it's interesting how people's memories are all quite rosy.
So I remember talking to john calls from stripe about this.
He did really remember how many times they had an interlaced like, I seem like it was
going pretty well.
And if you look at the numbers, actually, not that big, actually, in the very early
days, if you that I talked to Peter from segment, and also similarly, he doesn't really remember.
But then when you look at it, it's almost actually aren't that big.
And of course, it's an incredible business now.
And I'll solve for a few billion dollars Twilio.
I also talked to Figma, Dylan Figma.
If you look at those kind of numbers, you know, in the very early days, they were also
pretty small.
Of course, now it's a tremendously large company, right?
But I think founders oftentimes forget how difficult the early days were.
And for me, that was a little bit demotivating because because, you know, I would ask them
to be like, Oh, seems like things are always going well for us.
I don't know what's up with you.
But then, you know, when you actually look at it, now we're a little bit past the hump
and we look back, you can see, you know, sort of every time we do something, you know, maybe
it's we've launched the hacker news, maybe I go on a podcast or whatever else, there
actually is a fairly noticeable spike, actually.
And then for the next two months thereafter, the actually baseline has actually increased.
And so it's a lot of these things that eventually sort of build up over time, but there is no
sort of overnight success or, you know, any aha moment where we find this one marketing
trick that unlocks all these or something like that.
It really is pretty slow for a while until it stops low and then you forget the slow
part.
There's this talk that I always loved that was given by Kathy Sierra at the Business
of Software conference, and she had this framework for making your users badass.
Her whole idea was that if you want word of mouth growth, that comes from people talking
to their friends.
And people when they talk to their friends about themselves and stuff they're using,
they want to like, cast themselves in a positive light, so they like to brag about what they're
up to.
And so if you want them to talk about your product, your product has to make them into
badasses so they can brag about themselves.
Like somebody would be like, oh, Cortland, you know, you're able to make any hackers
by yourself.
You know, that's so cool.
And I'd be like, yeah.
That's a good retool.
Be like, I could do it because, you know, I've got all these cool internal tools that
just make it way easier to manage and give me like way more leverage.
So I'm curious how you think about word of mouth growth, do you follow the same framework
that she does?
And, you know, what do you think are the sort of the main levers for growing by word of
mouth?
Yeah, I think high level.
Yes.
I think one interesting, nuanced point is between sales and product or go to market
with same EPD.
And I think most technical founders typically overweight EPD over go to market.
And most startups fail because there is because they never do sales and never find customers
or they charge too little money and whatever they die.
Right.
I do think though, if you look at a lot of other companies in the sort of SaaS world,
if you look at like Salesforce for Zillowar Workday, or, you know, sort of these big
SaaS companies, a lot of them actually overweight go to market.
And a lot of them just hire a lot of salespeople and they hire army salespeople and just, you
know, sell you a product and they flood the world with, you know, Datadog or Salesforce
or whatever else.
Right.
And I think the ideal point, at least for a retool, somewhere in the middle where I
think sales is critically important to retool.
There is no way we're going to be a hundred billion dollar company without a sales tip.
Sales is incredibly important to us and yet we're not a sales driven company.
And I'm fairly confident we'll never be a sales driven company.
And the reason is, I think precisely what you said, in order to get to our goal of being
the way developers build software, if you sort of think about all the other, you know,
pretty tools that have gotten quite big, let's say like Stripe, Twilio, whatever else.
Stripe has not struck because they have a giant sales team.
They also have a big sales team that, you know, is performing incredibly well and as
does Twilio, but Twilio is not Twilio because they have a big sales team giving demos to
every developer in the world.
Right.
At the end, you have to build a really great product that really generates a lot of word
of mouth that friends tell each other about.
And that is the only scalable, sustainable way of becoming a sort of an iconic developer
tools company.
And so in our case, so I would agree with you.
I think word of mouth is critically important to us.
That said, sales is also important because, you know, no one is ever going to put $10
million on a credit card.
Right.
So I think both are important, but EPD or word of mouth is what is really important.
There's this cool almost arms race going on where, you know, there are these developer
tools that are increasing productivity.
And as a result, developers are going to react into that by demanding even more.
So it's almost like, you know, the snake bites the honey badger, honey badger doesn't care
because it's resistant, but the snakes are even more poisonous and so on and so forth.
You know, companies build all these tools so we can build software better and faster
and cheaper than ever.
And what happens is like, we don't only just build software better, faster and cheaper.
But now you have all sorts of new people who decide, hey, you know, there's time enough
to build software on the weekends because all these tools are so good, I'm gonna start
doing it.
And they have even more picky, demanding requests because they want it to be even faster.
And so the cycle repeats and it's never quite done.
And if you're trying to, you know, build retool into this thing that changes the way the software
is built, I can't even imagine your vision for the future here.
Is it going to be some sort of weird AI driven, something I can't even imagine that you're
thinking about that's going to make us way more productive at building code?
Yeah, it's interesting you mentioned this, because when we first started selling retool,
we always thought the value prop was we'll save you engineering time.
You know, that is true, we do save you engineering time.
But as we started selling more and more retool with more customers, we realized the real
impact actually was on all the people in your company, because now they actually have tools
for the job, right?
You know, it's sort of hacking together, instead of hacking to the Excel spreadsheets, or using
tools that are often outdated and secure.
When you log into a tool, I generally think like, oh, it's probably not gonna work, you
know, it's probably outdated or whatever else, for sure, you probably have experience too.
Now they're high quality to all companies, all of our customers at least have high quality
internal software that they can trust and is robust and is secure and is performant.
And that actually dramatically unlocks the productivity of the whole company, it's not
just saving developers time, it really is allowing the company to operate at a higher
clock speed than before.
And so for us that you know, is second order effect, I think that's what's really interesting
is you know, by sort of making building software easier, lowering the bar for building software,
now a lot more software is built.
And if you think about the world today, the way most companies drive more efficiency in
their businesses, typically is by software, you know, if you sort of look at Coca Cola,
Coca Cola, you know, the manufacturing of you know, the beverage is not really getting any
substantially cheaper over time, you know, it's kind of fixed cost, constant cost at
this point in time, right?
But what Coca Cola is doing in order to drive profit margins up is by really focusing on
software.
And so, you know, to your point, I think software is going to be more and more, more and more,
even more so than today, a larger part of the economy.
And I'm really sort of glad to be powering a little bit of that.
And you know, eventually, one day, hopefully, you know, when all software is built and retooled,
you know, if it's very far out, that is the goal.
Far away.
You've shared with me in our previous conversations, just something like, to me, mind blowing facts,
like I forget what the percentage of it, but you like what is the percentage of all software
that's built internally versus externally?
It's probably something like 50 or 60%.
And it's very counterintuitive, but it's because you think about your job or my job, right?
You know, we're a Silicon Valley, our jobs are at software for other people.
These Silicon Valley companies, Stripe, Airbnb, Uber, whatever else, they are writing code
for others.
They're selling their code.
But if you look at most more traditional companies, like some of our customers, NBC, for example,
Warner Bros, Mercedes Benz, Jaguar Land Rover, all these companies, they're not selling software.
You know, Mercedes is definitely not selling software.
They're selling cars, right?
It just turns out that software is tremendously helpful in them doing their job.
If you look at most software engineers in the world, most of them actually aren't in Silicon
Valley.
They're sort of more traditional companies where their jobs are to write software to
power internal operations.
So I think the opportunity for us is quite big.
I assume you didn't know that when you first came up with the idea for retool.
So I'm just curious, what are some things that might not be obvious to people who are
thinking about no code and low code that weren't obvious to you?
I think that one thing that is underappreciated is that the general workforce is getting much
more technical.
And so if you look at, let's say, people who are in non-engineering roles at Silicon
Valley companies, let's say, PMs, people that work in operations, that work in support,
marketing, sales, whatever else, a lot of them, especially the new grads, have actually
taken some sort of computer science class in college, to take a comp sci class.
They might not be, let's say, the 10x developer who is really productive writing React or
whatever else, or dealing with Redux or whatever else, or understand how Redux works under
the hood.
But they are able to go write SQL.
And I think that has really fueled the rise of low code or no code in the past team months
or so, because now the sort of average knowledge of the knowledge worker has gotten higher.
And I think most tools that we use assume less knowledge, or assume that the knowledge
sort of baseline has not changed, or as retool assumes that, hey, you know, you probably
know what SQL is, you know what a database is, you can write a little bit of code.
And we've seen tremendous adoption because of that.
I love that.
It's not only technology that changes, but it's actually people's familiarity with technology
that changes.
And that provides opportunities for you to build new apps and tools and websites that
couldn't have existed in the past, because like the user base just wasn't ready for it.
We're kind of at the end of our time, but most people listening in have not started
anything.
They haven't come up with an idea.
They haven't run the line of code.
They don't know what they want to do.
What do you think they can take away from your journey, David, to help them get started
on their own?
I think this is one thing I myself learned from YC and watch the startup school talks
too, is you should just get started.
The sort of risk is so low, especially the start of the side project, right?
If you start a side project, you know, code in the weekends, code at nights, you know,
see what happens.
And then if something takes off or you eventually find traction, even then quitting your job
or quitting school or whatever else to start something, it's actually just so low risk
that you might as well try to see what happens.
The worst case is you do something, a side project number takes off and you still work
at your job.
There's really no downside.
So you might as well get started and see what happens.
Get started.
See what happens.
Can you tell people where they can go to find out more about what you're up to at Retool
and where they can find you online?
Yes, please.
Retool.com is the place to be.
David Chiu, thanks a ton.
Thank you.
Listeners, if you enjoyed this episode and you want an easy way to support the podcast,
you should leave a review for us on iTunes or Apple Podcasts.
Actually the fastest way to get there if you're on a Mac is to visit ndhackers.com slash reviews.
I really appreciate your support and I read pretty much all the reviews you leave over
there.
Thank you so much for listening and as always, I will see you next time.