Companies differing motivations and resources determine their priorities and impact how they develop their products. In this way, not all companies base their business model on building a product to solve a real problem. Still, some of them do. In the case of Flagsmith, a commercial open-source feature flagging software, its developers focus on features that are valuable to its users instead of gambling on market hype. This episode will explore Flagsmith’s origins, design philosophy, and recommendations for putting it to use.
Edited transcription
As it stood out among a handful of product ideas for a side project, Flagsmith came to fulfill the need for a feature-flagging open-source platform. Developers use feature flags to control the visibility and behavior of features in their applications without deploying new code, which can be useful for:
- Rolling out new features gradually
- A/B testing different feature versions
- Experimenting with new ideas
Flagsmith also provides remote config tools for changing an application’s configuration at runtime without deploying new code. Remote config is used to customize the user experience and optimize an application’s performance.
Prioritizing value over features
From day one, Flagsmith has been a commercial open-source business, meaning that while it is developed and distributed as open-source software, the company behind it also generates revenue from it. In this way, as Flagsmith’s co-founders and CEO Ben Rometsch recalls, rather than being stressed out by an “urgency around revenue” the open-source nature of Flagsmith allows its developers to focus on “people starring the project, people contributing to it,” and the “general level of interest around it.”
In this regard, Ben noticed that when his team turned payment on in the Flagsmith platform, they “suddenly became myopic” around revenue and temporarily stopped “seeing things as a whole.” They swiftly had to remind themselves that building a product “it’s not just about the ARR (Annual Recurring Revenue) number”, but to “care just as much about the engagement on the open-source side and all of those non-financial metrics.”
As a parallel, Ben identifies this distinction in how the two most prominent Flagsmith customer groups do business and whose “needs and wants and how well a product lands” differ.
On the one hand, there are venture capital (VC) companies. These companies start business by going public to raise initial capital and, Ben notices, often create products for companies on the same business model.
As Ben describes, VC companies’ engineering teams “move quickly, they’re very, very much on the cutting edge, they’re quite often building tooling themselves.” Often, these are Silicon Valley companies “that really have the capacity and the money essentially to be on the bleeding edge of everything.” They “have a very urging need to adopt that technology” as a way to proliferate and gain market share.
Still, while VC companies can grow to be worth multi-billion dollars, Ben insists that these represent “a very small percentage of the market.” In turn, the other large group of Flagsmith customers are late technology adopters who “don’t have the money to waste on adopting something new and untested that will bite them,” but rather, “are just trying to ship their software.”
Simplicity first
From the beginning, the motivation behind Flagsmith was building a product that solves a real problem. The work Ben and his partners were doing at their consulting agency heavily influenced choosing this business model, and consequently, Flagsmith’s design and development: “It’s not strange now that businesses that sustained Flagsmith as a business look similar to the ones that we were working for and consulting to at the time that we were sketching out the overall product,” Ben observes.
Being a bootstrapped company, Flagsmith was designed and built having the same business model as non-venture-backed companies, which has allowed Flagsmith developers to design their product with the same concerns in mind. So rather than prioritizing features aligned with cutting-edge technologies, Flagsmith’s roadmap is made according to what would be valuable for their client’s industries.
In this regard, Ben points out that too many SaaS products suffer from aimless complexity that makes it difficult to use due to adding unnecessary features. “Engineering or product design defines itself way more on what you don’t do than on what you do,” he believes. While VC companies can’t make this kind of decision since stakeholders are prone to push as many trendy features as possible in their products, from the beginning, the Flagsmith team decided never to have an analytics ingestor that integrates with the UI. Even though Flagsmith competitors include metrics that indicate how feature flagging performs, Ben understands that engineers do not demand such a tool and it is the responsibility of a different team or department to measure and present performance metrics.
Besides, Ben says his team is “very careful about not adding mental loads to the platform” and tries to preserve the CI and not add extra elements or walkthroughs that bother users. Despite the big effort put into building a product, it is not for the user to be aware of this and it should not be in the UI. As an example, Flagsmith implemented a single button to migrate users to their new Edge API, without additional elements highlighting it. Ben understands that big releases changes or new features should not be highlighted intrusively to the user, but rather be part of the documentation.
In like manner, technical documentation should follow the same path of conciseness and clearness. “My absolute favorite pull request you can have is when you have a net negative line count,” Ben says, meaning that the developer should prioritize removing more lines of code from the documentation than they have added. Ben believes that this is a sign of a good developer who is thinking carefully about what information is essential for users to know and what information can be omitted without sacrificing clarity, an approach to technical documentation that has significantly influenced the design of Flagsmith.
The bottom line
Ben believes feature flagging is still in the early stages of adoption, so he encourages developers to try it out through Flagsmith. The best place to start with Flagsmith is the GitHub repository, at github.com/flagsmith. You can also join the Flagsmith Discord community to discuss design patterns and other topics related to using feature flags.
For those using a YAML file-based feature flag system and looking to move to Flagsmith, Ben recommends two main ways:
- Use the Flagsmith Docker Compose file, made of two containers (Postgres and Flagsmith), to get the platform up and running quickly.
- Sign up for the Flagsmith SaaS platform, which is free to use until it exceeds a certain amount of traffic.
Additionally, since Flagsmith is open source, it is possible to run it on-premise or in a private cloud. Also, Ben recommends Kubernetes for Flagsmith deployments, as it is the orchestration platform of choice for most Flagsmith users.
To keep up with Flagsmith and his other projects, follow Ben on Linkedin and on Twitter. You can also check his consultancy company Solid State Group.
