InstaNear
End-to-end product design
Quick Commerce
The Problem
Quick commerce is rewriting the rules.
Local stores are losing — quietly.
Blinkit, Zepto, Swiggy Instamart. These platforms deliver in under 15 minutes from dark stores stocked and managed by the platform. For a corner grocery or neighbourhood pharmacy that's operated for decades, this isn't just competition — it's an existential threat.
But local stores carry what dark stores don't - regional brands, loose grains, specialty items, the trusted shop that knows your name. The problem isn't the product — it's the absence of digital infrastructure.
The goal wasn't to out-Blinkit Blinkit. It was to give local stores the same digital muscle without taking away what makes them irreplaceable.
Research Approach
Secondary research first.
Users to validate direction.
With a lean team and no existing user base to interview, we made a deliberate methodological choice: secondary research to form a strong hypothesis, then structured user validation before over-investing in the wrong direction.
This sequencing mattered. Building for local commerce is emotionally intuitive — it's easy to assume you understand the space because you've lived in it. Secondary research forced us to separate feeling from pattern.
What secondary research surfaced
Design Hypothesis
If we match the UX patterns users already know from Blinkit/Zepto, and layer differentiation into the value model rather than the interaction layer — we maximize adoption while still building something meaningfully different.
Consumer App
Familiar on the surface.
A different model underneath.
The consumer ordering experience was designed to feel immediately legible to anyone who'd used a quick-commerce app. Splash screen, phone login, browsable categories, search, product detail, cart, checkout. No learning curve, no onboarding tutorial required.
The UI language echoed what users already knew — category icons, product cards with MRP and selling price, add-to-cart affordances, order tracking with live status updates. This wasn't a lack of creative ambition; it was a deliberate choice to reduce the cost of switching.
Screen slot · Consumer — Onboarding
Primary Differentiator
Store-first discovery —
not product-first
Unlike quick-commerce apps where a pooled anonymous catalogue serves every order, InstaNear let users browse a curated list of nearby stores — their regular chemist, the electronics shop on the corner, the sweet shop they've visited for years — and order directly from a named vendor. The store had an identity. That was the point.
Pick your store
Intercity ordering
Schedule for later
Smart stock suggestions
Consumer — Onboarding
Why store-first,
not pooled catalogue?
Intercity + scheduled delivery
A regional brand unavailable in the city, a traditional sweet for a festival, a part for an old appliance — ordered from anywhere, delivered on a schedule. No quick-commerce app served this.
Multi-store ordering
When users wanted items from different stores in one session, the app resolved it gracefully — cart management, delivery grouping, and transparent pricing all handled at checkout.
Consumer — Checkout
Smart Suggestion System
When a searched product wasn't available at the user's chosen store, the app surfaced nearby alternatives — other stores stocking the same item. This kept users in the session instead of bouncing, and fed directly into the vendor-side insight engine described in the next section.
Vendor App
Getting a kirana store online
without a tech team.
The vendor app was the harder design problem. The consumer experience had precedent — Blinkit, Zepto had shown the pattern. The vendor operations experience was largely uncharted, and the user was fundamentally different: a shopkeeper managing 500–2,000+ SKUs, often using pen and paper, with little patience for new software.
The design brief was clear: a store had to be able to go live in a single session. If onboarding took more than one sitting, it would fail in the field.
Vendor — Onboarding
Inventory onboarding — designed for the shopkeeper's reality
Vendor — Inventory
The full delivery loop —
one app, zero context-switching
STEp 1
Order receiving
Notification, item breakdown, customer details
Step 2
Accept & pack
Vendor confirms, marks ready for pickup
STEp 3
Partner assigned
Delivery API auto-assigns nearest rider
STEp 4
Live tracking
Shipment tracked end-to-end in app
Step 5
Payment settled
UPI or COD, visible in earnings
Order Management
Standout Feature — Smart Vendor Nudges
Every time a customer searched for a product a store didn't carry, the system logged the miss. Vendors received aggregated weekly nudges: "14 customers searched for Maggi Masala-e-Magic near you this week — consider stocking it." This turned an operational failure state into a growth signal. It wasn't in the original brief — it emerged from thinking hard about what happens when the app can't help a user.
Vendor — Smart Insights
Design Gaps & Reflections
What V1 didn't fully answer —
and should have.
V1 was a strong first cut, but a few gaps stood out in hindsight. The store-picker lacked trust signals — no ratings, reviews, or popularity cues to help new users choose confidently. Cart edge cases like out-of-stock items mid-checkout and multi-store sessions needed explicit design resolution, not just engineering fixes. On the vendor side, the OCR error-correction experience needed more care — a misread product name shouldn't feel like a broken form. We also shipped without a meaningful analytics layer for vendors, and without a shared design system, which led to inconsistencies across both apps in error, empty, and loading states. Accessibility wasn't formally audited either — a real gap given the diverse vendor user base.
Outcome
2 Apps designed end-to-end from research to hi-fi
1 Core differentiator, clearly scoped and executed
Key Learnings
Sometimes a single surface can change how an entire product feels.
This wasn’t just a visual refresh—it helped reset perception at the very first touch.