A checkout that failed slowly on mid-range Android hardware, and a payment retry path that quietly gave up.
Client
A direct-to-consumer retailer
Industry
Commerce
Duration
9 weeks
Team
1 senior · 2 mid
Stack
Next.js · Node · Postgres · Stripe
Engagement
Fixed scope, then T&M
The situation
Abandonment sat at a number the client had come to accept. Analytics blamed price sensitivity. The session recordings said otherwise: people were waiting.
On a mid-range Android device on 4G, the payment step took long enough to become interactive that people gave up waiting, and a failed card silently ended the session with no retry.
Constraints we worked inside
Peak
A four-week trading peak during which no structural change could ship.
Compliance
PCI scope could not widen; card data had to stay with the provider.
Team
One in-house developer who had to be able to own the result afterwards.
Architecture
measured first, changed second
Client
Edge
Data
Decisions & tradeoffs
Decision 01
We bought three mid-range Android phones and tested on them. Everything that followed came from what those devices showed, not from a desktop profile.
TradeoffTwo weeks of the engagement produced a document, not a feature.
Decision 02
The payment step needed almost no client-side state. Moving it to the server removed almost all of the wait before the page became usable.
TradeoffA different rendering path from the rest of the storefront, documented and fenced.
Decision 03
An idempotent retry with a clear error message recovered a meaningful share of sessions that had previously just ended.
TradeoffMore states to design and test than the original single happy path.
Next case study
Ask us for a code sample or an architecture walkthrough from a comparable project. Anonymised, no NDA required, no sales call attached.
Scope your projectA senior engineer reads every one of these. If we’re not the right fit we’ll say so, and point you at someone who is.
No spam, no drip sequence. A senior engineer replies within one business day.
