Before companies have the time to set up sophisticated internal tools, there’s usually an ad-hoc collection of incantations, from SQL queries to custom API snippets (and maybe some Python scripts, too). These usually cover nontrivial tasks like kicking off a billing process or fixing a "one-off" bug that hasn't gotten prioritized. One day, one of the engineers at Assembled got tired of this state of affairs (captured in a photograph below) and decided to set up Retool. This post describes how Assembled uses Retool to build and maintain internal tools quickly.
Some context on how Assembled works
Assembled helps modern organizations scale great customer support — this includes technology companies like Google, Stripe, and GoFundMe as well as retail brands like Harry's, Glossier, and Everlane. We have a core tenet to "act as an extension of our customers' team" and from early on investments in internal tools have had a big, user-facing impact.
Because we work with fairly sizable companies, who tend to feel the challenges of scaling support most acutely, we're often forced to solve "custom" problems that are nonetheless mission-critical for a given user. This also requires close collaboration between our business and engineering teams. As a team of 8, good internal tools make all this possible by reducing the number of handoffs and amount of manual toil needed to support our service.
How we got started with Retool
I learned about Retool well before my time at Assembled through their Show HN thread in 2017. At the time I worked on the Support Tools team at Stripe. A database-aware app-builder seemed like a perfect idea—there were lots of potentially high-impact workflows to be built, but we were slowed down by needing to work around a very old, Bootstrap-looking Ruby app.
At Assembled, we knew we wanted to use Retool eventually but weren't sure at what size it would make sense. As described before, things kind of just happened one day when an engineer on our team took it upon himself to improve the state of affairs. Within a few hours he'd connected our PostgreSQL instance, built our first configuration app, and showed the nontechnical members of the team how to use it.
Supporting custom experiences without getting bogged down
Our most used Retool App is called Edit Company Settings. First, you select a company's account to configure, which is basically a SELECT query over our companies table. Then, you can edit a number of company-wide settings that control how Assembled looks and behaves. Hitting Save Changes fires off an UPDATE query parameterized by the company selection and the fields changed.
For example, the base_interval setting controls the size of cells in our team calendar. The default is 3600 seconds, or an hour. The team calendar also shows helpful metrics like how many people are scheduled versus required, and several of our larger users prefer to see such metrics at 30 or even 15 minute intervals to plan more precisely. The UI becomes incredibly information-dense but they explicitly want more data!
With the Edit Company Settings App, we're able to sidestep internal debates like how to support more customization without making our product too confusing. Instead our business team can engage candidly with users and customize what they see according to their needs. On the engineering side, we're able to support this with minimal effort because the UI/UX are simple Retool components. There are several other potentially contentious settings, like the start of the week, that we explicitly chose to support in this way.
How we use the Query Library
Retool also has a neat feature called the Query Library, which can be used as a nice SQL interface with access to database schemas, or to save and share queries amongst the team. At Assembled we use it extensively, whether it's engineers debugging support issues or business folks building user-facing analyses. Among other things, we consider simple, secure access to be a killer feature in its own right—before Retool, we had to specifically set up SSH access and explain tunneling in order for a Data Scientist on the team to run queries.
We want more cowbell (security)
Security and compliance have always been top of mind for us, as we need to satisfy the requirements of large enterprises. Retool supports audit logs and can distinguish access by App, but we'd also love to see granular access control around particular bits of data. For example, we'd like to annotate and restrict access to personally identifiable information or otherwise sensitive fields. These are all things that we'd traditionally need an enterprise or compliance team to build a program around, so having them partially solved through Retool is already a huge boost.
Conclusion
When I first heard about Retool, I was immediately sold that it would be useful for a dedicated internal tools team by reducing the time spent on unnecessary UI/UX choices. However, at Assembled, which has only 8 people full-time, it's become a core part of how we work much sooner than I would have previously guessed. Both business and engineering teams rely on it in their day-to-day, and in general it's the tool that most reduces handoffs and manual toil.
If you'd like to brainstorm other use cases or hear more about how we use it, please do get in touch at team@assembled.com.