Customer Story: Brella

Brella introduces new features to differentiate their product with Flagsmith.

At Flagsmith, we love to share how our customers are using feature flagging in their day-to-day. In this post we caught up with Niklas over at Brella.io.

Who are you and what is your role at the company? 

Niklas Lepistö, Senior Frontend Developer at Brella. (Niklas is on Github: https://github.com/laznic)

What does your company do? 

Brella is the world’s leading virtual event & networking platform. Thousands of companies and organizations around the world trust Brella to deliver truly interactive virtual, hybrid and in-person events that empower attendees and sponsors to make meaningful connections.

Describe your platform and how your team builds software: Process, Methodology, Release Cadence, etc. 

We have multiple different applications: Admin Panel (for event organizers, React), Web App (the attendee facing site, React), Native apps (for attendees, React Native). 

We build our products based on Agile methodology, so we do incremental feature releases. Our Product Team is divided into smaller squads, which consist of one designer, two backend developers, two frontend developers, and one QA. All our squads have their own areas of responsibility in our products. For example, one squad is responsible for onboarding, people, and networking features while the others are responsible for sponsors and community.

We use GitHub Actions and Vercel integration to do deployments. Our project planning and management is done via Shortcut (formerly Clubhouse). We do Preview deployments for each of our frontend branches so that designers and QA can test features in isolation without affecting production or other staging environments. All our stuff gets released only when QA is satisfied with it. And we never deploy on Fridays.

How did you discover feature flags?

We’ve had our own implementation for feature flagging in the past, however it’s a bit cumbersome to use as it’s pretty much hard coded in the backend. We also realized that we need to have some sort of feature flagging, as we are working on features that we don’t want every event to have, and would like to have feedback before releasing those features for the general public.

I had stumbled upon Flagsmith, while it was still called Bullet Train, in the past via some Hacker News post or a recommendation in a developer Slack community. I was initially impressed how simple it all looked, and suggested that we use it here at Brella.

Tell us about an interesting way you've used Flagsmith at Brella. 

Since one of the key features in Brella is matchmaking, it helps the attendee experience in the events if they can rate the meetings they are having with other people on the platform. Rating the meetings helps event organizers, sponsors and Brella. We use this data to understand; whether the meeting happened, whether the meeting delivered value to them, and why they perceived it as delivering value to them.

Adding meeting ratings to our platform is a big feature, and we didn’t want to just go out and release it to the public without knowing the real value of it. We wanted to pilot it with a select few customers of ours, and get feedback from them to see if it works as intended and it would be something that is missing from our platform. And this is where Flagsmith came in.

Usually when you add feature flags, you are applying them for the logged in users. However, in our case, we also want virtual events to have differentiating features, or we want specific virtual events to test out some features before releasing them to everyone. We found that Flagsmith is super flexible when it comes to feature flagging entities: while everything is called a user on the platform, you can actually store any kind of JSON data. So we treat each virtual event as a user on Flagsmith, which works very well. We’re now able to toggle various feature flags for any of the events we have on the platform. And since we’re using the event name instead of the event ID as the user name on Flagsmith, it makes it easy to search and find the correct events where we want to toggle the feature flags.

We also have a use case for identifying the logged in users on Flagsmith, and big thanks goes to Kyle who quickly added the support to the Flagsmith JavaScript SDK to be able to create multiple Flagsmith instances in our code, so that we can fetch and use different flags for both events and the regular users at the same time. Now only the sky's the limit with the flagging system! For example, we could implement event specific features which require the logged in user to have a specific email address, or just some other specific flag toggled in their data on Flagsmith.

Then aside from the serious business features, we also wanted to play with Flagsmith a bit, and decided with the Product team that we wanted to do something special for our own internal Brella virtual kickoff event! Here at Brella we have internal kickoffs twice a year where we get together with everyone, talk about the company, our future, and of course have fun. Due to the pandemic, we’ve held these kickoffs remotely on our own platform, which has been nice. And this time we wanted to take it to the next level, so we created Party Mode just for our own event! 

The implementation was quick and dirty as we only had a few days to work on it. However, it didn’t matter that the quality of the code wasn’t as good as what we usually stick to because it was wrapped inside a feature flag. So what we did is that when you entered the kickoff event, you’d see this button saying “party mode” on the very top and when you clicked it, it would display this animated color gradient with animated emojis on top of everything, while playing music in the background. And boy, did people love it! We also did some other cool things with the party mode, however, those we will keep as a secret! 

How have you driven adoption of feature flag development among your team?

When we added the Party Mode to our kick-off event in production, people realized that this is an amazing service! It opens so many possibilities to start and try out stuff without having to affect all the users. The team is excited to use it more, and we’ve been thinking about ways how we could even do branch specific feature flags, so that for example some events could have a feature enabled that doesn’t exist in the production branch yet. Like they could have their own isolated production branch for themselves to have a specific feature in.

We’ve also been talking that maybe in the future we will give our CS team access to Flagsmith so that they can enable and disable feature flags directly without having to message the development team. This would then improve the relationship between us and our customers, as they would get faster responses to toggling features on and off while their events are running, or they get to take part in testing more exclusive and exciting new features we’re currently working on.

What are the downsides? Or gotchas that others should be aware of when using feature flags?

We haven’t faced any downsides so far, however one thing I could say is that you should create your own feature flagging service in your code! Just a class or some functional approach, where you wrap the Flagsmith SDK methods inside in order to use it more conveniently.

And make sure you are calling the identify method asynchronously, especially if you are using Redux Sagas like us. We initially had a problem where the feature flags we’re one step behind when fetching them between switching events. So if one event had a feature flag on and we loaded the event page, nothing appeared on our screen. Then, if we switched to another event that didn’t have the feature on, it suddenly appeared on the screen. When we looked closer, it was using data from the previous event and wasn’t keeping up with the life cycle. Debugging this made us realize that we had forgotten to add the crucial await keyword in front of the identify method, so our Sagas never actually waited for the feature flag data to arrive before loading the event data. Easy fix though!

If you could add one feature, what would it be and why?

I think it would be super cool to be able to add scheduled flags or just automate them! For example, if we wanted to offer a two-week trial period, and after that all the flagged features get disabled if the customer hasn’t picked a monthly plan or such.

Great idea! We've added the feature request to our Github repository here. Thanks for taking the time to share your experience with us!