DukaanAI: Turning Product Photos into Inventory Lists with Open-Source AI

For street-corner grocery stores and small retailers, maintaining a product catalog is a repetitive, tedious chore—name, category, description, price, stock quantity, every field has to be entered by hand. The more products there are, the more painful it gets. A developer ran an experiment around this: what if a shop owner could simply upload a photo of a product and have an inventory record generated automatically? That idea became DukaanAI.

What DukaanAI Does

DukaanAI is an AI-assisted inventory tool built for small retailers and local shop owners. Its core logic is straightforward: upload a product image, AI generates a suggested name, category, and description, the owner confirms or edits them, then fills in the actual price and stock quantity and saves it to the inventory.

The current MVP includes the following features:

• Product image upload
• AI-generated product name, category, and description
• Editable fields for human review
• Manual entry of price and stock
• Inventory search and deletion
• CSV catalog export

The developer emphasizes that the goal of this tool is not to replace the shop owner's judgment, but to reduce repetitive data entry while preserving final decision-making authority. This positioning matters—it shapes the product as an "assistant" rather than an "automation."

Technical Architecture: A Local-First, Open-Source Model Approach

DukaanAI's tech stack reflects a clear orientation: to complete AI inference locally whenever possible.

The frontend is built with React and Vite, while the backend uses Node.js and Express to receive uploaded images. The core AI capability comes from a locally running Gemma 3 4B model, invoked through Ollama. After analyzing the image, the model returns structured JSON containing the suggested product information. Image uploads are handled by Multer, inventory data is initially stored in browser localStorage, and CSV export is implemented in JavaScript.

Full tech stack:

• React + Vite (frontend)
• Node.js + Express (backend)
• Gemma 3 4B via Ollama (AI inference)
• Multer (image upload)
• Browser localStorage (inventory storage)
• JavaScript (CSV export)

Interestingly, the initial version stores inventory in the browser locally, meaning it's a local-first prototype rather than a cloud-based multi-user system. This choice reduces complexity and aligns with a "validate the core value first" mindset.

Gemma 3 4B is part of the family of open-weight multimodal models Google released in 2025, with 4B referring to roughly 4 billion parameters. This model series supports both text and image input and can directly understand and describe images, making it well-suited for tasks like product photo recognition. Compared with large models that often have hundreds of billions of parameters, a 4B-scale model has lower VRAM and compute requirements—it can run on ordinary consumer-grade GPUs and even some high-performance laptops. This is exactly the precondition for local deployment.

Ollama is an open-source tool for running and hosting local large models. It packages model download, quantization, and inference serving into simple command-line and HTTP interfaces, so developers don't have to handle the underlying inference framework themselves. DukaanAI's backend calls Gemma through the local API exposed by Ollama, and the model response returns structured JSON, mapping image understanding results directly to product name, category, and description fields.

localStorage is a key-value local storage mechanism provided by browsers. Data is kept on the user's device and is not sent to the server with requests, with capacity typically around 5MB. For a prototype like DukaanAI, putting inventory data in localStorage means there's no need to set up a database or handle user authentication, and data persists after refreshing or reopening the browser—but it becomes inaccessible when switching devices or browsers. It's the lowest-cost storage approach during the stage of validating a product hypothesis; once multi-device sync or multi-user collaboration is needed, migration to a cloud database becomes necessary.

Why Choose an Open-Weight Model

The developer explicitly explained in the article why he chose an open-weight model like Gemma: for products aimed at small businesses, the cost and control of AI inference are critical.

By running Gemma through Ollama, the model can run locally on compatible hardware. Product image analysis doesn't need to be sent to a third-party hosted AI API. This approach also lets the developer freely experiment with prompts, evaluate different models, and build workflows around specific use cases.

This choice comes with trade-offs. Local inference requires the shop owner to have suitable hardware, inference speed may be slower than a hosted service, and the information generated by the model may be inaccurate. That's precisely why the app requires users to review AI suggestions before saving. This is an honest response to the limitations of local inference and a necessary compromise in product design.

An open-weight model refers to an AI model whose parameter files are publicly released and can be freely downloaded and deployed locally, as opposed to closed-source models that can only be called remotely through a vendor's API. Open-weight does not equal fully open source—training data and code may not be disclosed—but usage and deployment rights are usually fairly permissive. For products aimed at small merchants, the significance of open weights is that inference costs are borne by local hardware rather than billed by usage volume, business data such as product images doesn't need to leave the shop's devices, and developers can fine-tune or switch models themselves without being locked into a single vendor.

A hosted AI API refers to a model inference interface provided by a third-party cloud provider, where users pay by number of calls or token count. Its advantages are no local hardware needed, fast responses, and usually stronger model capabilities, but the cost is that every image must be uploaded to an external server, creating ongoing expenses and data privacy concerns. For a small shop that may need to enter dozens or even hundreds of products a day, per-call billing grows linearly with scale, while the marginal cost of local inference is close to zero. This is the core trade-off behind DukaanAI's decision to choose a local solution over a hosted API.

Lessons from the Project

The developer says the process of building DukaanAI taught him how to integrate a user interface, backend APIs, image processing pipelines, and open-weight AI models into a practical application.

More importantly, there's a product-level lesson: generating text is only part of the solution. The app must fit the shop owner's existing workflow and produce results that are accurate enough to be genuinely useful. This insight points to the core challenge of deploying AI applications—technical feasibility does not equal product usability.

Business Potential and Next Steps

DukaanAI's initial target users are independent grocery stores and small retailers that need a simple way to create product catalogs.

The developer plans to validate whether the tool truly saves time by testing it with local shop owners. Specific steps include comparing the efficiency of manual entry versus AI-assisted entry, gathering feedback on accuracy, and asking users whether they'd be willing to pay for a more complete version. A possible business model is a monthly subscription, but willingness to pay needs to be validated before pricing.

Future improvement directions include cloud sync, shop accounts, barcode support, low-stock alerts, and integration with existing point-of-sale systems.

Implications for Bringing AI Tools to Small Merchants

DukaanAI's value lies not just in being a working prototype, but in demonstrating a pragmatic approach to AI applications:

Local inference lowers the barrier. For small merchants, sending every product image to a cloud API means ongoing costs and privacy concerns. Running an open-source model locally sacrifices speed, but gains cost predictability and keeps data on-premises.

Human-AI collaboration rather than full automation. Letting AI generate suggestions and letting a human confirm them acknowledges the current imperfections of models while preserving room for efficiency gains.

Validate first, then expand. From localStorage storage to single-machine deployment, every step of this MVP controls complexity and focuses resources on validating the core hypothesis—whether photos can be effectively turned into inventory records.

If you run a small retail business, the developer's question is worth considering: can generating a product catalog from photos save you time? What else would you need before actually using a tool like this?

One-line Summary

DukaanAI uses a local Gemma model to turn product photos into inventory records, validating the feasibility of AI-assisted entry for small merchants.

Paragraph Summary

DukaanAI is an AI-assisted inventory tool prototype for street-corner grocery stores and small retailers. The shop owner uploads a product photo, a locally running Gemma 3 4B model invoked through Ollama generates suggested product name, category, and description, and after confirmation or edits the owner adds price and stock to save it to inventory. The tech stack is a React + Vite frontend, a Node.js + Express backend, Multer for image uploads, browser localStorage for temporary inventory storage, and CSV export support. The project deliberately chooses an open-weight model to control inference costs and keep data local, but must accept compromises in hardware requirements, inference speed, and accuracy. The product is positioned as an assistant rather than a replacement for the shop owner's judgment, and the next step is to validate time savings and willingness to pay through testing with real shop owners.