A documented backlog
Every hypothesis, its evidence and its result — including the losers, which stop the same idea being re-proposed every year.
CRO, SPEED, UX AUDITS AND LANDING PAGES
Research, hypothesis, test, ship. A continuous programme against the numbers you agreed at the start, not a one-off redesign.
IN SHORT
Four areas, each with its own page.
Research, hypothesis, test, ship — a continuous programme rather than a one-off redesign.
App bloat stripped, scripts deferred, LCP and CLS measured on real devices rather than a lab score.
A senior engineer walks your storefront, theme and checkout and sends back a prioritised list of fixes.
Campaign and launch pages built to a section library, so marketing ships without a dev queue.
Not because the ideas are bad. Because nobody agreed what was being measured, so every result becomes an argument. A test lifts add-to-cart and drops revenue per session — was that a win? If you did not decide beforehand, you will decide afterwards, and you will decide in favour of whoever proposed it.
The second failure is stopping early. A variant goes 20% up on day three, someone calls it, and the store ships a change that was noise. Two full business cycles is the minimum for a reason.
The third is testing trivia. Button colours and headline tweaks on a store doing modest traffic will never reach significance, and the team spends a year learning nothing. At that traffic level, research and qualitative evidence beat split testing — and we will say so rather than sell you a testing retainer.
A four-stage cycle, repeating monthly.
Analytics, session recordings, support tickets, on-site search and checkout drop-off. Evidence before opinion — most stores already contain the answer to what is wrong, unread.
Every hypothesis is scored on expected impact against build cost, so the running order is arithmetic rather than whoever argued hardest in the meeting.
Changes built in theme code. Where traffic supports a split test we run one; where it does not, we ship the better-evidenced version and measure the before and after honestly.
Monthly: what shipped, what moved, what was a dead end, what is next. Losers are documented rather than quietly forgotten, because they are the cheapest knowledge you own.
Roughly 10,000 sessions and a few hundred conversions per variant per month. That gets a test to significance in two to four weeks, which is a cadence you can actually run a programme on.
Below it, you have two options. Run tests anyway and wait months per result — viable if you only have a handful of questions. Or optimise from research: session recordings, support tickets, on-site search and checkout analytics tell you a great deal, and shipping the better-evidenced version is usually worth more than waiting a quarter to be 95% sure about one button.
Every hypothesis, its evidence and its result — including the losers, which stop the same idea being re-proposed every year.
Winners live in theme code, not in a third-party script that slows the site and expires with the subscription.
The metric is named before work starts, so there is no argument about what counted afterwards.
If a quarter produced nothing, the review says so. Optimization programmes that never report a failure are not reporting.
Wonderskin runs continuous landing page production with us alongside maintenance. Mighty Jaxx we manage end to end. See the full client list.
Roughly 10,000 sessions and a few hundred conversions per variant per month to reach statistical significance within two to four weeks. Below that, split testing produces confident-looking numbers that are mostly noise, so we optimise from research and qualitative evidence instead.
At least two full business cycles, usually two to four weeks. Stopping early because a result looks good is the most common way teams convince themselves of something that is not true.
Only where it earns its performance cost. Testing scripts run before your page renders, so a permanent testing tool on every page is a real speed tax. We prefer tests built in theme code, with the tool used deliberately rather than by default.
CRO changes what people see and decide; speed work changes whether they wait around to see it. Speed is usually the better first move because it lifts every page at once and the work is finite, where CRO is an ongoing programme.
Speed improvements are measurable within days of shipping. CRO results depend on traffic — with enough of it, the first tests conclude within a month. Anyone promising a specific percentage before looking at your store is guessing.
Start with a free UX and checkout audit if you are not sure where the problem is. If the store is slow, speed optimization usually pays back first. Ongoing work runs as a development retainer.
NEXT STEP
Storefront, theme performance and checkout reviewed by a senior engineer. No pitch deck, no obligation.