| name | adding-feature-flags |
| description | Add feature flags to an application for gradual rollouts, A/B testing, and kill switches using PostHog, LaunchDarkly, or a simple local implementation. |
Add Feature Flags
Use this skill when the user asks to add feature flags, feature toggles, gradual rollouts, or A/B testing.
Option A: PostHog Feature Flags (Recommended)
-
Install PostHog if not already present:
npm install posthog-js
-
Use feature flags in code:
import { useFeatureFlagEnabled } from "posthog-js/react";
function MyComponent() {
const showNewFeature = useFeatureFlagEnabled("new-checkout-flow");
if (showNewFeature) return <NewCheckout />;
return <OldCheckout />;
}
-
Server-side evaluation — for server components or API routes:
import { PostHog } from "posthog-node";
const posthog = new PostHog(process.env.POSTHOG_API_KEY!);
const isEnabled = await posthog.isFeatureEnabled("new-checkout-flow", userId);
-
Create flags in the PostHog dashboard — set up targeting rules based on user properties, percentage rollouts, or cohorts.
Option B: Simple Local Feature Flags
For projects that don't need a third-party service:
-
Create a flags config — lib/feature-flags.ts:
export const FLAGS = {
NEW_CHECKOUT: process.env.NEXT_PUBLIC_FF_NEW_CHECKOUT === "true",
DARK_MODE: process.env.NEXT_PUBLIC_FF_DARK_MODE === "true",
} as const;
-
Use in components:
import { FLAGS } from "@/lib/feature-flags";
function App() {
return FLAGS.NEW_CHECKOUT ? <NewCheckout /> : <OldCheckout />;
}
-
Add env vars — add flags to .env and .env.example:
NEXT_PUBLIC_FF_NEW_CHECKOUT=false
NEXT_PUBLIC_FF_DARK_MODE=true
Notes
- Use feature flags for all user-facing changes during rollout, not just experiments.
- Clean up stale flags — remove the flag and the old code path once a feature is fully rolled out.
- For server-side flags, cache the evaluation result to avoid per-request API calls.
- Name flags descriptively:
new-checkout-flow not flag-1.