Ronnie Caspers, Product at Lithic, on using Retool for fintech ops

Could you talk about contextually what was happening and what was the circumstances in which it made you think about looking for a solution like Retool initially?

Our head of engineering was a big driving force behind getting Retool launched, and I was really in the right place at the right time to be a power user of it internally. 

Our goal was to get our engineers out of the weeds and make Retool our force multiplier. It’s gone extremely well for us.

Can you talk about that first ops core use case? Because the ops use cases are something that I think people don't fully appreciate about Retool.

Retool enables users to take actions in your systems. 

There’s all sorts of products like Metabase, Looker, and Tableau that let you visualize and cut data in different ways. 

But Retool empowers a user—and particularly a non-engineering user—to reach into your systems and take an action like firing off an actual call into your core server or hitting your API endpoints. 

Retool provides dashboards, but you can also view a customer's configuration and then with one click, change their configurations or send emails very easily. 

In Retool, very, very powerful commands are made extremely simple and safe for people to execute.

Permalink

Can you talk about that safety component? One of the core ideas in Retool is that it actually enables you to work with production data and the production database, but can you give us a little more clarity around the guardrails that allow that to occur?

Safety and security are first and foremost for Lithic because our business is handling other people’s money so we’ve employed a multi-layered approach.

The first layer is just access: who can use your applications? That’s access both to the application, but then to specific features within the application, so baseline view access for a user and then admin layers above them. Even within the same application, we have different layers of controls. 

The second layer is a lot of fat finger protection. That’s just ensuring there are no accidents and making the command the user is about to perform very clear: so showing a preview of what it's going to do, lots of "Are you sure?" boxes, lots of input validation, and lots of other pretty obvious things.

Then we have deeper controls around implementing business logic. You could structure a command where everything is typed correctly and it makes sense, but for example, would it really make sense for you to set a customer spend limit to be $100B per month? We have processes in place to make sure this never happens. 

So we systemize that logic and controls so that when a new user is using the tool, that guidance is there.

Permalink

Can you talk about the actual ops use case? What does this dashboard do? Did you consider other SaaS for this? And then how would you position that against doing it with as its own full-fledged app?

There’s a long list of parties involved with getting a card program up and running. We are an issuer processor, and play a key part in getting new card programs to market. We connect the bank to the card network, process card transactions, and orchestrate network messages between the issuing bank and the card networks. For card programs, there are two types of relationships you can have with your card issuing partner: program manager or processor. We do both - and for our program managed customers - we have a list of responsibilities— things like setting up your Bank Identification Number (the first 8 digits on a credit or debit card), coordinating with the issuing bank and card networks, and ensuring all of your activity is compliant. So across this whole list of activities that we have to do, we basically started peeling off those activities one at a time into a few apps. 

For the operational apps, the tip of the spear is setting up a customer’s program and configuring it correctly.  

As a program manager, we have BINs with sub-BIN ranges. A BIN can be dedicated to a single company or can be shared across multiple companies. A dedicated BIN may be the best solution for some but it’s important to understand the pros and cons of each option. There's a lot of strategy that goes into which customers are where on those ranges. 

It’s a bit of a puzzle, and changes were previously executed exclusively by engineers editing the tables in our systems. Now, that's in the hands of our ops teams to manage in a more visual and efficient way. 

Seeing the information is good, but what makes the difference for us is all the actions an authorized user can take in our systems.

And was there any sort of off the shelf SaaS that does certain parts of this? Or on the opposite end, did you think, "Okay, instead of using Retool, this is actually part of our core competency as a fintech and we need to have our own fully configurable app”?

For Lithic, it’s been the last 10% of customization that’s delivered the majority of the value. 

One example is that we used to use a third party for compliance transaction monitoring. Every transaction that goes through our platform has to be monitored against a list of rules that are defined by our partner bank, by the card networks and by us.We used to use a third party vendor for that but that vendor wasn't built to handle the way our data model works. 

We have customers that are businesses and they have their own customers so we have a B2B2C model where we need to monitor two layers. Almost every service out there assumes that you want to monitor just that primary customer's activity, not that second layer.

That two layer monitoring requirement made even robust tools struggle, so we built our own system in-house with Retool. 

Our monitoring is more advanced, fully featured, and customized to work exactly with how our business is set up. 

I think other people will probably empathize with that challenge, you've got some non-standard business use case or multiple databases in different places and you wish you had tools that could access all of those or play nicely with them, but they don't.

Is that fully encapsulated by this idea of building custom for your data model, and is it entirely about data or are there other things?

The list of Retool virtues really goes on and on. 

We’ve been able to tie together very disparate systems. It'd be great if all of our stuff on the backend was in one spot, but that's just not the way the world works. 

With Retool, we can tie together Snowflake or Postgres databases, DynamoDB, and things from our API very, very easily. Being able to access information from all areas of your organization when you build things is huge. 

You can make pretty powerful stuff pretty quickly. I haven't come across another product where I could ask someone, "Hey, I want to do a bunch of joins across Snowflake and Postgres and API data and things from Slack and Zendesk and make this app."

Do you see the market break down between technical/non-technical? Is that how you see things? And as a product person, how do I contextualize your enthusiasm for a product like Retool and your ability to use it based on your skillset?

Anyone who's worked a lot with Excel can manage Retool. It’s pretty easy to pick up and run. It is Javascript. I didn't know any Javascript when I started, but Google is your friend, and you can just teach yourself to do a lot of the basic things. 

Retool is emerging in this nice sweet spot of “write code anywhere”, and Javascript is pretty easy to get up and up and running with. That's where it's really killing it—the front-end work is drag and drop, but you can customize things very easily by just writing tiny Javascript snippets everywhere in your app, and that's what really makes it sing.

Is Retool actually a meaningful part of engineering culture at Lithic, or is it more just like, "Hey, this is a tool we use." Would this ever come up in an engineering interview? Would it be a selling point or is it more peripheral?

Retool has empowered the people who are building cool things to make a front end for their service and do it themselves. 

Instead of building a service then shipping it over to another team to do some front end work and make it actually useful for the organization, it's very much a part of the project you are working on where you are responsible for doing that now, which is pretty cool. 

You have all the context and know the ins and outs of the service you've built, why not have it be you who makes the front end and puts it in the hands of your teammates?

Permalink

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.