t About Trevo
We build the experiment loop we wanted to use.
Trevo is for product and growth teams with plenty of test ideas and too little engineering time. It reads the relevant code, writes an approved variant on a branch, and brings the work back as a pull request. Your team still decides what merges.
Why Trevo exists
Most experimentation software gives a team flags, assignment, and a results page. Those are useful rails, but they do not clear the implementation queue. The hypothesis still needs a variant, tests, instrumentation, review, and cleanup. Trevo is built around that missing work.
The product keeps code review in the middle of the loop. Trevo writes only to its own branches, CI runs as usual, and a person with repository access chooses whether to merge. When a test ends, the winner or rollback returns as another diff instead of becoming a forgotten flag.
How we publish
Our product and engineering articles are grounded in the architecture, decisions, and failure modes we encounter while building Trevo. Guides explain the product as it behaves today. Comparison pages link to each company's own documentation and focus on workflow differences, especially who has to write and remove experiment code.
We use named bylines when a piece reflects one person's point of view and the Trevo Team byline for collective product documentation. Dates are visible, material product changes should trigger a review, and corrections belong on the page rather than behind vague marketing language.
Who is behind the writing
Lucy Guo, Trevo's founder, writes about growth teams, startup constraints, and the operating decisions behind the product. Collective articles come from the product and engineering work of the Trevo team.