The engineering org behind a fast checkout
A look at the architecture, the team rituals, and the trade-offs that turn a slow checkout into a fast one.
Head of Engineering
Integrity Tech
When we start a checkout re-platform engagement, the storefront is usually rendering somewhere in the 3-5 second range at p95. By the time we hand off, it's rendering in well under two. Here's how — focused on the choices that actually moved the number, not the ones that made the architecture diagrams pretty.
We do not rewrite anything we don't have to
Most teams arrive several months into a full rewrite. We usually throw the rewrite away. The product catalog, inventory, tax engine — none of that is the bottleneck. We leave the legacy services running and build the new storefront in front of them.
Server Components move the floor
Server Components let us push the majority of cart logic to the edge, return only HTML, and skip the SPA hydration tax. The first paint becomes the meaningful paint. JS bundles drop by a multiple.
We replace one ritual at a time
- Daily 15-minute standups against the roadmap — never status updates, always blockers.
- Friday demo at 4pm, every week. If you don't have something to show, you weren't building the right thing.
- Postmortems on near-misses, not just outages. The best signal is what almost broke.
- A weekly latency review with the on-call dashboard open.
The hardest part is deleting code
By the end of these engagements we've usually cut more lines than we added. That's the right ratio for a refactor. Every line of code is a future bug; every deleted line is a small win for whoever inherits the codebase.
“The faster you can delete, the faster you can deploy.”