Jan-Erik Asplund
Background
We spoke with an ex-employee of Retool to better understand the enterprise opportunity around internal tool builders, Retool's transition from a bottom-up PLG motion to a focus on enterprise sales, and the big 5-10 year vision for the company.
Questions
- Can you run us through the use cases for Retool? Mostly dashboarding, engineers building tools for ops to process stuff? What does the distribution look like—is there an 80% of what people mostly use it for?
- Across the universe of admin panel use cases, like you mentioned, customer support, refunds and delivery dashboards, is it pretty evenly distributed?
- What are the use cases that Retool does really well and what are some that it does poorly?
- What are the key substitutes/primary competition for Retool? How does Retool position itself against them?
- Help me really get in the head of an engineer that uses Retool. When does the need for it come up, how do you find it, how do you start using it? How does that usage eventually expand?
- Who tends to be the champion for Retool inside an organization? What makes Retool particularly useful/sticky for them?
- What kinds of people have Retool seats within a company?
- What were some of the key objections you heard from potential customers?
- What are the main drivers for teams to upgrade from Free to Team ($10 per month) to Business ($50 per month) to Enterprise? What are the big triggers for an upgrade? What features are people most looking to get access to when they upgrade?
- Were there key learnings that you had around what made Retool a good fit in the enterprise?
- Can you talk a bit about Retool’s future vision? What’s Retool building towards? What does it want to be in 5 years and what does success look like?
- Can you talk a bit about competition from other internal tools businesses like Airplane and Superblocks?
Interview
Can you run us through the use cases for Retool? Mostly dashboarding, engineers building tools for ops to process stuff? What does the distribution look like—is there an 80% of what people mostly use it for?
Philosophically, you have data stores at your company and those data stores need to get exposed to two parties, like party number one is your users because it's got information about their settings and their profile, and their orders, and whatever your data model looks like. The way they interact with that data is mostly reading. If they're writing, you want it to be in a very specific way. There's some things they shouldn't have access to, stuff like that.
On the other side of the universe, you've got your internal team, and it's the same data, the same database, the same table, but they want to do very different things with it, and these are the two kinds of applications that get built in the universe, broadly speaking. The former is well understood. The latter is not, and has very different priorities. That's the genesis of this whole category.
I don't think people understand that maybe half of the software that's being written in the world is the internal stuff.
The main use case is like, "I need to build something on top of a production database or set of APIs on top of a production database that lets me work with my internal data." That's like 80% of what is going on. There's different forms of that. There's a customer support team who needs a tool to let them refund orders or look up customer data. There's a use case where a delivery team needs a dashboard on a map with data points on it. There's a use case where a sales team needs a particular review of their data and needs to be able to update stuff using the Salesforce API.
There's so many different things, but you can really bring it back down to this concept of, "There's some sort of data source. I need a UI on top of it."
You can get into the details of the differences between those. But I think they're sufficiently similar, that it's worth bucketing them together. You can break it down by what team the tool is built for. Is it support? Is it operations? Is it marketing?
You can break it down by what type of data the tool's using. Is it my production database? Is it Salesforce or Stripe or is it some third-party API?
That’s what most of it comes down to. Over the past year or so, Retool's been expanding a little more into workflows—automation without a human being in the loop—mobile apps for field service, and databases now as well. The core product was and is the admin panel and dashboard type of internal app.
Across the universe of admin panel use cases, like you mentioned, customer support, refunds and delivery dashboards, is it pretty evenly distributed?
The dashboard and the admin panel that you have is going to basically resemble the kind of business that you're building, though a lot of this stuff is pretty much the same.
You want to do some feature flagging. You want to allow people to onboard or gate your product early on. You want to search for some user data.
But when you get into physical and logistical heavy businesses, everything could be different. CommonBond, for example, did loans, and they used Retool for all these different loan approval processes. That's not something a SaaS company would need. So that's a fintech use. There are also healthcare use cases. But in general, almost all of the use cases fall under this idea of having an admin panel to work with your production data and some basic CRUD.
What are the use cases that Retool does really well and what are some that it does poorly?
There's a couple of things that Retool just doesn't support yet, which make it a deal breaker for some people.
One example is any language other than Javascript. Retool doesn't support server-side Python or anything like that. That's a deal breaker for some teams.
Anything with very highly custom UI work, like super intense animations or very, very custom flows and stuff—Retool’s UI builder gives you a little less flexibility than if you were writing code from scratch.
Retool has a custom component thing but it’s not very good. The core component set is very, very good for those core 80% admin panel things, because these admin panels all kind of look the same—there’s a table, form, button, and some inputs—and there's really no reason for you to rebuild the wheel.
If you don't care really what the app looks like, Retool is just killer. It's so much faster and so much better than building it from scratch.
What are the key substitutes/primary competition for Retool? How does Retool position itself against them?
This is a great question, because the answer is unintuitive.
Retool's primary competitor—what we lost the most deals out to—was React.
It was not a company. It was not a startup. It was not another tool. It was always engineers choosing to build internal tools themselves. That could be in Django, or it could be in React, or it could be in anything—but usually it was React.
The way that Retool positioned itself against build-it-yourself was as a massive timesaver. That was the one value we focused on, we focused: build tools much faster.
There's no reason for you—when you're building an internal UI for your team—to be writing React code from scratch to set up your infrastructure, and then setting up your web server, and then setting up your table component, and then setting your date picker component, and then every time you want to make a change, you have to go through your whole Git workflow.
That was very resonant. They'd be like, "Look, I built maps in React and you know what that looks like here, I'm going to build you an admin panel in four minutes. That's going to work just as well, and if we want to change any part of it, it's just as simple as clicking something and changing it."
It was a time-saving thing. If we were to have to position more against enterprise competitors, which I can run through in a bit, or other startups, they think that the value prop might have been different. But when I was there, it was very clearly like we are positioning against a building-this-yourself situation.
Help me really get in the head of an engineer that uses Retool. When does the need for it come up, how do you find it, how do you start using it? How does that usage eventually expand?
The beautiful thing about Retool’s business is that the need for internal tools arises exactly when a new application hits the wild. It’s rare that you’d say, "Well, we're a little too early for a tool like this," especially with the free plan.
Usually, the moment you have some production data running through your systems, you're going to need to start working with that data.
Early on, engineers can get around this—it’s rare that a 10-person startup would have a nice, organized admin panel, like internal.sacra.com.
Instead, there'll just be a script that gathers the monthly invoices or a script that pulls users and revenue for the month, and they'll just run it, and maybe they'll create a very simple internal UI for it.
Pretty much, though, Retool is relevant from day one. Not enterprise Retool—but the basic, free, cloud Retool is definitely relevant from day one.
Who tends to be the champion for Retool inside an organization? What makes Retool particularly useful/sticky for them?
Retool's initial positioning was very primitive—it was just about targeting engineers. We did say for a time that Retool was best for “ambitious engineers at growing startups”—meaning people that were taking initiative and thinking about buying tools and thinking about saving their team's time. When the enterprise stuff started working, we kind of dropped that.
With almost all the deals that Retool has closed, the customers are technical. A marketer just can't pick up Retool and be successful because the product is built to require writing SQL or Javascript in order to get anything done. That is a conscious choice—and I think a good choice.
What kinds of people have Retool seats within a company?
Retool has an interesting pricing model, which is that all users are charged the same.
It doesn't matter if you're a developer who's editing the app and writing queries and moving components around, or if you're a customer support person who's just using the app, searching in the table, and clicking the button to refund users. They're both $10 a month on Team, $50 a month on Business, and a lot more on Enterprise.
That pricing model has an important effect. And on larger deals, the majority of seats will be people who use the app, not people who edit the app.
What were some of the key objections you heard from potential customers?
Yeah, there's always, "I could use the free plan for this."
A few others: a customer doesn’t want to write Javascript, Retool doesn’t have a component they want to use and they don’t want to build it from scratch, or a feature they want to use is too expensive.
A really good example is deploying on-prem.
Arguably, the main reason why SDRs or AEs would have success in PLG outreach is because anyone at a large company who needs Retool needs to deploy on-prem, and you can't do that for a while without talking to a salesperson.
A lot of people would be like, "I need to deploy on-prem because I have medical data or patient data. I don't want to pay you $200,000 a year just to do that. I can't afford that. We don't have that kind of money”.
There's also the whole, "I don't want to trust this critical part of my business to an external tool or to a third party." There's, "I wish this was open source and it's not." Those were the main ones.
What are the main drivers for teams to upgrade from Free to Team ($10 per month) to Business ($50 per month) to Enterprise? What are the big triggers for an upgrade? What features are people most looking to get access to when they upgrade?
The big feature that people upgrade to the Business plan for is granular access control, so they can give somebody view-only access to an app. The Business plan also has audit logs, but those are only really important for larger use cases.
With the Enterprise plan, the big draw was deploying on-prem. If you want to deploy on-prem—before Retool started doing self-serve on-prem—you need to upgrade to the enterprise plan.
You also need to upgrade if you want to do SSO other than Google—so if you want to integrate with Okta or Active Directory or anything like that—or if you want to integrate Retool with Git and make sure any change to an app is version controlled.
Those were the really big ones. There's some other things in the pricing page they talk about, like custom branding, which is nice—but not that important.
To go back to the self-serve on-prem concept, what that lets you do is deploy Retool on your own servers without talking to a salesperson.
Every piece of open source software on the planet lets you do that, but very, very few SaaS businesses do the same. Confluence let you do it for a while, but they stopped.
Adding self-serve on-prem was basically about adding another degree of price discrimination—to where there are people who need to deploy on-prem for various reasons, but they're not really relevant for the enterprise plan, so we just decided to separate those two out.
Were there key learnings that you had around what made Retool a good fit in the enterprise?
The reality is that for developer tools, the money is always going to be in the enterprise. And whether a company's admitted it or not, that's the situation.
Early on, yes, we were very focused on self-serve, but I think that it gets harder and harder when one enterprise deal in a month is more self-serve revenue than you've made in the past two months.
Over time, I think companies just get less and less focused on the product-led thing because the data just tells you not to care about it.
When you think about, “How do I make the self-serve experience good?”, you're either thinking about it from a perspective of “How do I make it good for someone who is poking around before I sell them an enterprise contract?”or, “How do I make it so good that they never need to talk to me?”
Those are two different product strategies and two different ways of doing onboarding.
For example, Retool put a lot of time into creating sample data. Because if you're an engineer at Pinterest and you sign up, you cannot connect your Postgres database to a cloud service. That's not something you can do. So to let them look around and get confident in the power of the tool, we provide them with some decent data and templates and onboarding.
The shape of your organization when you want to sell to an enterprise is very different. Retool hired a lot of salespeople because they realized it was working. They hired a head of sales. They hired a lot of AEs. They hired SEs. They hired SDRs. The sales organization is huge now.
Can you talk a bit about Retool’s future vision? What’s Retool building towards? What does it want to be in 5 years and what does success look like?
Internal tools is the beachhead. We know that Retool works well for internal tools and there’s really good product-market fit there.
The next frontier: why wouldn't you develop all apps this way?
Today, there are some good answers to that question.
There's a much higher degree of customizability. There's the infrastructure component. There's highly unpredictable usage, and much larger user bases, and it's going to be a much more difficult infrastructure problem.
There's even more of this objection of, “How could I possibly have my entire business built on some closed third-party tool?”
I think the argument for Retool being the biggest software company ever is if they can figure out external facing tools and they can win that: then, this will maybe be the biggest company ever maybe. That's the exciting vision.
Can you talk a bit about competition from other internal tools businesses like Airplane and Superblocks?
In general, these kinds of companies were not on our minds. We were not losing deals to them. Retool was so far ahead feature-wise—in the little things that enterprises need, and polish, and also our marketing and sales. We had a huge head start. Like I said, our biggest competitor was React.
On the other side of things, it was interesting that we didn't run up against companies like Unqork, Pegasus Systems, and Appian more often—the enterprise internal tools companies.
If they were targeted at developers, they'd be targeted at enterprise developers, which are a different universe of people.
Disclaimers
This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.
