LazyRack: A Clothes Shop That Fetches Itself (Gemma, Running Locally)

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Think about the last time you went clothes shopping.

You ask for a kurta in blue and the shopkeeper pulls down six. You want to see the other colour, so he pulls down four more. You try a few on, then ask for a size that turns out to be out of stock. Forty-five minutes later you leave with nothing, and he is standing in a pile of unfolded clothes.

Nobody did anything wrong. It is just a lot of manual work for everybody.

LazyRack takes most of that work away. The shopkeeper sticks a QR code on the counter. The customer scans it with their phone, sees only what is actually in stock, picks a size and colour, and taps Order. A screen in the godown (the storeroom) shows the new order, the assistant brings exactly that piece, and the customer can try it on right there.

The shopkeeper never unfolds a shirt that nobody wanted. The customer never asks for a size that doesn't exist. Both of them get to be a little lazier.

And the laziest part is the setup: the shopkeeper never types a catalogue. He photographs a garment and Gemma fills in the name, category and colour. He only adds the price and how many pieces he has in each size.

Demo

https://1drv.ms/v/c/136E95ECD6A003BB/IQC4cVNEnD-mRZWDqeOI_C-YAb8-WcLxg-VDFlnS-9v4glk?e=Hin8ZI

1. The shopkeeper uploads a photo, Gemma fills in the details

2. The customer scans the QR and sees only what is in stock

3. The godown sees the order the moment it is placed

4. Gemma running locally through Ollama

Code

{ https://github.com/NitinGangwal/LazyRack }

How I Built It

• Gemma 3 (4B), an open-weight model, served locally through Ollama on my own laptop (16 GB RAM, nothing else needed).
• Streamlit for the three screens: shopkeeper, customer and godown.
• SQLite for the catalogue and orders, in a single file.
• A QR code generated by the app that points to the shop's local address. The phone and the laptop only need to be on the same WiFi.

Gemma does two jobs. First, it reads a garment photo and returns the name, category (Men / Women / Kids) and colour as JSON:

resp = ollama.chat(
    model=VISION_MODEL,   # gemma3:4b by default
    messages=[{"role": "user", "content": DESCRIBE_PROMPT,
               "images": [_shrink(image_bytes)]}],
    format="json",
)

Second, it powers the customer's search. A customer can type something like "shaadi ke liye blue kurta", and Gemma reads the catalogue and returns the best matches. Hindi in Roman script works too. If the model is unavailable, the app falls back to a simple keyword search, so the shop never gets stuck.

Stock is reduced the moment an order is placed, so the last piece of a size can never be ordered twice.

I am a third-year student and still learning Python, and I built this with an AI coding assistant helping me write the code. I ran, tested and debugged everything myself on my own laptop.

Why Does Open Innovation Matter?

A small shop is exactly where a closed API is a bad fit.

• The shop's data stays in the shop. Product photos, prices and stock live in a file on the shopkeeper's own laptop. Nothing is sent to someone else's server.
• It costs nothing to run. There is no per-photo or per-search fee. A shopkeeper who adds 200 items pays the same as one who adds 2: nothing. With a paid vision API, the shop with the biggest catalogue would pay the most.
• The AI doesn't need the internet. The model and the app run on the shop's own WiFi, so a dropped connection doesn't stop the shop.
• I can swap the model with one line. If a shop has a stronger laptop, setting VISION_MODEL=gemma3:12b gives better results without changing any code. With a closed API, that choice isn't mine to make.

The Lazy Payoff

I haven't put this in a real shop yet, so I am not going to invent a "saves X hours a week" number. Here is what I actually measured:

• I added more than 20 clothes across Men, Women and Kids, using photos of clothes at my home and professional product photos from the internet.
• Gemma got every category, name and colour right, on both the messy home photos and the clean product photos.
• The first photo took about 40 seconds because the model had to load into memory. Every photo after that took about 15 to 20 seconds. The shopkeeper can keep working while it runs, so cataloguing one item means taking a photo, then adding the price and stock.
• The full flow worked end to end: scan the QR, pick a size, place the order, and the godown sees it.

One honest limitation: once, when I searched for "shirt under 500", a shirt priced at 600 also showed up. On the next attempt it was correct, and it stayed correct for the rest of my testing. The reason is that the model reasons over the catalogue in a prompt, it doesn't run a strict price filter. My next step is to read the price limit in plain code and use Gemma only for the fuzzy part (style, occasion, colour).

The same idea fits shoe stores, malls and even restaurants, anywhere people browse a physical catalogue and someone fetches things for them.

Prize Categories

Best Use of Gemma: Gemma 3 (4B) runs locally through Ollama and does the photo cataloguing and the customer search. Swapping in a larger Gemma is a one-line change.