Scaling an on-prem first SaaS company to tens of millions of ARR

We started building Retool in 2017, and got to around a few million dollars in ARR with 4 people. Today, many companies—ranging from startups like Brex, DoorDash and AllBirds to large companies like Amazon, NBC, and Peloton —are paying customers, and use Retool for building internal applications much faster.

We believe that on-premise software has been much maligned in recent years, even though it offers a host of advantages, especially for smaller software companies starting out today. We’re lucky to have started after the advent of Docker and Kubernetes; by offering an on-prem Docker image of Retool, we’re able to confidently answer security questionnaires, speed up deployment, and therefore quickly sell into enterprise.

Not much has been written about this trend, and so we wanted to write a blog post about what it’s like to start and scale an enterprise, on-prem-first software business to mid-8 figures in ARR.

How did we get here? A part of that story has to do with opening our minds towards some pretty unconventional moves, including adding an on-prem offering to our SaaS business.

When we started Retool, we only had a cloud version. But in order to build a useful app for themselves, users typically have to connect their own database. For Retool to access your Postgres database hosted on RDS, for example, users have to add our IP addresses to their allowlist. For most companies, this takes time. And it should! These companies store sensitive data in their databases, and they should minimize their security surface area by very rarely (if ever) adding external IP addresses to their allowlist. After all, many companies have lost sensitive user data due to having too broad of an allowlist.

When we began telling people about Retool, it became clear that a large percentage of potentially interested customers weren't able to use us because they wouldn't be able to get access to the data they needed.

In addition, a good amount of potential customers never onboarded because they couldn’t connect their data.

This was especially true for larger companies and companies in regulated industries (such as fintech or healthcare). We were losing them midway through the funnel, simply because they weren't able to actually try the product in the first place.

We considered a few separate solutions, including allowing users to import data, anonymizing their uploaded data, generating fake data, etc. But when we tested them with customers, it was clear that none of these solutions would've worked. Because a core value prop of Retool was writing back to databases, writing back to fake data just wasn't compelling enough. We had to find a way to allow users to go build applications on their actual data.

That's when we started considering how hard it would be to host Retool on-prem. Allowing customers to host Retool on-prem would guarantee that no data ever left their VPC, and would enable customers to secure their own servers however they wanted (such as putting it behind a VPN, or behind SSO).

But at that point, Retool was two people, and we ourselves deployed Retool via a script that scp'd our frontend build up to a directory served by nginx, and restarted PM2 for our backend. We were quite far off from allowing users to host Retool on their own infrastructure.

In the end, we settled on using Docker images as the distribution method for on-prem Retool, given it was so widely adopted. To minimize dependencies, we decided to replace our nginx with a separate node process that served static assets, and we replaced PM2 with our own implementation of clustering worker processes. To make it easy to deploy Retool, we created a repo with docker-compose.yml to preconfigure the Postgres database that Retool used for storage. We also built a simple licensing endpoint to let on-prem instances check-in with and a Retool app to make it easy to manage license keys. Three days later, Retool was running off a Docker image on an EC2 instance.

We reached out to a few of the customers who had initially shown interest, but were unable to use Retool because they couldn't connect their data. One of these customers deployed Retool the same day, connected their data, and ended up building dozens of applications that have had a large impact on their business. Today, they've built hundreds of applications in Retool, and have saved tens of millions of dollars in engineering time.

In retrospect, building on-prem Retool was critical. First and foremost, it unlocked specific customers and specific industries which were previously out of reach, and now represent a significant portion of our customer base.

When we were a smaller company (with no customers and no revenue), our customers would often ask: “what happens if you go out of business?” With cloud-hosted software, there's no right answer. We have certainly had our share of vendors go out of business. But with our self-hosted offering, we could now promise customers that Retool (and the applications they build) would continue working, regardless of what happened to the company.

Similarly, when we were talking to customers, they'd often ask us to fill out security questionnaires, which were invariably onerous. These security reviews were often large Excel spreadsheets filled with hundreds of questions, which slowed down our iteration speed, and delayed us from discovering if a particular customer was or wasn't a good fit.

With self-hosted Retool, most of these concerns and questions no longer applied. We told our customers to block all inbound and network connections from their box, which ensured that no data ever made it out of their VPC—meaning we didn't store any data, worry about retention policies, or deal with storing passwords.

This approach shaved off substantial back-and-forth with security teams, and cut down our average security review timeline from 30 days to 5 days. (In fact, one of our customers—a $100B+ financial services company—recently told us that Retool passed through their security review in a few days, "faster than anything I'd ever seen before".)

Investing in on-premise Retool may sound counterintuitive at first glance.

Over the past few years, all we've heard about is the "cloud", how quickly it's growing, and how it's going to take over all on-prem software. But the meaning of "on-prem" is also evolving! It no longer involves buying a box and plugging it in. Instead, it involves downloading a Docker image, and running it in your own EC2 instance. Yes, it's in the cloud. But it's in your own cloud, not in your vendor's cloud. And that gives you better control over where your data is going, what datasources it can connect to, as well as the software's uptime.

Surprisingly, many “cloud” companies make most of their revenue from self-hosted deployments. For example, the pioneers of “the cloud”—ServiceNow, MongoDB, UiPath, and others—all make billions of dollars of ARR from self-hosted software. Even Elastic makes more than 70% of their revenue from “on-premise” customers.

We often associate on-premise software with larger, enterprise companies, but that too is not necessarily the case any longer. For example, since we made our self-hosted offering available self-serve, we've seen companies self-host for a variety of reasons, including for performance (given you can now locate Retool in the same region as your database), security, or just business continuity.

Should more forms of software be self-hostable? We think yes. As deployment tooling gets better, it's possible that many forms of SaaS software will have self-hostable versions, especially those that interact with sensitive data, or require special permissions.

For example, it might not make sense to self-host Salesforce, since it doesn't access sensitive data. But maybe it would make sense to self-host GSuite, since there's critical data, and potentially could be connecting to internal databases and APIs. If self-hosting software became as easy as signing up for a cloud account, we think there are clear advantages to self-hosting certain classes of software.

That said, there are downsides to supporting on-prem:

These are challenges we've surmounted in various ways. If there's interest, we'd be happy to write a blog post about this: tweet to us to let us know.