How marketers can launch Shopify landing pages with AI.

Here's how we set that up without putting their checkout at risk, and what it changes for a brand that tests as much as they do.

We rebuilt Hey Harper's store from the ground up in 2024, on Shopify and Storyblok, in a project that went on to win Best of the Year at the eCommerce Awards. Their marketing team tests ideas faster than any engineering backlog can keep up with, and many of their paid campaigns land on a custom page with a layout the main site has nothing like. Storyblok lets them rearrange the blocks we designed for the site, but the ideas worth testing usually need something those blocks can't build, so each one turned into a brief and having to wait for an available developer, which added cost and delayed every test.

Now, we set things up so Hey Harper's marketers can make these pages themselves with Claude Code, an AI coding tool, and submit each one as a pull request, a proposed change to the store's code that one of our engineers approves before it goes in. The first, a subscription box page built to test two choices in the box builder against none took three days to set up, instead of previous experiments which took about three weeks of back and forth each.

With tools like Claude Code, a marketer can already produce code that works, so most of our effort went into the other side of the problem: making a live store that could safely accept it. In Running a Product Discovery with AI, we wrote about building our own principles into the tools we work with, so that following them becomes the path of least resistance. This project applies the same thinking to a client's live store.

Running a Product Discovery with AI.

Faster product discovery. Sharper decisions.

Learn more

Preventing a test page from jeopardising a whole store

Every landing page lives in its own folder, set apart from the rest of the site and holding its own components, copy and styles. Those styles can't spill onto other pages, so a test page can look nothing like the main site while the main site stays exactly as it was.

What a page can't do is reach the parts of the store linked to payments. An automated rule blocks it from touching the cart, checkout, analytics or the Shopify connection directly, and gives it a small SDK instead, a short list of approved actions such as adding to cart or tracking an event. Behind that list sits the logic that's easy to break and expensive when you do, like keeping a customer's cart consistent while an A/B test is running, and a landing page can't get that wrong because it can't get to it.

That's also what makes reviews rather quick. Our engineers still approve every pull request, but all they need to check is that every change stayed inside the page's folder. Whether the page is any good is the marketers' call, since it's their experiment, and for Hey Harper it means a test page can be as unusual as the idea behind it without ever touching the checkout that pays for the campaign.

Pages don't share parts with each other either, so changing a button on one test can't quietly change it on another. When a page wins, it comes back to us, and we improve on it with what the test showed before building it into the site properly, which keeps the experiments cheap and gives the ideas that earn a permanent place the investment they deserve.

A page reaches the store only through the SDK, and the Storyblok story decides whether merged code shows.

Marketing decides when a page goes live

The most useful part of this setup was one we hadn't planned: approving a page's code doesn't put it live. Code reaches Hey Harper's store in planned releases of the whole site, so without something extra, every mid-campaign copy tweak, or worse, taking down a page that's misfiring, would have meant waiting for one. Instead, each landing page has a twin entry in Storyblok, which Storyblok calls a story, and the story decides whether the page exists. While it's unpublished, visitors get a 404; once it's published, the page is live on the next visit, with no engineer or release needed in either direction.

The story also lets editors change any of the page's text, so a headline can be fixed at 11pm mid-campaign and clearing the field brings the original back, and it holds the page's SEO title, description and share image. The code still owns the structure, which means the CMS can change the words but never break the layout. If Storyblok itself is slow or down, the page shows its original copy, because a hiccup in the CMS shouldn't take a live campaign down while the ads are still spending.

New pages therefore go out invisible and appear when someone presses publish. The site's release schedule and the campaign calendar stop being the same thing, which for a marketing team is most of the freedom: Hey Harper owns a page from launch to switch-off without booking time in a developer's week, and because test pages go to a small group of users, a bad idea costs very little.

How we tested it with four agents

Each page folder comes with written instructions that the marketer's AI reads automatically, covering the rules and the patterns that work, so the marketer never needs to read the codebase. Automated checks then run on every pull request to catch what instructions alone would miss.

Before a real marketer touched any of it, we gave four AI agents a campaign brief and nothing else, and asked each to build a complete page. All four passed every check, and some showed exactly the judgement we'd hoped for: one noticed its page had no header, which meant shoppers would get no confirmation after adding something to the cart, so it made the cart slide open instead. The only defect was in our own setup. Our instructions banned a CSS technique that the automated check allowed in a safe form, and when an agent needed it for a scroll animation, it followed the check. We changed the instructions to match, and it's the lesson we'd pass on to any brand putting AI tools in its team's hands: what the system enforces counts for more than what the guidelines say.

That cuts the other way too, and we'd rather say so than be tidy about it. Two rules still depend on people: one code check runs on the marketer's own machine for boring infrastructure reasons, and a change to the guardrails themselves needs the same single approval as any other pull request. By our own argument, those are the weak kind of rules, and they're on the list.

What happened in real use

Real use found the gap our test run couldn't. The very first page tried to change parts of the main site, outside its folder, and an engineer caught it in review before it went live, so nothing broken reached customers. That catch depended on a person, because checking that every change stays inside its folder is still a manual step, and it's the next one we're moving into the automated checks.

What these guardrails can't do

None of this makes a landing page worth shipping. This setup can't tell a marketer which of ten decent variations has a pulse, or when a test has given its answer and the page should come down. It makes those calls cheap to act on, since building a page costs hours and killing one costs a click, but the judgement is still the work, and it still belongs to people.

What did change is who gets to act. "Only engineers can touch production" has long bundled two things together, keeping the store safe and keeping the work good, because beyond the blocks a CMS offers there was no practical way to pull them apart. Here, the judgement stays with people, and the safety is moving into the store itself, from the folder each page lives in to the button that publishes it.

Which of your own "only engineers may" rules are about safety, and which are about never having built the guardrails? And who in your organisation could ship tomorrow if the boundary were engineering instead of trust?

If your campaigns keep outrunning your backlog, we'd like to hear how you're handling it.