A growth or marketing engineer usually sits alone between two teams: close enough to marketing to own the landing page and the onboarding copy, close enough to engineering to ship the code that decides who sees which version. On a small team, that means you run experiments constantly and you don’t have a dedicated experimentation platform, a data team, or time to file a ticket for a test that expires next week.
The surface you actually test on
- Landing page headlines, layouts, and CTAs.
- Onboarding steps — how many, in what order, with what copy.
- Pricing page structure and plan framing.
- Paywall and upgrade-prompt copy.
- Lifecycle emails and in-app nudges tied to a specific cohort.
Every one of these is a small, fast test. Most of them run for a week or two and get thrown away either way.
Why “just use your analytics tool” isn’t enough
Your analytics platform is good at telling you what happened. It’s usually not the thing deciding, on every page load, which variant a given visitor gets — that part gets hand-rolled: a cookie, a hash, an if statement in the landing page code. It works until a visitor clears cookies mid-test and gets reshuffled, or the split logic lives in three different places (site, app, emails) and quietly disagrees with itself, or you need to kill a test at 11pm because the new headline is tanking sign-ups and there is no toggle, only a deploy.
What changed in the market
Worth knowing if you’re re-evaluating tools right now: OpenAI acquired Statsig outright for $1.1B in September 2025, and the founding team moved there. Separately, Amplitude acquired the Statsig product, brand, and customer base in May 2026 — two deals, eight months apart, not one. Either way, Statsig’s roadmap isn’t independent anymore. LaunchDarkly, meanwhile, has been pointing its roadmap at AI-agent runtime operations for platform teams — a different buyer than a solo growth engineer flipping a landing-page test. Neither is a knock on either product; it just means the “flags and experiments for one growth engineer, no platform team required” slot is more open than it’s been in a while.
The lightweight toolkit
The mechanics don’t need to be complicated. A flag decides the variant. A rollout percentage controls how much traffic sees it. A targeting rule scopes it to a segment — new signups only, a specific campaign, everyone except your own team. All three live in one place, changeable without a deploy:
import { useFlag } from '@toggletown/react';
function LandingHero() {
const variant = useFlag('landing-hero-copy', 'control', {
userId: visitorId,
utmSource: params.get('utm_source') ?? undefined,
});
return variant === 'direct-cta' ? <DirectCtaHero /> : <ControlHero />;
}Ship it to 10% of new visitors from one campaign, watch it for a day, widen it if it holds, and turn it off from your phone if it doesn’t. No dashboard login required — the MCP server lets you do all of this by telling your AI assistant what you want changed.
Reading the result without a data team
For most week-long tests, a rollout split plus a segment in whatever analytics tool you already have (PostHog, Amplitude, GA) is genuinely enough — filter by flag value, compare the numbers, done. When a test is big enough to report on — a pricing change, a new onboarding sequence — that’s the point to create a real experiment: named variants with explicit traffic allocation, a primary metric, and a start/pause/complete lifecycle instead of a flag you have to remember to check on.
The point
You don’t need an experimentation platform built for a 40-person growth org. You need a flag that ramps, targets, and rolls back without a ticket — and a way to run it from wherever you already work. If you’re running the same kind of tests on the product side, see A/B Testing for Product Engineers.