Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle 🌱
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle 🌱
From product photos to marketplace listings, receipts, and real unit economics.
Independent online sellers do much more than sell products. They write product descriptions, research keywords, manage inventory, process supplier receipts, track expenses, and calculate whether their products are actually profitable.
These tasks are repetitive, time-consuming, and often spread across multiple tools.
I built ListLocal to bring these everyday seller workflows together in one AI-powered application, with a local-first design philosophy.
| 🚀 Live demo | https://list-local.vercel.app |
|---|---|
| 💻 Source code | https://github.com/yansudarshan/ListLocal |
Working screenshots of The Project:
🏠 ListLocal Dashboard — Your AI-Powered Seller Workspace
🖼️ Vision-Powered Listing Generation
🧾 Receipts & Cost Engine
⚔️ Model Arena — Local Vision Model Comparison
🔒 Privacy & Offline Proof
💡 The problem
A small online seller might need to:
- Turn product photos into marketplace-ready listings.
- Write descriptions and search tags for different platforms.
- Extract line items from supplier receipts.
- Separate direct product costs from overhead.
- Calculate unit costs and account for marketplace fees.
- Keep track of product information and terminology.
Each task looks small on its own. Together, they create a lot of operational overhead.
My goal with ListLocal was to connect these workflows into one practical application instead of building another general-purpose chatbot.
🔓 Why Does Local-First AI Matter?
Independent online sellers deal with product photos, supplier receipts, listing descriptions, and profit calculations 📦. These are structured business workflows—not just questions for a chatbot. 💬❌
| 🔒 Cloud-dependent approach | 🌱 Local-first approach (ListLocal) |
|---|---|
| Upload product photos and business documents to an external AI service | Designed with a local-model workflow using Ollama |
| Generate descriptions without clearly separating observations from assumptions | Extract visible product attributes and keep uncertain claims reviewable |
| Process receipts without a transparent cost breakdown | Extract receipt line items and support cost allocation and margin estimates |
| Pay per API call when using metered hosted AI services | Local inference can avoid per-request model API fees when run locally |
| Change AI providers and potentially rewrite integrations | Keep seller workflows in the application while configuring supported local models |
| Treat AI output as the final answer | Keep the seller in control of reviewing and editing listings |
🔐 Privacy: ListLocal includes outbound-request blocking controls and a privacy verification interface. Actual privacy guarantees depend on the deployment, model endpoint, and network paths being tested.
🧾 Business transparency: Receipt line items, direct costs, packaging, labor, and suggested selling prices help sellers understand the assumptions behind their pricing decisions.
🖼️ Evidence-aware AI: A product photo can show color, shape, and texture—but it cannot reliably prove claims such as lead-free glaze, exact firing temperature, or dishwasher safety. ListLocal's workflow is designed to keep those claims reviewable rather than treating guesses as facts.
⚙️ Local model flexibility: The application integrates with Ollama for configured local-model workflows. Its Model Arena provides an interface for comparing vision models, while benchmark results should be interpreted according to whether they come from live runs or demo data.
🚧 Deployment note: The public hosted demo and a local installation are not identical. Mock mode can demonstrate the application workflow without proving live model inference, and local SQLite data does not automatically persist as shared storage on a serverless deployment.
A generic chatbot can write a product description. ListLocal aims to connect product listing generation, receipt processing, and cost-aware pricing into one seller workflow—with more control over data and more visibility into the decisions. 🛍️
🧭 The complete workflow
ListLocal brings together two major workflows:
Product workflow: Upload a product photo → extract attributes → review uncertain claims → generate a listing draft → seller reviews the result.
Financial workflow: Upload a receipt → extract line items → validate arithmetic → classify expenses → calculate product costs and estimate margins.
The seller remains in control of the final information and decisions.
🖼️ 1. Product photo to marketplace listing
Creating a good product listing requires more than identifying an object. Sellers need useful descriptions, relevant tags, and accurate product details.
ListLocal's listing workflow turns product photos and seller-provided information into structured attributes and marketplace-oriented drafts.
How the pipeline works
- Image input: The seller uploads a product photo.
- Attribute extraction: The application extracts useful visual information.
- Claim review: Attributes that cannot be established from the image are treated as uncertain.
- Listing generation: The application prepares a title, description, and relevant tags.
- Seller review: The seller checks and edits the draft before using it.
For example, a terracotta-colored ceramic mug may have visible colors and textures that help describe it.
However, an image alone cannot establish whether its glaze is lead-free, whether it was fired at a particular temperature, or whether it is dishwasher-safe.
That distinction matters. An AI-generated listing should not turn a plausible guess into a product specification.
🧾 2. Receipt scanning and the Cost Engine
Product listings help sellers present their products. Understanding costs helps them make better business decisions.
ListLocal includes a Receipts & Cost Engine workflow designed to process receipt images or PDFs, extract line items, validate totals, classify expenses, and support unit-cost and margin calculations.
Consider a sample receipt containing:
| Item | Amount |
|---|---|
| Honeycomb protective padding | $28.00 |
| Kraft packing tape | $17.00 |
| Total | $45.00 |
The arithmetic is straightforward: $28 + $17 = $45.
The more important part is what happens when the figures do not reconcile. A useful financial workflow should flag discrepancies instead of silently accepting incorrect totals.
Expense allocation also needs care. Packaging overhead and direct product materials may need different allocation rules, and the resulting margin depends on those assumptions and the applicable marketplace fees.
🏗️ 3. Architecture and technology
ListLocal is built around a Next.js application, structured application routes, data persistence, and an integration path for local models.
The repository includes:
- Next.js and TypeScript for the application and its routes.
- SQLite / better-sqlite3 for application data.
- Ollama integration for configured local-model workflows.
- Mock mode for predictable demonstration and workflow testing.
- Vercel for the public hosted demo.
One important distinction: the intended local execution architecture is not identical to every hosted deployment configuration. A local Ollama service is not automatically accessible from Vercel, and local SQLite storage does not automatically become durable shared storage in a serverless environment.
🔒 4. Local-first design and privacy
Seller data can contain sensitive business information, including supplier receipts, product costs, inventory, and unpublished listings.
ListLocal is designed around local-first principles, including a local-model integration path and outbound-request controls.
But privacy is an engineering property that needs to be tested—not simply a label in the UI.
The actual network behavior, model endpoint, file handling, and deployment environment all matter. A privacy dashboard or blocked-request counter alone does not prove that every possible outbound request is prevented.
For that reason, local execution and the hosted demo should be evaluated separately. Mock-mode output demonstrates a workflow, but it is not evidence of fresh model inference.
🧪 5. What I'd show judges
| 🌱 Practical problem | Reducing repetitive work for independent online sellers |
| 🧠 AI workflow | Product-photo attributes and marketplace listing drafts |
| 🧾 Financial workflow | Receipt extraction, arithmetic checks, and expense classification |
| 🛡️ Trust and accuracy | Separating visible features from unverified product claims |
| 🚀 Shipped application | Live demo, GitHub repository, and application interface |
| 🔍 Honest evaluation | Distinguishing seeded fixtures and mock outputs from live model results |
| 🔒 Privacy-aware design | Local-model integration and outbound-request controls, with deployment limitations acknowledged |
The goal is not to claim that every feature is perfect. It is to show a coherent application, demonstrate the workflows that work, and make the limitations clear.
🛠️ 6. Testing the workflows
I use seeded records and sample inputs to exercise the application's major screens.
| Test | What to verify |
|---|---|
| Listing library | Product search and status filters |
| Listing generation | Titles, descriptions, tags, and unsupported claims |
| Receipt extraction | Line items, quantities, and arithmetic |
| Cost allocation | Direct materials, overhead, and unit-cost calculations |
| Glossary | Regional terminology and language selection |
| Model Arena | Historical benchmark records and their labels |
| Privacy controls | Actual outbound behavior in the tested environment |
Seeded benchmark records should be identified as sample data rather than freshly measured model performance. Similarly, mock outputs should not be presented as live AI inference.
🚧 7. Challenges and lessons learned
AI needs boundaries
A visually plausible attribute is not necessarily a verified fact. Separating observations from seller-confirmed specifications is important for reliable product content.
Financial calculations need transparency
Receipt totals, quantities, allocations, fees, and margins should be inspectable. Correct arithmetic is essential, but allocation assumptions must also be clear.
Mock mode is useful—but must be labelled
Deterministic fixtures help test interfaces and demonstrate workflows when model infrastructure is unavailable. They should not be confused with live model results.
Local-first is an architectural commitment
The actual model endpoint, data storage, and network behavior must match the intended privacy properties. Hosted and local deployments can behave differently.
The workflow is the product
An AI model is only one component. Input handling, validation, persistence, useful outputs, and seller review are equally important to the overall experience.
🚀 Try ListLocal
| 🚀 Live demo | https://list-local.vercel.app |
|---|---|
| 💻 GitHub | https://github.com/yansudarshan/ListLocal |
I would especially appreciate feedback on the receipt-to-margin workflow, evidence-aware listing generation, and how to validate local-first privacy guarantees across different deployment environments.
🌱 Final thoughts
With ListLocal, I wanted to explore how AI could help with the everyday operational work behind running an online store—not just generate text, but organize product information, validate business data, and make cost decisions more transparent.
The next steps are to keep improving reliability, test model-backed behavior separately from mock workflows, and make privacy guarantees measurable.
The broader idea is simple: AI should help sellers work smarter without asking them to blindly trust every output.
Top comments (3)
Nice work
Great Build!
Solid work!