[mattbrewsbytes]

Its a SaaS web app so feature flags are stored in the DB for easing flipping by biz people so they can rollout features w/o having to involve engineers. Simple homegrown solution of a table, name of feature flag and a boolean, corresponding object with handy methods and a simple UI. Feature flags are commits as blocks of feature flagged code. There might be a dozen or two at a time so querying an indexed DB table with < 50 rows is not an issue.

Blocks of code around the intended feature flag find the feature flag boolean and do whatever they are supposed to do. If a feature flag is not found it defaults to false/off. Later on after features are rolled out and have become the default, an engineer removes the FF code, related tests, and DB row.

I don't see how a tool/SaaS could be any better for this scenario. There is a DB dependency but honestly if the DB isn't available then shit is on fire in a very bad way and I don't care about feature flags in that moment.

Other options could be ENV variables loaded at app startup, this can get unwieldly though if you have a lot of them and requires an engineer to be involved. Putting feature flags in an external system seems like purposely introducing more failure modes to your app.

[GeorgeMac]

Nice. Have you had to develop any capabilites around knowing what changed, when and by whom? i.e. audit log or so on?

Just wondering what is your process in an incident when you want to know what changed in the system? e.g. so you can correlate observed error rate changes with a the enabling or disabling of a flag.