Feature flags without the platform

Feature flags let you merge unfinished work safely, release to a subset of users, and turn something off without a deploy. All three are genuinely valuable to a small team.

What is not necessary, early on, is a platform to manage them.

What flags actually buy you

• Merging continuously instead of maintaining long-lived branches that grow harder to merge each week.
• Separating deploy from release, so shipping code and exposing a feature become two decisions.
• Turning something off in seconds when it misbehaves, rather than reverting and redeploying.

That second one is the real prize. A deploy that changes nothing visible is a low-stress deploy, and low-stress deploys happen more often.

The minimum viable implementation

A table with a name, a boolean, and optionally a list of accounts it applies to. A cached helper that reads it. An admin screen with toggles.

That covers the large majority of what a small team needs. Caching matters — a flag checked on every request must not mean a database query on every request.

Flags are debt with a short fuse

Every flag is a branch in your code and a doubling of the states you must reason about. Three flags is eight combinations, most of which nobody tests.

The discipline that makes flags work:

1. Give every flag an owner and an expected removal date when you create it.
2. Remove it within weeks of the feature being fully released.
3. Review the list monthly and delete anything permanently on or permanently off.
4. Never let a flag become permanent configuration — that is a settings table, and it should look like one.

When a platform earns its cost

When you want percentage rollouts with proper bucketing, experiments with statistical analysis, flags evaluated in the client without a round trip, or an audit trail of who changed what.

Those are real features and building them properly is more work than it looks. But they are the second problem, and buying the solution before having the problem is how small teams end up with a dependency they use at five percent.

Do feature flags slow an application down?

Only if evaluated badly. A flag check should be an in-memory lookup against a cached set refreshed every few seconds, which costs nothing measurable. It becomes a problem when each check hits the database or an external service on every request — at which point the flag system is doing more damage than the feature it guards.

How many flags is too many?

There is no fixed number, but if you cannot name what every live flag does and who owns it, you have too many. The practical test is whether anyone is confident about deleting one. When the answer is no, the flags have stopped reducing risk and started being risk. For how this fits a wider release approach, see why software projects run late.