Statsig building product observability OS

This ambition means Statsig is trying to own the full loop from shipping a feature to measuring what happened next. Instead of handing teams off between LaunchDarkly for flags, Optimizely for tests, and Amplitude for analytics, Statsig is building one system where the same event stream powers rollouts, experiment reads, funnels, dashboards, session replay, and even infrastructure monitoring, which makes product decisions faster and harder to dislodge.

• The concrete workflow starts with a developer wrapping a new feature in a flag, then setting rollout rules and guardrails in the same console. As users hit the feature, Statsig logs exposures and product events, then turns that same data into experiment results, funnels, metrics, and user level analysis without sending teams into a separate analytics stack.
  1 sacra 3 sacra
• This is also a land grab against adjacent vendors. LaunchDarkly is moving beyond release control, analytics vendors are moving into testing, and observability platforms are pulling experimentation into bigger platform contracts. Statsig’s answer is to bundle product analytics, session replay, and warehouse native analysis around its experimentation core before those categories collapse into someone else’s suite.
  2 sacra 3 sacra 4 sacra
• The business model fits that strategy. Statsig charges on usage, including the volume of events and higher value features like session replay, so every extra team that uses flags, experiments, analytics, or replay on the same install base can lift spend. By May 2025 it had reached about $40M ARR from more than 300 paying customers.
  2 sacra 3 sacra

Over the next few years, the winners in this market will look less like point tools and more like operating systems for product teams. If Statsig keeps deepening its shared data layer and adding adjacent workflows, it can become the default place where teams decide what to ship, watch how it behaves, and choose what to change next.