Roadmap

Goals

Q2 2026 Objectives

AI-first flag management ONLY for PostHog employees (Driver: Phil Haack)

We have loads of people who work with feature flags internally, so let's dogfood the shit out of this. The bet is that teams will manage their entire feature flag lifecycle (this includes both flag and cohort-based targeting) through AI coding agents without ever opening the PostHog UI (or exclusively through PostHog AI). If agents can create, modify, and reason about flags autonomously, we become the default flags tool in agentic workflows rather than losing to DIY implementations.

What we'll ship:

• MCP server with full CRUD for flags, rollout conditions, and overrides
• Flag usage metrics & evaluation stats exposed via MCP
• Proactive signals pushed to agents: rollout changes, stale flag detection, evaluation anomalies
• Add MCP support for early access features

Real-time cohorts (Driver: Gustavo Henrique Strassburger)

This is our most-requested feature. Dynamic cohorts today are computed on a delay, which makes them useless for real-time targeting decisions like "user did X in the last 5 minutes." If we can make cohort membership evaluate in real-time at the point of flag evaluation, we collapse a whole category of custom targeting logic people currently build themselves.

What we'll ship:

• Real-time cohort evaluation at flag check time
• Cohort membership change signals for MCP / webhooks
• Migration path from existing dynamic cohorts

Close the targeting functionality gap (Driver: Phil Haack)

User and group targeting in the same flag is the most requested targeting capability we don't fully support. Every time someone hits this wall, they either hack around it or leave. This is table-stakes work that unblocks expansion in accounts already using flags.

What we'll ship:

• API and UI support for BOTH user AND group target management

Short term reliability and performance — Matheus BatistaMatheus Batista

Goal: Reliable remote evaluation with stable, predictable performance.

• Define and stick to clear metrics — p50/90/99 response time, error rate percentage, and availability SLA (e.g. 99.99% per month), equally defined for both remote and local evaluation
• Update flags HyperCache — Pre-compute more operations to reduce memory and CPU during evaluation
• Load shedding and request hedging — Graceful degradation under load
• Port local evaluation to Rust — Move local evaluation to the new flag definitions service
• Customer-facing latency and uptime dashboard — Make key performance metrics publicly visible

Move from read-heavy architecture to write-heavy — Phil HaackPhil Haack

Goal: Decouple flag evaluation from the Persons DB to contain blast radius.

• Dedicated Persons Feature Flag Store — A denormalized store purpose-built for flag evaluation, so we're not dependent on the shared Persons DB
• POC for pre-calculated flag evaluation store — Explore pre-computing flag results so evaluation doesn't require live DB reads

Improve deployment confidence and reduce foot guns — Patricio TarantinoPatricio Tarantino

Goal: Deploy changes safely with confidence, especially concurrency-sensitive changes.

• Load tester — Build a load testing framework for the flags service
• Improvements to "side" canary deploys — Enhance the existing canary deployment approach
• Full canary deployment — Graduate to a full canary deployment model
• Argo deployment pipeline — Work with the ops team on a proper deployment pipeline

Handbook

What this team does

We build feature flag tools, SDKs, and the in-app UI to help users safely ship new features and make data-driven decisions. We also own the reliability, stability, and performance of the feature flags targeting service and local evaluation endpoints.

Here are some of the things we own:

• Feature flag SDKs - SDKs in JS/TS, Python, Java, Rust, PHP, Go, Ruby, Dotnet, Unity, iOS, Flutter, and Android.
• Feature flags UI and CRUD API - a way to manage your feature flags in PostHog
• Feature flag evaluation API - both the soon-to-be-legacy /decide endpoint and the new /flags endpoint
• Local evaluation - ensuring fast, reliable flag evaluation at the edge

We write Rust, Python, and a bunch of client SDK languages. We're programming polyglots who care deeply about developer experience, latency, and uptime. Flags should be trivial to add, obvious to manage, and impossible to forget about. That means:

• Easy instrumentation — Adding a flag should be a one-liner in any language. SDKs should feel native, not bolted on.
• Sensible management — The UI should make it obvious what a flag does, who it targets, and whether it's still in use. No flag should become a mystery.
• Clean lifecycle — Flags are temporary by nature. We build tooling to help you clean up stale flags before they become tech debt.

Slack channel

#team-feature-flags

Feature ownership

You can find out more about the features we own

User personas

Assessing customer fit

Use this guide to determine if a prospect's use case is a good fit for feature flags now, in the future, or at all.

Engineers (product, growth, software, etc.)

✅ Fully supported

They're the primary users of feature flags and get the most value. They can implement flags end-to-end for progressive rollouts, kill switches, canary releases, and targeted feature access without coordination overhead.

Best fit: Any engineering team that wants safer deployments and granular release control.

Product Managers

⏳ Partially supported

They use flags to control feature rollouts, manage beta programs, and make release decisions independently. However, they typically need an engineer for initial implementation and adding flags to the codebase. Once implemented, they can independently manage flag targeting, rollout percentages, and enable/disable features.

Coming soon: AI-assisted flag creation will reduce the engineering dependency by enabling flag generation with natural language prompts.

Best fit: PMs who want control over feature releases without deploying code, and have access to engineering resources for initial setup.

DevOps/Platform Engineers

⏳ Limited support → Full support planned (further out)

What works today: Can use flags for infrastructure changes, database migrations, and operational toggles. Flags provide safe rollback mechanisms and gradual infrastructure rollouts.

Coming later: Infrastructure-as-code integration (Terraform, etc.) to better integrate flags into deployment pipelines.

Is this customer a fit?

• ✅ Yes, if they're comfortable managing flags via UI/API
• ⏳ Wait if they require deep IaC integration (coming but no firm timeline)