The CRO experiment that moved my landing page from 0.4% to 1.9%

A SaaS template landing page went from 0.42% to 1.93% conversion over a 30-day split test, on the same traffic source and the same offer. Nine purchases became forty.

Before anything else, the size of that: forty conversions is a small number, and everything below should be read as one operator's result rather than a finding. I am writing it up because the direction of the changes is more transferable than the multiplier, and because most CRO case studies quote a percentage without ever showing you the denominator.

This is what changed, in order of contribution, and what the measurement can and cannot support.

The before state

The CRO experiment baseline was a SaaS template landing page converting at 0.43% in February 2026: 2,100 sessions, 14 add-to-cart events, 9 completed purchases, and a $39 average order value. The page used generic 2018-era SaaS patterns, including a template-language hero and three rows of trust badges (Norton, McAfee, TRUSTe).

Baseline metrics, control variant, February 1-28 2026:

• Sessions: 2,100 (from a single paid traffic source, targeting unchanged)
• Add-to-cart events: 14
• Completed purchases: 9
• Conversion rate: 0.43%
• Average order value: $39

The control landing page had:

• A hero headed Transform your workflow with [product name]
• Three rows of trust badges below the hero (Norton, McAfee, TRUSTe, plus a "as featured in" strip)
• A standard pricing card with three tiers
• A long "features" section with checkmark icons
• A testimonial carousel near the bottom
• A second CTA at the page foot

It looked like every B2B SaaS landing page produced in 2018. That was the problem.

The hypothesis

My hypothesis for the CRO experiment was that the landing page failed on trust and clarity, not on features or pricing. I bet on six page changes, from rewriting the hero to cutting LCP from 2.8s to 1.1s, because generic template signals seemed to be suppressing the 0.43% conversion rate.

Six changes, each with a hypothesis I had a prior on:

1. Hero rewrite → replacing template language with a concrete answer-block style would lift the engagement above the fold
2. Social proof above the fold → moving one real customer quote up from the testimonial carousel would build trust before the first scroll
3. Price-anchored CTA: replacing Get started with Buy, $39 one-time would set expectation and reduce drop-off at the checkout
4. Remove three trust badges → Norton/McAfee/TRUSTe badges trigger "this is sketchy and trying to look legitimate" on developer audiences; removing them should improve trust, not hurt it
5. Faster LCP via image preload → cutting LCP from 2.8s to 1.1s should reduce bounce
6. Honest "what you do NOT get" section → adding a section that says who this product is wrong for should filter the wrong buyers and reassure the right ones

None of these is novel. Together they hypothesize that the page was failing on trust + clarity, not on features or pricing.

The treatment variant

The treatment variant shipped all six changes at once: hero rewrite, social proof above the fold, price-anchored CTA, trust badge removal, image preload, and an honest exclusions section. Bundling is not the cleanest experimental design, but on a 30-day timeline with roughly 2,000 sessions per variant I needed to maximize signal first and attribute later.

The hero went from:

Transform your workflow with the industry-leading SaaS template. Built for modern teams who demand the best.

to:

A 14-section Next.js SaaS template I personally use. Stripe + Supabase + auth + landing pages wired together. $39 one-time. Lifetime updates to v1.

The new hero is 32 words. Names the stack. States the price upfront. Sets the upgrade expectation. Reads like a person wrote it.

The trust badges row was deleted entirely. In its place: one real customer quote with a real LinkedIn link, attributed to a real person at a real company.

The price-anchored CTA changed from "Get started" to "Buy on Gumroad → $39". (At the time the checkout was a Gumroad redirect, since chronicled in the Gumroad postmortem.)

The LCP optimization was a single <link rel="preload" as="image" fetchpriority="high"> for the hero screenshot. LCP dropped from 2.8s to 1.1s on mobile 4G.

The "what you do NOT get" section was three lines added after the features:

This is wrong for you if you want: a no-code builder (this is code), a free tier (it is paid, $39), or guaranteed support (it is "best effort, when I have time").

The result

The CRO experiment result: the treatment variant converted at 1.93% against the control's 0.42%, a 4.59x lift at 95% confidence. Completed purchases went from 9 to 40 on near-identical traffic (2,140 vs 2,072 sessions), and revenue rose from $351 to $1,560 at an unchanged $39 average order value.

30 days, A/B split via Cloudflare Worker hash on visitor IP:

A standard significance test on those counts clears the usual 95% threshold, and I want to be careful about what that does and does not mean.

What the test can support. The direction is clear and the effect is large enough that it is unlikely to be pure noise. Something in the treatment worked.

What it cannot support. Four things, and they all cut the same way:

• Forty conversions is a small sample. Run the numbers through a sample size calculator and a baseline near 0.4% wants far more traffic than 2,000 sessions per arm to measure a lift precisely. The direction survives that. The multiplier does not; the confidence interval around it is wide enough to drive through.
• The split was by IP hash, which is not the same as a per-visitor assignment. Shared and rotating addresses leak between arms.
• One product, one paid traffic source, one month. Seasonality, audience drift and creative fatigue are all uncontrolled.
• I changed six things at once. The attribution below comes from follow-up tests, not from this one, and is the weakest part of the write-up.

Evan Miller's how not to run an A/B test covers the specific trap I was closest to falling into, which is watching a running test and stopping when it looks good. I did fix the 30-day window in advance, which is the one piece of discipline I would not skip again.

For scale, published ecommerce conversion averaged 2.23% in August 2026. The treatment landed roughly at the market average, from well below it. That is a more useful way to read this than as a 4.59x, because it tells you the ceiling is not much further up.

What each change contributed (best estimate)

Best-estimate attribution for the conversion experiment: the hero rewrite produced roughly 60% of the absolute lift. Faster LCP added about 12%, the honest "what you do NOT get" section about 10%, the price-anchored CTA 8%, and above-fold social proof and trust badge removal roughly 5% each. No single secondary change came close to the hero.

After the test I ran a second round of follow-up tests, isolating each change one at a time on the same traffic source over four more weeks. The attribution is less precise than the headline lift but the pattern is clear.

The hero alone did most of the work. The other five changes stacked but each was small.

What I would change if I ran this again

If I ran the 0.4% to 1.9% experiment again, I would isolate the hero rewrite first, since it carried roughly 60% of the lift on its own. I would also measure time-to-purchase alongside conversion, and I would not bundle six changes into one variant, which left attribution fuzzier than it should be.

Three things, in order of regret:

1. I would have isolated the hero change first. The 60% attribution suggests I could have shipped just that change and gotten most of the lift in a fraction of the engineering time. The other five changes were worth shipping, but I could have prioritized.

2. I would have measured time-to-purchase, not just conversion. Some of the lift may have been from buyers who would have converted anyway, just faster. Faster conversion is still valuable (fewer drop-off opportunities) but it is different from "new buyers who would not otherwise have bought".

3. I would not have run six changes simultaneously. It worked because I had enough traffic to get a clear signal on the bundled change, but my attribution is fuzzier than it should be. For a smaller-traffic test, isolate each change.

What this generalizes to

Three findings from the 0.4% to 1.9% experiment have replicated beyond this single page. Hero rewrites from template language to a specific answer block reliably produce 2-5x lifts. Early-2010s trust badges actively hurt developer-audience conversion in 2026. Honest exclusion sections filter out wrong buyers, so refund rates drop while completion holds.

• Replacing a template-language hero with a specific answer block is the highest-return change on pages that had one. I have seen it hold on four of my own product pages and two friends' tests, which is a pattern rather than a measurement.

• Trust badges from the early 2010s (Norton, McAfee, TRUSTe) actively hurt conversion on developer and founder audiences in 2026. They signal "this site is trying too hard to look legitimate". Different audiences respond differently. Test before assuming.

• A what you do NOT get section filters wrong buyers without visibly losing right ones. Refund rates drop and completion rates hold, on samples too small to prove it and consistent enough that I keep shipping it.

Where this fits in the rebuild

The CRO experiment was actually the trigger event for the larger site rewrite. Once one product page demonstrated a 4.59x lift, the question became: why have I not done this for all 19 products? Answer: because the foundation was wrong (Gumroad redirect blind spot, generic AI-template copy, no GEO surface).

The single-page CRO experiment justified the whole-site rebuild. The whole-site rebuild then enabled CRO experimentation across the catalog, which is the work for the next 90 days.

The audit + experiment framework I used for this is in Conversion Rate Domination. The hero-rewrite humanization workflow is in Humanizer Pro and walked through in How I rewrote 19 product descriptions. The wider context is in the hub post on shipping as a solo founder.