Customer Story: Motosumo

Motosumo manages major releases with feature flags using Bullet Train.

At Bullet Train, we love to share how our customers are using feature flagging in their day-to-day. In this post we caught up with Niels Christensen over at Motosumo, a Bullet Train customer, to learn more about his company and the ins-and-outs of how they use feature flags.

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

I’m a computer science Ph.D. who’s spent most of his adult years developing server-based software and looking for the best ways to do that.

At Motosumo my title is “Principal Software Engineer”, which means I’m a contributing part of the Tech Team.

We’re a startup, so roles aren’t rigid 🙂

What does your company do?

Motosumo (https://www.motosumo.com/) wants everybody to enjoy live, at-home indoor cycling classes. That’s why the Motosumo app turns any bike into a smart bike with live fitness tracking and pro stats. We offer fun, unforgettable classes that keep members coming back for more.  The Motosumo app is also designed for gym operators and fitness professionals who want to host group fitness classes themselves.

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

Our frontend components are React and React Native, while the servers run Python and Elixir in Docker containers hosted on AWS.

In the Motosumo Tech team, we deliver features using Kanban. Our app is usually updated once per week but at times we have been known to submit a new version each day. Our cadence for non-app components tends to be higher. We release on-demand, up to two or three times per day, using git merges that trigger automated deployments in CircleCI and AWS.

How did you discover feature flags?

At a previous employer we were 40-50 developers on 7-8 teams contributing to one Monolith application server.

The complexity of avoiding code conflicts was a major pain, so feature flagging was suggested to make integration work more smoothly across teams. We assigned a small group of strong developers to make the surgery that allowed the Monolith to be controlled by feature flags. They were ready by the next release, and it brought great relief to the entire department.

What was the first flag you implemented at Motosumo and why?

Motosumo classes include racing games that pits one half of the group against the other. We were re-implementing one of these games from a 2-dimensional CSS-based version to a Unity-based 3D experience. This was a major feature that required a lot of test classes before we were satisfied with everything from graphical finish to team balancing. Feature flagging this feature meant we were able to keep the two different games smoothly side-by-side.

Has feature flagging increased your deployment cadence?

It has. Using feature flags have allowed us to always make sure the trunk branch in git is deployable. This is a particular relief in these challenging times (under a partial COVID-19 lockdown), because we can’t always check with everyone on the team.

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

Cleanup! If you are not careful and disciplined, one piece of functionality can be governed by many feature flags, and it gets really difficult to figure out whether that particular menu option should appear or not in a test.

We are currently tracking all feature flags on our Kanban board to remind us to remove each one from the code once the feature is fully released.

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

We love our PO, and at the top if his Feature Flag Wishlist is quick and easy segmentation, so he can activate features for select partners or customers even while he’s on call with them.

Thanks for taking time to share with us, Niels!