Case Study: Rebuilding an E-commerce Checkout That Was Losing 40% of Carts

ThreadLine was losing $180,000 per month in abandoned carts. Not window shoppers. People who clicked “Proceed to Checkout” and then gave up. 40% of them, gone.

Their D2C apparel store did $18M in annual revenue, which meant the checkout was quietly bleeding $2.16M per year in lost sales. We rebuilt it in three weeks.

Everything That Was Wrong

We recorded 500 checkout sessions on Hotjar in the first two days. The problems were obvious once you watched real people try to buy a t-shirt.

Seven steps. The checkout had seven distinct pages: cart review, email, shipping address, shipping method, billing address, payment, and confirmation. Each step was a full page reload. On a 4G connection, that meant waiting 3-4 seconds between each step. Seven waits to buy a $35 shirt.

Stripe.js loaded twice. The original freelancer loaded Stripe.js on the cart page (for no reason) and again on the payment page. The second load was an older version. This caused a console error on roughly 8% of sessions. The checkout still worked, but it threw a visible error in some browsers.

No saved payment methods. 62% of ThreadLine’s revenue came from repeat customers. Every single one of them had to re-enter their card number every time.

Mobile keyboard covered the zip code field. On iOS, the keyboard popped up and obscured the zip code input on the billing address page. Users had to scroll down while typing, and many of them accidentally tapped the browser’s back button instead. This one bug accounted for roughly 9% of mobile abandonment based on the session recordings.

No Apple Pay, no Google Pay. 73% of traffic was mobile. Zero support for mobile wallet payments.

The checkout had been built three years earlier by a freelancer using React on a headless Shopify backend. Two agencies had added features on top of it (subscriptions, gift cards, loyalty points). The result was 14 separate API calls, three different state management approaches, and a 6.2-second load time on mobile.

What the Pod Built

We deployed one senior frontend architect, two frontend engineers, one backend engineer, and a PM.

Step 1 of 2: Shipping

We collapsed seven pages into two steps on a single page. No reloads. Step one collects email, shipping address (5 fields using Google Places autocomplete, down from 11), and shipping method. The shipping methods load asynchronously while the user types their address, so by the time they finish, options are already visible.

Step 2 of 2: Payment

Stripe Elements embedded directly in the page. No redirect, no context switch. Apple Pay and Google Pay buttons appear above the card form on supported devices. For returning customers, we show their saved card with a “Pay $47.00” button. One tap.

We cut the API calls from 14 to 4. Cart validation, shipping rates, tax calculation, and order creation. Everything else was either redundant or could be handled client-side. Response time dropped from 3.8 seconds to 0.9 seconds.

The Details That Mattered

Error messages got specific. Instead of “Payment failed,” users see “Your card was declined. Try a different card or use Apple Pay.” Network timeouts show a retry button instead of a dead page.

Every form field uses the correct inputmode attribute. Credit card fields show a numeric keyboard. Email fields show the @ keyboard. ZIP code fields show the numeric keyboard and do not trigger autocorrect.

We tested on 12 device/browser combinations and load-tested against Black Friday traffic levels (4x normal). The new checkout rolled out to 20% of traffic on day one, then 50%, then 100% by end of week three.

The Numbers

Post-intent abandonment dropped from 40% to 18%.

Overall conversion rate improved by 28%, worth approximately $4.2M in additional annual revenue at ThreadLine’s traffic levels.

Mobile checkout completion improved by 34%. This was the biggest win because mobile was the biggest channel.

Page load time dropped from 6.2 seconds to 1.4 seconds on mobile.

Average time to complete checkout went from 4 minutes 30 seconds to 1 minute 48 seconds.

The saved payment method feature alone drove a 15% increase in repeat purchase conversion.

Why the Old Checkout Was So Bad

It is not that the original freelancer was incompetent. The checkout worked fine when it was built. The problem was three years of bolted-on features with no architectural ownership. Each agency added their piece, tested it in isolation, and moved on. Nobody owned the full user experience.

This is the pattern we see constantly. The checkout is not anyone’s job, so it degrades quietly while marketing spends more and more to drive traffic that bleeds out at the last step.

Three Months Later

ThreadLine’s checkout conversion has held steady at the improved rate. They have since hired us to rebuild their product detail pages using the same approach: watch real sessions, find the friction, fix it in a focused sprint.

If you suspect your checkout is underperforming, watch 50 session recordings on mobile. If you wince, we should talk.