∴ For growth teams
Ship the experiments already sitting in your backlog.
The experiment doc is rarely empty; the engineering queue is. Trevo turns an approved hypothesis into a reviewable pull request, runs the test in your code, and brings the result back with the evidence needed to make a call.
> trevo scan acme/web found 34 routes · 11 server actions · 6 funnels wrote 8 proposals, each cited to your code #1 Quote tax before the payment step #2 Lead the hero with the concrete offer #3 Server-priced bundle nudge in the cart approve → PR opens on trevo/*
What does Trevo do for a growth team?
Trevo is an AI growth engineer. It connects to your GitHub repository, reads the actual code behind your funnel, and writes experiment proposals with the evidence cited. When a growth team approves one, Trevo opens a pull request with the variant implemented behind a feature flag — on a trevo/* branch, never on main. Experiments run with always-valid sequential statistics (mSPRT), so the team can check results at any time, and the losing variant is removed by an automatic cleanup pull request. The practical effect: the experiment backlog stops waiting on engineering capacity.
How it works
The loop your team already runs — ideate, build, run, decide — with the build step handled by an agent your engineers review.
Connect the repo and the metrics
The Trevo GitHub App reads your code and writes only to trevo/* branches. Metrics come from the Trevo SDK or your PostHog project. Trevo maps routes, server logic, pricing paths, and the events that mean money.
Review proposals like a growth meeting
Each proposal is a hypothesis with the mechanism spelled out and the code it read cited. Prioritize, dismiss, or approve — approval is the only trigger that creates code.
Merge the PR, run the test
The variant is real code behind a Trevo flag, with the diff reviewable line by line. Your CI and your review process are the gate. Once merged, assignment and exposure tracking are automatic.
Decide on always-valid stats
mSPRT sequential testing means no fixed horizon and no peeking penalty. Ship the winner by merging; Trevo opens a cleanup PR that removes the loser and the flag.
Proposals argued from your code, not a template library
Trevo does not suggest “try a different button color.” It reads the checkout flow, the pricing rules, and the empty states you actually shipped, then argues each test from what it found.
- ✓Every proposal cites the files it read
- ✓Estimates are labeled as starting points until events flow
- ✓Full-stack surface tags: frontend, server-side, full-stack
hypothesis late tax reveal drives cart abortscites lib/cart.ts · CheckoutSummary.tsxsurface full-stackmetric checkout_completed → revenue
The variant is a pull request your engineers can veto
No dashboard-injected snippets and no edits your team cannot see. The experiment is a branch, the hypothesis is the PR description, and nothing reaches production without your review.
- ✓Writes only to trevo/* branches — never main
- ✓Winners merge like any other change
- ✓Losers removed by an automatic cleanup PR — no flag debt
const totals = useCartTotals(); return <Summary totals={totals} />; const variant = useExperiment(TAX_UPFRONT); return variant === "upfront" ? <Summary totals={totals} taxLine="estimated" /> : <Summary totals={totals} />;
What this looks like in practice
Illustrative proposals of the kind Trevo writes for growth funnels — yours are argued from your own code.
Δ checkout
Quote tax before the payment step
Surface the estimated total earlier so the payment page stops being where visitors discover the real price.
measures → checkout_completed → revenue
Δ landing page
Lead the hero with the concrete offer
Replace the brand statement with the offer your code already implements — free shipping thresholds, trial length, bundle rules.
measures → signup_started → activation
Δ activation
Progressive disclosure on the signup form
Ask for the work email first and reveal the rest after the first commitment, instead of one long form.
measures → trial_started → retained trials
Frequently asked questions
How is Trevo different from a feature-flag or experimentation platform?
Platforms give you rails: flags, targeting, and a stats dashboard, while your team still writes every variant. Trevo does the experimenting — it proposes the test, writes the variant as a pull request in your repo, runs the analysis, and cleans up afterward. You review code instead of building it.
Does Trevo replace our growth engineer?
It replaces the backlog-clearing part of the job: implementing variants, wiring metrics, and removing dead flags. Strategy, prioritization, and review stay with your team — approval is the only action that turns a proposal into code.
Can it run server-side experiments?
Yes. Trevo works in the repo, so it can test pricing rules, ranking logic, limits, and API behavior as well as UI — anything expressible as a code change behind a flag. Proposals are tagged frontend, server-side, or full-stack.
What statistics does Trevo use?
Sequential testing with mSPRT, which keeps results valid at every look. There is no fixed sample size to wait for and no penalty for checking early; when the dashboard says significant, you can act on it.
How fast do we see the first proposals?
Minutes after connecting a repository. The scan reads your routes, components, and server logic, and the first proposals are written before any SDK is installed — installing the SDK is what turns estimates into measurements.
Keep reading: Trevo for startups · Onboarding & activation experiments · Pricing experiments · PostHog + Trevo · Trevo vs Optimizely
Bring Trevo one real funnel problem.
Connect the repo and the first proposals arrive in under fifteen minutes, each one naming the exact files a full-stack experiment would change. Not ready? A free scan previews the ideas on your domain first.