Skip to main content
Trevo is an A/B testing platform where the experiments arrive as pull requests. You connect a repository. Trevo reads it, proposes an experiment with a hypothesis grounded in your actual code, and — once you approve — opens a PR containing both variants behind a flag, plus the tracking calls needed to measure it. You review the diff like any other PR, merge it, and real traffic decides the outcome. When there’s a winner, a cleanup PR promotes it and deletes the loser.

Why this shape

Running an experiment normally has two bottlenecks: someone has to think of what to test, and an engineer has to build both versions. That’s why most teams run a handful of tests a year rather than hundreds. Trevo’s bet is that an agent can do both, and that the output should be code in your repository rather than configuration in someone else’s dashboard. That last part is the real difference from older tools. Visual editors inject JavaScript that rewrites your page at runtime, which is why those sites flicker and why the experiment is invisible to your codebase. Trevo never touches the DOM. Your own code branches on a variant:
Which means experiments go through code review, run in CI, and are removed by a PR when they’re done. No accumulated flag debt, no drift between what’s deployed and what’s configured.

What the SDK does

Very little, deliberately. Two things:
  1. Answers “which variant is this user in?” — a local hash of the user’s identity and the experiment key. No network call, deterministic, sub-millisecond.
  2. Reports what happened — exposures when a variant is seen, conversions when you call track().
Everything else — deciding what to test, writing the variants, calling the winner — happens in Trevo, not in your bundle. The browser SDK is under 10kb gzipped.

What you need

  • A JavaScript or TypeScript codebase. The SDK ships for browsers (@trevosdk/browser) and servers (@trevosdk/node). Other languages can record conversions over REST.
  • Live traffic. Experiments need users. How many depends on your conversion rate and the size of the effect you’re looking for.
  • Conversion events you’ve instrumented. Trevo has no autocapture — a conversion exists where you write track(). This is the step people most often skip, and without it an experiment runs but can never produce a result.

How results are decided

Trevo uses mSPRT, a sequential test. The practical consequence is that you can look at results whenever you like without invalidating them. That isn’t true of classical A/B statistics, where you commit to a sample size in advance and checking early inflates your false-positive rate — peek at a dashboard daily and you will “find” winners that aren’t real. Sequential testing is built for the way people actually use these tools. More in Reading results.

Where to start