Feature flags are conditionals in the codebase that decide whether a piece of functionality is live, checked at runtime instead of locked in at deploy time. Flip one and the behavior changes for some or all users without a new release. That mechanic is simple. Deciding who may create, flip, or remove a flag gets harder once part of the team building the product sits outside the company's payroll, as on a blended in-house and nearshore or contract team.
What is a feature flag?
Martin Fowler's toggle-category framework sorts every flag by expected lifespan: release toggles that come out once a rollout finishes, experiment toggles that run for the length of a test, ops toggles that stay live as a production control, and permissioning toggles tied to who a user is rather than what's being tested. The category a flag falls into should decide how long it's allowed to stick around, before anyone writes a line of code for it. OpenFeature's vendor-agnostic flagging specification frames the same idea from a different angle: an open specification for a community-driven API that works with any flag management tool a team runs, or an in-house one, so governance doesn't have to get rebuilt every time a vendor's SDK changes.
How to run feature flags without flag debt
LaunchDarkly's definition of flag debt is direct: "Flag debt accumulates when code becomes littered with flags and old conditional logic that's no longer useful because the feature has already been fully rolled out." A flag platform's job, in LaunchDarkly's own framing, is managing the full lifecycle of a feature from internal testing and progressive rollout, through live observation and iteration, to eventual cleanup once the feature is fully rolled out. The six steps below are built to make that last stage, cleanup, an automatic part of the process instead of the thing nobody gets around to.
1. Pick a toggle category before you write the flag
Decide which of Fowler's four categories a flag belongs to before it ships, because the category is what tells you whether removing it in three weeks is expected or a sign the registry is being ignored. Fowler's inventory framing of toggle carrying cost makes the stakes explicit: "Savvy teams view their Feature Toggles as inventory which comes with a carrying cost, and work to keep that inventory as low as possible." A flag with no assigned category is inventory nobody is tracking.
2. Set an expiration date and a removal owner at creation
Unleash's feature-flag best-practices guide tells teams to set flag expiration dates and treat feature flags like technical debt, working removal tasks into sprint or project planning rather than saving them for a cleanup sprint that never gets scheduled. Fowler's version of the same discipline is a standing team rule: add a toggle removal task to the backlog the moment a release toggle goes in, or attach an expiration date to it directly. Either mechanic works. What doesn't work is deciding at creation that someone will deal with it later, because later is exactly when the engineer who wrote the flag has moved to a different project, or a different company.
Name the removal owner in the same pull request that adds the flag, before it turns into a separate ticket filed after the fact. A name survives a project handoff. A team label doesn't.
3. Decide who can create, flip, and remove a flag when the team is blended
a CI/CD vendor's advice on stale-flag cleanup starts with a question no vendor page answers for you: "Have conversations up front. How often will you remove stale flags? Who is responsible? Are there different owners for different types of flags?" On a single-employer team those conversations tend to settle by default, usually whoever owns the service. On a blended team they don't settle on their own, and skipping the question is how a flag nobody remembers creating survives well past the rollout it was built for.
Split the authority by action instead of by employer. Creating a flag should sit with whoever owns the service it touches, in-house or not. Flipping a flag in production, including an ops toggle that changes live behavior, is a decision a senior augmented or nearshore engineer should be able to make without waiting on an in-house sign-off: HighCircl's own position is that a senior augmented engineer should have full voting weight in code review and architecture discussions, the same as any senior in-house engineer, and the same logic applies to flag authority. Removing a flag is the one action worth a second signature regardless of who requests it. Unleash's four-eyes approval recommendation covers exactly this kind of change: "additional controls like feature flag approvals using the four-eyes principle" are worth adding, and a flag whose removal breaks a code path nobody remembers is reason enough to keep that rule even on a small team.
The same post also flags a wrinkle worth deciding on purpose: "by separating deployment from release, engineering teams are able to empower other teams to engage with feature flags for their own purposes, such as product management, sales, marketing, or customer support." Decide separately whether that access extends to external engineers with the same trust as in-house ones, or whether it stays read-only for anyone outside the core team until the audit trail is solid enough to open it up.
4. Turn on audit logging before the first flag ships
Datadog's governance guidance for flag platforms is specific about what a platform needs: role-based access, change approvals as needed, and audit logs that record who made changes and when. That list matters more on a blended team, because "who made changes" has to resolve to a name outside the company directory just as reliably as one inside it. If the audit log only ties changes to an internal SSO identity, an external engineer's flips show up as a shared service account, and the question stops being answerable exactly when it matters most, during an incident review.
LaunchDarkly's own platform lists RBAC, audit logs, streaming updates, and automated responses based on production signals as baseline features included by default. Whatever platform a team runs, configure those four at setup, before the first flag reaches production, rather than adding them after a flag change causes an incident nobody can trace back to a name.
5. Treat the flag registry like the technical-debt register
Datadog's write-up on flag governance names the failure mode directly: flag sprawl builds as unused or permanent flags accumulate, adding code complexity and maintenance risk with every release that doesn't clean up after itself. Unleash's advice matches it from the other direction: archive a flag once it's removed from the codebase, because that archive becomes the record of what a team ran and when.
Don't build a separate process to catch this. The same debt register with a named owner and a review cadence that a team already runs for technical debt is the right home for stale flags too. A flag overdue for removal is a specific, dated entry in that register, rather than a spreadsheet a different person maintains on the side. Review it on the same cadence the debt register already gets reviewed, so a stale flag competes for attention the way any other unpaid shortcut does, instead of getting forgotten until the next audit.
6. Use ops-toggle kill switches as part of the incident playbook
An ops toggle, one of Fowler's four categories, exists to change production behavior without a deploy, which makes it a legitimate incident-response tool as much as a release mechanism. Flip the flag that disables the feature causing the outage, and the fix ships in seconds instead of waiting on a build pipeline. That's a direct lever on DORA's change failure rate metric, the percentage of deployments that cause a production failure. A flag flip that resolves an incident without shipping new code doesn't add to that count the way a rushed hotfix deploy would.
Don't stand up a separate approval process for who's allowed to flip an ops toggle mid-incident. The ownership question a postmortem's action items already have to answer applies here directly: whoever is allowed to flip the kill switch needs to be named, in the runbook, before the incident happens, and the flip itself belongs in the incident timeline like any other change. A team that treats emergency flag flips as outside normal governance is the team that finds out, during the postmortem, that three different people had production access to a toggle nobody was tracking.
Feature flags vs. feature toggles: is there a difference?
Fowler's own article, titled "feature toggles," treats the two words as interchangeable: he lists feature flags, feature bits, and feature flippers as other names for the same set of techniques. LaunchDarkly's own FAQ on the same page draws a narrower line: "They're related but not identical. Feature toggles are the broader practice of controlling feature visibility at runtime without redeploying. Feature flags are the implementation mechanism that makes toggles possible." The category framework above, release, experiment, ops, and permissioning, holds regardless of which distinction a given team draws.
OpenFeature's own governance is worth knowing separately from its naming choice: it runs as an open source project incubating under the CNCF, under an Apache 2 license, rather than under any one vendor. Pick whichever term matches what your own team already searches for internally, and don't expect a governance policy written around "flags" to need a rewrite because half your documentation says "toggles."
FAQ
What is flag debt, and how is it different from technical debt?
Flag debt is LaunchDarkly's term for what accumulates when code stays littered with flags and old conditional branches that a team no longer needs because the feature they gated already shipped fully. It's a specific instance of technical debt rather than a separate category: the fix is the same discipline of a named owner, a risk level, and a scheduled removal, applied to a flag instead of a workaround or a shortcut.
Who should be allowed to flip a feature flag in production?
Split it by action rather than by employer. Creating a flag sits with whoever owns the service it touches. Flipping a flag, including an ops toggle mid-incident, should be something a senior engineer can do regardless of whether they're in-house or on an external team, provided the flip lands in an audit log tied to a real name. Removing a flag is the one step worth a second approval, since removal is what breaks a code path if the flag turns out to still matter.
Do feature flags replace a rollback plan?
No. An ops toggle can disable a specific feature in seconds, which covers a narrower set of incidents than a full rollback does. A flag only helps if the feature causing the problem was gated by one in the first place; a bad deploy that breaks something outside any flag's control still needs a real rollback path. Treat flags as one fast option in the incident playbook, alongside a rollback plan you still need to have.
Does OpenFeature let us switch flag vendors without a rewrite?
That's the specification's stated purpose: a vendor-agnostic API that works with whichever flag management tool or in-house system a team runs, so the code calling the API doesn't have to change if the platform behind it does. It solves the integration layer. Governance is a separate question: a team still has to decide its own rules for ownership, expiration, and audit logging, whichever vendor OpenFeature happens to be pointed at.