Since adopting Posthog for user analytics at poketto.me, I’ve grown pretty fond of the tool. Beyond the basics and advanced insights, I’m now also using it for feature flagging.
Fine-grained control (and easy rollback) of new features or major changes is becoming increasingly important as the poketto.me user base grows. Why?
š¤ In a B2C app, you can’t count on users to complain when something breaks—they’ll just leave. Especially for early-stage products, every irritated user is a missed opportunity.
š§Ŗ Having a small group of early adopters to test new features is incredibly useful. But you don’t want to manage access manually in the code or via a clunky, home-grown interface.
š Launching new features is now a bigger, coordinated effort: update the website, write an announcement email, post on Bluesky and X… oh, and actually make the feature available š
As I shared in TIL #81, my first attempt at feature flagging used “entitlements” as a catch-all: a simple list of strings per user that I managed in an admin UI. (“Is this user allowed to see/do that?”) The fact that this wasn’t sustainable quickly made itself evident when I tried to untangle subscriptions, entitlements, pricing plans, and feature flags.
Sure, there are specialized tools like LaunchDarkly, Flagsmith, and many others. But for the size and scope of poketto.me, the fewer tools I need to manage, the better.
With Posthog, I can:
š Check “feature X enabled or not?” with a single line of code
š Toggle features on/off in the same environment I already use for analytics
š Manage fine-grained rollouts (e.g., by country, browser, or platform—like only Android users)
The only downside: Posthog doesn’t directly support the OpenFeature API (yet), which means you can’t easily swap it out for another feature flag provider later. There are a few projects out there aiming to help you with that, such as the Posthog Provider for OpenFeature for Node, but nothing that works across languages—so far.
