Feature flag naming conventions that scale

A flag name gets read a thousand times and written once. Spend the extra minute on the name.

Here’s the scheme we use at Flagify and the reasoning behind each rule.

Rule 1: kebab-case, always

new-checkout-flow       ✓
newCheckoutFlow         ✗
NEW_CHECKOUT_FLOW       ✗
new_checkout_flow       ✗

Kebab-case is readable at a glance. It matches the way URLs are written. Every other casing style invites typos — isNewCheckoutFlow vs isnewcheckoutflow vs is_new_checkout_flow. Pick kebab-case and move on.

Rule 2: start with the area, then the specific thing

checkout-new-flow       ✓
new-checkout-flow       also ✓, but less sortable
checkout-express-lane   ✓

When you have 50 flags, alphabetical sorting is how you navigate the list. If all your checkout flags start with checkout-*, they cluster together. If they start with adjectives (new-checkout, fast-checkout), they scatter.

Some teams prefer verb-first (enable-checkout-new). That works too if you apply it consistently. The important thing is that the area is somewhere in the prefix.

Rule 3: describe what the flag does, not when it was created

new-search-engine       ✓
search-v2               OK (acceptable)
search-2026-redesign    ✗ (dates are noise)
sprint-47-search        ✗ (who cares about sprint numbers)

The version numbers in v2, v3 are borderline. They are fine when the old and new coexist. They are annoying when v3 has been live for two years and nobody remembers what v1 or v2 were.

Rule 4: encode the type in the name when it matters

Some teams prefix flag types so you can tell at a glance what category they are:

release-new-checkout    (release flag, temporary)
kill-payment-processing (kill switch, permanent)
exp-pricing-page        (experiment)
plan-csv-export         (entitlement by plan)

This is optional. Most flag tools let you tag flags by type in the dashboard, so you don’t need to encode it in the name. But if your team doesn’t use tags, the prefix helps.

Rule 5: make intent obvious

The name should answer “what happens when this flag is true?”

Good: enable-dark-mode — on means dark mode is on Confusing: dark-mode-override — on means what, exactly?

Good: show-beta-banner — on means the banner appears Confusing: beta-banner-suppress — double negative

Avoid flags where the meaning depends on context. The person reading the code should not have to look up the flag definition to know what “true” does.

Rule 6: keep names stable

Once a flag is live in production, renaming it is a coordinated change: code, tests, dashboard, docs. It is usually not worth it. Spend the extra minute when you create the flag so you don’t regret the name later.

If you do need to rename, create the new flag, wire it up in parallel with the old one, let them run together for a deploy cycle, then remove the old flag. Don’t rename in place.

Rule 7: no secrets, no PII

Flag names end up in logs, dashboards, git history, and (if you’re unlucky) screenshots shared in Slack. Don’t put anything in a flag name that you wouldn’t want visible.

internal-policy-override   ✓
customer-x-special-deal    ✗ (names real customer)
bypass-fraud-check-acme    ✗ (exposes internal workaround)

Examples across flag types

Release flags (temporary):

checkout-new-flow
search-elasticsearch-backend
dashboard-redesign-2026

Kill switches (permanent):

enable-email-sending
enable-payment-processing
enable-llm-suggestions

Entitlements (business rules):

feature-csv-export-pro
feature-sso-enterprise
feature-unlimited-workspaces

Experiments (temporary):

exp-pricing-page-headline
exp-onboarding-flow
exp-checkout-cta-copy

Scaling past 50 flags

Once you have more than about 50 flags, a flat namespace gets painful. Options:

Projects. Split by product area. Flagify supports multiple projects per workspace. Flags in project checkout can have simpler names because checkout- is implicit.

Tags. Tag flags in the dashboard (area, team, flag type). Use tags to filter, not to name.

Prefixes. Within a project, prefix by team: team-payments-new-gateway, team-growth-referral-banner. Helps with ownership.

What we do internally

We have about 40 active flags across three projects. Our convention:

Kebab-case
Start with the area when it exists: cli-, api-, dashboard-
Use enable- prefix for kill switches
Use exp- prefix for experiments
Don’t use date or sprint numbers

It’s simple enough that new engineers pick it up in their first week.

Read feature flag best practices for the broader context, or the What are feature flags guide for flag types and lifecycles. Flagify enforces kebab-case automatically — you can’t create a flag with invalid casing.

Start for free — no credit card required.