How Brex used Retool to scale 10x in three years

Brex believes in empowering employees to make decisions and execute actions. To do this, Derek knew that it was critical to create internal tools that could be maintained easily. More importantly, those tools couldn’t be built as an afterthought—they needed to be a part of the product from the beginning. That lesson was hard-earned from his time at Pagar.me, when internal tools were built way after the product shipped and grew dramatically out of scope

At Pagar.me, internal tools were added to the stack well after the product was finished. Before the tools were built, support agents had to help customers by using a duplicated deployment of the customer dashboard with additional (secret) tooling features on top of it. This was a nightmare for both the engineers building the dashboard, the agents using it, and the customers receiving the help.

Eventually, Pagar.me created a dedicated team for internal tooling. At first this worked well, but the team ended up creating 15 different tools, each with their own code base that needed to be maintained. However, problems surfaced when changes to internal component libraries broke the tools. On top of that, a failure to follow good coding practices resulted in low test coverage and spaghetti code.

While Derek says the 15 different tools and code bases were worth the effort for Pagar.me—they helped provide a better customer experience — ultimately, he wanted to find a more durable solution. Upon joining Brex, Derek discovered Retool and figured it might be the right fit for helping the team scale and build out internal tools from the start.

At Brex, there are around 120+ engineers split among 15 different teams. Each team owns every layer of the products they ship--from frontend to backend to internal tools--to keep work moving steadily. This ensures domain knowledge stays fresh within every team. Plus, having the engineering teams build tooling from inception helps with product integration.

Typically, engineers are asked to treat the internal tools they build the same way that they would treat code going into the product. That means mapping to a business case, understanding core functionality, and getting continuous feedback from customers. In this case, the “customer” of an internal tool would be another employee at the company who is using the tools, like a support agent or a sales rep.

The key difference between building internal tools and the product is in the design and review cycles. Since internal tools are never seen by Brex’s customers, there isn’t a stringent design process for how it looks or behaves. Tools are built quickly and iterated on as needed.

While putting internal tools on an even playing field with the core product is great, it doesn’t solve the problem of scope. Tooling can quickly become a large, complex, interconnected mess that acts as a time-suck for engineers, especially when doing all the work from scratch. From choosing a framework to selecting a component library, a tool suite can essentially become a whole other product. That’s why selecting software for building internal tools that’s easy to use and saves engineering time (thus limiting scope) is critical.

A great example of this in action is the first project that Derek used Retool for at Brex. He needed to simulate transactions in Brex to test a feature but nothing like that existed. Before Retool, Derek says he would have taken hours (or days) to create a simple command-line tool that no one else would have used. Instead, he was able to create a simulator in less than 30 minutes by dragging and dropping components, building a few queries, and making a couple of REST API calls. Now, Derek’s transaction simulator tool is used daily by many engineers in the company.

By finding software that made building internal tools nearly effortless, it has been easier to convince engineers to build internal tools alongside the product. Now, Brex has a full suite of internal tools that are easy to use and well-maintained and have been in use for as long as the product has existed. In fact, Derek says that Retool is the main tool used by Brex employees for getting things done at the company—including operations, customer support, sales, and engineers.

As a software company, Brex doesn’t believe that you should scale by adding more people. Instead, scaling happens by giving tools to the people you already have to get things done. Here’s how we helped Brex build internal tools to do exactly that.

Brex has a variety of notifications — email, SMS, and push — that are sent to their customers. The problem was that the content of the notifications was hardcoded into the app. Changes to the notification copy, even something small like changing one word in a header, had to be done by an engineer.

This was a problem for a variety of reasons. First, any code change to Brex’s product was subject to code reviews and a deployment schedule. So that one-word header change could take days before it reached customers. Second, this created a major visibility problem for the marketing, product, and design teams. No one had insight into what was being sent to whom or what it looked like.

What Brex needed was a way to give product design and copywriting teams the ability to create and edit email templates without going through engineering. Not only did they need this to help the employees do their work, but consistent messaging toward customers was essential for building trust as well, especially for a financial company.

In this video clip, Derek walks through how Brex teams have created a tool called the Template Manager that anyone at the company can use to create and edit templates.

If a copywriter needs to change the copy of a notification or configure settings on whom the notification goes to, they can edit an existing template. First, they choose a template from the menu.

Once the template is loaded, the copywriter can configure settings on the notification, edit the copy, and preview the message’s appearance:

Once the user is finished, they can save their copy, which sends an email to the copywriting team. At this point, another copywriter can view the changes and click “Approve” or “Unapprove.” If the template is approved, it is immediately available to customers. If it is unapproved, the template will not be rendered in the code.

If the team needs a new template, engineers can create the new version on Retool. Then, non-technical users can easily adjust the template as needed, preview it, and ship it.

Brex has spent very little time in Retool compared with what would have been spent if they had done the coding to build the tools themselves.

“The outcome of this tool,” Derek says, “is that we have reduced [by] 75% the amount of code that you have to write to ship a notification.” Imagine for a second that your engineering team got three-quarters of their time back when creating internal tools. That time could instead be spent focusing on the customer-facing product.