Customer Story: Smartex

Customer Segmentation and Staged Rollouts to Early-Adopter Clients with Lower Risk

We sat down with Jared Baribeau, Head of Software Architecture at Smartex. Smartex builds tools for the Modern Textile Factory. For example, they offer Smartex Core, which automates inspection for Circular Knitting Machines. They have a lot of hardware and complex, stateful software and their focus is on reducing release cycles and testing cycles.

Smartex uses Flagsmith to segment customers and run staged rollouts to selected early-adopter clients in line with their preferences. They wrap the features in feature flags, so if a feature is causing problems, they can toggle that off and continue patching in parallel. Now the product team is unlocked to segment more easily, and they can continue rolling out features with less risk.

Could you tell us a bit about what your role is Smartex? 

I'm the Head of Software Architecture here. Smartex is building, scaling, and expanding to more countries and customers. As we’re growing, we want to make sure that our processes and tools grow with us. 

We need to make sure that the software we're building can sustain the traffic and operations that are coming, and that our teams continue to function well as we add additional teams and processes. 

More concretely, I work on team planning and process building, system design, and as a tech-lead in one of our squads.

How do your teams use feature flags?

One of the first projects I had when I joined was bringing in feature flags. We had—and still have—our own config tooling that we use for some things. The config tools are for things that are very infrequently changed and are engineering-specific. 

We wanted releases to be more accessible for the product team, so we looked at feature flags to help solve that. We didn't want product managers to have to go in and make changes via the API or by going into the database to update feature settings. 

Instead, we wanted them to be able to segment features for phased rollouts in line with customer preferences.

Now the product team can segment customers for feature rollouts by themselves. They don't have to go through engineering to decide where to ship things, which makes the process much more efficient.

What do phased rollouts look like for you?

We’re B2B, so our customers are different factories. Our customer success team will talk to customers and work out who can handle advanced settings. Depending on how good our relationship is with the factory—or what their appetite is for beta features—we can roll out features to those customers first. That way we’re constantly changing our list of beta clients. 

Now the product team can segment customers for feature rollouts by themselves. They don't have to go through engineering to decide where to ship things, which makes the process much more efficient.

At the moment we’ve dedicated flags to on/off toggles and segmentation. We have very few flags with values. Flagsmith allows us to fine-tune the experience for our customers.

How do you see your flag use cases changing as you grow to more countries and customers?  

This is a conversation that we’re having right now. We have some old configs that require pretty strict validations and parameters. We have an ongoing discussion about where we want different things to live and which tools can help with which processes. 

Since we don't want to build and maintain an internal tool for feature flagging; we want a tool with a nice UI that can handle segmentation. And that's where Flagsmith fits in really nicely.

Is that what made you decide against using an internal tool for flags? 

Yes, exactly. We want to put as much of our time, energy, and money as we can into building tools and software that are core to our business. Feature flags enable our core business but are not our core business. 

And so in line with that, we offload and outsource feature flagging. It would be fun to build in-house, but as you know from building a whole company around it—there's a lot to do and it's a never-ending undertaking.

Absolutely, that makes sense. What do you think has changed the most since your teams started managing feature flags with Flagsmith?

We’ve reduced the amount of time that our DevOps and software teams have to spend going in and manually adjusting configs in the database. The product team also spends less time going through the engineering team to make updates or to turn things on. 

The amount of time saved by the teams is super valuable. Plus, the product team can now check on features and statuses on their own really easily. 

It seems like much of the focus has been on release processes. Do you have main goals that you’re aiming for when you approach releases and rollouts? 

We want to reduce the release cycle. 

We've got three or four different products on separate release cycles. The one that we're trying to cut down the release cycle for is our Smartex Core product. This is the key piece doing fabric inspection that’s right inside the machines. It's where the whole business started. 

It’s also by far the most complex product. The release cycles are much longer than we’d like, and we’re trying to bring them down. Part of that is through staged rollouts—which comes down to configs and Flagmith. 

How do the embedded devices work with feature flags?

Our fabric inspection product is powered by cameras and a couple of embedded computers that we install inside circular knitting machines. We’ve got thousands of embedded devices in factories across 10 countries—so having strong tooling to manage this fleet and effectively roll out updates is crucial.

Customers interact with the system via a tablet at each machine in their factory or a web application that provides factory-wide data and tools.

On the embedded Python side, using Flagsmith has allowed us to perform staged rollouts.

And on our tablet app, built with React Native, we’re able to meet product demands and customer success needs.

How is that going?

We’re getting better all the time. Right now, our biggest pain point is our testing cycles.

There’s a lot of hardware and complex, stateful software involved and so automated testing is hard. We built a whole simulation engine so that we can add more software testing. When we deploy a new release to our fleet, our staged rollouts start with early-adopter clients who are eager to be the first to use new features and are more fault-tolerant. 

Most new features are deployed behind feature flags using Flagsmith, so if a feature is causing problems, we can toggle that off. Since our QA cycle takes some time, feature-specific toggles are excellent for reducing rollbacks which would delay the other features included in the release. This way, we can continue with the rollout and work on patching the problematic feature in parallel.

Testing is improving, and the main thing that we want to do now is bring down the release cycle time. 

Since your software and hardware are complex, how did you go about configuring Flagsmith for your team? Were there any custom things that you did to deploy it and make it work for you?

The biggest challenge was setting up our dev and test workflows to effectively incorporate Flagsmith. The various Flagsmith SDKs made it really easy to get flags up and running quickly, so we were able to focus our efforts on building a workflow that fit within our company. We’re using Flagsmith in four different products—being worked on by different teams—so we had to figure out which parts to standardise and which parts to allow teams to shape themselves.

Take QA and tech support for example. Adding any new system adds complexity, which needs to be accounted for in testing and debugging. For every new flag added, there’s a new possible configuration for the application. This is multiplied for each flag, creating more permutations than would be feasible to test, and some potential for tricky bugs to emerge.

One of the team challenges was that we've got a lot of different products. We need to get everyone to be aligned when we take on a new tool like Flagsmith. For example, we need things like naming to be consistent.

And how have you gone about looking at that and solving it?

It’s a work in progress. It’s been a much more organic process than I originally expected. We wanted this to be a tool that empowered our teams, not one that added more friction, so we started with minimal processes and rules around it. The main thing that we’ve done is spent time educating the teams on how everything works (and the common feature flagging pitfalls to watch out for) so that our processes can emerge over time, without creating a bunch of technical debt along the way.

With debugging, it’s hard to troubleshoot something you don't understand. So the biggest thing has just been creating processes and explaining the architecture of our feature flagging to the teams. For example, “If you turn a flag off, or if you adjust a flag and it doesn't do what you expected it to, here are the things you probably want to check.” 

It's trickier in our embedded software. In the front-end client, you can just inspect and see what's going on. So we also built some tooling into our logging to show the flag values that are being returned, for example.

Do you use any integrations to help with your processes?

The Slack integration is really helpful for our teams. It allows everyone to keep tabs on flags. We have a feature flags production channel, and we also have channels split by environment. Now the right people know when there are changes to flags. 

Makes sense. Do you use any of the Flysmith SDKs?

Yes. Python is a server-side SDK, but we're using it in all of our embedded devices. That's the bulk of our traffic because there are so many devices. 

The way our product works, we might install four different devices inside a knitting machine and then a tablet. All of those devices are running one of the SDKs. The tablets are built in React Native so we're using the JavaScript React SDK there. 

Our current web app is built with React, and utilizes the React Flagsmith SDK; however, we just did a big rebuild using Angular (and the Flagsmith Javascript SDK). We’re starting to roll that out now.

Is there anything else you’d like to mention?

I would say that a big part of why we went with Flagsmith originally was because it seemed like the intuitive option, with an easy-to-use UI.  

Feature flagging is not an easy thing to put a good interface around. It's complex like there's a lot going on. So we really appreciate the fact that Flagsmith is so intuitive to use! 

We love to hear that. Thanks so much for your time and insights, Jared! 

If you’d like to find out more about how Flagsmith could work with your teams, start by creating a free account, or contact us.