Cutting a US sports platform's checkout time by 83%

Context

Playbook365 is a sports event platform used across US sport categories — teams register, buy memberships, pay for matches, and purchase merchandise through a single checkout. That checkout had grown into six distinct purchase types layered on top of one another over years of feature work.

By the time I joined as lead, a single checkout took roughly 30 seconds to load and routinely threw transaction errors. Every failed payment was lost revenue and a support ticket.

Constraints

• No downtime. The platform processed live transactions daily; the fix had to ship incrementally behind the running system.
• Six purchase types, each with its own tax, discount, and fulfillment rules that could not regress.
• A 10-engineer team shipping other features in parallel — the refactor had to be reviewable in small, safe increments.

Approach

I treated the checkout as one system rather than six special cases.

• Collapsed the six flows into a single pricing pipeline. Each purchase type became a strategy feeding a shared engine, so tax and discount logic lived in exactly one place.
• Moved synchronous third-party calls off the critical path. Payment-provider and event-data lookups that blocked render were cached in Redis and hydrated asynchronously.
• Rewrote the client in Vue with optimistic UI, so the cart responded instantly while confirmation settled in the background.
• Standardized integrations (payments, auth, event data) into reusable API patterns the whole team could reuse — cutting future integration time.

Architecture

Results

• Checkout load dropped from 30s to 5s — an 83% improvement.
• Critical transaction errors eliminated across 1,000+ monthly transactions.
• Integration time fell for every subsequent third-party service the team added.

What I'd do differently

I would have invested in load-testing harnesses earlier. We validated correctness per purchase type well, but the performance wins were confirmed largely in staging and production monitoring — a synthetic load rig would have caught two edge-case regressions before they reached real users.