The problem
When you work on a new feature, you sometimes need to hide it and grant access only when certain conditions are met. When you refactor complex functionality, you want a way to switch between the old, proven code and the new version. Sometimes you simply want to switch between two implementations for fetching or storing data.
Feature flags cover all of these: they change system behavior without changing the code.
Our requirements
- Group feature flags per application and restrict access to specific applications
- Record an owner for every flag
- Support more than on and off, including date and time based conditions
- Keep the service lightweight
- Support Google SSO for login
- Support auditing
- Provide SDKs for Python and JavaScript
Where we started
We had been storing flags in two places: Contentful, which gave any team member a friendly UI for changes, and Redis, where developers changed flags through pull requests. With that setup we could not easily track changes, did not know who owned or created a flag, which application used it, or whether it was still in use.
We decided to introduce a dedicated feature flag service.
Looking at what exists
We first looked for an open-source or paid option that fit well enough. We evaluated Flagsmith, FeatureHub, Unleash and GrowthBook. All of them have public demos and good documentation for self-hosting.
All four offered a front end, Python and JavaScript SDKs, and an out-of-the-box solution. Most supported SSO and auditing, usually in the paid tier. But none met all our needs: each had features we did not need and lacked some we did.
Deciding to build
We concluded we could build a focused MVP ourselves in a few weeks. We chose PostgreSQL for storage and FastAPI for the Python back end, planned simple Python and JavaScript SDKs, and skipped the front end for the first increment.
The service had a few components:
- Users for user management
- Applications for the systems that consume flags
- Permissions to decide who can change flags for which application
- Audit log for a record of every change
- Feature flags for flag management itself
We estimated two weeks for the MVP and delivered it in two weeks, with only the features we actually needed.
What we learned
There is a ready-made solution for almost everything. But general-purpose tools are built for a broad audience, and can be more complex and cover more than you need. Sometimes it is better to build exactly what you need.
Even if you do buy, the research is not wasted. The domain knowledge we gained while evaluating the options was tremendously useful when we planned and built our own.