KumarKart was a Lucknow-based online store selling groceries and daily essentials. Their products were good. Their prices were competitive. But their website was silently killing every sale before it could happen — and they had no idea why conversions were so low. This is the full story of what we found, what we changed, and what any e-commerce business can take from it.
The Client
KumarKart is an online store based in Lucknow, selling groceries, household essentials, and home products to customers across the city. They built their first website on WordPress using a purchased theme, added WooCommerce, and launched. For a while, it was enough.
By mid-2024, it wasn't. Competitors with similar or worse product ranges were consistently outselling them. The owner, Rajat Kumar, noticed that almost nobody who added items to the cart was actually completing their order. He reached out to us after reading our piece on what websites actually cost in India.
Before we started, here's where KumarKart stood:
KumarKart's products, prices, and delivery areas didn't change at any point during this project. Every metric improvement you'll read about is attributable entirely to the website rebuild — not a sale, a new product category, or a marketing push.
What Was Broken
The old site had been built quickly by someone who knew WordPress but didn't know e-commerce UX or performance. There was nothing wrong with the intent — the problems were the kind that only become visible when you audit the site the way a first-time customer experiences it: on a mid-range Android phone, on a 4G connection, without any prior knowledge of how the checkout was supposed to work.
Here's what we found during a single two-hour session using the site as a real customer:
-
8.2-second load time on mobile
The homepage took over 8 seconds to show meaningful content on a 4G connection. At that speed, most users hit the back button before seeing a single product. Google's own data shows that 53% of mobile visits are abandoned if a page takes longer than 3 seconds to load.
-
Checkout was silently broken on iOS Safari
The payment step would fail on Safari without any error message — the user would tap "Place Order" and nothing would happen. Affected approximately 22% of their traffic. Nobody had noticed because there were no error logs and customers who couldn't pay simply left without saying anything.
-
Seven-step checkout on a 5-inch screen
The WooCommerce default checkout had been left untouched — billing address, shipping address, order notes, coupon, payment selection, review, confirm. Each step required scrolling. The "Place Order" button was below the fold on an iPhone SE. Most users gave up at step three.
-
Zero visible trust signals
No customer reviews on any product page. No return or refund policy visible from the cart. No payment security badge at checkout. For a first-time buyer, there was no evidence this was a legitimate, trustworthy store — even though it had been operating successfully for over two years.
-
14 top-level navigation items
The main menu had 14 categories at the same visual level. On mobile, this collapsed into a hamburger that opened a wall of text. First-time visitors couldn't identify the store's core product categories without reading every label — and most didn't.
-
Product images averaging 4MB each
Every image was a high-resolution JPEG uploaded directly from a phone. A typical category page with 12 products was loading 48MB+ of images before any compression or lazy loading. On a 4G connection, this alone explained most of the LCP problem.
The Audit Findings
The red flags above were visible without any tools — just a phone, a timer, and a willingness to actually try to buy something. The formal audit confirmed everything and added precision to the numbers.
Anything below 50 is considered poor. The primary culprit was LCP at 8.2 seconds, driven by the unoptimised hero banner — a 6.4MB JPEG. Secondary issues included render-blocking scripts from 9 active plugins and a TTFB of 740ms from ₹199/month shared hosting.
Nearly 8 in 10 mobile visitors were leaving without interacting with a single element. This confirmed that the speed problem was causing abandonment before users could engage at all — not a product or pricing problem, a load time problem.
Of users who reached the cart, 68% left before completing the purchase. Step-by-step funnel data showed the biggest drop-off at the billing/shipping form — a 14-field form that auto-filled nothing and required manual entry of every detail on a phone keyboard.
Cross-referencing analytics with order data revealed that while ~22% of sessions came from Safari on iOS, not a single completed order came from that browser in the previous 90 days. The silent checkout failure wasn't a theory. This was real revenue that had simply never existed because the payment path was broken.
Users who stayed were browsing, but not finding complementary products. Low average order value pointed to a navigation and discovery problem: the 14-item menu and absent cross-sell modules made multi-category browsing too difficult to bother with.
We'll Find Your KumarKart Problem
A 2-hour audit of your store will surface the exact issues costing you conversions. Free consultation — no obligation to proceed with a rebuild.
What We Built
We recommended a full rebuild rather than patching the WordPress site. The reasoning was straightforward: performance problems at this severity aren't fixable with plugin changes — they're structural. A site built on a heavy theme with 9 plugins isn't a fast site with a speed plugin added on top. We rebuilt on a custom React frontend with a lean API backend, and treated every decision as a performance decision first.
The rebuild had four primary pillars:
We gave Rajat two options — patch the existing WordPress site (cheaper, faster, lower risk) or rebuild from scratch (more expensive, 6-week timeline, but solves the root causes). We were honest that patching could improve performance by 30–40% but would not fix the iOS Safari checkout failure, the checkout UX problems, or the structural slowness baked into the theme. He chose the rebuild. The results reflect that choice.
The 60-Day Results
We launched the rebuilt site on December 3, 2024. The comparison window is November 2024 (before) vs January 2025 (60 days after) — same season, same product catalogue, same delivery areas, same prices. No paid advertising ran in either period.
I knew the site was slow, but I didn't realise how much money I was losing every single day because of it. The iOS issue — I had no idea. Nobody had ever told me about it.
— Rajat Kumar, Owner, KumarKart
Why It Worked
The speed improvement mattered. But it wasn't the primary revenue driver. If you fix load time and leave a broken checkout in place, you just get more people arriving at a dead end. The thing that moved revenue the most was fixing the checkout.
73% of KumarKart's traffic came from mobile. The original checkout required 7 separate screens on a 5-inch display. We rebuilt it as a single-page flow with 3 fields visible at once, pre-filled address from the OTP login profile, and a single prominent "Place Order" button always visible above the fold. Cart abandonment halved within the first two weeks of launch — before any other metric had time to catch up.
The iOS Safari fix was the second biggest revenue mover — and probably the most costly problem to have gone undetected. A zero-error payment failure on the most common iPhone browser, invisible to the owner because it produced no error logs and no customer complaints. We found it in the first 45 minutes of audit.
Trust signals made a quieter but measurable contribution. Adding 34 verified reviews to product pages — collected retroactively from past customers via a simple WhatsApp message — increased the add-to-cart rate on those products by 28% compared to products still without reviews. Making the return policy visible from the cart page reduced drop-off at the final confirmation step.
The speed fix gets customers to the door. The checkout fix gets them through it. The trust signals are why they come back. Miss any one of the three and the other two underperform.
What You Can Steal
You don't need a full rebuild to apply most of what worked here. These five things can be checked and acted on this week — in order of likely impact.
Use your actual phone — not your laptop, not Chrome DevTools. Pick a product, add it to cart, complete the checkout on a real payment. Do it on an iPhone if you have access to one, and on an Android. You will find problems in the first five minutes that no analytics dashboard has ever surfaced. This is the most important thing on this list and the one almost nobody does.
Go to pagespeed.web.dev, run both pages on mobile. If your LCP is over 3 seconds, you are losing customers before they see a single product. The report identifies exactly what's slow — most findings are image-related and fixable without a developer by converting images to WebP and setting explicit width/height attributes.
If your checkout has more than 3–4 meaningful steps on mobile, you're losing buyers at each one. The acceptable minimum for a mobile checkout in 2025: enter phone number, confirm delivery address, pay. Everything beyond that needs a compelling reason to exist.
Not buried in the footer. On the product page, near the "Add to Cart" button — a single line: "Free returns within 7 days." This costs nothing to add and directly addresses the biggest hesitation for first-time buyers who don't know your store yet.
WhatsApp them directly. Keep it simple: "Hi, you ordered [product] last week — would you be willing to leave a quick review on the site? It really helps us." Most will. A product page with 8 honest reviews converts meaningfully better than one with zero, regardless of how good your product photography is.
If you've read this and you're now unsure whether your own checkout has a broken flow on a specific browser — contact us. The first thing we do in every audit is complete a real purchase across 6 device/browser combinations. It's included in the free consultation and takes about 45 minutes.