A growing retail brand had outgrown its off-the-shelf e-commerce platform, hitting performance and customisation limits during peak sales periods. DXDasia built a custom platform that cut checkout time 35% and cart abandonment 22%.
35% Faster Checkout, 22% Lower Cart Abandonment
The brand’s off-the-shelf platform worked at a small scale but started breaking down under real load — slow page speeds during sales events, limited checkout customisation, and plugin conflicts that made every update risky.
We built a custom platform designed around this specific brand’s catalogue and traffic patterns, rather than a generic template stretched to fit.
Moving off the constrained off-the-shelf platform changed both the shopping experience and the technical risk profile:
Off-the-shelf platforms are built to work reasonably well for everyone, which means they rarely work exceptionally well for anyone. Building around this brand’s actual catalogue size, traffic patterns, and checkout requirements removed the compromises that were quietly costing conversions every sales cycle.
The platform was built with checkout as a dedicated, independently-optimised flow rather than inheriting the general page-rendering pipeline, which is what delivered most of the speed improvement. Inventory sync runs on a real-time event-driven architecture — a sale on the storefront immediately decrements warehouse stock rather than waiting for a scheduled batch job — eliminating the overselling risk that batch sync created. Performance engineering specifically targeted the sales-event traffic pattern (a short, extreme spike rather than steady load), which required a different caching and scaling approach than general-purpose optimisation would have delivered.
Tech Stack: Next.js for storefront performance, Node.js backend, PostgreSQL, Redis for caching, Stripe and Razorpay for payments.
Only when the platform's limits cost you more than a build would. Off-the-shelf stores are quick and cheap to launch, and most merchants should stay on them. A custom build earns its place when checkout needs logic the templates cannot express, traffic arrives in sharp spikes, or stock must stay in step with a warehouse. Our guide to e-commerce development in 2026 covers the wider options.
Baymard's review of 50 studies puts the average cart abandonment rate at 70.22%. Its own checkout testing estimates that fixable checkout issues could lift the conversion rate of an average large e-commerce site by up to 35.26% (the page gives no year for that estimate). The reasons shoppers give are mostly design choices: 40% cite extra costs, 18% were asked to create an account, 17% found checkout too long or complicated, 17% hit errors or a crash, and 10% had a card declined. On form length, Baymard found the average checkout has 5.1 steps and 11.3 form fields (2024).
| Checkout measure | Typical | Baymard's ideal |
|---|---|---|
| Steps from cart to order review | 5.1 (2024) | Fewer steps matter less than fewer fields |
| Form fields shown | 11.3 (2024) | About 8 for most sites |
| Form elements shown by default | 23.48 (US average) | 12 to 14 |
| Sites that delay account creation to the confirmation step | 84% do not (one Baymard page gives 42% elsewhere) | Delay it, so guests convert first |
Sources: Baymard Institute checkout benchmark and its article on checkout form fields. Baymard's two pages give different figures for account-creation timing; check the current benchmark before quoting.
Evidence suggests so. In Vodafone's A/B test, a 31% better Largest Contentful Paint went with an 8% increase in total sales (2021, telecoms retail, otherwise identical pages). Google's Core Web Vitals set "good" at LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile. A sale spike pushes more visitors into the slow tail, so test peak load, not average load.
Retries. Networks fail, webhooks repeat and customers double-click. Stripe's API handles this with idempotency keys: retries with the same key return the saved result of the first request, and keys can be pruned after 24 hours in API v1. Apply the same idea to inventory events so a repeated message cannot decrement stock twice.
Prove the platform is the bottleneck before you commit to a rebuild.
On an Indian D2C Shopify store we audited, the homepage scored 33 on real mobile Lighthouse, but product pages were far worse: an 18-second largest contentful paint and 5.7 MB per page. The biggest culprit was a scroll-animation library hiding the main product image until all the JavaScript had run. The lesson we took away is to measure every page type, not just the homepage, before deciding that a platform is the problem.
With the platform now handling peak load reliably, the brand is planning its next major sales event with confidence instead of the operational anxiety that came with the old system. The modular architecture also means new features — like a loyalty program or subscription options — can be added as independent modules going forward, rather than requiring a platform-wide risk assessment for every change.
When the platform's limits cost more than a build would: checkout logic the templates cannot express, spiky traffic, warehouse stock that must stay in step, or plugin conflicts that make every update risky. If none apply, stay on the platform and fix speed and checkout first. Discuss your case through our custom web application service.
Baymard's 2024 benchmark found the average checkout has 5.1 steps and 11.3 form fields, and says most sites need only about 8 fields. Field count affects usability more than step count. Cut fields first, make guest checkout the default, and offer account creation after the order.
Update stock from events as orders happen, rather than in a delayed batch, and make every event safe to repeat so retries do not decrement twice. Payment providers such as Stripe use idempotency keys for this. Then load-test the inventory path at sale-event traffic, not typical traffic.
No. Using a hosted payment provider reduces your scope but does not remove responsibilities for your own page. PCI DSS 4.0.1 added requirements for managing scripts on payment pages. Confirm the details and dates with your acquirer and the PCI Security Standards Council.
