Customer Story: Rain (VP of Platform Engineering)

Feature Flags to Meet Customer Needs and Migrate Users from Legacy Systems

We sat down with Venu Narayanabhatla, Rain’s Vice President of Platform Engineering. Rain is a Fintech platform that gives employees more control over their finances and earlier access to their wages.

Rain uses feature flags because they release to production multiple times per day and need an easy way to manage that. They’ve also used Flagsmith to migrate users from legacy platforms to new systems safely.

(This is a two-part series. We talked to Venu about the teams’ feature flag use cases and how they’ve changed the developer experience. We also spoke to Dario, their Tech Lead, for a deep dive into the technical implementation. Find the interview with Dario here.)

What your role is at Rain?

I’m the Vice President of Platform Engineering at Rain. I’m responsible for Cloud and DevOps developer productivity. We also have a Loan Management System (LMS), where we manage the loans and invoices for our customers, and I’m responsible for managing that.

I drive engineering excellence across the company. This relates to Flagsmith because it’s one of the standard tools that is used across the entire engineering team to launch features and keep our releases high quality.

What made you realize that you needed feature flags and a solution like Flagsmith?

We’re in Fintech. We launch features to production a few times every day, and it’s very important for us to be able to react fast and manage those releases easily. We’re constantly responding to customer needs and realised that we needed a way to manage new features and new code coming into production in a much more effective way.

How do you use flags now?

We have different business branches at Rain. This means we have different projects in Europe, the US, and India, and the business logics are different but we wanted a uniform code base. We decided that this can be managed with feature flags, since then we can control which area of the business we release to by wrapping the features in flags.

We can also be selective and choose which customers (employers) are exposed to which features if we manage releases with feature flags.

And what are your goals for releases and development?

We have defined goals for the company each quarter. When those are set, we look at development and map goals to the features we need to launch and the user enhancements we need to make. We’re constantly evaluating our releases against the goals.

When we launch code to production, for example, we have dashboards and monitors that we monitor. Those help us track the health of our systems but also help us keep an eye on metrics for the health of the business as well.  

For us to achieve all of the goals we set, we need to have a stable platform and a solid process for launching code to production.

How do you look at bringing new tools into those processes? What types of hurdles exist?

Feature flags are an interesting part of our development process because some flags are business and revenue-impacting. This means that the processes and tools around them need to be extremely reliable. Our main concern in bringing on a feature management tool is latency since we can’t have issues in production tied to flags.

100% uptime of Flagsmith is critical for running out business. For example, we monitor every transaction, and all transactions are tied to revenue. So every transaction is important. If there’s an issue with transactions in production, it’s a real problem. The good news is that Flagsmith is always there and we’ve mitigated potential issues together.

That makes sense! Can you tell us about a way you’ve implemented feature flags?

We use feature flags to improve our development process and increase engineering excellence. One way that happened was through a huge project we had around our Loan Management System (LMS).

We make sure employees can see how much balance is available on their app and based on that, they can run transactions to get funds. So the business is all about early wage access.

They’re supposed to be able to access the money much earlier than they would traditionally be able to. We were using legacy technology there and we built a brand new available balance algorithm and new messaging system on top of our platform. We use feature flags to manage the way that employers moved to the new available balance flow versus the old available balance flow.

Here we had to really rely on Flagsmith.

How did feature flags and Flagsmith support the migration?

We developed a new way to manage loans and instalments for customers, and this required us to migrate from the existing legacy system to the new system aggressively within six months. We used Flagsmith to control the onboarding and migration of users to the new employee system.

We had parts of the code that were built into our enterprise business and platform code to look for feature flags. While we were migrating, we had to be able to operate in both modes—we had to operate in the legacy mode and also move employers to the new LMS and operate the business in the new model. Flagsmith helped us manage the business and manage both products simultaneously in production.

We’ve just completed 100% of the migration! Now we’ll go back and slowly remove the feature flags.

That’s great! How do feature flags work with your new LMS?

Our Loan Management System (LMS) has an employer filter. We manage this filter to see which employers need which features enabled. The LMS also has new features for sending emails, scheduling the auto ACH, and so on. We have a lot of flags that we set up to manage the flows of the LMS.

For example, there are some customers we want to disable the transaction fees for. We use several flags to maintain use cases like that.

We also introduced mobile biometrics authentication. A lot of that authentication adoption was gradual and handled through phased rollouts. So whenever employers were ready, we would go in and enable the feature just for those employers. We could create flags and control how features were managed across the use cases and employers.

When you were configuring Flagsmith for the team, how did that adoption go?

We created a strategy to communicate with the team about when and how to use feature flags. This involved—among other things—running a talk with our team to cover a few of our use cases.  

We also did something specific in terms of monitoring how new flags are behaving with respect to the features that we are launching. Our monitors are all based on the new features. Not on the feature flag.

The LMS is built to enable our employers. We monitor how many employers have enabled it and how many loans are paid on top, and we monitor this on a weekly basis.

Thanks so much, Venu! We love working with Rain!

For a deep-dive into Rain’s technical implementation of feature flags, read the interview with Dario here.