Everyone is building the same dashboard
Five or six years ago, a reasonably serious product team bought four tools. One to run A/B tests. One to see what users did in the product. One to catch exceptions. One to watch the servers. They came from four different companies, had four different SDKs, four billing pages, and four ideas about what a "user" was. If a checkout experiment tanked conversion because the new variant threw errors on Safari, you would find out by noticing it in the experiment tool, then going to the analytics tool to confirm the drop, then going to the error tracker to find the exception, then going to the infra tool to see if the API was slow. Four tabs, four logins, and a Slack thread stitching the story together.
In 2026 that story is collapsing. PostHog, Sentry, Datadog, and Amplitude all started in different corners of that map and are now sprinting toward the same center. Each of them wants to be the place where you flip the switch, watch the metric, catch the crash, and read the trace, without leaving the page. I have used three of the four, PostHog on my own products and Sentry and Datadog at previous jobs, and the thing that surprised me when I sat down to write this was not that they are converging. It is what they are converging on. It is not the dashboard. It is the feature flag.
What an A/B test actually is in 2026
Strip away the marketing and an experiment today is four things wired together. First, an assignment: a deterministic hash of some user identifier plus the experiment key decides whether this person is in control or variant, and that decision has to be stable so the same person sees the same thing on every visit. Second, an exposure event: the moment the code actually reads the flag, you log that this user was exposed to this variant, because "assigned" and "actually saw it" are different populations and only the second one counts. Third, the metrics: a primary metric you are trying to move and a handful of guardrail metrics you refuse to hurt, like error rate, latency, and churn. Fourth, the stats engine that decides when you are allowed to believe the result.
The stats side is where the last few years actually changed something. The old sin of A/B testing was peeking: you check the result every morning, and the first morning it looks significant you ship it, which inflates your false positive rate wildly. The fix that has become table stakes is sequential testing, where the p-value or confidence interval is valid no matter how many times you look. The other big one is CUPED, which uses each user's behavior before the experiment to explain away variance during it. In practice it cuts the number of users you need by something like a third to a half, which for a small product is the difference between an experiment that finishes in two weeks and one that never finishes at all.
And the architecture changed. The serious platforms no longer insist you send them a copy of every event. They run the analysis inside your warehouse, in Snowflake or BigQuery or wherever your revenue table already lives, so the experiment's "conversion" metric is the same number finance uses instead of a lookalike computed from client events. Eppo built its whole company on that. Statsig added a warehouse-native mode. GrowthBook is open source and was warehouse-native from day one. If you have a warehouse at all, this is the version you want.
Why the flag became the center of gravity
Look at what each of the four original tools needs in order to do its job well, and notice they all need the same thing. The experiment tool obviously needs the flag, because a variant is a flag value. The analytics tool needs the flag, because "did the new onboarding help retention" is unanswerable unless every event carries which onboarding the user saw. The error tracker needs the flag, because the single most useful piece of context on a new exception is "this only happens to users with new_checkout enabled." And the infra tool needs the flag, because when p99 latency jumps at 2:14pm, the question is always "what changed at 2:14pm," and increasingly the answer is not a deploy, it is a rollout that went from 10% to 50%.
So the flag is the one primitive that release, experimentation, and incident response all touch. It is also the only one of the four that changes behavior in production. Analytics, errors, and traces are read-only. A flag is a write. Whoever owns the write owns the moment where a human decides to roll forward or roll back, and every one of these companies has figured out that being the tool open at that moment is worth more than being the tool open for the retrospective afterward.
Once you see it that way, the acquisitions of the last eighteen months stop looking like a random shopping spree and start looking like four companies buying the same missing piece.
PostHog: start with everything, then go down
PostHog is the one I know best because it is what I run on AgentBudget and what we used at Airstitch. Its pitch has been "all the product tools in one place" since the beginning, and the list keeps getting longer: product analytics, session replay, feature flags, experiments, surveys, a data warehouse, error tracking, and now an AI layer on top. Experiments literally run on flags there. There is no separate experiment SDK. You create a flag with variants, attach a goal metric, and the experiment UI is a view over the flag plus the events.
For a tiny team this is exactly the right shape. When I was building Airstitch we did not have anyone whose job was analytics. Having the replay of a session sitting one click from the funnel step where the user dropped off, in the same tool where the flag lived, meant a lot of "why did this happen" questions got answered in five minutes instead of becoming a ticket. The honest downside is that PostHog is a mile wide and, in places, an inch deep. Its error tracking is not Sentry. Its stats engine is fine but you would not run a hundred-experiment program on it. It is winning the bottom of the market on price and convenience, and the numbers say that is working: a Series E in October 2025 at a $1.4 billion valuation, and revenue that by outside estimates roughly doubled year over year to around $57 million in ARR by early 2026. Notice the direction, though. PostHog started at the product layer and is moving down, toward errors and infrastructure. Everyone else is moving up.
Sentry: start with the crash, then widen
Sentry went the opposite way. For most of its life it was the exception tracker, the thing you installed in the first hour of a project and forgot about until it paged you. At a previous job it was the tool I actually trusted: when Sentry said a release introduced a new error, it had, and the stack trace with breadcrumbs told me where. Over the last couple of years it has widened relentlessly from that anchor. Performance tracing, then session replay, then logs, and in May 2026 a proper Application Metrics product, so you can watch a counter spike and jump straight to the trace behind it. In April it shipped Seer Agent, an AI debugger you can ask questions in plain English, which walks the connected graph of errors, spans, logs, and code to answer them. By June the blog was talking about "self-healing software."
What Sentry conspicuously has not done is build flags or experiments of its own. It integrates with the flag providers, so a flag change shows up as an annotation on your error timeline, but it does not own the switch. That is either a very disciplined bet that the developer-facing debugging loop is a big enough business on its own, or the one gap in the convergence story, and I genuinely cannot tell which. If I were guessing, I would say Sentry's view is that its customer is the engineer holding the pager, not the PM deciding what to ship, and that those are still two different people at most companies. It is the one company on this list betting the four tools do not fully merge.
Datadog: start with the servers, then buy the top
Datadog was the infra tool. Metrics, logs, APM, the giant bill. At the job where I used it, Datadog was where you went when something was on fire and nowhere else. It was not where anyone thought about users. So it was a real signal when Datadog bought Eppo in May 2025, because Eppo was the most statistically serious experimentation platform on the market, the warehouse-native, CUPED, sequential-testing one that the data science teams liked. Datadog did not buy it to become a product analytics company. It bought it because experimentation is a wedge into the release decision, and in February 2026 the intent became explicit: Datadog Feature Flags, wired natively into APM and RUM, with automated rollbacks when a rollout degrades a metric and an AI assistant that cleans up stale flags.
This is the most interesting version of the pitch because Datadog already has the telemetry nobody else has. If your flag platform and your tracing platform are the same platform, "roll back automatically if error rate on the new variant exceeds baseline by two standard deviations" is a checkbox, not an integration project. Datadog is coming at the flag from below, with the strongest infra data and the weakest product instincts, and the question is whether product teams will live inside a tool that still looks like it was designed for SREs.
Amplitude: start with the chart, then buy a company without its people
Amplitude was the product analytics tool, the one with the beautiful retention curves that PMs presented to leadership. It has been adding the surrounding pieces for years, session replay and its own experiment product among them, and in February 2026 it went all-in on AI agents: an agent that watches replays and quantifies friction, an agent that designs and launches web experiments, and a system called Wave that ranks product opportunities from all of the above. The company is guiding to a year of accelerating growth on the back of it, and Q2 2026 came in at $101 million in revenue, up 21%.
The strange move was Statsig. OpenAI bought Statsig in September 2025 for about $1.1 billion, mostly, it seems, to get its founder as CTO of Applications and its team onto ChatGPT. Then in May 2026 Amplitude took over the Statsig brand, product, and customers, while the people who built it stayed at OpenAI. Optimizely's CEO called it "a race car without a driver," which is unkind and also not obviously wrong. Amplitude gets a real experimentation platform, about $17 million in ARR from its customers, and the job of maintaining a codebase whose authors work somewhere else. Whether that goes well will tell us something about how much of a tool like Statsig is the code and how much is the team.
It is worth adding LaunchDarkly to the picture even though it is not one of the four, because it proves the thesis from the other side. LaunchDarkly was the flag company, and nothing else. In April 2025 it bought Highlight to get error monitoring, session replay, and tracing. Then it bought Houseware for warehouse-native experimentation and analytics. The flag company decided it needed the dashboard. The dashboard companies decided they needed the flag. Same destination.
If you are a small team
The practical question is not "which one is best," it is "which layer do you actually live in." If you are two people with a product and no data team, you live in the product layer, and PostHog is the right default. You get flags, experiments, replay, and enough error tracking to survive, on one SDK, for roughly free until you have real traffic. That is the choice I made twice and I would make it again. If you already have serious infra and an on-call rotation, you live in the infra layer, and Datadog with flags bolted on is the version where rollbacks become automatic. If your company already has a warehouse and a data person who cares about statistics, whichever of these runs its analysis against your warehouse is the one to pick, because the experiment metric that matches finance is worth more than any feature.
And whatever you pick, put the flag key on every event, every error, and every trace from day one. That single tagging habit is the entire convergence story compressed into a line of config. It is the reason you will be able to answer "did the new checkout break Safari" in one query instead of four tabs, regardless of whose logo is on the dashboard.
Where this goes
I wrote recently, with my friend Rahul, about how software architecture keeps rising a level of abstraction, with the architect's job shifting from building components to configuring layers. This is that trend arriving at the experiment loop. Right now a human still writes the hypothesis, picks the metric, watches the result, and decides. Every company on this list is trying to turn some of those steps into a layer you configure instead of a task you perform. Amplitude's agent proposes and launches the experiment. Datadog's rolls it back on its own. Sentry's finds the bug the variant introduced and drafts the fix. Push that a few years forward and the "A/B test" stops being something you run and becomes something the platform runs continuously, with you setting the guardrails and reading the summary.
I am not sure that is entirely good. A lot of what I learned about my own products came from staring at a session replay and being confused, and a summary would have skipped the confusion. But the direction is not really in question. Four tools became four companies racing toward one dashboard, and the reason the race exists at all is that somewhere in the middle of it sits a boolean that decides what your users see. The dashboard was never the prize. The switch was.