Problem
What made this hard
Each service uses different product names, pack sizes, prices, stock, fees, and delivery promises. Rebuilding the same cart makes the comparison slow while a cheap item can still produce an expensive or incomplete order.
Consumer product · Mobile · 2025
Compare the whole basket, not one tempting price.

Problem
Each service uses different product names, pack sizes, prices, stock, fees, and delivery promises. Rebuilding the same cart makes the comparison slow while a cheap item can still produce an expensive or incomplete order.
Outcome
An Android concept that turns text, voice, or a photographed list into comparable baskets, then explains the tradeoff between total cost, exact matches, substitutes, missing items, and delivery time.
The thesis
Case-study proof
Enough context to judge the choice, inspect the work, and separate evidence from ambition.
Why this, not that
I designed around the complete basket instead of highlighting the cheapest individual item. Item-level comparison ignores fees, unavailable products, substitutions, pack sizes, and delivery time—the factors that decide whether a basket is actually better.
Why this case is specific
The model is rooted in Indian quick commerce: rupee totals, Blinkit/Zepto/Instamart-style trade-offs, inconsistent pack sizes, regional-language input, and shoppers choosing between savings, speed, and exact matches.
What you can inspect
Interactive Android prototype · static page evidenceThe project includes an interactive Android prototype; this portfolio page currently presents representative static interface frames and the underlying decision model rather than embedding a live commerce experience.
Decision to outcome
The basket model produced three explainable recommendations—lowest complete total, fastest viable delivery, and most exact matches. It remains an independent concept, so user trust, data access, and switching behaviour are validation questions, not outcomes.
Interface evidence
01 / Opportunity
The research framing focuses on people who regularly use more than one quick commerce service. Their current journey involves repeating searches, resolving inconsistent names, checking stock, and calculating the final value by hand. The estimated ten to twenty minute comparison time is a hypothesis to validate, not a measured product outcome.
02 / Audience
Working professionals and families may optimise for time. Students and budget conscious households may prioritise the final total. Homemakers, senior citizens, and regional language users add accessibility, familiarity, and input needs that a simple price table would miss.
03 / Input
A shopper can type, speak, paste, or photograph a list. SmartGrocery then converts rough intent into structured items before asking the person to resolve uncertain matches.
04 / Intelligence
Milk, one litre and a platform specific product title may describe the same need. The system has to compare category, brand preference, quantity, unit, pack size, and substitution tolerance without pretending that every match is equal.
05 / Decision
The comparison separates product total, fees, availability, substitutions, and delivery time. Instead of naming one universal winner, the interface can recommend the lowest complete total, the fastest viable delivery, or the basket with the most exact matches.
06 / Scope
The concept concentrates on list capture, product matching, and basket comparison. Pantry management, nutrition guidance, budgeting insights, and meal planning remain future possibilities and are not presented as current product capability.
07 / Feasibility
The experience depends on current prices, inventory, fees, delivery estimates, and platform access. API availability, rapid price changes, product naming inconsistency, inventory synchronisation, platform policy, and aggregation rules can determine whether the concept is trustworthy enough to launch.
08 / Validation
The next research round should verify the current journey estimate, observe how people judge substitutes, and measure whether savings or speed justify switching services. Data access needs technical validation in parallel. Affiliate revenue, premium planning tools, clearly labelled sponsorship, and privacy preserving insights remain business model hypotheses.
Supporting evidence
Bring me the difficult part.
Complex workflows, AI trust, and enterprise systems.
Discuss a product challenge