Marketing-team-owned page publishing, with A/B testing and a self-tuning optimization loop built in
A brand-locked publishing engine for a marketing team
Landing pages a marketing team can ship without engineers — brand-locked components, A/B tests on by default, and a loop that rewrites and re-tests each page against its own goal until it stops getting better.
A marketing team with ideas constantly, and a release pipeline that let almost none of them out. New pages waited weeks behind an engineering queue; A/B tests ran once, often unread; nothing iterated after launch because everyone had moved on. The bottleneck wasn't talent — it was the path from idea to live page, then from live page to better page.
A publishing engine the marketing team owns directly — brand-locked components so pages can't go off-brand by construction, A/B tests on by default, and a self-tuning loop that critiques and rewrites each live page against its goal until improvement plateaus. Pages ship in minutes; they keep getting better on their own.
| Before | After | |
|---|---|---|
| Who can ship a page | engineering, queued behind sprints | the marketing team, any day |
| Time per release | a sprint or two | minutes to push live |
| A/B testing | one-off, often unread | on by default, results read by the system |
| Brand safety | reviewed by hand, slowed releases | enforced by the components themselves |
| After launch | nothing — the team had moved on | the page critiques and rewrites itself until it stops improving |
| Cost of trying ten ideas | the cost of ten engineering projects | the cost of one |
A weeks-per-page cycle, one-shot A/B tests, and silence after launch became pages shipped any day, tests on by default, and a continuous improvement loop that keeps tuning the work already live. The marketing team got their release pipeline back; engineering got out of the landing-page business; the pages themselves kept getting better every week instead of slowly going stale.
What I built
A publishing engine for a marketing team that wanted to ship landing pages without an engineering queue and have those pages keep improving after launch.
- A brand-locked component library. Every block — hero, value-prop, social proof, CTA, footer — is pre-approved for layout, accessibility, tone, and brand voice. The marketing team can compose any combination; they can't go off-brand because nothing off-brand is available to drag in.
- A staging-and-approval flow. Pages land in a preview environment before launch, with one-click promotion. The team reviews the actual page, not a Figma mock.
- A/B testing on by default. Every new launch is wrapped in a test against the current control, with traffic split and GA4 events fired automatically — nobody wires up the test, but every page has one.
- A self-tuning optimization loop. Once a winner emerges, the system critiques the winning page against its stated goal, proposes a tighter variant in the brand voice, ships it as the next test, and keeps going until improvement stops. Nobody schedules the iteration; it just runs.
The whole thing lives where the marketing team works, not in an engineering tool.
Why it matters
The story most marketing teams tell themselves is "we'd ship more if we had more engineering time." That's only partly true. The deeper bottleneck is that a marketing team and an engineering team optimize for different things — speed of experimentation vs. stability and craft — and when one is queued behind the other, the experimenting loses. This engine doesn't replace engineering; it takes one category of work (brand-safe, structured landing pages) and gives it back to the people who understand the customer best, then keeps quietly improving the work for them.
Normally "marketing pages that ship in minutes and tune themselves" is the pitch of a SaaS platform with a sticker price and a long contract. Here it's a stack the brand owns, wired into the data the brand already has — pages that ship the day the idea lands and keep getting better the week after.
The temptation with any "AI optimizer" is to let it write anything and trust the metrics to sort it out. That breaks two things at once: brand voice (the AI drifts toward whatever clicks) and the engineering safety net (raw HTML dumped into production has a way of breaking things). The discipline here was to do the opposite — constrain the *building blocks* tightly (every component pre-approved for layout, tone, and accessibility) and let the AI compose freely *within* those blocks. The optimizer can rewrite headlines, swap proof modules, reorder sections, even rewrite body copy in brand voice — but it cannot invent a layout or break a brand rule, because no such options exist to choose from. That single constraint is what makes a marketing-team-owned, AI-driven publishing engine safe enough to run in production at brand scale.
The shift is from one release every few weeks, reviewed once and forgotten, to pages that ship in minutes and tune themselves continuously. The marketing team got their release pipeline back; engineering got out of the marketing-page business; the pages themselves started getting better every week instead of slowly going stale.
Which components are 'safe enough' to lock and which still need a human in the loop, how the optimizer judges 'better' against a page's actual goal, and how brand voice is encoded so a generated variant still sounds like the brand — those are what separate a sane optimizer from one that drifts.