Shipping new features shouldn’t feel like crossing your fingers and hoping for the best. If you want to move fast and break things without breaking your users, feature flags are your best friend. This guide is for product folks, engineers, and anyone tired of the old “all-or-nothing” release game. We’ll walk through how to roll out feature flags using PostHog, and keep it honest: what’s worth your time, what isn’t, and how to avoid shooting yourself in the foot.
Why Bother With Feature Flags?
If you’re here, you probably know the basics: a feature flag is a switch. It lets you turn features on or off — for everyone, or just a slice of your users — without redeploying code. That’s huge for:
- Testing in production (safely)
- Rolling out gradually (not everyone gets the new thing at once)
- Quick rollbacks (turn it off if things go sideways)
- A/B testing (see what works, kill what doesn’t)
The catch? You need a system that’s easy for both engineers and non-engineers to use, doesn’t slow you down, and won’t turn into a tangled mess of “if/else” statements in six months. PostHog is one of the better options here — it’s open-source, self-hosted or SaaS, and doesn’t make you pay through the nose for basic features.
Step 1: Get PostHog Set Up
If you already have PostHog running, skip ahead. If not, here’s the honest take: self-hosting is great for privacy and control, but can be a pain to maintain. The cloud version is easier, but you’ll pay as you grow. Either way, pick what fits your team and budget.
To get started:
- Sign up at posthog.com or set up your own instance (Docker, Kubernetes, your pick).
- Add the PostHog SDK to your app. They support most languages and frameworks (JavaScript, Python, React Native, etc.).
- Verify events are coming in — check the dashboard for real user data.
Pro tip: Don’t obsess over “perfect” data setup from the start. You’ll tune things as you go.
Step 2: Understand How Feature Flags Work in PostHog
Before you start flipping switches, know what you’re working with.
- Flags live in the UI. You define them in PostHog, not in your codebase.
- Flags can target users. You can show a feature to 10% of users, only users in Canada, or just your internal team.
- They’re evaluated client-side or server-side. Where you check the flag depends on your SDK and use case. For anything sensitive, do it server-side.
Gotchas: - Don’t use flags for security. If a feature shouldn’t be public, don’t trust a flag to hide it. - Feature flags are not a replacement for code review, QA, or thinking things through.
Step 3: Create Your First Feature Flag
Let’s make a real flag.
- Go to the “Feature Flags” section in the PostHog UI.
- Click “New Feature Flag.” Give it a clear, specific name. (“new-onboarding-flow” beats “test123.”)
- Set rollout rules.
- Everyone: All users see the feature.
- Percentage rollout: Randomly show to X% of users.
- Property-based: Only users matching certain properties (country, email, etc.).
- Multivariate: Test more than just “on/off” (great for A/B/C testing).
- Save the flag. Make note of the key (you’ll use it in code).
What to ignore: Don’t overthink the naming scheme. Just make it clear enough for your future self.
Step 4: Check the Flag in Your Code
Here’s where things get real. You need to “ask” PostHog if the flag is on for a given user.
Basic example (JavaScript): js if (posthog.isFeatureEnabled('new-onboarding-flow')) { // Show new onboarding } else { // Show old onboarding }
Server-side example (Python): python if posthog.feature_enabled('new-onboarding-flow', user_id): # Serve new onboarding else: # Serve old onboarding
- Pass in a unique user ID, or PostHog won’t know who you’re talking about.
- For web apps, make sure users are “identified” in PostHog before checking flags, or results will be random.
Pro tip: Wrap flag checks in a helper function, so you can change things later without a giant search-and-replace.
Step 5: Test Your Flag Before Launch
Don’t just flip the switch and hope.
- Use the “try out flag” feature in the UI to see which users get the flag.
- Test as a specific user. You can force a flag “on” or “off” for your own account to check the experience.
- Check analytics. Make sure events fire as expected for both flag states.
What doesn’t work: Skipping this step. Even “simple” flags break in weird ways if you’re not careful.
Step 6: Roll Out Gradually (or to a Segment)
Here’s where feature flags shine.
- Start with internal users. Restrict the flag to your team’s email domain.
- Expand to 5-10% of real users. Monitor errors, support tickets, and user feedback.
- Go wider if things are stable. You can always dial it back if needed.
Don’t: - Roll out to 100% immediately, unless you have zero users or nerves of steel. - Ignore metrics. If you’re not measuring impact, you’re flying blind.
Step 7: Monitor, Measure, and React
This part is less glamorous, but it’s where you get value.
- Track usage and errors by segment (flag ON vs. OFF).
- Watch for performance issues. Sometimes new features are slow, and you’ll only notice at scale.
- Collect feedback. Actual user complaints are better than dashboards.
If things go wrong, turn the flag off — it’s that simple. But don’t just walk away; figure out what broke before you try again.
Step 8: Clean Up Old Flags
Nobody does this perfectly, but it matters.
- Remove dead flags. Once a feature is out for everyone, delete the flag from PostHog and rip the code out.
- Keep your codebase tidy. Too many old flags = technical debt and bugs.
Ignore the temptation to keep every flag “just in case.” If you’re not using it, kill it.
Honest Takes: What Works, What Doesn’t, and What to Watch Out For
What works: - Gradual rollouts with real-time monitoring. You catch issues before everyone sees them. - Giving product managers and non-devs the power to control features without waiting for deploys. - Using flags for A/B tests and experiments.
What doesn’t: - Using flags for security or access control. If it must be locked down, do it at the code or API level. - Leaving flags in forever. They’ll rot, and you’ll lose track.
What to watch out for: - “Flag hell”: too many flags, not enough cleanup. - Performance: Calling out to a remote flag service on every request can slow things down. PostHog SDKs cache flags, but test this in your stack. - Overcomplicating things: Don’t flag every pixel. Use them where it matters.
Keep It Simple — and Iterate
Feature flags aren’t magic, but they’re one of the best ways to ship faster and safer. Start small. Get one flag working, see how it feels, and build from there. Clean up after yourself. And don’t let tool hype distract you from the basics: good code, clear communication, and listening to users. That’s how you actually launch better products.