Roadmap

Goals

Q4 2026 objectives

Launch realtime cohorts and make behavioral targeting the reason to choose PostHog flags Matheus BatistaMatheus Batista

Targeting a flag at people based on what they did is one of our most-requested features. Realtime cohorts let a flag target a cohort such as "completed checkout_started in the last 14 days", and people move in and out of the cohort a minute or two after their events arrive. Realtime cohorts are in early beta behind a waitlist today. The Workflows team is building on them too, with realtime cohorts as audiences and branch conditions.

What we'll ship:

• Packaging, with pricing shown in the product and published in the docs
• Self-serve access in place of the waitlist, with no manual setup on our side
• A processing pipeline that scales to every project
• General availability, with a launch announcement and realtime cohorts shown where people build flags

Plan for scale and reduce the cost of operating Feature Flags Phil HaackPhil Haack

Our margins are small, and the cost of operating flags does not scale. We want to make sure that scaling 10x doesn't cost us 100x.

What we'll ship:

• $feature_flag_called events written to their own $flag_evaluations table
• The ability to query $flag_evaluations
• Tighter provisioning of the resources that serve flags

Realtime flag definitions Gustavo Henrique StrassburgerGustavo Henrique Strassburger

Customers want an alternative to polling for flag definitions. To deliver it, we need to restructure our pricing and find out what it costs us to run.

What we'll ship:

• Pricing for realtime flag definitions
• Possibly the feature itself, if the pricing work supports it

"Auto" rollback and rollout Gustavo Henrique StrassburgerGustavo Henrique Strassburger

After a flag ships, users watch their own metrics to decide whether to roll it back or widen the rollout. We can watch those metrics for them. Rollback and rollout read the same metrics for a flag and differ only in the direction they recommend. This automates work for users and adds a layer of protection to every release.

What we'll ship:

• An RFC that scopes the MVP and splits it into phases that each deliver value
• Phase 1: detect when a flag should roll back or widen its rollout, and notify the user

We'll know we're successful when: users accept our suggestions, and no accepted suggestion later needs to be reversed or causes a guardrail breach. Before customers see suggestions, a dry run must test at least 10 rollouts across 3 product areas, with at least 90% of recommendations correct and useful, and none unsafe.

Make flags the default way developers ship end-to-end Patricio TarantinoPatricio Tarantino

Developers build features in code, usually by talking to an agent, and rarely open the flags UI. Flags only enter that flow when the developer already knows to ask, and agents don't suggest them on their own. When a developer does ask, the agent creates the flag and stops. It doesn't wire the flag into the code, test it locally, or plan the rollout. MCP flag creation is booming, but many of those flags are never evaluated.

A flag only helps once code evaluates it. So flags should come to developers in the tools where they already build, together with the code change that uses them.

What we'll ship (candidates, to be refined):

• Flag by default: when a developer builds a feature with an agent, the agent flags it without being asked. The agent creates the flag in the right project, adds the SDK check to the code, toggles the flag on and off locally to confirm the code works both ways, checks that the targeting rule matches the developer, and proposes a rollout. This ships as a PostHog skill that the wizard installs, and covers both MCP and PostHog AI. This is the most important item in this objective.
• Flag on request (Ruby): when a developer asks an agent to flag a feature, the agent creates the flag, adds the SDK check to the code, confirms locally that the code works with the flag on and off, and proposes a rollout. This covers both MCP and PostHog AI.
• Proactive flags (Patricio): other PostHog products, such as Error Tracking and Data Warehouse, suggest a flag when their signals show one would help. The suggestion reaches the developer through their agent or as a code change. One example of the shape, not a commitment: a GitHub agent that scans PRs for risky changes and opens a draft PR that puts the risky feature behind a flag.
• UI simplification (Ruby, lower priority): trim the flags UI to what the core jobs need, so it doesn't distract the less technical users who now use PostHog.

We'll know we're successful when: a larger share of new flags created by agents and from proactive suggestions get evaluated. We'll set a baseline this quarter, and add instrumentation if we can't measure it today. We'll also track a fixed set of "build feature X" prompts that never mention flags, and measure the share where the agent flags the feature.

Make flag evaluation correct and consistent with cohorts and Product Analytics Phil HaackPhil Haack

Some flag operators behave differently when we evaluate them locally, remotely, or in Product Analytics. For example, a cohort can evaluate one way in remote evaluation and another way when its definition is part of the flag definitions for local evaluation. This confuses customers, produces results that look wrong, and reduces trust. We want flags to be trustworthy.

What we'll ship:

• SDK specs for all operators
• Flag evaluation that matches Product Analytics
• SDK local evaluation that matches remote flag evaluation

Other Q4 work

We plan to do this work in Q4, but none of it is a quarterly objective.

Platform

• Persons service: explore what it would take for flag evaluation to rely on the Persons service instead of isolating further, and give the Persons team feedback. We'll decide by mid-November whether to switch. If we switch, the migration becomes a Q1 objective.
• Rust writer for HyperCache: finish moving flags.json writes to the Rust writer (#96828). Edit and refresh already use it, but the verifier doesn't. Then delete the Python writer for flags.json, and after that the other HyperCache Python writers, one cache at a time.
• One bad filter breaks /flags: fix #98879, where one unparsable property filter in one flag makes /flags return HTTP 500 for the whole team.

Customers

• Unanswered issues and PRs: 25 issues labeled team/feature-flags have never had a reply from us. Reply to each one and triage open community PRs.
• Data Warehouse targeting: flags can already target Data Warehouse data through warehouse properties, but our flag docs mention it in a single bullet. Check for gaps, then add examples and a tutorial, such as targeting by Stripe plan tier.
• Status page metrics: turn on the feature flag metrics on the status page.

Carry-over and exploration

• Experiments support: keep working with the Experiments team on the Q3 Improved Experiments objective: boolean flag experiments, multiple experiments on a single flag, and a dedicated exposure event.
• Fit into how teams ship: explore Git as the source of truth for flag definitions, and promoting flags between projects (#34877).

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)