Feature flags you can build in an afternoon
The value is decoupling deploy from release. That does not require a platform, and the platform is not the hard part.
Feature flags separate shipping code from turning it on. That is genuinely valuable — it makes deploys smaller and less frightening, and it turns a rollback into a toggle.
The tooling around it is often larger than the problem.
What a flag actually needs
A name. A rule for who sees it. A way to change that rule without a deploy. That is it.
A table with a name and a state, cached in memory, covers a great many cases. Percentage rollout is a hash of the flag name and the actor id compared against a threshold — stable per user, so someone does not flicker in and out between requests.
Per-account overrides are a second table. Now you can enable something for one customer, which is most of what enterprise flag tooling is sold on.
The check should be boring
One entry point, called the same way everywhere. Flags scattered as environment variables in some places and database lookups in others become impossible to inventory.
Default to off. A flag whose lookup fails should behave as though the feature is disabled, not enable it because of an exception. This matters more than it sounds — a cache miss or a database blip should not launch a half-finished feature.
Flags are debt with a timer
Every flag doubles a code path. Two flags interacting produce four, and nobody tests all four.
A flag that has been fully on for three months is not a flag, it is dead code plus a branch. Record when each was created and who owns it, and treat removal as part of finishing the feature rather than a nice-to-have.
The failure mode is a codebase where nobody can tell which paths are live, and a bug report that cannot be reproduced because the reporter had a different combination.
A flag without a removal date becomes permanent branching that everyone is afraid to delete.
Where a vendor earns it
Real-time updates across many processes without a deploy. Sophisticated targeting — attributes, segments, gradual rollouts with automatic rollback on error rates. Audit trails of who changed what. Experimentation with statistical analysis attached.
If you need those, buy them. If you need "turn this on for staff, then 10% of users, then everyone", that is a table, a cache and about fifty lines.