Lookup: solving product catalog creation for offline retailers
A hardware-led case study from Shopgro: how Lookup evolved from a grocery marketplace idea into a barcode-driven catalog capture system, pilots, grants, and hard-earned startup lessons.
Overview
Lookup was the hardware-led product we built inside Shopgro to help independent grocery stores in India get online.
Shopgro started as an attempt to help independent grocery stores in India get online.
The original idea was straightforward: give retailers a mobile app to catalog products, keep inventory updated, and receive orders from nearby consumers. The deeper problem revealed itself quickly. Getting online was not mainly a marketplace or payments problem. It was a catalog creation problem.
Retailers would only benefit from digital orders after they had done a large amount of manual setup work. Most of them never got far enough to see that value. That insight forced the product to evolve from an app-led workflow into a hardware-assisted catalog capture system.
The Initial Bet
Back in 2014, smartphones were becoming mainstream in India. That shift made it feel possible to build a B2B marketplace for neighborhood grocers before larger platforms had fully occupied the space.
The first version of the startup focused on two simple surfaces:
- A retailer app to catalog products and maintain inventory
- A consumer app to browse, order, and pay
The strategy for distribution was pragmatic. We partnered with a large P&G distributor in Chennai whose field reps already visited thousands of stores every week. Those reps introduced the app, helped with onboarding, and created the initial push.
That gave us distribution quickly.
The First Signal
The go-to-market motion worked far better than the product.
In a short window we signed up roughly 1,000 stores, but usage collapsed within a few weeks. Adoption fell close to zero.
The failure was not subtle. Stores were willing to register, but very few were willing to do the repeated manual work needed to build a usable catalog.
The Real Problem
The core issue was incentive timing.
Retailers had to invest effort upfront before they saw any return. Cataloging inventory was tedious, repetitive, and disconnected from immediate business value. There was no instant gratification, no external enforcement, and no reason to keep doing the work once the onboarding push ended.
That changed how we framed the startup:
- The app was not the product bottleneck
- Catalog capture was the product bottleneck
- Without solving catalog capture, the marketplace could not get off the ground
The Pivot in Thinking
Once we stopped treating cataloging as a user-behavior problem, a more interesting question appeared:
If stores already scan products all day during billing, can that behavior become the catalog engine?
Most retailers were already using barcode scanners or billing machines as part of normal checkout. That meant product information was flowing through an existing workflow. Instead of asking retailers to enter products manually, we looked for a way to observe what was already being scanned.
We explored two directions:
- Integrate with POS software directly
- Intercept barcode scanner output outside the POS stack
Direct POS integration was unattractive. The market was fragmented, vendors were inconsistent, and many stores ran unsupported or cracked installations. The more scalable path was to stay POS-agnostic and build around the barcode scanner itself.
The Hardware-Led Solution
During research we discovered Pointy in the US, which had built a patented product around intercepting scanner logs before they reached the POS. That validated the shape of the opportunity even if we had to find our own path through the problem.
Through my network I found a hardware engineer and we built a proof of concept using an off-the-shelf hardware kit, while concentrating most of the innovation in software.
The core idea was:
- Sit between the barcode scanner and the POS
- Capture the scan stream
- Send the product events to the cloud
- Use those events to build the catalog and later reason about inventory
The prototype worked. That proof of feasibility led to early recognition and non-dilutive support:
- $50,000 government grant
- A $10,000 award
The First Pilot
We ran a pilot across 20 stores in Bangalore to validate reliability and operational behavior in real environments.
The encouraging part: the system worked. The hardware held up, the scanner interception worked, and the product data flow was viable in live stores.
The Next Layer of Ambition
Once the scanner pipeline was working, the business case expanded.
This was no longer just about helping stores build catalogs. The same stream of scan activity could potentially support:
- Live product catalog creation
- Better inventory visibility
- Merchant-side operating tools
- Market data and analytics for brands or research players
That vision helped us raise another $80,000 through the Startup India initiative.
The Cost Problem
The next major barrier was cost.
The early hardware version cost around $150 per unit once assembled and packaged. That price made the product unrealistic for mass retailer adoption. Stores were not willing to pay for a device whose value still felt indirect.
So we treated cost reduction as a product problem, not just an engineering problem. We reduced the system aggressively:
- Replaced GSM with Bluetooth and used the retailer’s phone connection for sync
- Removed extra power components
- Shrunk the form factor by roughly 5x
- Drove unit cost to below $10
That made the system much more commercially plausible.
The Second Pilot
We ran another pilot with more than 100 stores and achieved clean, dependable data streaming.
At that point the system was doing what it was designed to do. The technical path had become much stronger than the original app-only approach.
Why It Still Failed
The startup still did not become a durable business.
The problem moved from invention to operations. Retailers unplugged devices, turned off Bluetooth, and created frequent edge cases in day-to-day use. The system could work, but keeping it working consistently across a fragmented retail environment was much harder than building the core technology.
The shutdown eventually happened during COVID, but the deeper truth was visible earlier: the solution was technically novel, but the business still depended on behavior change and operational discipline from merchants who did not intrinsically want hardware.
Key Takeaways from Lookup
Build around what people already want
Retailers wanted more business and consumers wanted convenience. The hardware only mattered if it made that value easier to capture.
Value creation is not the same as value realization
We could create value in theory, but struggled to make it obvious, attributable, and immediate for merchants.
The hard part is usually not the first thing you build
The device was difficult but manageable. The real challenge was building repeatable distribution, merchant behavior, and operations.
Novel technology does not remove go-to-market friction
Awards, grants, and technical breakthroughs did not remove habit change, retention, or commercial pull as the real bottlenecks.
Truth-seeking matters more than momentum theater
The best learning came from looking directly at where usage collapsed and what problem the product was truly failing to solve.
Talk to more people, earlier
More conversations with merchants, partners, and skeptics would have sharpened both product framing and commercial strategy sooner.
Closing Thought
Lookup did not become the enduring business we originally imagined. But it forced a much more useful product instinct: when adoption stalls, look for the hidden prerequisite work users are being asked to do.
In this case, the hidden work was catalog creation. Everything interesting followed from finally seeing that clearly.
| Times of India | Device helps local stores stave off e-commerce sites |
| Elevate 2019 | Karnataka government grant winners |
| Startup India | Deshpande Startups |