I was a regular Swiggy user until I noticed a pattern that kept frustrating me: every time I tried to compare menus across two restaurants — something I do almost every time I order — Swiggy would wipe my existing cart the moment I added an item from a different restaurant.
This happened to me enough times that I eventually switched to Zomato as my default app. It was only after making that switch that I realised: Zomato lets you maintain separate carts across restaurants while browsing. It felt obvious. Why didn't Swiggy do the same?
"I didn't discover this problem in a spreadsheet. I discovered it because I was a real user who got frustrated and left. That's the most honest signal a product team can get."
Swiggy is one of India's two dominant food delivery platforms, operating in 500+ cities with millions of daily active users. Its core value proposition is speed, variety, and convenience — helping users discover restaurants, place orders, and receive food with real-time tracking.
In a market where Swiggy and Zomato are near-identical in pricing and restaurant selection, user experience is the primary differentiator. Small friction points compound into platform switching behaviour — exactly what happened in my case.
Swiggy currently allows users to maintain a cart from only one restaurant at a time. When a user adds an item from a second restaurant, a modal appears asking them to clear their existing cart. The user must either abandon their current selection or abandon exploration of the new restaurant.
This creates a forced decision at the worst possible moment — mid-browse, when the user is still in discovery mode and hasn't yet committed to any restaurant.
The core issue: Swiggy conflates the browsing phase with the checkout phase. These are two fundamentally different user states, and the cart system treats them as one.
The result is added cognitive load — users must now mentally track what they wanted from Restaurant A while exploring Restaurant B. For indecisive users (a very common type in food ordering), this is genuinely exhausting and pushes them toward the path of least resistance: a competitor app.
I spoke with 8 regular food delivery users in my network — friends and family, aged 18–45 — about their cart experience on Swiggy. The findings were consistent.
Zomato addresses this problem by maintaining separate, persistent carts for each restaurant a user interacts with. Users can freely browse and add items across multiple restaurants, then choose which cart to checkout from at the end.
| Feature | Swiggy | Zomato |
|---|---|---|
| Multi-restaurant cart retention | ✗ Not supported | ✓ Supported |
| Cart persistence during browsing | ✗ Cleared on switch | ✓ Saved per restaurant |
| Side-by-side comparison possible | ✗ Manual memory required | ✓ Naturally supported |
| Friction at restaurant switch | ✗ Forced modal / decision | ✓ Seamless |
| Operational complexity | ✓ Simple | ~ Slightly higher |
Notably, Zomato's approach does not compromise their operational model — checkout still happens from one restaurant at a time. The multi-cart feature only affects the browsing experience, not the order fulfilment layer.
Introduce a "Saved Selections" layer that sits between the browsing phase and the checkout phase. Users can temporarily hold items from up to 2 restaurants simultaneously while browsing, then choose one cart to proceed to checkout — keeping Swiggy's single-restaurant fulfilment model intact.
Browse & Save Freely
User adds items from Restaurant A. A persistent cart tray appears at the bottom. When they navigate to Restaurant B, instead of a destructive "clear cart" modal, Swiggy saves Restaurant A's items silently and starts a new tray for Restaurant B.
Compare Saved Selections
A "My Selections" tab shows both saved carts side by side — items, prices, estimated delivery time. User can edit either cart freely without losing the other.
Choose & Checkout
When ready, user taps "Order from [Restaurant Name]" on their preferred cart. The other cart is cleared. Checkout proceeds exactly as it does today — no operational changes required.
Cap at 2 Restaurants
To avoid overwhelming the user, limit saved carts to 2 restaurants at a time. If a third is added, prompt the user to remove one existing selection first.
A successful rollout would be measured across three dimensions — user behaviour, satisfaction, and competitive retention.
Cart Abandonment Rate
Target: 15–20% reduction in mid-browse cart abandonment within 60 days of launch
Time-to-Order
Track whether decision time decreases — users who compare should order faster with less friction
App Store Rating
Monitor review sentiment around cart and browsing experience post-launch
Session-to-Order Conversion
% of browsing sessions that result in a completed order — key indicator of reduced drop-off
Risk
Users feel overwhelmed managing two saved carts simultaneously, leading to decision paralysis rather than faster ordering.
Mitigation
Cap at 2 carts. Design the comparison UI to be clean and minimal — one clear "Order from X" CTA per cart, no clutter.
Risk
Engineering complexity of maintaining parallel cart states could delay rollout or introduce bugs at checkout.
Mitigation
Phase the rollout — A/B test with 10% of users in 2–3 cities first. Checkout flow remains unchanged, reducing backend risk.
Risk
Saved carts from a previous session may show outdated prices or unavailable items, causing user confusion.
Mitigation
Set cart expiry at 2 hours. Show a clear "prices may have changed" warning when a saved cart is resumed after a gap.
This is not a complex feature. The technical lift is moderate, the UX pattern already exists on a competitor, and user demand is clear. What makes this worth studying is what it reveals about product philosophy:
Swiggy built their cart for operational simplicity. Zomato built theirs for user behaviour. In a duopoly where everything else is equal, that difference in philosophy is what drives platform preference — and ultimately, market share.
The multi-cart preview feature isn't just a UX improvement. It's a signal to users that Swiggy understands how people actually make decisions — not how the system wishes they would.